Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt

[Gyan Mishra <[e-mail]>]

Hi Robert

My opinions presented in this discussion are related to Verizon’s network
for CT use for real world operational meaning being deployed within
Verizon’s network.  CT can be used for color mapping within the same
administrative domain or between administrative domains and applies to all
transport technologies which is a use case for Verizon.

As myself and Luay mentioned in the previous email, Verizon support both
drafts, CT as myself as Co-author  and Luay as Co-author of CAR.

Once the technical aspects of both drafts have been analyzed in Q3 and both
are deemed sound and solid solutions with their own niche use cases, we
support progressing both drafts and let the market decide which one or both
prevail as options in the operators toolbox.

Kind Regards

Gyan
On Sat, Jul 16, 2022 at 12:45 PM Robert Raszuk <[e-mail]> wrote:

> Hi Gyan,
>
> May I ask how are your opinions presented in this discussion related to
> the real Verizon network ?
>
> I am asking based on the stated support for BGP-CAR solution by Verizon
> Fellow:
>
> https://mailarchive.ietf.org/arch/msg/idr/PKkqHGQYlrU2or3Af3ABbODq24I/
>
> Are your opinions carry real operational meaning or are they just coming
> from individual and CT draft co-author ?
>
> Many thx,
> R.
>
>
> On Sat, Jul 16, 2022 at 6:17 PM Gyan Mishra <[e-mail]> wrote:
>
>>
>> Hi Miya
>>
>> Comment in-line
>>
>> On Fri, Jul 15, 2022 at 12:41 PM Miya Kohno <[e-mail]> wrote:
>>
>>> Hi Robert,
>>>
>>> Indeed. I wanted to mention the difference in starting points, but the
>>> classification was a bit misleading.
>>> BGP CAR works equally well over MPLS , and in fact can work over RSVP-TE
>>> too.
>>>
>>> >BGP-CT  - of legacy data and control plane origin
>>>
>>
>>       Gyan> I would not call using L3 IP VPN semantics legacy as it is a
>> proven technology that works very well has been used in the past for VPN
>> overlay and will continue to be used in the distant future with SR and
>> beyond technologies.  L3 IP VPN technologies are far from being legacy or
>> deprecated.  We are seeing the technology being used in other areas such as
>> SD WAN and now at the transport layer due to its proven track record for
>> operators.
>> BGP-CT control plane applies to existing technologies as well as all
>> future technologies.
>>
>> >BGP-CAR - modern data plane + extensibility
>>>
>>> Completely agree.
>>>
>>> Miya
>>>
>>> On Sat, Jul 16, 2022 at 12:40 AM Robert Raszuk <[e-mail]>
>>> wrote:
>>>
>>>> Hello Miya & WG,
>>>>
>>>> > Basically yes. But I would say they have different origins. BGP-CT is
>>>> MPLS-native, whereas BGP-CAR is SR-native.
>>>>
>>>> How about SR-MPLS ? Do you classify it under MPLS or under SR :) ?
>>>>
>>>> Don't you think CAR would be a good fit as well even for MPLS customers
>>>> especially those LDP free and/or RSVP-TE free ?
>>>>
>>>> I would rather classify the two proposals a bit differently:
>>>>
>>>> BGP-CT  - of legacy data and control plane origin
>>>>
>>>> BGP-CAR - modern data plane + extensibility
>>>>
>>>> The choice is simple ...
>>>>
>>>> Best regards,
>>>> Robert
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jul 15, 2022 at 4:43 PM Miya Kohno <[e-mail]>
>>>> wrote:
>>>>
>>>>> Dear Sue,
>>>>>
>>>>> I support the adoption of BGP-CAR.
>>>>>
>>>>> > 1. Do you agree or disagree that these two drafts are functionally
>>>>> identical?
>>>>>
>>>>> Basically yes. But I would say they have different origins. BGP-CT is
>>>>> MPLS-native, whereas BGP-CAR is SR-native.
>>>>> From the SR/SRv6 operation point of view, CAR is simpler, more
>>>>> scalable/extensible and more consistent with SR Policy.  BGP-CT's
>>>>> indirection and the need for the Mapping Community seems unnecessarily
>>>>> complex.
>>>>>
>>>>> > 2. If you agree, should we have just one draft or do the
>>>>> operational difference encourage us to have two drafts?
>>>>>
>>>>> One draft is preferable. And BGP-CAR is a more natural extension,
>>>>> especially for SR/SRv6, which is characterized by simplicity.
>>>>>
>>>>> > 3. If you disagree, do the functional differences encourage us to
>>>>> have one or two drafts adopted?
>>>>>
>>>>> Thanks,
>>>>> Miya
>>>>>
>>>>> On Thu, Jul 7, 2022 at 3:17 AM Susan Hares <[e-mail]> wrote:
>>>>>
>>>>>> This begins a 2-week WG Adoption call (7/6/2022 to 7/20/2022) for the
>>>>>> following drafts:
>>>>>>
>>>>>>    - draft-dskc-bess-bgp-car-05.txt
>>>>>>
>>>>>> (https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/)
>>>>>>
>>>>>>    - draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
>>>>>>
>>>>>> (
>>>>>> https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/)
>>>>>>
>>>>>>
>>>>>> The associated drafts may be useful in your consideration.
>>>>>>
>>>>>> CAR:
>>>>>>
>>>>>>    - draft-ietf-spring-segment-routing-policy-22
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/
>>>>>> draft-ietf-spring-segment-routing-policy/
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - draft-ietf-idr-segment-routing-te-policy-18
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/
>>>>>> draft-ietf-idr-segment-routing-te-policy/
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - draft-dskc-bess-bgp-car-problem-statement-05.txt
>>>>>>
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/
>>>>>>
>>>>>> CT
>>>>>>
>>>>>>    - draft-hegde-spring-mpls-seamless-sr-06.txt
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - draft-kaliraj-idr-multinexthop-attribute-02.txt
>>>>>>
>>>>>> (
>>>>>> https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - draft-kaliraj-bess-bgp-sig-private-mpls-labels-04
>>>>>>
>>>>>> (
>>>>>> https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/
>>>>>> )
>>>>>>
>>>>>>
>>>>>>
>>>>>> You may discuss adoption of one or both the main drafts (CAR or
>>>>>> Classful-Transport (CT)) in your response, and the associate drafts.
>>>>>>
>>>>>> A few caveats on your discussion:
>>>>>>
>>>>>>    1. Please do not worry whether the drafts belong in BESS or IDR.
>>>>>>
>>>>>> Both BESS and IDR work on creating relevant quality standards in BGP,
>>>>>>
>>>>>> and the chairs will work this out.
>>>>>>
>>>>>>
>>>>>>
>>>>>>    1. The IDR has spent time over 2020-2022 discussing these
>>>>>>    drafts.
>>>>>>
>>>>>> For background information, see the following links below.
>>>>>>
>>>>>> You can refer to these previous presentations or email discussions in
>>>>>> your responses.
>>>>>>
>>>>>>
>>>>>>
>>>>>>    1. Please constrain your discussion to whether these drafts
>>>>>>    should be adopted.
>>>>>>
>>>>>> I’ve started another email thread on whether path
>>>>>> establishment/distribution
>>>>>>
>>>>>> for a color (aka QOS/SLA/Transport Class) should be done via a
>>>>>>
>>>>>> specific BGP route (i.e., per-color NLRI) rather than as per-color
>>>>>> attributes on a route.
>>>>>>
>>>>>> https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/
>>>>>>
>>>>>>
>>>>>>
>>>>>> Questions (to consider) for these drafts:
>>>>>>
>>>>>> Jeff Haas (IDR Co-chair) posted a summary on March 21, 2022 that for
>>>>>>
>>>>>> route resolution and route origination/propagation, BGP-CAR and
>>>>>> BGP-CT are functionally identical,
>>>>>>
>>>>>> but operationally different.
>>>>>>
>>>>>>     (
>>>>>> https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/
>>>>>>
>>>>>>    1. Do you agree or disagree that these two drafts are
>>>>>>    functionally identical?
>>>>>>    2. If you agree, should we have just one draft or do the
>>>>>>    operational difference encourage us to have two drafts?
>>>>>>    3. If you disagree, do the functional differences encourage us to
>>>>>>    have one or two drafts adopted?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>>
>>>>> _______________________________________________
>>>>> Idr mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>
>>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*