Hi Sasha, all, Thank you very much for reviewing this document. It’s a good point.
We just published rev 06 of the draft: https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-06 And added this sentence that should address your question: As shown in [RFC9136<https://www.rfc-editor.org/info/rfc9136>] Table 1, valid EVPN IP Prefix routes may be advertised either with a zero label or with a non-zero valid label. In all cases, the Border Routers update the next hop to their own address. However, generating a new valid EVPN label and re-advertising it in the IP Prefix route sent to the adjacent domain is required only when the received IP Prefix route carries a non-zero valid label. When the received EVPN label has a value of zero, the re-advertised IP Prefix route MUST also retain a label value of zero. Other than that, we made a few changes to improve readability. Let us know if you have further questions. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Thursday, May 22, 2025 at 1:54 AM To: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org <draft-rabadan-bess-evpn-inter-domain-op...@ietf.org> Cc: bess@ietf.org <bess@ietf.org> Subject: draft-rabadan-bess-evpn-inter-domain-opt-b 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 a question about procedures for handling IP Prefix (EVPN Type 5) routes in the case of inter-AS Option B for VPN. The corresponding text (item “e” in Section 2.1.1 of the draft<https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-05#section-2.1.1>) says: Specified in [RFC9136<https://www.rfc-editor.org/info/rfc9136>], this route allows the Egress PEs to advertise the IPv4 or IPv6 prefixes that they have learned locally in their IP-VRF. The route's NLRI contains an EVPN label that the Option-B Border Router needs to extract and program in the Forwarding Information Base, along with a label swap operation. Besides the next hop self and generating a new valid EVPN label for the IP Prefix route readvertised to the adjacent domain, the Border Router does not change any of the fields in the NLRI and preserves all the attributes along with the route, including EVPN extended communities. Table 1 in Section 3.1 of RFC 9136<https://datatracker.ietf.org/doc/html/rfc9136#section-3.1> explains relationship between different fields of the NLRI of EVPN Type 5 routes as following: ESI GW IP MAC Label Overlay Index Non-Zero Zero Zero Don't Care ESI Non-Zero Zero Non-Zero Don't Care ESI Zero Non-Zero Zero Don't Care GW IP Zero Zero Non-Zero Zero MAC Zero Zero Non-Zero Non-Zero MAC or None (as per local policy) Zero Zero Zero Non-Zero None My understanding of this table is that the procedure of the draft: · MUST be applied to EVPN Type 5 routes in which the Label value is Non-Zero while other fields are Zero or None (the Overlay Index in this case is None). To the best of my understanding this corresponds to the case of Interface-less IP-VRF-to-IP-VRF Model<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.1> · MUST NOT be applied to EVPN Type 5 routes for which the Overlay Index is used. This matches all other models of usage of EVPN Type 5 routes defined in RFC 9136. Is my understanding above correct? If yes, can you please add a corresponding clarification to the draft? Regards, and lots of thanks in advance, Sasha Regards, 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 -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
