eVPN Type 0 RDs [was Re: evpn rebase to HEAD]

[Pim van Pelt]

(starting a new thread)
Hoi Bird eVPNers!

I spent some time with RFC4364 and RFC7432 today. I want to revisit the 
IMET key and make a case for changing it from RD to hash{RD,etag,rtr}.

Referencing RFC4363 section 4.2, there are three types of RD:
Type 0: 16 bit ASN, 32 bit sequence (eg 8298:123456) -- not necessarily 
unique in eVPN if same seq is chosen
Type 1: 32 bit IP, 16 bit sequence (eg 192.0.2.1:123) -- unique in eVPN 
due to use of PE router-id
Type 2: 32 bit ASN, 16 bit sequence (eg 829800:123) -- not necessarily 
unique in eVPN if same seq is chosen

Referencing RFC7432, notably section 7.3:

    For procedures and usage of this route, please see Sections11 <https://datatracker.ietf.org/doc/html/rfc7432#section-11>
    ("Handling of Multi-destination Traffic"), 12 ("Processing of Unknown
    Unicast Packets"), and 16 ("Multicast and Broadcast").  The IP
    address length is in bits.  For the purpose of BGP route key
    processing, only the Ethernet Tag ID, IP Address Length, and
    Originating Router's IP Address fields are considered to be part of
    the prefix in the NLRI.

The route key for IMET is {etag,iplen,rtr} so the current code, using 
RD, will not work for Type 2 or Type 0 RDs like the ones from Nokia I 
showed below. It will work for Type 1 RDs because there the RD encodes a 
unique IP.

Maybe we can consider rte_src to be something like:
u64 imet_key = u64_hash0(rd_to_u64(n0->rd), HASH_PARAM,
   u32_hash0(n0->tag, HASH_PARAM,
   ip6_hash0(n0->rtr, HASH_PARAM, 0)));

A strictly RFC-conformant key for the stated purpose of IMET uniqueness 
would be {etag, rtr} (with iplen implicit in rtr), but perhaps 
{rd,etag,rtr} is a safe superset with defense in depth. Either choice 
would allow Type 0 (and Type 2) RDs to work in Bird and also in inter-op 
cases with vendors, and it would have no impact to Type 1 RDs.

groet,
Pim

On 11.03.2026 10:06, Pim van Pelt wrote:
> Hoi,
>
> On 11.03.2026 08:41, Ondrej Zajicek wrote:
>> I think it is because you have the same route distinguisher 8298:200 
>> on all these routers. If i understand it correctly, each router 
>> should use different RD (while they use the same route target (RT) if 
>> they are in the same VPN).
> I interpreted RFC 7432, Section 7.9 differently
> "An RD MUST be assigned for a given MAC-VRF on a PE. *This RD MUST be 
> unique across all MAC-VRFs on a PE*. It is RECOMMENDED to use the Type 
> 1 RD [RFC4364]. The value field comprises an IP address of the PE 
> (typically, the loopback address) followed by a number unique to the PE."
>
> (emphasis mine) While the RFC mandates uniqueness only within a single 
> PE (across its MAC-VRFs), it als recommends Type 1 RDs using the PE's 
> loopback IP, which happens to produce globally unique RDs across the 
> network.
>
> I was further thrown off because on a set of Nokia SR-Linux routers 
> that run an eVPN VxLAN mesh, the RDs are indeed the same:
> A:pim at asw120# info flat / network-instance peeringlan protocols 
> bgp-vpn bgp-instance 1
> set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 
> route-distinguisher rd 65500:2604
> set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 
> route-target export-rt target:65500:2604
> set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 
> route-target import-rt target:65500:2604
>
> A:pim at asw100# info flat / network-instance peeringlan protocols 
> bgp-vpn bgp-instance 1
> set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 
> route-distinguisher rd 65500:2604
> set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 
> route-target export-rt target:65500:2604
> set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 
> route-target import-rt target:65500:2604
> which is why I would've assumed adding multiple Bird2's with RD 
> 65500:2604 would be the idiomatic way to do this.
>
> However the important bits are that (a) I can now rely on etab having 
> the multiple IMETs as you said, so I can simplify my vppevpn protocol 
> to rely only on etab, and not evpntab; and (b) I learned a lot :) 
> Thank you so much!
>
> groet,
> Pim
> -- 
> Pim van Pelt <pim at ipng.ch>
> PBVP1-RIPE https://ipng.ch/
>

-- 
Pim van Pelt<pim at ipng.ch>
PBVP1-RIPEhttps://ipng.ch/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260313/d0348dd7/attachment.htm>