Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[Robert Raszuk <[e-mail]>]

Hi Kaliraj,

As described above, main difference between option (c) and (b) is that
>
> there is no service-route (SAFI 128) state at ASBRs. The ASBRs are
>
> “Transport ASBRs” that carry BGP-LU (SAFI 4) or BGP-CT (SAFI 76) routes.
>
>
>
> So, there is no ambiguity that SAFI 76 is a Transport-layer family, that
>
> enables Inter-AS option (c) solution.
>


The fundamental difference between SAFI 128 Option C vs Option B is that in
the former next hop is not changed between ASNs while in the latter it is.

I do not see any reason why not to say that CT uses Option-B especially
based on the fact that ASBR do maintain state and do rewrite next hop.

You seem to be stuck with Option C which simply is not what CT is doing.
Why ?

And also you keep bringing SAFI 4 over and over to the discussion which is
completely irrelevant to the subject.


> But CT does not like ADD-PATHs - so how are you planning to solve this
> original L3VPN distribution issue ?
>
>
>
> Further, about Addpath, CT doesn’t dislike Addpath 😊. BGP-CT does use
> Addpath to avoid
>
> the redundant ASBR path-hiding problem you describe, as stated in the
> following sections:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-10.6
>
>
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-18.3
>
>
>
>    Addpath is enabled for BGP CT family on the sessions between RR27 and
>
>    ASBRs, ABRs such that routes for 1.1.1.1:10:1.1.1.1 with the nexthops
>
>    ASBR21 and ASBR22 are reflected to ABR23, ABR24 without any path
>
>    hiding.  Thus giving ABR23 visibiity of both available nexthops for
>
>    Gold SLA.
>
>
>
> We just don’t think Add-path-ID is a good end-to-end distinguisher.
> Because it is per-session scoped.
>
> RD plays a better role of being an end-to-end distinguisher.
>


So you confirm that your solution when deployed inter-as requires
ADD-PATHs. Cool. We are making progress.

You also need to educate all of your customers that without ADD-PATHs use
the CT solution becomes single point of failure. And that is easier said
then done. ADD-PATHs has been supported for SAFI 1 for a while but not
necessarily for SAFI 128. So new code is needed which I am sure will be
part of OS which includes SAFI 76.

Note that path hiding on the RRs can also be addressed using BGP Diverse
Path RFC 6774 without the need to use ADD-PATHs.

I mention this here as those customers mobilized globally to support CT
must be aware that analogy to SAFI 128 is not identical when it comes to
SAFI 76.

As far as your last comment of ADD-PATHs being session scoped and using
this as counterargument let's observe that for transport layer where you
set next hop on transport anchors actually per session scope makes much
more sense as opposed to carry luggage from other ASNs into your domain.

Kind regards,
Robert