Jorge, Jeffrey and all,
I have re-read Section 4.1 of RFC
9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.1>, 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).
(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://datatracker.ietf.org/doc/html/rfc7432#section-6.3>, 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
* Share the same set of Route Targets
* 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.
1. 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:
* 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
* NVE2 would identify BD-10 as the context for lookup of the destination
MAC address based on both the “application” label and inner VID.
Hopefully these notes will be useful.
Regards,
Sasha
From: Jeffrey (Zhaohui) Zhang <[email protected]>
Sent: Thursday, June 5, 2025 7:43 PM
To: Alexander Vainshtein <[email protected]>; Jorge Rabadan (Nokia)
<[email protected]>
Cc: [email protected]
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
<[email protected]<mailto:[email protected]>>
Sent: Thursday, June 5, 2025 10:47 AM
To: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Jeffrey (Zhaohui) Zhang
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>>
Sent: Thursday, June 5, 2025 4:15:39 PM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>; Jeffrey
(Zhaohui) Zhang <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>
Date: Wednesday, June 4, 2025 at 11:54 PM
To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>>
Sent: Thursday, June 5, 2025 12:40 AM
To: [email protected]<mailto:[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
