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

[Natrajan Venkataraman <[e-mail]>]

Hi Robert,

>>> 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.

I don’t see any functional deficiencies in BGP-CT when compared to BGP-CAR. Neither is BGP-CT a functional subset of BGP-CAR. Rather I would say that BGP-CT is functionally efficient and adaptable than BGP-CAR. So, I don’t agree to whatever you are trying to project here without any technical evidence.

>>> 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 ?

I read these statements as “If it’s possible for BGP-CT to accomplish this with existing VPN technology, why re-invent the wheel with BGP-CAR?”

>>> 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.

You are more than welcome to have your opinions, but I don’t have to agree with the same. Time and Field will answer these questions.

Best,
-Nats-

From: Robert Raszuk <[e-mail]>
Date: Thursday, July 14, 2022 at 1:05 PM
To: Natrajan Venkataraman <[e-mail]>
Cc: idr@ietf. org <[e-mail]>, Susan Hares <[e-mail]>
Subject: Re: [Idr] CAR vs CT observation/question ...
[External Email. Be cautious of content]

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]<mailto:[e-mail]>> wrote:
Hi Robert,

Please find my answers inline marked with NV> below

Best,
-Nats-

From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 14, 2022 at 2:01 AM
To: idr@ietf. org <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[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


Juniper Business Use Only