To our knowledge, the authors from Arista are not aware of any relevant
undisclosed IPRs that apply to this draft document.
Thank you
On Wed, Sep 22, 2021 at 3:04 AM Ajay Kini wrote:
> I support adoption of this draft as a co-author.
>
> On Tue, Sep 21, 2021 at 2:10 PM Akshay Gattani wrote:
>
Hello Jorge
Again many thanks for your review and comments.
I submitted 01 to cover this. Please have a look at the diffs in
https://www.ietf.org/rfcdiff?url2=draft-thubert-bess-secure-evpn-mac-signaling-01.txt
Keep safe;
Pascal
From: Rabadan, Jorge (Nokia - US/Mountain View)
Sent: jeudi 11 n
Hi again,
John pointed to me that there are some cases where a non-zero Ethernet Tag ID
on the IP Prefix route may be used in RFC9136.
In the RFC9136 IP-VRF-to-IP-VRF use cases, the Ethernet Tag ID is always zero,
since the IP Prefix route is advertised in the context of the IP-VRF. However
it
Hi Jorge,
>>> IP Prefix route is advertised in the context of a BD,
Is this a case wherein MAC/IP (RT-2) published with L2/L3-VNIS is further
relayed as only RT-5.
For example, PE2 receives RT-2 from PE1 for host1's MAC1/IP1.
PE2 relays only Host-route (IP1/32) via RT-5 to PE3. Is
Host1(MAC1/IP1
Hi Jorge and Vinayak,
I don't understand this use case of RFC9136 very well either,
because when a BD of VLAN-aware bundle EVI is used in Bump-in-the-wire use case,
I don't sure how the IP prefixes routes are recursively rosolved.
I hope to share my understandings to help to make this
