Re: [Idr] BGP Classful Transport Planes

[Robert Raszuk <[e-mail]>]

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 ?

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

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.


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.


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 ?

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 ?

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

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.

Many thx,
Robert.