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

Dear IDR WG,



As co-author of CT, I support IDR WG adoption of CT.

1.       Do you agree or disagree that these two drafts are functionally
identical? Agree

2.       If you agree, should we have just one draft or do the operational
difference encourage us to have two drafts? Only one draft should be
adopted for interoperability. CAR & CT are functionally identical, however
adopting both drafts could result in interoperability issues.

3.       If you disagree, do the functional differences encourage us to
have one or two drafts adopted?

The functional differences are in the mechanisms used by each architecture
where CAR is using new mechanisms to provide a solution for a very narrow
corner case color mapping between domains, where CT is using existing
proven Layer 3 VPN mechanisms and provides a much broader sweep of
technologies supported.


CT & CAR provide similar functionally, however the mechanisms and inner
workings are vastly different.  Therefore, only one proposal should be
adopted to ensure interoperability.



Both CAR & CT act at both the Service layer & VPN layer and provide mapping
of VPN service route color to transport layer technology using next hop
resolution schemes.



CT provides an overall broader sweep of technologies supporting RSVP-TE and
all inter-as options widely deployed today as well as Segment Routing
SR-MPLS & SRv6.



*Below is a comparison & contrast of CAR & CT and reasons why I chose to
adopt CT.*



*CAR-Color Aware Routing:*



·         CAR provides an E2E intent aware path with a new key argument for
(key,color) (E3,C1) combination for mapping VPN service route coloring
intent to route resolution underlay technology RSVP-TE, SR Policy etc
between domains.

·         CAR supports color pruning and grafting with transport route
resolution for supported underlays IGP-FA, SR Policy, RSVP-TE, BGP CAR,
BGP-LU.

·         CAR supports a very unique corner case of inter-domain color
mapping and multihoming.

·         CAR introduces a new NLRI which cannot express diverse paths for
traffic engineering.






*CT -Classful Transport Planes:*



·         CT provides a VPN Service route coloring mapping community
Color:0:<n> to transport layer CT RIB database next hop resolution for
current and future steering technologies, RSVP-TE, SR-TE, Flex Algo.



·         CT Supports Inter AS option A, B, C, AB.



·         CT provides coloring at the transport layer and service layer.



·         CT is very similar to SR-TE with TEA like color signaling
mechanism from egress PE to ingress with a mapping community color
Color:0:<n>, where ingress PE resolves mapping community color to CT RIB
next hop steering technology, RSVP-TE, SR-MPLS SR-TE, SRv6 SR-TE, Flex Algo.



·         CT is based on inter-as option C end to end LSP, and is in the
same vein of BGP-LU, as well as provides a loose coupling of overlay layer
VPN service route coloring to underlay layer technology coloring providing
a “flexible” mapping to underlay transport steering technology.  CT
provides the ability to stitch disparate inter-domain underlays, RSVP-TE,
SR-MPLS, SRv6 domain segments, into an end to end (E2E) LSP.



·         CT supports option B without SAFI 76 for segmented LSP similar to
Option-B not using BGP-LU.



·         CT’s common operator use case is for Seamless MPLS end to end LSP
deployed today by operators with RSVP-TE / BGP-LU. BGP-LU can remain side
by side with CT when migrating brown field to CT.



·         CT SAFI 76 utilizes existing well known L3 VPN RD, RT & RTC
mechanisms to import the transport protocols RSVP-TE, SR-TE, Flex Algo next
hops into the CT RIB.



·         CT is not a transport layer steering mechanism, however it does
utilize proven L3 VPN technologies with a L3 VPN VRF style “CT Transport
RIB” of all transport layer steering technologies for next hop resolution,
without direct overlay to underlay fixed underpinning, providing underlay
mapping flexibility.



·         CT optimizes per VRF to RSVP-TE mapping per VRF macro flow
steering capability used widely by operators which involves next-hop
rewrite with a 1-1 mapping of VPN Service route to loopback resulting in
scalability issues, where now with CT the service route coloring can map to
a single loopback using unique RD on the PEs, similar to existing mechanism
used on RR L3 VPN use case with unique RD to allow all diverse paths to be
advertised.



·         CT provides an optimization for Inter-AS CSC (Carrier Supporting
Carrier) Hierarchical LSP where the customer carrier transport prefixes can
now be carried in CT RIB for scalability segregated from VPN SAFI 128
prefixes and thus allows for customer carrier transport prefixes per prefix
label allocation.



·         CT supports unique RD per PE on VPN which provides diverse paths
which allows for the elimination of multiple loopbacks on egress PE for
both RSVP-TE & SR-TE.   SR-TE plus Flex Algo allows for a single loopback
with multiple Algo, where CT can provide a similar same next-hop rewrite
with single Loopback using unique RD for Next hop path selection.



·         CT with unique RD provides multipath or 1:1 protection for backup
paths 50ms restoration, BGP PIC Edge like pre-programmed backup path.



·         CT uses proven existing L3 VPN mechanisms of RTC membership for
grafting / pruning the colors within the AS, so only the Service route & CT
RIB transport colors necessary exist on each PE.  This allows for the CT
Transport RIB database on each PE to only contain pertinent interesting
intent based Next hop resolution routes which are to be imported from RR.



·         IETF Network Slice provisioning by Network Slice Controller (NSC)
can use the VPN Service Route mapping community to map VPN overlay traffic
to the desired underlay transport slice using CT RIB transport database
next hop resolution.



Multi Next hop Draft and use with CT:

https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-02



·         Multi next hop used w/ or w/o CT provides a labeled next hop that
can be signaled from egress to ingress and provide multipath or protection
for the VPN service routes and can be used with or without CT and can be
used with BGP-LU.



MPLS Name spaces and use with CT:

https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-04



·         MPLS Name Spaces can be used w/ w/o CT presented at IETF 111
provides provide an abstraction of all the steering protocol technology
loopbacks for all PEs, now abstracted to a single labeled prefix to provide
inter-as options b/c combo, to instantiate the end to end inter-as LSP
using only a single labeled prefix abstraction of the domain or AS
propagated between domains for inter-as scalability.  This scalability
feature avoids the massive flooding of loopbacks for seamless MPLS.


Multi Next hop & MPLS Name spaces can be extended to the CE layer as well.

Kind Regards

Gyan

On Wed, Jul 6, 2022 at 2:17 PM 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
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*