Jorge, I think that a more detailed definition of the TEA-based solution for inter-AS Option BC and EVPN is required.
According to RFC 9136, Encapsulation Extended Community can be attached to EVPN Ip Prefix routes in some cases. And Section 4.1 of RFC 9012<https://www.rfc-editor.org/rfc/rfc9012.html#section-4.1> says that the semantics of this extended community are the same as could be encoded in the "barebones Tunnel TLV". Are there valid scenarios in which Encapsulation Extended Community has to be attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, how these two usages can be clearly differentiated? Regards, and lots of thanks in advance, Sasha From: Jorge Rabadan (Nokia) <[email protected]> Sent: Monday, July 31, 2023 6:32 PM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: [email protected]; Nitsan Dolev <[email protected]> Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft 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 <[email protected]<mailto:[email protected]>> on behalf of Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Sunday, July 30, 2023 at 12:33 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Nitsan Dolev <[email protected]<mailto:[email protected]>> 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://clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k=&u=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://clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8=&u=https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12> and BGP Color-Aware Routing<https://clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE=&u=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://clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ=&u=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://clicktime.symantec.com/15t5z3YdWSSWCUF9bxWYU?h=Eo8x2bOQorNn4An26KlhQGMaow4EDWU6fwDgx-LKhZg=&u=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://clicktime.symantec.com/15t5uDMM3pkunXRE4Q7Pr?h=X5O-7WPStfY9Ws3f_gOPo314zCnRjXQrJAId3fyJJSc=&u=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://clicktime.symantec.com/15t64sjuy486cR559Wuh6?h=dV-HpTGRjieAGayybwXeM9RPxaokaMJmf7LVxKZVsl8=&u=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://clicktime.symantec.com/15t69hwCRfoh2Mtzh5Jqi?h=ncsX_KRsobTP9rvyLPeSchKXu21eb5KVtZz0rSqgqhA=&u=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 [email protected] https://www.ietf.org/mailman/listinfo/bess
