Jorge, Lots of thanks for a prompt response. I will submit an erratum to RFC 9135 along the lines you have suggested.
Regards, Sasha From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Thursday, April 3, 2025 9:45 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Ali Sajassi (sajassi) <saja...@cisco.com>; John Drake <je_drake=40yahoo....@dmarc.ietf.org>; ssa...@cisco.com; Samir Thoria (sthoria) <stho...@cisco.com> Cc: bess@ietf.org Subject: [EXTERNAL] Re: A gap in the DP procedures for Asymmetric IRB? Hi Sasha, I see your point, however, I would have imagined that “OPTIONAL” behavior in which you reuse labels for multiple BDs of the same vlan-aware bundle EVI is rarely seen out there. In fact, RFC8365 does not really allow anything similar for NVO3 tunnels. Personally I would be fine with an RFC9135 erratum as long as it is clearly stated that the issue only affects that vlan-aware bundle option in RFC7432, and not vlan-aware EVIs in RFC8365. But other co-authors will comment too.. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Thursday, April 3, 2025 at 6:54 AM To: Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, John Drake <je_drake=40yahoo....@dmarc.ietf.org<mailto:je_drake=40yahoo....@dmarc.ietf.org>>, ssa...@cisco.com<mailto:ssa...@cisco.com> <ssa...@cisco.com<mailto:ssa...@cisco.com>>, Samir Thoria (sthoria) <stho...@cisco.com<mailto:stho...@cisco.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: A gap in the DP procedures for Asymmetric IRB? 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. Hi all, I think that I have found a gap in the DP Procedures of the ingress PE in the case of an Asymmetric EVPN IRB as defined in Section 6.3 of RFC 9135<https://datatracker.ietf.org/doc/html/rfc9135#section-6.3>. I will refer to Diagram 3 in Section 4 of RFC 9135 that illustrates the notion of Asymmetric IRB (copied below for your convenience). Ingress PE Egress PE +-------------------+ +------------------+ | | | | | +-> IP-VRF -> | | IP-VRF | | | | | | | | BT1 BT2 | | BT3 BT2 | | | | | | | | | | | +--|--->----|--------------+ | | | | | | v | +-------------------+ +----------------|-+ ^ | | | TS1->-+ +->-TS2 The problematic section says (the relevant text is highlighted): When an Ethernet frame is received by an ingress PE (e.g., PE1 in Figure 4<https://datatracker.ietf.org/doc/html/rfc9135#fig-4> above), the PE uses the AC ID (e.g., VLAN ID) to identify the associated MAC-VRF/BT, and it performs a lookup on the destination MAC address. If the MAC address corresponds to its IRB interface MAC address, the ingress PE deduces that the packet must be inter-subnet routed. Hence, the ingress PE performs an IP lookup in the associated IP-VRF table. The lookup identifies a local adjacency to the IRB interface associated with the egress subnet's MAC-VRF/ bridge table. The ingress PE also decrements the TTL / hop limit for that packet by one, and if it reaches zero, the ingress PE discards the packet. The ingress PE gets the destination TS's MAC address for that TS's IP address from its ARP table or NDP cache. It encapsulates the packet with that destination MAC address and a source MAC address corresponding to that IRB interface and sends the packet to its destination subnet MAC-VRF/BT. The destination MAC address lookup in the MAC-VRF/BT results in a BGP next-hop address of the egress PE along with label1 (L2 VPN MPLS label or VNI). The ingress PE encapsulates the packet using the Ethernet NVO tunnel of the choice (e.g., VXLAN or NVGRE) and sends the packet to the egress PE. Because the packet forwarding is between the ingress PE's MAC-VRF/BT and the egress PE's MAC-VRF/ bridge table, the packet encapsulation procedures follow that of [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>] for MPLS and [RFC8365<https://datatracker.ietf.org/doc/html/rfc8365>] for VXLAN encapsulations. Now suppose that: 1. BT-2 in the diagram in question belongs to an EVI that implements VLAN-aware bundle service interface as defined in Section 6.3 of RFC 7432<https://www.rfc-editor.org/rfc/rfc7432.html#section-6.3> 2. PE-2 advertises the same label in EVPN Type 2 routes it advertises for all its BTs in the and uses the VLAN tag in the customer Layer 2 header for identification of the specific BT. This OPTIONAL behavior is allowed, and I am aware of several implementations that follow this scheme. The marked text defines how Destination and Source MAC addresses of the IP packet that undergoes inter-subnet forwarding using an Asymmetric IRB are defined. It does not mention any VLAN tag manipulations. And RFC 7432 explicitly states that any VLAN translation procedures MUST be only implemented by the disposition (egress) PEs. So, depending on implementation of the IRB, the resulting Ethernet frame would either be untagged (if the original VLAN tag is stripped when the packet is ushered for IP forwarding via the IRB) or the VLAN tag in the Layer 2 header of the received Ethernet frame is preserved. In both cases the egress PE will not be able to identify the correct BT where the Destination MAC address should be looked up. One way to address this issue would be for the ingress PE, in addition to pushing Source and Destination MAC addresses on the IP packet that undergoes IP forwarding, to push the “normalized VLAN” corresponding to the BT in question on IP packet. Another possibility is to state explicitly that the BDs of an EVI that implements VLAN-aware bundle service interface that are used as broadcast domains of Asymmetric EVPN IRBs cannot assume that “a single VLAN is represented by a single VID and thus no VID translation is required” and, therefore, per <MAC-VRF, BD> label allocation scheme MUST be used. I wonder if the above should be reported as an Erratum to 9135? 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 -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
