Ali, Neeraj and all,
Lots of thanks for prompt responses and clarifications.
My reading of your responses looks as following:
1. An optimized IRB is a Symmetric EVPN IRB:
* It advertises an RT-2 with the Label2 field present and RTs of both
MAC-VRF and IP-VRF attached for each IP-->MAC pair it locally learns
* The Label2 field carries the label that identifies the IP-VRF that
contains the EVPN IRB in question
2. Traditional Proxy ARP for the subnet of the of this IRB (making it
respond with its own MAC address to ARP requests for any ARP requests to
addresses from its subnet is enabled
3. An dedicated Extended Community is attached to RT-2 mentioned above and
indicating that this route MUST be installed (as a host route) in IB and FIB of
IP-VRF with matching Import RT and in the “RIB” but not in the FDB of the
MAC-VRF with matching Import RT.
If this understanding is correct, I see a minor issue with this draft (the
relevant text is highlighted for clarity):
Section 2.1.1 of the
draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-l3-optimized-irb-00#section-2.1.1>
says that the PE operating in the optimized IRB mode “advertises a MAC/IP
Advertisement route (aka route-type 2) along with a flag (via BGP extended
community) to indicate this mode of operation so that the receiving PE adds the
received MAC address to the L2RIB table but not the L2FIB”. However:
1. AFAIK, no such flag has, so far, been defined in any Extended Community
used in EVPN
2. Section 6 “IANA considerations” of the draft says, “This document
requests no actions from IANA”.
Should be trivial to fix in the next revision of the draft, I think.
My 2c,
Sasha
From: Ali Sajassi (sajassi) <[email protected]>
Sent: Tuesday, November 7, 2023 3:41 AM
To: Neeraj Malhotra <[email protected]>; Ali Sajassi (sajassi)
<[email protected]>
Cc: Alexander Vainshtein <[email protected]>;
[email protected]; [email protected]; Nitsan Dolev
<[email protected]>
Subject: [EXTERNAL] Re: [bess] A question about
draft-sajassi-bess-evpn-l3-optimized-irb
Hi Neeraj,
Exactly! And I mentioned this during my presentation at BESS. It Is also
explicitly described in section 2.1.1 of the draft:
“ Since there is no L2 forwarding, there is no need
for populating L2FIB; however, L2RIB needs to be populated for host
mobility procedures because host mobility in EVPN is based on MAC
mobility which is tracked in L2RIB.”
Cheers,
Ali
From: Neeraj Malhotra <[email protected]<mailto:[email protected]>>
Date: Monday, November 6, 2023 at 4:13 PM
To: Ali Sajassi (sajassi)
<[email protected]<mailto:[email protected]>>
Cc: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
Nitsan Dolev <[email protected]<mailto:[email protected]>>
Subject: Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb
Hi Ali, Sasha,
minor comment in case it wasn't already clear - each PE still learns all MACs
in the control plane (for mobility procedures to work) but only locally
connected MACs are installed in the forwarding plane. Hence the optimization.
Ali, please confirm.
Thanks,
Neeraj
On Mon, Nov 6, 2023 at 11:37 AM Ali Sajassi (sajassi)
<[email protected]<mailto:[email protected]>> wrote:
Hi Sasha,
Each PE only learns local MAC addresses and NOT remote ones. So, lets says you
have a subnet that is stretched across 10 PEs and each PE has 100 locally
connected hosts. So, the total number of MAC addresses for the subnet is 1000
(10X100) but each PE ONLY learns 100 MAC addresses. This is in contrast with
the traditional EVPN-IRB where each PE learns all 1000 MAC addresses.
Cheers,
Ali
From: BESS <[email protected]<mailto:[email protected]>> on behalf of
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Monday, November 6, 2023 at 5:31 AM
To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
Nitsan Dolev <[email protected]<mailto:[email protected]>>
Subject: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb
Hi,
This the question I have tried to ask during the meeting.
The Introduction to draft in
question<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-l3-optimized-irb-00#section-1>
claims “improving MAC scalability of customer bridges and PE devices
significantly”.
The first of these claims is easy to understand: each specific CE switch has to
learn just one MAC address (that of the optimized IRB) in addition to MAC
addresses of its locally attached hosts.
But I have doubts about the second of these claims: to the best of my
understanding, each PE attached to the subnet in question will learn MAC
addresses of all attached hosts in the subnet.
What, if anything, did I miss?
Regards, and lots of thanks in advance,
Sasha
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
