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

[Kaliraj Vairavakkalai <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, March 22, 2024 at 3:09 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>, idr@ietf. org <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, March 22, 2024 4:49 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; idr@ietf. org <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, March 21, 2024 11:05 PM
To: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: idr@ietf. org <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DLzvBSclY11M9ydeChee7lthNoRGVKchrUQNbjZDHsxSLSevYErz0a9fSwXHgXUdpEqXk0NAZeTCIiM50KG2$>