Re: [Idr] BGP Classful Transport Planes

[Kaliraj Vairavakkalai <[e-mail]>]

Robert,

Please see inline for some responses.

From: Robert Raszuk <[e-mail]>
Date: Monday, October 19, 2020 at 12:27 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,

Thank you for more comments. Just to finish this little thread:

The new attribute attached to SAFI 76 (BGP-CT) route is a Route-Target extended-community.

Actually I am not sure if overloading RT is the best idea here. Have you considered defining a new extended community instead ?

Yes it is a new extended-community Format/Type. Section 4 describes it:

"Transport Class" Route Target extended community is a transitive
extended community EXT-COMM [RFC4360] of extended-type, with a new
Format (Type high = 0xa) and SubType as 0x2 (Route Target).

We did this, so that there is no collision of these Transport-plane RTs with currently deployed service-plane RTs. If I understand you right, this is what you are suggesting as-well.

Sure you would have to update RTC in such a case, but this seems the only issue.

RTC seems to work with any Route-Target (extended-community with SubType 0x2). We can update RTC to specify that if required.

Note on RTC ... today RTC dynamics are pretty static. You advertise RTs which are locally configured for import. Here we are completely changing this to also advertise RTs which are learned via VPNv4/v6 AF to receive transport overlays. While I am not immediately saying this will trigger more instability I think the dynamics between VPN routes itself and signalling the need for requested colors for tunnels should be differentiated. Since the draft does mention RTC it should at least give a hint to implementers about this.

About RTC dynamics, agree – it could be either via local-configuration or a feedback from VPN service-families, to request SAFI-76 routes for the required PNH, Transport-class. This provides a ‘On Demand Nexthop’ mechanism for the ingress SNs.

Page 11, section “Constrained distribution of PNHs to SNs.” tries to explain this. I will add a note about the change in dynamics.
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.

+

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.


My feedback is that per route coloring is not enough. At least per dst port is needed.

Therefore if you are going via the effort to define a new classful forwarding signalling my suggestion is to make it a bit more useful in practical deployments.

This is a new classful Transport signaling. I think there is a difference. Service-routes, used for Forwarding resolve over Transport-routes. So I still think service-plane information should not be carried in SAFI-76. But if such per-dest-port service/forwarding-routes is carried via some other mechanism, it can resolve over transport-classes built using SAFI-76. I will discuss your suggestion internally to check if I am missing something.
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.

Let's see if I understand your proposal here.

Today VPN next hops are advertised across all domains by OSPF. You are you saying that not only those will be distributed by OSPF ... now 1000s of them will also be duplicated and distributed by SAFI-76 as well ?

No. intra-AS distribution will not change. Intra-AS IGP or tunneling-protocol(e.g. RSVP) routes will remain in one domain. They don’t need to be advertised everywhere. That provides better resiliency, by decoupling the domains and confining blast-radius. We do BGP nexthop-self between these loosely coupled domains. That’s the environment we are addressing/presuming in this draft. I will perhaps mention that.

Only the intra-AS tunnel end-points which want to be advertised on inter-domain boundaries, they will be advertised in SAFI-76 with appropriate transport route-target to indicate their class. It is just like redistributing intra-AS tunnels into SAFI-4, here we redistribute them in SAFI-76. And they are received, re-advertised by BNs on adjacent domains, until they reach the ingress-node.

Today all of those advertised by OSPF along with labels carried by LDP or 3107 will be installed into inet.3 (mpls RIB + LFIB) to resolve VPN next hops.

Now for transport class you construct (logically or physically - does not matter) a new class.inet.3 RIBs and LFIBs and "leaking" VPN next hops from SAFI-76 based on their RT membership ?

That is right. However not only SAFI-76 routes, but the intra-AS tunneling-protocol routes (e.g. RSVP/SRTE) will also install ingress routes in class.inet.3. Those intra-AS tunneling protocols are transport-class aware at the ingress-node.

Is that right ? If so I am still not seeing much room for aggregation and LPM there.

OK, there will typically not be anything less specific than /32s in these Transport-RIBs – if that’s what you meant. Because they are tunnel ingress routes, they will be /32s. I just mean to say the nexthop lookup will happen in class.inet.3 instead of inet.3, such that the LPM will pick only a route that belongs to the desired class.
And, these transport-ribs can contain routes from various transport-protocols (RSVP, SRTE, BGP-CT, others). I hope I got your question right.

Feeding transport-ribs is based on the mapping-community. So now do you expect all of those listed transport-protocols to also carry such route target communities ?  If so IMO we clearly should not overload RT semantics with this completely new role.

Feeding transport-ribs is based on Transport Class Route-target. And no, non-BGP transport-protocols don’t carry this RT. They install routes in class.inet.3 by either local configuration (e.g. in RSVP case), or by virtue of mapping the color in their NLRI to a transport-class (SRTE case). E.g. SRTE color 100 maps to Transport-class ID 100. These RSVP/SRTE routes will be installed in class100.inet.3. When they are advertised out in SAFI-76, they will be advertised with Transport-Target:0:100, and on the receiving node, imported into Transport-RIBs class100.inet.3 which is provisioned to import this RT value.

Further, the SAFI-76 routes received in color100.inet.3 will be resolved using intra-AS RSVP/SRTE routes in color100.inet.3 in that receiving domain. Such that end to end, the transport-class 100 SLA is preserved.

Thanks
Kaliraj


Juniper Business Use Only