Hi Sasha,

Thank you for raising this. 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.

Sasha, it may be that I processed your errata observation and the proposed 
solution through the looking glass of rfc9135 incorrectly and welcome your and 
bess wg feedback on my errata assessment.

Brgds,
G/


________________________________
From: Alexander Vainshtein <[email protected]>
Sent: Wednesday, July 22, 2026 8:55 AM
To: Gunter van de Velde (Nokia) <[email protected]>
Cc: [email protected] <[email protected]>; '[email protected]' <[email protected]>
Subject: RE: Erratum 9000 on RFC 9135


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 a prompt response, just wanted to be sure that this was not 
lost.



Regards,

Sasha



From: Gunter van de Velde (Nokia) 
<[email protected]>
Sent: Wednesday, July 22, 2026 8:05 AM
To: Alexander Vainshtein <[email protected]>; 
'[email protected]' <[email protected]>
Cc: [email protected]
Subject: [EXTERNAL] Re: Erratum 9000 on RFC 9135



Hi Sasha, Thanks for your follow up and the reporting of this errata. This 
delay is on me. I saw your reported errata but did not come to process it due 
to other priorities. Yesterday I had a chat with BESS chairs and will soon 
check with BESS WG. There are two open BESS errata currently to proce

Hi Sasha,



Thanks for your follow up and the reporting of this errata.



This delay is on me. I saw your reported errata but did not come to process it 
due to other priorities. Yesterday I had a chat with BESS chairs and will soon 
check with  BESS WG. There are two open BESS errata currently to process.



G/





________________________________

From: Alexander Vainshtein <[email protected]>
Sent: Monday, July 20, 2026 6:05 PM
To: '[email protected]' <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [bess] Erratum 9000 on RFC 9135





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.



Hi all,

I have posted Erratum 9000 on RFC 9135<https://errata.rfc-editor.org/eid9000> 
on 10-Jun-2026 (i.e., 40 days ago).



The erratum has been recognized as Technical, but it seems to be stuck in 
Reported state.



Any ideas as to what (if anything) should be done to speed up its progress to 
Verified?



I am asking because, IMHO and FWIW it reports a real gap in RFC 9135.



My 2c,

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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to