Re: [Idr] CAR vs CT observation/question ...

[Robert Raszuk <[e-mail]>]

Hi Natrajan,

*NV> The assumption that you are making about BGP-CT being a subset of
BGP-CAR is neither correct nor backed by substantial technical evidence.*

When I stated  that CT can be subset of CAR I did mean functionally. Do you
dispute the fact that functionally both proposals are equivalent.

So the only significant difference voiced in almost all CT support emails
was the fact that CT uses RD and VPN like encoding. Do you  also
dispute that fact ?

So with both I do have an opinion that CAR's VPN mode can successfully meet
expectations of those customers who feel much more comfortable with RD
based encoding.

Many thx,
Robert





On Thu, Jul 14, 2022 at 9:57 PM Natrajan Venkataraman <[e-mail]>
wrote:

> Hi Robert,
>
>
>
> Please find my answers inline marked with NV> below
>
>
>
> Best,
>
> -Nats-
>
>
>
> *From: *Idr <[e-mail]> on behalf of Robert Raszuk <
> [e-mail]>
> *Date: *Thursday, July 14, 2022 at 2:01 AM
> *To: *idr@ietf. org <[e-mail]>, Susan Hares <[e-mail]>
> *Subject: *[Idr] CAR vs CT observation/question ...
>
> *[External Email. Be cautious of content]*
>
>
>
> All,
>
>
>
> Reading Sue's last email I can not resist asking one very basic but key
> question.
>
>
>
> CT supporters love RD based information distribution schema. Yes, RD and
> VPN format has proven useful for a lot of services. But we are not stuck
> with it forever.
>
>
>
> But as it is defined CAR does support VPN scoped distribution of
> transport colors with RDs.
>
>
>
> So natural question pops:
>
>
>
> *Isn't CT just a subset of CAR ? If you like to use RD schema to
> distribute your classes of transport do it in the CAR VPN mode. Treat the
> Internet as a VPN if needed. Keep a broader solution to progress. *
>
>
>
> *NV> The assumption that you are making about BGP-CT being a subset of
> BGP-CAR is neither correct nor backed by substantial technical evidence. I
> would like you to discuss technical viewpoints that you may have as part of
> Susan’s Part 3 (Q3) thread that is being scheduled. We will be more than
> happy to evaluate your comments in the context of that thread provided you
> present sound technical evidence. *
>
>
>
> Yes sure there are still encoding differences but what everybody
> supporting CT is saying is that what is convincing for them is the VPN
> model of distribution using RDs which CAR does support today (section 8 of
> draft-dskc-bess-bgp-car).
>
>
>
> With that is this debate really needed ?
>
>
>
> NV> This debate is needed because BGP-CT has proved that “all the
> use-cases” that apply to this problem space can be solved by leveraging
> existing BGP machinery that is available today with simple well-defined
> constructs. What is really the incentive to define something completely new
> like BGP-CAR to solve the same? In the networking world, anything brand-new
> is always seen as additional cost, sub-optimal ROI and takes time to mature.
>
>
>
> The IDR chairs have come to an agreement that these two approaches are
> functionally identical. The only thing that needs to be affirmed is whether
> BGP-CAR brings something radically different with respect to
>
>    - Operational benefits
>    - Operational cost
>    - Training cost
>    - Ease of migration
>    - Ability to solve use-cases with an unified approach
>    - Overall efficiency in handling use-cases
>    - Optimal ROI
>    - Better scaling and performance
>    - Error Handling
>    - Maturation time
>
> In exchange for adopting brand-new greenfield procedures that haven’t
> either stood the test of time or the scenarios available in the field.
>
>
>
> Many thx,
>
> Robert.
>
>
>
> Juniper Business Use Only
>