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

Sure, we can wait for Kaliraj.

Another simple solution is to just remove the following text from section
13.4 since it is not really necessary.

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

Thanks,
Ketan

On Fri, Mar 22, 2024 at 2:49 PM Susan Hares <shares@ndzh.com> wrote:

> Ketan:
>
>
>
> My understanding was that
>
>    1. TC-id = 0 was only defined for transport class ID,
>    2. Configuration of the transfer between color and transport class ID
>    was an implementation specific “knob”.
>
>
>
> I could be wrong.  Kaliraj responds really quickly if he can.  I suspect
> he’ll respond to us by Monday or Tuesday.
>
>
>
> Cheers, Sue
>
>
>
> PS – Warning – in 8 hours I start my trip back home.  I’ll try to respond
> from airport, but you know how travel is.
>
>
>
>
>
> *From:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Sent:* Friday, March 22, 2024 4:49 AM
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* Kaliraj Vairavakkalai <kaliraj@juniper.net>; natv@juniper.net;
> idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] Color & TC semantics (was Re: I-D Action:
> draft-ietf-idr-bgp-ct-30.txt )
>
>
>
>
>
> Hi Sue,
>
>
>
> I don't mind if the registry is retained. Not using the registry was a
> solution - not the issue.
>
>
>
> My concern was:
>
> 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?
>
>
>
> I hope this document is not trying to change the semantics of the color
> value "0" in the Color extended community.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Fri, Mar 22, 2024 at 2:11 PM Susan Hares <shares@ndzh.com> wrote:
>
> Ketan and Kaliraj:
>
>
>
> Ketan thanks for mentioning this point.
>
>
>
> On the following comment from Ketan:
>
>
>
> “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].”
>
>
>
> IANA has checked Kaliraj’s usage of the registry.  As it stands, Ketan’s
> was the only comment on this matter of registry during the WG LC.  I had a
> long chat with Kaliraj at IETF-119 about the pros/cons of the registry.
> He’s aware of all the choices of assignment.
>
>
>
> [Shepherd’s hat on]
>
> My current plan is to note this issue in my shepherd’s report.  I will ask
> if the IESG has a strong preference.  If the IESG has a strong opinion, I’m
> sure John Scudder will help me adjust it.
>
>
>
> At this point, I do not see any profit in holding up sending the document
> to the IESG.
>
> [Shepherd]s hat off]
>
>
>
> Let me know what you think about this approach.
>
>
>
> Sue
>
>
>
>
>
> *From:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Sent:* Thursday, March 21, 2024 11:05 PM
> *To:* Kaliraj Vairavakkalai <kaliraj@juniper.net>; natv@juniper.net
> *Cc:* idr@ietf. org <idr@ietf.org>; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] Color & TC semantics (was Re: I-D Action:
> draft-ietf-idr-bgp-ct-30.txt )
>
>
>
>
>
> A gentle reminder on this one please ...
>
>
>
>
>
> On Mon, Mar 18, 2024 at 6:00 PM Ketan Talaulikar <ketant.ietf@gmail.com>
> wrote:
>
> 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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>