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

[Ketan Talaulikar <[e-mail]>]

Hi Kaliraj,

That works for me.

Thanks,
Ketan


On Tue, Apr 9, 2024 at 8:02 AM Kaliraj Vairavakkalai <[e-mail]>
wrote:

> Please see inline. KV2>
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Monday, April 8, 2024 at 1:45 AM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Susan Hares <[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]*
>
>
>
> 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?
>
>
>
> KV2> Correct. Pls see inline for further responses.
>
>
>
> 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 ...
>
>
>
> KV2>  Ack! CT provides operational ease by default, and flexibility to
> suite real world scenarios.
>
>
>
> 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.
>
>
>
> KV2> The IANA team asked me to add this text, and they reviewed, approved
> it.
>
> KV2> IANA does have the action of reserving value 0 for best-effort TC.
>
>
>
> 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]."
>
>
>
> KV2> We can do this:
>
>
>
> KV2>        As noted in Sec 4 and Sec 7.10, 'Transport Class ID' is
> interchangeable with 'Color'. For purposes of backward compatibility with
> usage of
>
> KV2>        'Color' field in Color extended community as specified in
> [RFC9012] and [RFC9256], the range 1-4294967295 uses 'Private Use' as
> Registration Procedure.
>
>
>
>
>
> 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$>
>
>