Re: [Idr] BGP Classful Transport Planes

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Robert, thanks for the comments. Please see inline.

From: Robert Raszuk <[e-mail]>
Date: Saturday, October 17, 2020 at 8:30 AM
To: Kaliraj Vairavakkalai <[e-mail]>, Natrajan Venkataraman <[e-mail]>, Balaji Rajagopalan <[e-mail]>
Cc: "idr@ietf. org" <[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