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