Re: [Idr] BGP Classful Transport Planes

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Gyan,

No, there is no impact to existing CsC deployments.

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.

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.

The new SAFI 76 carries NLRI of the form RDx:PE1, such that route for each class is carried using a distinct RD and doesn’t hide the other classes. And a new type of RT is used to denote the transport-class of the tunnel. This RT is used to leak the transport-routes into transport-RIBs of the same class on the receiving nodes – just like what L3VPN family does.

The note about similarity with CsC was just that: CsC uses SAFI 128 (L3VN) family to carry transport-prefixes in the mother carrier. Similarly, this SAFI 76(BGP-CT) also carries transport-routes in option-C deployments.

Hope that clears the confusion. Thanks for the comments.

Kaliraj

From: Gyan Mishra <[e-mail]>
Date: Sunday, October 18, 2020 at 10:52 PM
To: Robert Raszuk <[e-mail]>
Cc: Kaliraj Vairavakkalai <[e-mail]>, Natrajan Venkataraman <[e-mail]>, "idr@ietf. org" <[e-mail]>
Subject: Re: [Idr] BGP Classful Transport Planes

[External Email. Be cautious of content]

Hi Kaliraj,

I read the draft and had a few comments.

This draft creates a new SAFI 76 BGP-CT that parallels BGP-LU that is being used to fix a deficiency with CSC as far as the transport label being used as customer carrier Hierarchical VRF to the customer carrier customer VRF and not in a separate transport rib.

The framework behind CSC is that the backbone carrier PE runs BGP LU to customer carrier CE, and the transport routes are within SAFI 128 Customer carrier VRF. The PE-CE backbone to customer carrier must MPLS enabled. The Customer Carrier
would have a it’s own hierarchical customer VRFs that would be tunneled across the backbone carrier.

The customer carrier hierarchical VRF to its customers are tunneled over the backbone carrier.

The customer carrier transport routes are in a VRF SAFI 128 and don’t touch the backbone carrier global table.  BGP LU is enabled on the eBGP connection PE-CE for the transport label binding and is identical to inter-as Opt B usage of BGP-LU and then the customer carrier transport prefixes  routes sit in SAFI 128 eBGP VPN IPV4 VPN IPV6.

You mention in the draft inter-as opt B interchangeably with CSC which they both are similar but very different.  However, I believe you are trying to address deficiencies with only CSC.

As RFC 4364 CSC had been deployed for years by many carriers and it scales very well.  I am trying to understand the issues and gap related to CSC.

So with this new SAFI the intent is to not have a hierarchical VRF and instead this new BGP-CT Transport rib.

What is the impact to existing CSC deployments using hierarchical VRF.  How would you address backwards compatibility.


Kind Regards

Gyan

On Sun, Oct 18, 2020 at 7:39 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kaliraj,

Just a few points as a follow up on your note.

Ad 1 - The point was that you can carry mapping (or if you will stitching information) by extending with new draft encoding defined in draft-ietf-idr-tunnel-encaps.

As you know tunnel SAFI (5512) was deprecated and going forward the recommendation is to use a new encap attribute. That is why I suggest you consider the use of a new attribute attached to RFC3107 SAFI 4 instead of defining new SAFI.

Ad 2a - You say "it will work" then just a few lines below you admit the current draft only addresses MPLS stitching via ASBR/ABRs.

Ad 2b - All three points on value of MPLS Inter-AS or Inter-area stitching are quite questionable even in brownfield deployment. But that's not the point to debate any more here. Market will decide.

Ad 3 - No I was not asking for yet one more abuse of flowspec use case. I was not asking for new ACL based mapping to specific VRF either. If your draft is about "BGP Classful Transport" it better also define "Classful RIB" where forwarding decision is done not only based on destination address and its next hop but also on other fields in the packet. That was the first thing I was curious to see in your new SAFI definition but there is none.

Ad 4 - I was asking where exactly is the Longest Prefix Match performed ? Based on aggregates generated by which network element and which protocol ? What set of destinations does the aggregate cover ? Assuming option-C don't you still need to leak all /32s or /128s across the domains - or you assume RFC5283 is in use ? I think it would help whoever is reviewing this work to have an end to end illustration of how each SN/BN/RR hop service route and its next hop changes as well as how underlay transport and overlay tunnels are advertised at each BN with the use of real IP addresses and labels. Even Shraddha's blog post does not go into that level of details.

Many thx,
Robert



On Sun, Oct 18, 2020 at 1:47 AM Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert, thanks for the comments. Please see inline.

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Saturday, October 17, 2020 at 8:30 AM
To: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>, Balaji Rajagopalan <[e-mail]<mailto:[e-mail]>>
Cc: "idr@ietf. org" <[e-mail]<mailto:[e-mail]>>
Subject: BGP Classful Transport Planes

[External Email. Be cautious of content]

Hi,

I have read https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01__;!!NEt6yMaO-gk!Xg6xfSibwETZhsptdOJv2QL0vVF8WVkztqeHhepYnVCyfQQAMILyPEH9JnXnhQDO$>
and have few questions & observations.

1.

> A domain boundary is demarcated by a rewrite of BGP nexthop to 'self' while
> readvertising tunnel routes in BGP.

For advertising tunneling in BGP we already have a number of options. Starting from RFC5512 through draft-ietf-idr-tunnel-encaps-19 or https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-intarea-tunnels-10__;!!NEt6yMaO-gk!Xg6xfSibwETZhsptdOJv2QL0vVF8WVkztqeHhepYnVCyfQQAMILyPEH9Jl8x4R7Q$>

Q: Do we really need more signalling extensions instead of working with existing protocols to accommodate new applications ?

This is not an extension parallel to TEA. The above para means to say, when BGP speaker does nexthop-self on a advertised transport-route, the details of the intra-domain tunnel used in the advertising-domain is hidden from the BGP-speaker in the other domain receiving the route. Because it sees as nexthop only the advertising BGP-speaker.

Such nexthop-self happens in
·   option-B VPNs, at the Service-ASBRs  (BGP-L3VPN families)
·   option-C VPNs, at the Transport-ASBRs or BGP ABRs (BGP-LU and BGP-CT are examples of this)

So this act of doing nexthop-self demarcate the boundary between two domains. That boundary either link on an inter-AS link, or an ABR.

May be I should clarify the statement to use “transport-route” instead of tunnel-route. Will that make it clear?

2.

> The path uses MPLS label-switching when crossing domain boundary

So if the network for any reason does not use MPLS in its data plane - what you are proposing here simply is not going to work. Just for clarity MPLS can be used for service plane demux while transport can still be pure IP.

It will work. There are two cases here:
·   intra-AS non-MPLS-tunnel.



As explained above, details of what type of intra-AS tunnel is used is confined to the tunnel boundary nodes. And we can encapsulate MPLS-traffic on other type of tunnels. So this will work.


·   Inter-AS non-MPLS data-plane.



Yes, in this document we take the case of inter-AS link running MPLS data-plane. Because that is the most prevalent deployment today. But we have put thought into how the mechanisms prescribed in this document can work with non-MPLS data-planes also. But they are out of scope of this document.



In brief, instead of doing MPLS label-swap on the inter-AS link, we can do plain IPv6 forwarding. We may have a separate document in future, that will explain how mechanisms in this document adapt to SRv6 data-plane.




In contrast if you are carrying your services with SRv6 across your domains you actually have Seamless SR for free without yet another BGP SAFI and stack of tunnels.

   Supporting inter-AS MPLS data-plane has the following advantages:
·   Uses and builds on top of deployment experience that we have gained thru the years.
·   Preserves returns on investment made in existing deployments. i.e. Brown-field networks.
·   Scales better. Because MPLS allows us to do build network hierarchies with nexthop chaining and label-stacks.

   But yes, if a green-field network decides to use IPv6 end-to-end, there are two ways it can be done:
·   Use IPv6 for control-plane, and MPLS in the data-plane.
·   Use IPv6 in the data-plane as-well. Even in this case, association of IPv6-tunnel endpoints with appropriate transport-class will be required. Which can be achieved with BGP-CT.

In summary, mechanisms described in BGP-CT are agnostic to
·   What type of tunneling technology is used in the intra-AS transport-layer
·   And what type of data-plane is used on the inter-AS links. Though the draft uses MPLS.

I will clarify the same in this draft. That, this draft uses MPLS as the defacto inter-AS data-plane, but the mechanisms will work with non-MPLS data-planes also. Future documents will specify details on how.

3.

>  Overlay routes carry sufficient indication of the Transport Classes they should be encapsulated over,
> in form of BGP community called the "mapping community".

My feedback here is that granularity to color routes and group routes into transport classes is not sufficient.

If I have a cluster of compute servers which I advertise as a single address block I must have ability to define and disseminate flows in/out such cluster on a per application basis (ideally per flow 5 tuple).

At min per dst port granularity would be must have. Just doing the dst based ip lookup and based on that placing the switching via proper color of inet.3 RIB will just not cut it.

Please note, BGP-Flowspec routes can be colored appropriately to achieve what you describe here. Flowspec becomes just another service-family that can resolve over transport-classes created by BGP-CT.

So, you could have an inet-unicast service-route advertised for the ‘cluster of compute servers’ with desired color mapping-community.

And further, inet-flowspec route with the 5-tuple can be advertised, with redirect-to-ip nexthop and color mapping community. Such that any flow mathing this flowspec route is redirected using the transport-class, that the color mapping community maps to.

Does that address this comment?

If yes, I can add some text to the draft describing the flowspec use-case.

4.

> Based on the mapping community, "route resolution" procedure on the ingress node selects from the
> corresponding Transport Class an appropriate tunnel whose destination matches (LPM) the nexthop
> of the overlay route.

Assume I am using inter-as option C across my domians.  So VPNv4 AF carries service routes with remote PEs next hops.

Can you elaborate or better update the draft with a new section describing in detail the relation between transport next hops, border nodes and service next hop for a given service route across 3 domains ?

Sure. We will add text to the draft describing this. in brief,

At the Transport BNs:
·   It will have BGP-CT route for remote-PE/32 in gold transport-RIB.
·   This BGP-CT route will be marked un-usable, if there is no routes in the gold transport-RIB matching remote-PE/32
·   It Will create mpls swap-routes when readvertising the BGP-CT route.

At the Ingress SN:
·   It will have the BGP-CT route for remote-PE/32 route in gold transport-RIB, when gold-connectivity exists end to end.
·   Service-routes carrying gold mapping-community will resolve using this gold transport-RIB route.

For example what is not stated in the draft - if LPM match is sufficient here do you depend on BGP-CT to remove the advertisements to remote overlay tunnel endpoints when such endpoint fails ?

Yes. The BGP-CT routes for a gold transport-class will fail resolving it’s nexthop if no gold tunnels exist. So, BGP-CT will not advertise it further. This is similar to the rules followed by any BGP-family regarding nexthop resolution.

Then how about not complete failure but partial service degradation (for example increased fabric drops) ? How do you intend to detect those and automate say "gold" class bypass around such BNs ?

BGP-CT will depend on the individual intra-domain transport-tunneling technologies to monitor such metrics, and classify whether ‘gold reachabilty’ exists to the nexthop in question. BGP-CT provides a way to collect such information procured from various intra-domain tunnels, and stich it across multiple domains and give an end to end picture to the service routes. How exactly such parameters are monitored will be left to the purview of the individual tunneling technologies.

e.g. RSVP or SRTE can monitor such parameters at nodes along the path, and give feedback to the RSVP/SRTE ingress node, which either adjusts the ingress route in gold transport-RIB, or takes down the gold transport-route. Which will trigger appropriate response in the BGP-CT layer.

5.

> baby carrier

Nice !

Never used such term when describing CSC to customers  :-)

Thanks! :)

Once we reach consensus on the various points discussed in this thread, we will update the draft.

Balaji, Natz, Shradha, please add if anything.

Thanks,
Kaliraj




Juniper Business Use Only
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!U8HbQ5jZBlsxEu8405jmF-287HZ0Rs-PwJCc2URxQqPyf59kvSU9h1YXFcFZxEh2$>
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!U8HbQ5jZBlsxEu8405jmF-287HZ0Rs-PwJCc2URxQqPyf59kvSU9h1YXFRulXXkX$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



Juniper Business Use Only