<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
(starting a new thread)<br>
Hoi Bird eVPNers!<br>
<br>
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}.<br>
<br>
Referencing RFC4363 section 4.2, there are three types of RD:<br>
Type 0: 16 bit ASN, 32 bit sequence (eg 8298:123456) -- not
necessarily unique in eVPN if same seq is chosen<br>
Type 1: 32 bit IP, 16 bit sequence (eg 192.0.2.1:123) -- unique in
eVPN due to use of PE router-id<br>
Type 2: 32 bit ASN, 16 bit sequence (eg 829800:123) -- not
necessarily unique in eVPN if same seq is chosen<br>
<br>
Referencing RFC7432, notably section 7.3:
<pre class="newpage"> For procedures and usage of this route, please see Sections <a
href="https://datatracker.ietf.org/doc/html/rfc7432#section-11">11</a>
("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.</pre>
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.<br>
<br>
Maybe we can consider rte_src to be something like:<br>
u64 imet_key = u64_hash0(rd_to_u64(n0->rd), HASH_PARAM,<br>
u32_hash0(n0->tag, HASH_PARAM,
<br>
ip6_hash0(n0->rtr, HASH_PARAM, 0)));
<br>
<br>
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. <br>
<br>
groet,<br>
Pim<br>
<br>
<div class="moz-cite-prefix">On 11.03.2026 10:06, Pim van Pelt
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0864b5ba-ef0b-486a-ae7e-ac94b10bad8f@ipng.ch">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hoi,<br>
<br>
<div class="moz-cite-prefix">On 11.03.2026 08:41, Ondrej Zajicek
wrote:<br>
</div>
<blockquote type="cite" cite="mid:abFjDQBH85hEU9FW@feanor">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).</blockquote>
I interpreted RFC 7432, Section 7.9 differently<br>
"An RD MUST be assigned for a given MAC-VRF on a PE. <b>This RD
MUST be unique across all MAC-VRFs on a PE</b>. 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."<br>
<br>
(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.<br>
<br>
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:<br>
A:pim@asw120# info flat / network-instance peeringlan protocols
bgp-vpn bgp-instance 1<br>
set / network-instance peeringlan protocols bgp-vpn bgp-instance 1
route-distinguisher rd 65500:2604<br>
set / network-instance peeringlan protocols bgp-vpn bgp-instance 1
route-target export-rt target:65500:2604<br>
set / network-instance peeringlan protocols bgp-vpn bgp-instance 1
route-target import-rt target:65500:2604<br>
<br>
A:pim@asw100# info flat / network-instance peeringlan protocols
bgp-vpn bgp-instance 1<br>
set / network-instance peeringlan protocols bgp-vpn bgp-instance 1
route-distinguisher rd 65500:2604<br>
set / network-instance peeringlan protocols bgp-vpn bgp-instance 1
route-target export-rt target:65500:2604<br>
set / network-instance peeringlan protocols bgp-vpn bgp-instance 1
route-target import-rt target:65500:2604<br>
which is why I would've assumed adding multiple Bird2's with RD
65500:2604 would be the idiomatic way to do this.<br>
<br>
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!<br>
<br>
groet,<br>
Pim<br>
-- <br>
Pim van Pelt <a class="moz-txt-link-rfc2396E"
href="mailto:pim@ipng.ch" moz-do-not-send="true"><pim@ipng.ch></a> <br>
PBVP1-RIPE <a class="moz-txt-link-freetext"
href="https://ipng.ch/" moz-do-not-send="true">https://ipng.ch/</a><br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Pim van Pelt <a class="moz-txt-link-rfc2396E" href="mailto:pim@ipng.ch"><pim@ipng.ch></a>
PBVP1-RIPE <a class="moz-txt-link-freetext" href="https://ipng.ch/">https://ipng.ch/</a></pre>
<br>
</body>
</html>