Gunter, Lots of thanks for your patience as well! I agree that the best way to address this issue (as well as several issues for which Errata have been verified) would be to start working on 9135bis.
I will try to propose this to the WG - and then we will see... Regards, Sasha From: Gunter van de Velde (Nokia) <[email protected]> Sent: Wednesday, August 26, 2026 3:31 PM To: Alexander Vainshtein <[email protected]> Cc: [email protected]; [email protected]; Jorge Rabadan (Nokia) <[email protected]>; [email protected]; [email protected]; John Drake <[email protected]> Subject: Re: [EXTERNAL] [Errata Rejected] RFC9135 (9000) Hi Sasha, Thank you for your patience. I needed some time to process and i currently do not believe that simply adding an exception to Section 9.1.1 would completely resolve the issue. In particular, retaining Label2 while omitting the IP-VRF Route Target would create a signaling combination whose s [Image removed by sender.]<https://report.mimecastcybergraph.com/?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Do20nRkVXf7VUVnANkXhoOwGytEwGN0YAlyeDJn7oBTGNl2kN%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.boDX0KSVk47TF0BURg8QHLJrE4VHJTmb3M8qWggyM0QfpC889VbeRNs4beR1wOnofURCwlBj4cceeR4dbUw6xTvZ8HFLTbQrE-UX71HQfCKHcN8_22cc297eiKDjycJ4voFNtFeneJe7otQ_6vcqucVRhr1Dq8ogmOQDxeDN6rd1SStQmItB6hgH2uSd3PfFMty-lxjC7Bybd4wK6QFeD0MQFnON9j0xM9SPxRUsQaKObtrChNwtIjBzXdx_jzkc80F_GwN6sXSuB5Ck5ClsUwI_c0Z0-NCshX-dW_2AehwtEQM-BiU1qseNhZ2fMqJFrxbWad_IovQSrpFmNNAm3A.Nko2EL2p2_HEZPQ_.hRp6dV5cysG0z7tpoNxTp-GKPsM6HqAKv3WAQ9vuQAvegfgUYA6ddOrAUuw2bifMXzCMFYm4-ZY-nPvBXQckAqqwEhpRkWTDvhsT2Uzkr4HooACMuPOD8xBB3GaFEcGzJIVhh1c3dCmbFl32TADCxltoJR2XYxDQn0spbbSlk24iJs4yPMUNFblpm_N4GgLcfqcEB4z6m-B-OMDh8op_tveXNDSWhb__yTvBi48ctokThkrmGVwm_473QtW5TpzNqNvMINbPwt_669VkouEyvgruCFDF9Xgj6OcLPhlFvbiqVLFh9fHqDfkHLgae9Ltv0ZsH_9nEFBQnfqLf5WYNbsA5vg5RT6cNkQ6CgB9gdWgVXSIcusdziEApnBwoyxr2EeapzQCRgyGhHwOyZH7LEAtTQnBt8S52moAtQ4rpgMEaUxrKNS5jFqsflavYLzyhKKAHt9L8QW78zxyFlD1IAgav4fKzLjrGl8nwX1HIQFhb7SLQjDoR0WuAGMSLw1755Hwp_Pwh6BTdBUejveHR04GwgEM17QnBGHL9SYNJnr14tCuMF--BEXesL9fy9olWbcZQWBmd2nZoSrpFuyAuogl9pMeOUU_n2MdhEYs2n8FlUNxcBCgGSnmd5b-9nE2iqtKiugfS-xs7THB8fiCfGaGgm-tBpvX_fdkWkiAZBVz2n3aw21HsSUPyRSFIIwoNq2CWUlxpmKQoLfSQ6JqdYNYB5bRg2cE7SCK_0I6XxSZ0l0wMOqhV5hh9nNsf_bXID5vPFxUpeSUVM8xhlgPFT7WVm3Hygc9psc9aAfuUbwLClnmY2djpwn4AxPWt4GMLxn_pBBfHJ7rV6qCAHj5a15g5Sw4otkNAk7gk61G84g.XT3kOmh_dR4WrQqVCp9wmA%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback> CGBANNERINDICATOR Hi Sasha, Thank you for your patience. I needed some time to process and i currently do not believe that simply adding an exception to Section 9.1.1 would completely resolve the issue. In particular, retaining Label2 while omitting the IP-VRF Route Target would create a signaling combination whose semantics are unclear. Section 4.2 associates symmetric IRB with the combination of a non-zero Label2 and an IP-VRF Route Target. Label2 would also serve no useful purpose if the link-local address is not imported into the IP-VRF. Omitting both Label2 and the IP-VRF Route Target appears more internally consistent, because the route could then be used only for MAC-VRF and BD-scoped Proxy-ND purposes. However, this would still require coordinated changes or exceptions in several parts of Sections 5.1, 5.2, and 9.1.1. It may also cause the route to be interpreted as asymmetric-IRB signaling under Section 4.2. Looking at all of this, I tend to believe that this is probably too broad for an erratum. Maybe it is better to bring the underlying issue to the BESS WG for a more normative update and fix it properly through WG consensus. Regards, Gunter ________________________________ From: Alexander Vainshtein <[email protected]> Sent: Wednesday, August 19, 2026 5:15 PM To: gunter <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; Jorge Rabadan (Nokia) <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; John Drake <[email protected]> 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: [email protected] <[email protected]> Sent: Tuesday, August 18, 2026 1:25 PM To: [email protected]; Alexander Vainshtein <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 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 <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
