Jeffrey, thanks for your answers. At least you and I are in synch now. Thx Jorge
From: Jeffrey (Zhaohui) Zhang <[email protected]> Date: Thursday, August 3, 2023 at 2:25 AM To: Alexander Vainshtein <[email protected]>, Jorge Rabadan (Nokia) <[email protected]> Cc: [email protected] <[email protected]>, Nitsan Dolev <[email protected]>, [email protected] <[email protected]> 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. Hi Sasha, Jorge, Thanks for the comments. Please see zzh> below. Juniper Business Use Only From: Alexander Vainshtein <[email protected]> Sent: Tuesday, August 1, 2023 5:42 PM To: Jorge Rabadan (Nokia) <[email protected]> Cc: [email protected]; Nitsan Dolev <[email protected]>; [email protected] Subject: RE: Comments on the VPN Inter-AS Option BC draft [External Email. Be cautious of content] Jorge, I think that a more detailed definition of the TEA-based solution for inter-AS Option BC and EVPN is required. Zzh> For the TEA based solution, I had thought the method was described well enough (except the normative encoding format). It also includes the interop between the nodes that are incapable of handling the new “composite tunnel” (more below). Apparently, we need to elaborate it more. Zzh> Indeed the draft was written more focused on IP VPN (RFC 4364) and in that case the double-label based approach is better in that many PEs may already be able to support it. In case of EVPN, as Jorge commented on the mic, TED based approach is needed. 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://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9012.html*section-4.1__;Iw!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_Tt86Xho$> says that the semantics of this extended community are the same as could be encoded in the “barebones Tunnel TLV”. Zzh> RFC9012 states: Section 6 of [RFC8365] talks about the use of the Encapsulation Extended Community to allow Network Virtualization Edge (NVE) devices to signal their supported encapsulations. We note that with the introduction of this specification, the Tunnel Encapsulation attribute can also be used for this purpose. For purposes where RFC 8365 talks about "advertising supported encapsulations" (for example, in the second paragraph of Section 6), encapsulations advertised using the Tunnel Encapsulation attribute should be considered equally with those advertised using the Encapsulation Extended Community. 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? Zzh> For Option-BC, the new “composite tunnel” needs to be used to convey the semantics that the label in the tunnel is used for label switching the traffic. Zzh> More below. Regards, and lots of thanks in advance, Sasha From: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Sent: Monday, July 31, 2023 6:32 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Nitsan Dolev <[email protected]<mailto:[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 Zzh> On the mic I think I mentioned “protocols could be extended” – I thought you were saying about TEA for EVPN use. Now I see you were referring to the multi-label encoding. I agree with you. - EVPN route type 2 uses multiple labels in the NLRI already, so it would be simpler to use TEA. Zzh> I agree that for EVPN we need to use TEA. Zzh> More below for Sasha’s comments. 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://urldefense.com/v3/__https:/clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k=&u=https:**Adatatracker.ietf.org*doc*html*draft-zzhang-bess-vpn-option-bc-00__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_XbrqVo4$> 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://urldefense.com/v3/__https:/clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8=&u=https:**Adatatracker.ietf.org*doc*html*draft-ietf-idr-bgp-ct-12__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_hehSxOA$> and BGP Color-Aware Routing<https://urldefense.com/v3/__https:/clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE=&u=https:**Adatatracker.ietf.org*doc*html*draft-ietf-idr-bgp-car-02__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_g47F0X8$>), 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. Zzh> That’s an interesting thought. Let me think about it more. 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://urldefense.com/v3/__https:/clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ=&u=https:**Adatatracker.ietf.org*doc*html*draft-rabadan-bess-evpn-inter-domain-opt-b-01__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_vbefCv4$>), 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://urldefense.com/v3/__https:/clicktime.symantec.com/15t5z3YdWSSWCUF9bxWYU?h=Eo8x2bOQorNn4An26KlhQGMaow4EDWU6fwDgx-LKhZg=&u=https:**Adatatracker.ietf.org*doc*html*rfc9012__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_a_gTZfw$>) and the other based on ability to carry multiple labels in the NLRI of “labeled” routes as defined in RFC 8277<https://urldefense.com/v3/__https:/clicktime.symantec.com/15t5uDMM3pkunXRE4Q7Pr?h=X5O-7WPStfY9Ws3f_gOPo314zCnRjXQrJAId3fyJJSc=&u=https:**Adatatracker.ietf.org*doc*html*rfc8277__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_kpPKmZo$>: 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 Zzh> In case of IP-VPN, the two can be made interoperable - as long as the one capable of both TEA and multi-label can convert from one to the other – see “1.2.2.1. Incremental Deployment”. 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://urldefense.com/v3/__https:/clicktime.symantec.com/15t64sjuy486cR559Wuh6?h=dV-HpTGRjieAGayybwXeM9RPxaokaMJmf7LVxKZVsl8=&u=https:**Awww.iana.org*assignments*bgp-tunnel-encapsulation*bgp-tunnel-encapsulation.xhtml__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_l5avSI8$>) should be specified, or a request for allocating a new tunnel type should be added to the next revision of the document Zzh> Yes – a new tunnel type needs to be added. 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://urldefense.com/v3/__https:/clicktime.symantec.com/15t69hwCRfoh2Mtzh5Jqi?h=ncsX_KRsobTP9rvyLPeSchKXu21eb5KVtZz0rSqgqhA=&u=https:**Awww.rfc-editor.org*rfc*rfc8365.html__;Ly8vLw!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_GDNSyeA$> Zzh> We need a new tunnel type so that the receiver can interpret it properly. “Label Stack sub-TLV” cannot be used here – see https://datatracker.ietf.org/doc/html/draft-zzhang-idr-tunnel-encapsulation-label-stack-02#name-traffic-steering-after-tunn. Zzh> Thanks! Zzh> Jeffrey 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
