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
