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/ -------------------------------------- Status: Rejected Type: Technical Reported by: Alexander ("Sasha") Vainshtein <[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 _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
