Jeffrey, Lots of thanks for your email.
In this email I will try to address just one of your comments, namely your question “what the scenario for is “NVE2/NVE3 could OPTIONALLY advertise the same Label in the Label1 field for all the BDs in the EVI in question”. This option is explicitly defined in Section 6.3 of RFC 7432<https://datatracker.ietf.org/doc/html/rfc7432#section-6.3> “VLAN-Aware Bundle Service Interface” that says (the relevant text is highlighted): In the case where a single VLAN is represented by a single VID and thus no VID translation is required, an MPLS-encapsulated packet MUST carry that VID. The Ethernet Tag ID in all EVPN routes MUST be set to that VID. The advertising PE MAY advertise the MPLS Label1 in the MAC/IP Advertisement route representing ONLY the EVI or representing both the Ethernet Tag ID and the EVI. This decision is only a local matter by the advertising PE (which is also the disposition PE) and doesn't affect any other PEs The corresponding section in 7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-12#section-6.3> RECOMMENDS difference behavior but preserves this option (again, the relevant text is highlighted): In the case where a single VLAN is represented by a single VID and thus no VID translation is required for the operational duration of that VLAN , an MPLS-encapsulated packet MUST carry that VID and the Ethernet Tag ID in all EVPN routes advertised for this BD MUST be set to that VID. The advertising PE SHOULD advertise the MPLS Label in the Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1 in the MAC/IP Advertisement routes representing both the Ethernet Tag ID and the EVI but MAY advertise the labels representing ONLY the EVI. This decision is only a local matter by the advertising PE which is also the disposition PE) and doesn't affect any other PEs. I am aware of at least two implementations that follow the highlighted option. This option has implications for the data plane behavior for Asymmetric IRB, and I have recently filed a corresponding Erratum<https://www.rfc-editor.org/errata/eid8375> for the gap in the definitions of RFC 9135. I will try address your other comments in a separate email. Regards, Sasha From: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> Sent: Tuesday, June 10, 2025 3:33 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org> Cc: bess@ietf.org Subject: [EXTERNAL] RE: Ethernet Tag ID in EVPN type-5 routes Hi Sasha, Please see zzh> below for my understanding: Juniper Business Use Only From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Sent: Sunday, June 8, 2025 12:23 AM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> Subject: RE: Ethernet Tag ID in EVPN type-5 routes Importance: High [External Email. Be cautious of content] Jorge, Jeffrey and all, I have re-read Section 4.1 of RFC 9136<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9136*section-4.1__;Iw!!NEt6yMaO-gk!Ecc4g6lsoN7uIpj7urT2aDq9gqzGldu4nGpzPlmmcVTRcfUrFDjMCnScXCA9X9WGstqrZRIWqDOYKtBBiF90OpSoON0$>, and it seems that that it is inaccurate in the case of EVI that implement VLAN-aware Bundle service interface. I am copying parts of this section below with the problematic fragments highlighted. IP4---+ NVE2 DGW1 | +-----------+ +---------+ +-------------+ SN2---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | M2/IP2 +-----------+ | | | IRB1\ | -+---+ | | | (IP-VRF)|---+ | | | +-------------+ _|_ SN1 | VXLAN/ | ( ) | | GENEVE | DGW2 ( WAN ) -+---+ NVE3 | | +-------------+ (___) | M3/IP3 +-----------+ | |----| (BD-10) | | SN3---TS3(VA)--| (BD-10) |-| | | IRB2\ | | | +-----------+ +---------+ | (IP-VRF)|---+ IP5---+ +-------------+ … DGW1 and DGW2 import both received routes based on the Route Targets: · Based on the BD-10 Route Target in DGW1 and DGW2, the MAC/IP Advertisement route is imported, and M2 is added to the BD-10 along with its corresponding tunnel information. For instance, if VXLAN is used, the VTEP will be derived from the MAC/IP Advertisement route BGP next hop and VNI from the MPLS Label1 field. M2/IP2 is added to the ARP table. Similarly, M3 is added to BD-10, and M3/IP3 is added to the ARP table. · Based on the BD-10 Route Target in DGW1 and DGW2, the IP Prefix route is also imported, and SN1/24 is added to the IP-VRF with Overlay Index IP2 pointing at the local BD-10. In this example, it is assumed that the RT-5 from NVE2 is preferred over the RT-5 from NVE3. If both routes were equally preferable and ECMP enabled, SN1/24 would also be added to the routing table with Overlay Index IP3. (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: · A destination IP lookup is performed on the DGW1 IP-VRF table, and Overlay Index = IP2 is found. Since IP2 is an Overlay Index, a recursive route resolution is required for IP2. · IP2 is resolved to M2 in the ARP table, and M2 is resolved to the tunnel information given by the BD FIB (e.g., remote VTEP and VNI for the VXLAN case) · The IP packet destined to IPx is encapsulated with: o Inner source MAC = IRB1 MAC. o Inner destination MAC = M2. o Tunnel information provided by the BD (VNI, VTEP IPs, and MACs for the VXLAN case). Zzh> The tunnel information is from the RT-2, not RT-5. (5) When the packet arrives at NVE2: · Based on the tunnel information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup. · Encapsulation is stripped off and, based on a MAC lookup (assuming MAC forwarding on the egress NVE), the packet is forwarded to TS2, where it will be properly routed. If BD-10 were part of an EVI that implements a VLAN-aware Bundle service interface as defined in Section 6.3 of RFC 7432<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-6.3__;Iw!!NEt6yMaO-gk!Ecc4g6lsoN7uIpj7urT2aDq9gqzGldu4nGpzPlmmcVTRcfUrFDjMCnScXCA9X9WGstqrZRIWqDOYKtBBiF90OMsb3Lg$>, the highlighted parts would be incorrect because: 1. In addition to BD-10, there would be at least one more BD in the EVI in question, and these BDs a. Share the same set of Route Targets b. Would be identified by their respective Ethernet Tag IDs i. In the case of RT-2, usage of the Ethernet Tag ID in its NLRI for identification of BD-10 within the EVI in question seems to be required by RFC-7432 ii. In the case of RT-5 Ethernet Tag ID “MUST be used as defined in RFC 7432 and RFC 8365” – whatever this means. My guess is that if Ethernet Tag ID in the NLRI would be zero, the 7432-compliant implementation would fail to find a matching BD. Zzh> The RT-5 can still have Tag ID 0. The recursive route resolution looks up the overlay index, which is the GW IP address that is already in the VRF, w/o needing to match the BD during the resolution, but encapsulation information associated with the GW IP address is enough for the NVE2 to locate BD-10. 2. In the case of EVPN-MPLS, NVE2/NVE3 could OPTIONALLY advertise the same Label in the Label1 field for all the BDs in the EVI in question. Therefore: a. Ethernet encapsulation of the IP packet received by the IP-VRF in DGW1/DGW2 MUST include an inner VLAN tag with the VID being equal to the Ethernet Tag ID of RT-5 b. NVE2 would identify BD-10 as the context for lookup of the destination MAC address based on both the “application” label and inner VID. Zzh> Again, the key is that GW IP address in the VRF on the ingress PE (DGW1/2) already has enough encapsulation information (learned from the RT-2) for the egress PE (NVE2) to identify the BD-10. The RT-5 does not need provide the Tag ID. Zzh> Additionally, what is the scenario for “NVE2/NVE3 could OPTIONALLY advertise the same Label in the Label1 field for all the BDs in the EVI in question”? This email thread https://mailarchive.ietf.org/arch/msg/bess/cF2WsvEAgkVsPggHuW-vfpXaHXI/<https://mailarchive.ietf.org/arch/msg/bess/cF2WsvEAgkVsPggHuW-vfpXaHXI> touched upon this topic. My understanding is that it is always the label alone that will determine the BT, which is per <mac vrf, BD> in the case of vlan-aware bundle, or per mac vrf in the case of vlan bundle. Zzh> If you’re referring to the first label scheme in the following: A PE may advertise the same single EVPN label for all MAC addresses in a given MAC-VRF. This label assignment is referred to as a per MAC-VRF label assignment. Alternatively, a PE may advertise a unique EVPN label per <MAC-VRF, Ethernet tag> combination. This label assignment is referred to as a per <MAC-VRF, Ethernet tag> label assignment. As a third option, a PE may advertise a unique EVPN label per <ESI, Ethernet tag> combination. This label assignment is referred to as a per <ESI, Ethernet tag> label assignment. As a fourth option, a PE may advertise a unique EVPN label per MAC address. This label assignment is referred to as a per MAC label assignment. All of these label assignment methods have their trade-offs. The choice of a particular label assignment methodology is purely local to the PE that originates the route. Zzh> I suspect it is also just for the vlan-bundle. Perhaps Jorge/Ali can clarify. Zzh> Jeffrey Hopefully these notes will be useful. Regards, Sasha From: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> Sent: Thursday, June 5, 2025 7:43 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> Subject: [EXTERNAL] RE: Ethernet Tag ID in EVPN type-5 routes Ah. I had replied to an older response from Sasha. I believe if the overlay index is a MAC address (or ESI?) from a vlan-aware bundle, then the tag ID needs to identify the BD. Otherwise (e.g., GW IP) there is no need. Jeffrey Juniper Business Use Only From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Sent: Thursday, June 5, 2025 10:47 AM To: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org>; Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> Subject: Re: Ethernet Tag ID in EVPN type-5 routes [External Email. Be cautious of content] Jorge, Lots of thanks for your email. I can easily imagine the case in which different BDs in a VLAN-aware bundle MAC-VRF serve tenant spaces with overlapping ranges of IP addresses. In this case GW IP addresses used in RT-5 would have to be differentiated by Ethernet Tag IDs for recursive resolution. I cannot say if such configurations exist in real deployments, but I definitely can build such a setup in the Lab. IMHO the bottom line is that usage of Ethernet Tag ID in RT-5 is not specified in 9136, and this issue should be addressed if/when somebody starts working on 9136bis😉. Regards, Sasha Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!NEt6yMaO-gk!BJSdDOKU-7j9VNX9Oj1VqypFpOt4412hGJeU7-pnrNDxL0Ndlw0hVZXO-4NR49n4mpRUlPJjMWLWea99Vwgxqd3FeSw$> ________________________________ From: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Sent: Thursday, June 5, 2025 4:15:39 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: [EXTERNAL] Re: Ethernet Tag ID in EVPN type-5 routes Hi Sasha, Jeffrey, I hope you're both doing well. Based on my understanding, there isn't a specification that mandates the use of the Ethernet Tag ID in the IP Prefix route for recursive resolution to a gw-ip or MAC overlay index. When RFC9136 was drafted, the inclusion of the Ethernet Tag ID in the IP Prefix route was primarily for consistency with other route types that advertise reachability for a given tenant. However, the assumptions you've mentioned were never really assumed or written. Regarding recursive resolution to a gw-ip, I believe that the Ethernet Tag ID doesn't add any significant value since the gw-ip is a unique IP within the tenant space. For recursive resolution to a MAC overlay index, I can understand how it might be beneficial if the MAC resides in a VLAN-aware bundle BD. That being said, I haven't come across any implementations similar to what you have described. If such implementations exist, it would be worthwhile to discuss them within this WG. Thanks, Jorge From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>> Date: Wednesday, June 4, 2025 at 11:54 PM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: [bess] Re: Ethernet Tag ID in EVPN type-5 routes CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Jeffrey and all, I think that Ethernet Tag ID in the NLRI RT-5: - Is only relevant if RT-5 in question requires recursive resolution - Is used to identify the specific EVPN route to be used for recursive resolution - Can be non-zero only if advertised by one of the BDs in an EVI that implements VLAN-aware bundling - in which case it identifies the specific BD within this EVI. E.g., if, as per the rules of Table 1 of RFC 9136, the GW IP Address has to be used as the key for recursive resolution of a received RT-5, recursive resolution can only be provided by a received RT-2 for an IP-->MAC pair such that: - IP address in the NLRI of RT-2 matches the GW IP Address in the NLRI of RT-5 - Ethernet Tag ID in the NLRI of RT-2 matches the Ethernet Tag ID of RT-5. The same applies for other cases of recursive resolution. If recursive resolution is not needed, Ethernet Tag ID in the NLRI of an RT-5 can be ignored. Regards, Sasha -----Original Message----- From: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> Sent: Thursday, June 5, 2025 12:40 AM To: bess@ietf.org<mailto:bess@ietf.org> Subject: [bess] Ethernet Tag ID in EVPN type-5 routes Hi, For the Ethernet Tag ID in the type-5 routes, RFC 9136 gives two examples of Tag ID 0 and mentions the following: * The Route Distinguisher (RD) and Ethernet Tag ID MUST be used as defined in [RFC7432] and [RFC8365]. Obviously, RFC7432/8365 won't have text about the tag used in EVPN type-5 routes, so I have the following assumptions: A particular tenant has one IP VRF and one or more EVIs (Mac VRFs) on a PE. In the case of vlan-aware bundle EVI, the Ethernet tag ID identifies a BD, and the mac address in a particular BD can be used as the overlay index for a type-5 route. In this case, the tag id in the type-5 route will be set to the ethernet tag ID that identifies the BD. This also assumes that the type-5 routes (with non-zero tag) are tied to one (of all) vlan-aware EVI, or there are some other means of identifying which vlan-aware EVI will be used together with the ethernet tag ID in the type-5 routes. In particular, a non-zero ethernet tag id will only be used in type-5 routes in the vlan-aware model when the overlay index is a MAC address in a particular BD. Is my understanding correct? Thanks. Jeffrey Juniper Business Use Only 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 -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
