Jorge, Lots of thanks for a prompt response. I tend to agree with your position. Let's wait for a more detailed version of the draft.
Regards, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Wednesday, August 2, 2023 3:02:28 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Cc: bess@ietf.org <bess@ietf.org>; Nitsan Dolev <nitsan.do...@rbbn.com>; draft-zzhang-bess-vpn-option-bc.auth...@ietf.org <draft-zzhang-bess-vpn-option-bc.auth...@ietf.org> Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft Sasha, Jeffrey would want to reply to those questions, the draft would need to be specific about the TEA use. Personally I don’t see any issues in using the TEA if properly specified in this draft. Thx Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Tuesday, August 1, 2023 at 8:42 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Cc: bess@ietf.org <bess@ietf.org>, Nitsan Dolev <nitsan.do...@rbbn.com>, draft-zzhang-bess-vpn-option-bc.auth...@ietf.org <draft-zzhang-bess-vpn-option-bc.auth...@ietf.org> Subject: RE: 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. 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://clicktime.symantec.com/15siFAn1RKeQBV28niQrX?h=Q05YbxJ5VmnNz13pCxBX5bAAu9TXh6SCpDGkNh0sS74=&u=https://www.rfc-editor.org/rfc/rfc9012.html%23section-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) <jorge.raba...@nokia.com> Sent: Monday, July 31, 2023 6:32 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-zzhang-bess-vpn-option-bc.auth...@ietf.org Cc: bess@ietf.org; Nitsan Dolev <nitsan.do...@rbbn.com> 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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Sunday, July 30, 2023 at 12:33 AM To: draft-zzhang-bess-vpn-option-bc.auth...@ietf.org<mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org> <draft-zzhang-bess-vpn-option-bc.auth...@ietf.org<mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Nitsan Dolev <nitsan.do...@rbbn.com<mailto: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://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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
