Re: [Idr] BGP Classful Transport Planes

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Robert,

Please see inline.

From: Robert Raszuk <[e-mail]>
Date: Sunday, October 18, 2020 at 4:39 AM
To: Kaliraj Vairavakkalai <[e-mail]>
Cc: Natrajan Venkataraman <[e-mail]>, Balaji Rajagopalan <[e-mail]>, "idr@ietf. org" <[e-mail]>, Shraddha Hegde <[e-mail]>
Subject: Re: BGP Classful Transport Planes

[External Email. Be cautious of content]

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.

The new attribute attached to SAFI 76 (BGP-CT) route is a Route-Target extended-community. Ref: https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01#section-4

This RT helps this SAFI in following RFC-4364 mechanisms. I think it doesn’t make sense to use/extend TEA to perform RFC-4364 mechanisms (route leaking in BGP VPNs).

The ‘mapping community’ is just a new role for a bgp-community. Any community/extended-community can be used as a mapping-community. We re-use existing ext-community “Color extended community” as the mapping-community on service-routes.

A new SAFI is required because it carries RD and RT. RD is required to distinguish the NLRI of gold/silver reachability info for a PNH PE1/32. RT is required to associate the PNH route with a specific Transport-class and leak it to the associated Transport-VRF RIB (its just a Transport-layer BGP VPN).

These cannot be achieved using SAFI 4. Addpath-ID can help with path-hiding on a per-BGP-session scope, but it does not provide a proper end-to-end end-point ‘distinguisher’. RD is good for debugging, since looking at a RD1:PE1 route, one can figure out which node in the multi-domain option-C network originated this advertisement. AddPathID doesn’t help with that. Also, instead of redefining SAFI-4 to follow RFC-4364 and allow leaking using RT, it appeared much cleaner to define a new SAFI that uses RD, RT.

We could have overloaded SAFI-128 to carry transport-routes as-well. But separating it into a new SAFI made sense with respect to operational simplicity.

This is explained in https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01#section-9

Yes, defining a new SAFI means other vendors need to come on-board to implement this mechanism. We are hoping customers and fellow-vendors will see the value this proposal brings to brown-field deployments.

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.

Sorry, I must have said it ‘can be made to work’, as the architecture maintains clear separation between layers, and has room for extension. But yes, current draft only addresses MPLS forwarding at the border-nodes.

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.

Agree, 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.

OK. I think you are asking about CBF (Class based forwarding). IMHO, CBF is local implementation matter. So we didn’t specify anything in the draft about it. E.g. Junos will support mapping a ‘forwarding-class’ to a ‘transport-class’ by local policy configuration.

SAFI-76 itself is at the Transport-layer, so I feel it should not have any CBF related details, which are service-layer level information.

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 ?

The LPM is performed on the transport-class specific transport-RIBs (e.g. gold.inet.3), which can contain routes from various transport-protocols.

Yes, the RD:PNH/32 or RD:PNH/128 routes will be leaked across all domains. There is no aggregation. And they will be collected in respective transport-ribs, e.g. gold.inet.3, bronze.inet.3 at the SN/BN nodes. Thus, e.g. When a route with mapping-community ‘gold’(Color:0:100) is received, to resolve it’s nexthop, we do the LPM in transport-RIB (gold.inet.3) associated with that transport-class. Routes in best-effort transport-rib (inet.3) will not be used. The RD:PNH/32 routes would have been leaked into this gold.inet.3, by virtue of carrying a RT: transport-target:0:100.

And, these transport-ribs can contain routes from various transport-protocols (RSVP, SRTE, BGP-CT, others). I hope I got your question right.

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.

Sure, I will add details to the draft with specific example topology.

Thanks a bunch for taking time to review, and give comments.

Kaliraj


Juniper Business Use Only