[Idr] Color & TC semantics (was Re: I-D Action: draft-ietf-idr-bgp-ct-30.txt )

Hi Kaliraj/Nats,

I have one concern about this change introduced in the latest version of
the document.

https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html#section-13.4

As noted in Sec 4 and Sec 7.10, 'Transport Class ID' is interchangeable
with 'Color'. *For purposes of backward compatibility with usage of 'Color'
field in Color extended community, the range 1-4294967295 uses 'Private
Use'* as Registration Procedure.

Per RFC9012, there is no special semantics associated with the color value
0. The CT draft has introduced special semantics for TC ID 0 (this is not
an issue) but seems to be associating those semantics to Color as well. Can
you please clarify the intent here?

If you remember, I had this concern with the introduction of a new term TC
for something that seems the same as Color.

I had also suggested to simply do away with the IANA registration for TC -
ID and just specify in the spec the special semantics of zero TC-ID. Doing
IANA registration for TC-ID this way is quite pointless. We have several
instances in routing protocols where we define protocol constant/special
values [1].

Thanks,
Ketan

[1] An example from top of my mind is in ISIS
https://datatracker.ietf.org/doc/html/rfc5305#section-3 where
MAX_PATH_METRIC is defined or OSPF RFC2328 where LSInfinity is defined
without the need for an IANA registration.

On Mon, Mar 18, 2024 at 9:42 AM <internet-drafts@ietf.org> wrote:

> Internet-Draft draft-ietf-idr-bgp-ct-30.txt is now available. It is a work
> item of the Inter-Domain Routing (IDR) WG of the IETF.
>
>    Title:   BGP Classful Transport Planes
>    Authors: Kaliraj Vairavakkalai
>             Natrajan Venkataraman
>    Name:    draft-ietf-idr-bgp-ct-30.txt
>    Pages:   75
>    Dates:   2024-03-17
>
> Abstract:
>
>    This document specifies a mechanism referred to as "Intent Driven
>    Service Mapping".  The mechanism uses BGP to express intent based
>    association of overlay routes with underlay routes having specific
>    Traffic Engineering (TE) characteristics satisfying a certain Service
>    Level Agreement (SLA).  This is achieved by defining new constructs
>    to group underlay routes with sufficiently similar TE characteristics
>    into identifiable classes (called "Transport Classes"), that overlay
>    routes use as an ordered set to resolve reachability (Resolution
>    Schemes) towards service endpoints.  These constructs can be used,
>    for example, to realize the "IETF Network Slice" defined in TEAS
>    Network Slices framework.
>
>    Additionally, this document specifies protocol procedures for BGP
>    that enable dissemination of service mapping information in a network
>    that may span multiple cooperating administrative domains.  These
>    domains may be administered either by the same provider or by closely
>    coordinating providers.  A new BGP address family that leverages RFC
>    4364 procedures and follows RFC 8277 NLRI encoding is defined to
>    advertise underlay routes with its identified class.  This new
>    address family is called "BGP Classful Transport", a.k.a., BGP CT.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ct/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-30
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-ct-30
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>