Re: [bess] Comments on the VPN Inter-AS Option BC draft

[Kaliraj Vairavakkalai <[e-mail]>]

Hi,

Sharing my impressions on draft-zzhang-bess-vpn-option-bc, which I had earlier shared offline with Jeffrey and Kireeti.

We lose “indirection” by carrying a label stack (combining service label and transport label) in service-routes.

That will affects us in following ways:


  *   Nexthop Scaling problems. Because of label-stack combinatorials.

(This could affect PE devices the most, which may be low end devices)

  *   BGP PIC is not possible. Since transport-layer does not exist.
  *   Service layer convergence. Any transport label changes will cause all service routes to be readvertised.
  *   ASBRs have service-routes now. in option-C ASBRs don’t have service-routes.
  *   ABRs also need service-routes now. In option-C they don’t. So it makes network’s core nodes “control plane” heavy.
  *   Label spoofing problem is not solved.
  *   Software upgrade is needed on all nodes: PEs, ASBRs, ABRs, RRs.

Because of these scaling and convergence problems, this mechanism doesn’t seem to be a good replacement for any transport-layer protocol.

I request the WG to consider these issues.

OTOH, the “MPLS Namespaces” solution presented in same BESS session solves all these problems.
Sec 6.1<https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-06#section-6.1> and 6.2<https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-06#section-6.2> of the draft describe how scaling, convergence and label spoofing protection is
achieved in an option-C network, using MPLS-NS. With software upgrade confined to ASBRs, regional-RRs.
The mechanisms described are for L3VPN label. But as noted in sec 6.1, they should work similarly for
any BGP service family carrying MPLS labels.

Just wanted to bring to attention of the WG.

Thanks
Kaliraj


Juniper Business Use Only
From: BESS <[e-mail]> on behalf of Jorge Rabadan (Nokia) <[e-mail]>
Date: Thursday, August 3, 2023 at 10:00 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>, Alexander Vainshtein <[e-mail]>
Cc: [e-mail] <[e-mail]>, Nitsan Dolev <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [bess] Comments on the VPN Inter-AS Option BC draft
[External Email. Be cautious of content]

Jeffrey, thanks for your answers. At least you and I are in synch now.

Thx
Jorge



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Date: Thursday, August 3, 2023 at 2:25 AM
To: Alexander Vainshtein <[e-mail]>, Jorge Rabadan (Nokia) <[e-mail]>
Cc: [e-mail] <[e-mail]>, Nitsan Dolev <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>
Sent: Tuesday, August 1, 2023 5:42 PM
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: [e-mail]; Nitsan Dolev <[e-mail]>; [e-mail]
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) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Nitsan Dolev <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Nitsan Dolev <[e-mail]<mailto:[e-mail]>>
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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-idr-tunnel-encapsulation-label-stack-02*name-traffic-steering-after-tunn__;Iw!!NEt6yMaO-gk!D4SbtWKz_KcZaN3pugtbEPlMe9DVdeoi-VxG39ZhGoPcxN4KOgHl9SbHu3ZNyHBB5V0v2F7dknr9rPnfa-pyihI$>.
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.