Hi everyone, I mostly agree with Sasha’s points. For completeness I’d like to add that, as I said on the mike, I believe a solution based on the TEA would be better (than based on multi-label NLRI). Reasons are:
* RFC8277 was only defined for SAFIs 1 and 128, never for EVPN * EVPN route type 2 uses multiple labels in the NLRI already, so it would be simpler to use TEA. Thanks. Jorge From: BESS <bess-boun...@ietf.org> on behalf of Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Sunday, July 30, 2023 at 12:33 AM To: draft-zzhang-bess-vpn-option-bc.auth...@ietf.org <draft-zzhang-bess-vpn-option-bc.auth...@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, Nitsan Dolev <nitsan.do...@rbbn.com> Subject: [bess] Comments on the VPN Inter-AS Option BC draft 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, A few comments on the VPN Inter-AS Option BC draft<https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00> that has been presented at the BESS WG session in SF last Thursday. I think that the draft presents an elegant and much needed solution for real problem. I fully agree with the statement in the draft that “Option BC” combines the advantages and mitigates the disadvantages of both classic “Option B” and “classic” Option C. I also think that “Option BC” provides a viable alternative to both emerging solutions for intent-driven service mapping (BGP Classful Transport Planes<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12> and BGP Color-Aware Routing<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>), because it is possible to set up intent=aware inter-AS/inter-domain tunnels for “colored” services based on the color of the original service routes. At the same time, I think that: 1. As mentioned during the session, Inter-AS Option B for EVPN has its own issues (documented in the EVPN Inter-Domain Option B draft<https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>), and these issues fully apply to “Option BC” 2. The draft defines two possible solutions, one based on the Tunnel Encapsulation Attribute (TEA, RFC 9012<https://datatracker.ietf.org/doc/html/rfc9012>) and the other based on ability to carry multiple labels in the NLRI of “labeled” routes as defined in RFC 8277<https://datatracker.ietf.org/doc/html/rfc8277>: a. My guess (FWIW) is that these solutions are not interoperable and, therefore, ability to support each of these options should be advertised using appropriate Capability Codes b. In the TEA-based solution the draft mentions “Composite Tunnel”, but there is no mention of composite tunnels in RFC 9012. From my POV: i. Specific tunnel type (one of the types defined in the IANA Tunnel Types registry<https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml>) should be specified, or a request for allocating a new tunnel type should be added to the next revision of the document ii. I wonder if MPLS Encapsulation Tunnel type and the Label Stack Sub-TLV can be used in the TEA-based solution. My guess is that this would require an update to RFC 8365<https://www.rfc-editor.org/rfc/rfc8365.html> Hopefully these issues will be addressed in the next revision of the draft. 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
