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

[Ketan Talaulikar <[e-mail]>]

Hi Kaliraj,

We've had this debate about the very need for introduction of TC and
mapping community terminologies instead of using Color. This isn't the time
to rehash - I believe we agreed to disagree.

My concern is that there should not be any confusion about the semantics
and the use of Color as in the Color Ext Comm and all the myriad use-cases
defined for it in existing documents. Can you please confirm that the CT
draft does not intend to change any semantics of Color as specified in
RFC9012 and RFC9256?

Please check inline below for responses.

On Wed, Apr 3, 2024 at 12:14 AM Kaliraj Vairavakkalai <[e-mail]>
wrote:

> Ketan, Susan,
>
>
>
> TC-ID indeed intends to be interchangeable and backward compatible with
> Color values in Color ext-comm.
>
> So that service routes with color:0:N can map to the transport tunnels
> with TC-ID N.
>
> This provides ease of operations.
>
>
>
> However, it is not mandatory that overlay routes have the same color value
> as transport tunnels.
>
> Customized resolution schemes can be used in cases where they are
> different. This is described
>
> in sections 7.3, 7.8, 11.2.
>
>
>
> Bottom-line: Though custom resolution schemes can be used to deal with the
> differences, we feel it is
>
> necessary to maintain the backward compatibility for ‘ease of Operation’.
> Where same color N is used
>
> in both service and transport layers.
>

KT> I couldn't agree more! This is going to be the de facto way. In any
case, I don't want to rehash ...


>
>
> This is the reason the text in 13.4 is conservative, and makes the range
> 1-4294967295 as ‘Private Use’,
>
> to be compatible with usage of color in service layer today. Just because,
> we value ‘ease of operations’.
>

KT> IANA considerations section simply contains instructions for the
actions to be undertaken by the IANA team. It is not the place for some
specification or providing rationale for something. Please refer to RFC8126.


>
>
> About best-effort TC,
>
>
>
> In the transport-layer, we reserve 0 as the well-known default value to
> use in
>
> “transport target extended community”, while still providing configuration
> to
>
> use a different value in case 0 cannot be used for some reason. This is
> described in 7.9:
>
>
>
>       Alternatively, BGP CT may also be used to carry the best effort
>
>       tunnels.  This document reserves the Transport Class ID value 0 to
>
>       represent "Best Effort Transport Class ID".  However,
>
>       implementations SHOULD provide configuration to use a different
>
>       value for this purpose.  Procedures to manage differences in
>
>       Transport Class ID namespaces between domains are provided in
>
>       Section 11.2.2.
>
>
>
>
>
> Service routes resolution over best-effort TC works as specified in sec
> 7.9:
>
>
>
>       When a BGP speaker receives an overlay route without any explicit
>
>       Mapping Community, and absent local policy, the best effort
>
>       resolution scheme is used for resolving the BGP next hop on the
>
>       route.  This behavior is backward compatible to behavior of an
>
>       implementation that does not follow procedures described in this
>
>       document.
>
>
>
> In general, there cannot be any conflict for best-effort resolution in
> service routes, because we don’t
>
> use color:0:0 today to resolve over best-effort, we just use ‘absence of
> any color community’
>
> on the service route to resolve over best-effort.
>

KT> Correct. This is the semantics as per the existing RFCs.


> With CT, same model works. And also, explcitly
>
> coloring the route (using color:0:0 or a different color:0:<BE>) will also
> work.
>
>
>
> Sue and IANA team reviewed the IANA section changes and OK’d it.
>

KT> Like I mentioned, the IANA team would likely not care since there is no
action in that text for them to take.


>
>
> One change in text I see that can be done is: sec 13.4 heading could be
> called just
>
> “Transport Class ID” without the ‘Best Effort’ part. I can do that change.
>

KT> Given the lack of clarity, we should either remove that text or if you
feel strongly to retain that then add further text that says "This document
does not alter the semantics and usage of 'Color' field in the Color Ext
Comm as specified in [RFC9012] and [RFC9256]."

Thanks,
Ketan


>
>
> Thanks,
>
> Kaliraj
>
>
>
> PS: I’m just back home from travel, hence the delay in response. Wish Sue
> a speedy recovery.
>
>
>
>
>
> Juniper Business Use Only
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Friday, March 22, 2024 at 3:09 AM
> *To: *Susan Hares <[e-mail]>
> *Cc: *Kaliraj Vairavakkalai <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>
> *Subject: *Re: [Idr] Color & TC semantics (was Re: I-D Action:
> draft-ietf-idr-bgp-ct-30.txt )
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Friday, March 22, 2024 4:49 AM
> *To:* Susan Hares <[e-mail]>
> *Cc:* Kaliraj Vairavakkalai <[e-mail]>; [e-mail];
> idr@ietf. org <[e-mail]>
> *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
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html*section-13.4__;Iw!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIpXyNUkF$>
>
>
>
> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, March 21, 2024 11:05 PM
> *To:* Kaliraj Vairavakkalai <[e-mail]>; [e-mail]
> *Cc:* idr@ietf. org <[e-mail]>; Susan Hares <[e-mail]>
> *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 <[e-mail]>
> 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
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html*section-13.4__;Iw!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIpXyNUkF$>
>
>
>
> 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
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5305*section-3__;Iw!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIlh9YdXc$>
> 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 <[e-mail]> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-ct/__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIl-yOMGL$>
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-30
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-30__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIsMQaMDH$>
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-ct-30
> <https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-ct-30__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIih_xSPK$>
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org
> <https://urldefense.com/v3/__http:/rsync.ietf.org__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIsA6bu46$>
> ::internet-drafts
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIiM50KG2$>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIiM50KG2$>
>
>