Re: [Idr] BGP Classful Transport Planes

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Gyan, please see inline..

From: Gyan Mishra <[e-mail]>
Date: Tuesday, October 20, 2020 at 8:00 AM
To: Kaliraj Vairavakkalai <[e-mail]>
Cc: Natrajan Venkataraman <[e-mail]>, Robert Raszuk <[e-mail]>, "idr@ietf. org" <[e-mail]>
Subject: Re: [Idr] BGP Classful Transport Planes

[External Email. Be cautious of content]


Hi Kaliraj

In-line

Thanks

Gyan
On Mon, Oct 19, 2020 at 2:06 PM Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

No, there is no impact to existing CsC deployments.

    Gyan> Understood as a new CT RIB is created per new SAFI 76.  So this draft defines a new SAFI RD/RT that could be used instead of the current BGP-LU Labeled Unicast rib in global table used for Opt C which would now be carried in a separate CT RIB within the domain.

Today with service VPN their is an automatic underpinning with label stack topmost encapsulation so no recursion with VPN routes.

I suppose you are mentioning option-B inter-ASBR link here. Other-wise at an ingress-node Service-VPN routes do use nexthop-resolution of their PNH, which can be resolved via either an intra-AS tunnel(RSVP, SRTE) or an inter-AS tunnel (LU/CT).

With BGP LU,  it is has a BGP RIB for transport prefixes injected between domains as it’s a BGP RIB and not a separate VRF RIB as being proposed with CT RIB new extended community,

Please consider the BGP-LU global RIB as the best-effort Transport-rib. And with CT, we create per-class instances of Transport-RIBs (e.g. gold, silver) each having a Transport-class ID (e.g. 100, 200 resp). And yes, we use the Transport-Class RT carried on the BGP-CT routes to leak them into appropriate Transport-RIBs. It is really a transport layer BGP-VPN. Origination of BGP-CT route happens at a tunnel-ingress node, where protocols like RSVP/SRTE publish their tunnel ingress routes into these per-class Transport-RIBs, by virtue of local config.

Once the routes are collected in per-class Transport-ribs, they can now be used by other BGP-routes to resolve their nexthop. That is where the ‘mapping-community’ comes in.

The presence/absence of ‘mapping community’ on a service/transport plane route indicates which of these transport-ribs (best-effort, gold, silver) the route’s PNH should be resolved in.


and so BGP LU sit in the global table so has next hop recursion.

BGP-LU has nexthop resolution at an ingress-node. But it doesn’t do nexthop-resolution at inter-ASBR link. Whether we do nexthop-resolution or not actually depends on whether the peer is directly connected or not. It is similar logic for all families: Inet-Uni, L3VPN, LU, CT. No changes there.

In contrast the next hop underpinning to topmost label tunnel PNH would be a special mapping community mapped it sounds like to a primary and failover tunnel or a set of tunnels  to map CT transport service to underlay tunnel

The mapping-community just indicates which Transport-RIB to resolve the route’s PNH on. And it is just a ‘role’ that any BGP-community can play. Local (auto)configuration at ingress/border node identifies mapping-communities, and resolution schemes they map to.

Different routes can use different communities as mapping-communities. Because they have different requirements with respect to fallback. To elaborate:


  *   Service-routes (e.g. L3VPN, Inet-Uni) use Color extended community as mapping community. These map to a resolution-scheme which includes fallback to best-effort tunnels.

E.g. routes received with Color:0:100 will resolve using gold Transport-RIB (Transport-Class-ID:100), and fallback to best-effort transport-rib which may contain BGP-LU and other class-less tunnels (RSVP, LDP).


  - Transport-routes (BGP-CT routes) use the Transport-Class RT as the mapping community. This maps to a resolution-scheme which resolves strictly over specified transport-class, and doesn’t use any fallback.
    E.g. a BGP-CT route for RD1:PE1 route received with Transport-Class RT = transport-target:0:100 will resolve using “gold” Transport-RIB only(Transport-Class-ID:100). It will not fallback to best-effort Transport-RIB if gold transport-rib does not have any matching routes. This will result in sending a withdrawal for the “gold” BGP-CT route, thus providing a feedback mechanism to ingress-node that end to end gold path doesn’t exist now.

This feature could also be used as stated in the draft with CSC customer carrier VRF new CT SAFI for the topmost labeled transport prefixes.

That is right. But it is not the main intent. The main intent is to be able to do provide an architecture for Transport-class aware nexthop-resolution of BGP nexthops.

Section 4 details the new extended community.  I believe this is a typo as the CT community would follow RFC 4360 and 5668.  You mention 8 byte RT and RD but I believe you meant 6 bytes community with new IANA codepoint for new Hi Order and low Order sub type setting.  I think you would want to stay with standard type 0 2 byte global 4 byte local for 2 byte AS, type 1 4 byte global 2 byte local for IPv4 Global, end type 2 4 byte global 2 byte local for 4 byte AS.

rfc4360 Extended communities are 8 bytes. I didn’t get why you think it is a typo. Transport-Class identifier needed to be compatible with the Color value carried by SRTE (one of the classful transport protocols that exist today), that is the reason we defined the transport-class ID as 32-bits, in order to interoperate with existing technology. Hence defined a new format of RT instead of overloading the 4byte-AS format.



This draft creates a new SAFI that parallels BGP-LU in option-C deployments. I will clarify this with an explicit mention to option-C in the introduction.

   Gyan> Understood
The deficiency being addressed is: In today’s option-C deployments, if multiple classes(gold, bronze, etc) of tunnels exist to a destination PE1 in one domain, they can not be extended out to the adjacent domains by using BGP-LU, such that service-traffic in those domains is able to choose a certain class of tunnel.

    Gyan> In general Opt C is not generally used between ASs with operators in separate administrative domains end to end LSP.  The other down side of Opt C is the RR-RR eBGP SAFI 128 129 next hop unchanged peering which makes it impossible to use between operators in separate admin domains.  The last major issue with Opt C being addressed here is the import of loopbacks between domains has to be carried in the global table.  So Opt C in general is used only for M&A or internal inter AS peering where their is a trust relationship and the loopbacks FECs can be imported between domains.  So with this SAFI 76 if addresses the loopback import into the global table issue but does not address the eBGP SAFI 128 129 RR-RR peering for VPN and MVPN NLRI.  So in this option as the LSP is end to end the next hop self rewrite is not done in ingress egress NNI inter-as peering as the LSP builds end to end from ingress PE in domain A to egress PE in domain B.  So the major advantage of Opt B is that BGP LU is only for connected transport label on the inter-as peer and no loopbacks are injected between domains and as next hop self is utilized to terminate each segment of the LSP into 3 segments.  In Opt B the 1st segment is Ingress PE to egress PE domain A, 2nd segment inter as link, 3rd segment ingress PE to egress PE domain B.

Option-B or intra-AS VPNs will also see benefit from this architecture. Because,

  *   Even without SAFI-76, intra-AS tunneling protocols (RSVP, SRTE) publish their routes in Transport-RIBs created for the transport-classes that exist in the network. And Service-routes can map to these Transport-classes using appropriate mapping-community.

When information in these transport-ribs needs to be exported out to BGP-speakers in other domains, SAFI-76 comes into play.



  *   When such an intra-AS service-route which has resolved over gold transport-class, gets readvertised across inter-AS link for option-B, the mpls swap-label will stitch to the gold transport-class tunnel. Thus the option-B traffic can also get gold transport-class end-to-end, while traversing any of the ASes participating in the option-B deployment.



  *   Also, when an AS is too big that full-mesh of tunnels between PEs is hard to manage, the network can be segmented into regions. And SAFI-76 can be used to carry Transport-class aware PE reachability across regions (within one AS) in such cases, to stitch together gold-class tunnels in each region, for e.g. to provide end-to-end gold tunnel in the AS.



does not address the eBGP SAFI 128 129 RR-RR peering for VPN and MVPN NLRI

I agree the Multihop EBGP session between domains to exchange service-routes is required. This proposal doesn’t change that. I don’t see any way to avoid that in option-C. Yes Option-B avoids that, but it pushes additional service-routes state at the ASBRs, and increasing the convergence hops in the network. Both Option-B and Option-C have some benefits and disadvantages. This BGP-CT proposal doesn’t alter that. But there is a new proposal “MPLS-namespaces signaled by BGP” which can potentially bring benefits of both these options together. I may present it in the oncoming IETF, in BESS WG. Though it doesn’t avoid the ebgp-multihop session, it brings the benefit of option-B to option-C deployments, without increasing service-route scale at the ASBRs. Details of that mechanism will be out of scope of this discussion.


So here I don’t see any benefit of using SAFI 76 for Opt B which scales well. With both Opt B SAFI 128 and new 76 you would have to do the RT rewrite as well so no benefit there.

There is no intent to mix SAFI-128(service-routes) and SAFI-76. The idea is to maintain clear separation between service-routes and transport-routes. SAFI-76 carries only transport-prefixes.

RTC is a RT membership optimization that can be used     RR-PE only RTs that the PE has membership explicit import of RT is what is sent to PE.  By default all PEs have RT filtering enabled by default so if their is not an interesting explicit import of the RT the RT is dropped.  So RTC is an optimizations for incongruent VPNs on operator PEs to cut down on flooding of all RTs. So for CT are we changing the behavior of RTC RFC 4684.  Are we making RTC part of CT architecture and what is the requirement that it must be used as RTC is only an optimization.

No, we are not changing the behavior. RTC is still optional with this family as-well.

Also for CSC we here we are changing the VPN rib for customer carrier from SAFI 128 to 76.  With CSC hierarchical VRFs VPNs the transport prefix in the customer carrier VRF sit in the separate SAFI 128 RIB and so do the have the issue as exists with Opt C and you are just shifting from one VPN to another SAFI 128 to 76.  I still don’t see the benefit.

There are a few benefits I can see:

  *   It makes it easier to give different treatment, like per-prefix-label, to transport-prefixes carried in SAFI-76. It provides stability by localizing churn. We don’t want to give this treatment to routes advertised in SAFI-128. Because it carries service-prefixes as-well, so it is a scaling problem.
  *   The transport-RIBs proposed in this solution are recommended to be implemented as Control-Plane only RIBs. That don’t get pushed to forwarding. Unlike the CsC VRFs today, which by default, do get pushed to Forwarding as ip-prefixes and consume forwarding resources.
  *   More importantly, debugging. Looking at a SAFI-128 route, it is difficult to tell immediately whether it is a service-prefix or a Csc transport-prefix. If we use SAFI-76, it gives better visibility to humans and tools managing the network.

With this draft overall I do see the benefit with Opt C to assist with the BGP LU carrying imported loopbacks between domains in the global table but don’t see benefit in any other inter as solution that exists today.

Thank you for the note on Option-C. I have tried to clarify above the usefulness in the other use-cases.

With SRv6 LPM IPv6 data plane and no BGP-LU and use of SR-TE binding sid policy inter domain I don’t see any benefit in using SAFI 76.

With SR-MPLS as can use legacy inter as options would have same opt-c benefit but I think most customers using SR-MPLS would prefer to use SR-TE binding sid policy instead of MPLS based inter as options.

IMO, SRTE will have the problem as one of our previous proposal (BGP-LCU). Because it carries Color in the NLRI, co-ordinating between different domains will be difficult. It is not as easy as rewriting RT.

Thanks for the engaging discussion.

Kaliraj


Juniper Business Use Only