Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption

[Robert Raszuk <[e-mail]>]

Hello Muthu,

*> Wrose, if it is in BGP whose stability is so crucial to the stability of
the Internet..*

Spot on !

So the two questions follow ...

*Q1: *

Should we continue adopting spot solutions which by design work only in
cooperative admin domains into single BGP ?

We already have a load of BGP-LS growing exponentially which is to work
only in limited domains. We have tons of VPNs loaded into BGP which again
has not helped with the stability of the Internet.

I simply do not get why we should keep adding this to the same boat. The
boat is built well and it is still floating but more containers (packed
into separate AFI/SAFIs) does not help with the portion of the Internet
centric load.

Why was there so much resistance to fork non interdomain staff off the main
BGP mainline and do all what is needed for limited domains ? We could
rename it to P-BGP .. allocate a new port, run as a separate process (in
implementations which can do that) etc ...


*Q2: *

Muthu's note brings up a very important point ... In the recent years there
were a number of proposals to enhance BGP with qos/color routing. To name
just a few:

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sla-exchange

https://datatracker.ietf.org/doc/html/draft-jacquenet-bgp-qos-00

https://datatracker.ietf.org/doc/html/draft-boucadair-qos-bgp-spec-01

https://datatracker.ietf.org/doc/html/draft-liang-bgp-qos-00

https://datatracker.ietf.org/doc/html/draft-knoll-idr-qos-attribute-08

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sla-exchange

Why now out of the sudden we focus so much on CAR/CT vs taking a holistic
approach to the problem and maybe dedicate time to compare all solutions in
this space ?

Seems that IDR should do the math comparing all of the above before making
any call. But here we keep focusing on limited domain solutions which by
design can not work in the real Internet. Can't understand why.

Assume CAR or CT get's standardized. How would it work with any of the
above proposals ? Are they all trash at that point ?

Kind regards,
Robert



On Fri, Jul 29, 2022 at 5:00 AM Muthu Arul Mozhi Perumal <
[e-mail]> wrote:

> +1. Having two non-interoperable standard solutions (experimental or
> otherwise) for the same problem in the same protocol + another standard
> describing how to interoperate b/w them adds unnecessary complexity to the
> protocol design and implementation. Wrose, if it is in BGP whose stability
> is so crucial to the stability of the Internet..
>
> IMHO, the first step is to move towards adopting the draft describing the
> problems, use cases and requirements, ensure there is rough consensus that
> it is in a good shape, then design a solution that addresses requirements
> -- the solution itself could borrow the best of CAR and CT.
>
> Regards,
> Muthu
> --perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.
>
> On Fri, Jul 29, 2022 at 7:00 AM Job Snijders <job=
> [e-mail]> wrote:
>
>> Hi all,
>>
>> On Thu, 28 Jul 2022 at 18:38, Randy Bush <[e-mail]> wrote:
>>
>>> i do not support progress of either CAR or CT.  they should resolve
>>> differences asap.
>>
>>
>> I concur, I encourage people to unify the approaches. It’ll pay dividends
>> in the long run.
>>
>> If I understood comments from the chairs at this weeks IDR session
>> correctly, there has been a lack of operator input.
>>
>> I imagine some operators might feel hard pressed to choose between CAR or
>> CT, when their underlaying desire might be “neither”: make one.
>>
>> Kind regards,
>>
>> Job
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>