[bess] Re: [EXTERNAL] [Errata Rejected] RFC9135 (9000)

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Sasha,

I'll check with the secretariat if there are prior experiences on this type of errata (impacting several parts of the text) and will get back to you.

G/


________________________________
From: Alexander Vainshtein <Alexander.Vainshtein=[e-mail]>
Sent: Wednesday, August 19, 2026 5:15 PM
To: gunter <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; John Drake <[e-mail]>
Subject: [bess] Re: [EXTERNAL] [Errata Rejected] RFC9135 (9000)


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.



Gunter,

Lots of thanks for your detailed review of the Erratum and explanation of reasons for rejecting it in spite of acknowledging the problem that has triggered its submission.



I agree that the proposed correction, as written, contradict the last para of Section 9.1.1 of RFC 9135<https://datatracker.ietf.org/doc/html/rfc9135#section-9.1.1> that says (the relevant text is highlighted):



If the receiving NVE receives an EVPN RT-2 with only label1 and only a single Route Target corresponding to IP-VRF; an EVPN RT-2 with only a single Route Target corresponding to MAC-VRF but with both label1 and label2; or an EVPN RT-2 with a MAC address length of zero, then it MUST use the treat-as-withdraw approach [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606>] and SHOULD log an error message.

The correction should either make an exception for IPv6 link-local address in the marked or should make an exception for inclusion of Label2 field for these addresses in Section 5.1.



I am not sure that an Erratum that, one way or another, affects multiple text fragments of the RFC, is the best way to handle the problem.



If you think that submitting a modified Erratum addressing the contradiction mentioned above would help, I can do that.



Regards, and lots of thanks in advance,

Sasha



From: [e-mail] <[e-mail]>
Sent: Tuesday, August 18, 2026 1:25 PM
To: [e-mail]; Alexander Vainshtein <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] [Errata Rejected] RFC9135 (9000)



The following errata report has been rejected for RFC9135,
"Integrated Routing and Bridging in Ethernet VPN (EVPN)"

--------------------------------------
You may review the report below and at:
https://errata.rfc-editor.org/eid9000/<https://errata.rfc-editor.org/eid9000>

--------------------------------------

Status: Rejected
Type: Technical
Reported by: Alexander ("Sasha") Vainshtein <[e-mail]<mailto:[e-mail]>>
Date Reported: June 10, 2026, 1:57 p.m.
Rejected by: Gunter Van de Velde (IESG)

Section 5.1 and 5.2 says:

Original Text
-------------
In Section 5.1:
This route MUST be advertised with two Route Targets, one corresponding to the MAC-VRF of the tenant's subnet
and another corresponding to the tenant's IP-VRF.

In Section 5.2:
When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertisement route, it performs the following:

The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are used to identify the correct MAC-VRF and bridge table,
and if they are found, the MAC address is imported.
The IP-VRF Route Target is used to identify the correct IP-VRF, and if it is found, the IP address is imported.

Corrected Text
--------------
In Section 5,1:
This route MUST be advertised with two Route Targets, one corresponding to the MAC-VRF of the tenant's subnet and another corresponding to the tenant's IP-VRF.
The Route Targets corresponding to the tenants IP-VRF SHOULD be omitted if the IP address the NLRI of teh route is a link-local IPv6 address.

In Section 5.2:
When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertisement route, it performs the following:

The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are used to identify the correct MAC-VRF and bridge table,
and if they are found, the MAC address is imported.
If the IP address in the NLRI of the route is not an IPv6 link-local address, the IP-VRF Route Target is used to identify the correct IP-VRF, and if it is found, the IP address is imported.

Notes
-----
Claim by submitter
============
As per Section 2.5.6 of RFC 4291, "Routers must not forward any packets with Link-Local source or destination addresses to other links".

Therefore, these addresses MUST NOT be in the IP-VRF in ingress PE, and there is no need to attach Route Targets of the IP-VRF in the egress PE because they are used solely for identification of the importing IP-VRF in the ingress PE.

AD Review
=======
I agree with the underlying observation that an IPv6 link-local address must not become an inter-subnet forwarding route. However, I do not think the proposed correction can be verified as written.

RFC 4291 prohibits forwarding packets with link-local source or destination addresses to another link, but this does not mean that link-local addresses cannot appear as interface- or zone-scoped state within an IP-VRF.

More importantly, the proposed correction conflicts with RFC 9135 itself. Section 4.2 uses the presence of both Label2 and an IP-VRF Route Target to identify symmetric IRB. Section 9.1.1 also says that an RT-2 carrying both Label1 and Label2 but only a MAC-VRF Route Target MUST be treated as withdrawn. Omitting only the IP-VRF Route Target would therefore cause compliant receivers to discard the route.

There may be a valid clarification or protocol update here: a link-local MAC/IP binding could perhaps be advertised only for MAC-VRF and Proxy-ND purposes, without Label2 or IP-VRF import. However, that would require coordinated changes to several sections and discussion in BESS.

I therefore recommend rejecting this erratum as written and taking the underlying IPv6 link-local handling question to the BESS working group.

--------------------------------------
RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding)
--------------------------------------
Title : Integrated Routing and Bridging in Ethernet VPN (EVPN)
Publication Date : October 2021
Author(s) : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
Category : Proposed Standard
Source : bess (rtg)
Stream : IETF



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.