Subject: Re: [Idr] Color domains in BGP routes with color

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Fri, 1 Apr 2022 11:55:31 +0000

Hello Sue,

Apologies for the delay; catching up with the email threads.

A CAR route can only have a single LCM Extended Community. As Jeff suggested, we will add clarifying and error handling text in the next version.

Regards,
-Dhananjaya

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 24, 2022 at 7:44 PM
To: "'idr@ietf. org'" <[email-masked]>
Cc: 'Robert Raszuk' <[email-masked]>
Subject: Re: [Idr] Color domains in BGP routes with color

Dhananjaya:

My question posted here:
https://mailarchive.ietf.org/arch/msg/idr/Rm_pnETWbt1gy2kxoNZMmc8BtGY/

ask about the error handling if LCM Extended community is listed twice in the PDU.

My question is not the larger question on route resolution that
Jeff asked you here:

https://mailarchive.ietf.org/arch/msg/idr/734Fj97YIPIeSF2BEnMGtidMoz8/

Below are excerpts that lead me to this position.
Please let me know if I missed something in your text.

Cheers, Sue

Excerpts from
  https://mailarchive.ietf.org/arch/msg/idr/734Fj97YIPIeSF2BEnMGtidMoz8/
> DR## As you phrased it, LCM color is used when the route is used for resolution. Just to restate, there is no rewrite of the BGP NLRI color as it traverses hops.

[Jeff]    Thanks.  The property I'm trying to ensure we're clear on is that the RIB
[Jeff]    key, (E,C) is not necessarily the resolution key (E, effective color).  The
[Jeff]    effective color will be the C from the NLRI unless an LCM is present.

DR>> Yes. Section 2.8 of the BGP CAR draft states this along with the rationale.

Excerpts from draft-dskc-bess-bgp-car-03.txt in
Section 2.8 states a set of procedures:

   o  The nodes within the receiving domain 1 use the local color

      encoded in the LCM-EC for next-hop resolution and BGP CAR route

      installation

….

   o  In the rare case of color incongruence, the local color encoded in

      LCM-EC takes precedence

:”Section 2.9 describes the procedures of this draft with the following text:

:

:  When a CAR route crosses the originator color domain's boundary, LCM

:   EC is added.  LCM EC conveys the local color mapping for the intent

:  (e.g. low latency) into transit or remote color domains.

:  The LCM EC MAY be used for filtering of BGP CAR routes and/or for

:  applying routing policies for the intent, when present.

It does not specify whether the LCM Extended community can be listed twice in the PDU.

I also do not find the text in 2.10 on fault management.

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Thursday, March 24, 2022 8:10 AM
To: Sue Hares
Cc: Robert Raszuk; idr@ietf. org
Subject: Re: [Idr] Color domains in BGP routes with color

On Mar 24, 2022, at 7:16 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Did you find any normative text that restricts to a single LCM-EC?

This was replied to by Dhananjaya:
https://mailarchive.ietf.org/arch/msg/idr/734Fj97YIPIeSF2BEnMGtidMoz8/

-- Jeff

---

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Mon, 4 Apr 2022 14:10:52 +0000

A few specific comments, just to clarify some incorrect assumptions stated below about CAR.

To restate, CAR creates color-aware paths in the transport and the intent/characteristics provided by them is represented by color. A service is steered over these CAR paths based on the intent requested/expressed in the service route using a Color Ext-Comm.

For the typical case of automated steering of traffic for a service route, the Color in the Color Ext-Comm maps to the Color in the CAR route NLRI (similar to the way it mapped to an SR-Policy in the SR-TE solution (https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22)).

However, this is not hard-coded nor the only option. The Color construct is flexible and expressive enough to support different requirements.

For instance, the Color in the service route Ext-Comm may map to multiple other colors via a local policy. This is already described in the SR-Policy draft, one example being support of per-flow steering.

There isn’t a compelling reason to add new constructs such as mapping communities or transport classes at different levels of the hierarchy to achieve the necessary flexibility.

The “mapping community” appears to be a distinction without a difference, and the claim in the thread below incorrect. The community values also either needs to be coordinated if the service routes goes across different domains that may reuse the values, or needs to be rewritten at the boundary. The same can be done with Color.

Regards,
-Dhananjaya

From: Idr <[email-masked]> on behalf of Natrajan Venkataraman <natv=[email-masked]>
Date: Thursday, March 24, 2022 at 4:13 AM
To: Robert Raszuk <[email-masked]>, Jeffrey Haas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Color domains in BGP routes with color

Hi Robert,

Please check replies highlighted with NV> inline.

Regards,
-Nats-

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Wednesday, March 23, 2022 at 5:32 AM
To: Jeffrey Haas <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] Color domains in BGP routes with color
[External Email. Be cautious of content]

All,

My intention is to illustrate that for each of the two proposals below
that as routes go from one domain to another that there are situations where
remapping may have issues.

Practically speaking I am not so sure about the value of complexity introduced by the notion of remapping colors at domain boundaries. That goes against the KISS principle.

NV> ------------{ Start…
I agree with you practically. However, “actual” customer use cases are not always practical or ideal. There have been known features that customers (predominantly DC) have requested for end to end connectivity between multiple color domains. One such requirement was MPLS RSVP LSPs with Abstract-hop ERO where the LSP have to navigate end to end through more than one color domains where each abstract hop provides the color to go forward. Here, the customer has specifically defined different color domains within their administrative domain(where the color domains are intra-as). Therefore, what is practical might not be what the customer “actually” wants. This is not a disagreement but purely factual based on the deployments that we see where community rewrites happen even today with any color constructs at the AS boundaries.

https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/statement/abstract-hop-edit-protocols-mpls.html
https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/lsp-labels.html#id-example-configuring-abstract-hops-for-mpls-lsps

NV> ---------End.}

Instead of remapping I would simply propagate tuples (ASN-Color). Now the meaning of color in each domain has to be known via some form of publishing it. Be it a web page or pub-sub or xyz is a different topic.

Why do we need to keep colors flat ? Moreover colors signalled by BGP interdomain may not be the same as intradomain colors as build by some constrained protocol.

NV> ------------{ Start…

For Service routes mapping to CT transport routes, such an agreement is possible. I will try to explain how.

Can a color uniquely identify the overall end-to-end service intent? This is where the proposals CAR and CT differ w.r.t expressing intent to multiple color domains. IMHO, color is a function of the transport and intent is a function of the end-to-end service realized as a sequential ordering of colors (, a Color Scheme). Color does not fully represent the service intent.

  1.  In CAR, Color is the Intent. Therefore, the service route carries the exact color in the CAR NLRI is encoded in the form of a color community as part of the Service Route which resolves to the CAR route. However, the fallback decision is strictly local to the ingress domain ingress PE. The Ingress PE needs specific policy (per-service / per-prefix) as to what color the Ingress PE needs to fallback when the EP:Color tunnel is down. i.e, the fallback order needs to be policed.
  2.  In CT, Color (Transport Class) is a collection of transport properties that contributes to the overall intent of the service. This is where the “extended mapping community” comes in. The CT transport routes as well as service routes carry extended mapping community. This maps not just to a color but a “resolution scheme” which can be configured and there is no need for local policy at each service/border node but a re-representation of a “globally unique color resolution scheme” that represents the color sequence and its corresponding fallback order, uniquely identified and shared via the extended mapping community. For example,

     *   MapCOM - Color:0:C1 resolve strictly over Transport Class C1 (used by CT transport routes for Color C1)
     *   MapCOM - Color:0:C2 resolve strictly over Transport Class C2 (used by CT transport routes for Color C2)
     *   MapCOM – Color:0:C1BE resolve to Transport Class C1 fallback resolve to Best Effort (Used by Service routes)  <<<
     *   MapCOM – Color:0:C1C2 resolve to Transport Class C1 fallback resolve to Transport Class C2 (Used by Service routes) <<<

In CT,

the extended mapping community helps in creating the same resolution schemes across color domains identified by the mapping community values C1,C2,C1BE,C1C2. CT Transport routes are attached with extended mapping community values C1 or C2 (depending on the transport class). Service routes are attached either with extended mapping community C1BE or C1C2 (uniquely identifiable values that do not represent individual colors)

CT Transport routes:
Rewriting of the mapping community “has to happen” to transit a different color domain since colors are uniquely identified by C1 and C2 values which represent individual colors. This is also where CAR brings in the Local Color Mapping (LCM) community.

Service routes:
Rewrites to Service route mapping communites are not needed as they are uniquely identifying a resolution scheme (sequential ordering of colors) and not the individual color. That being said, different administrative domains can actually come to an agreement on uniquely identifying resolution schemes than uniquely identifying colors easily.

For example.

Color domain A:- Low-Delay: Gold(100), CBR: Silver(200)
Color domain B:- Low-Delay: Blue(400), CBR: Green(500)

Now, the resolution scheme for color C1 falling back to C2 is identified by value Color:0:C1C2 extended mapping community that the service route maps in Color Domain,

  1.  {Resolve to Gold, Fallback resolve to Silver}
  2.  {Resolve to Blue, Fallback resolve to Green}

As we could see, the service intent is achieved irrespective of the differences in color across color domains under same or different administrative domains where in, the abstract value of the resolution scheme (or the sequential order of colors that the service wants) can be easily agreed upon.

NV> ------------End. }

Here is why I posting the above doubt:

* if things are under same admin control we could presume there is no issue. When you build policy which takes into account each domain's color mapped to some anchor points (on the edge or within a domain) and therefor end to end path will likely be formed and work as expected

* if things are not under same administration each color/class may mean completely separate thing unless we define in stone what it should mean. And if we do that there is no need to remap anything any longer.

NV> ------------{ Start… Example describing how color is different from intent

This is from one of the CT slides for IETF IDR. With CT, the following differential treatment for the different service prefixes of the SAME service at the SAME Service Node or Border Nodes is possible.

Say,

  *   R1 wants the intent : C1 primary, fallback to best-effort
  *   R2 wants the intent : C1 primary, fallback to C2
  *   R3 wants the intent : C1 primary, fallback to C3

Which is an use case where all service prefixes want C1 as primary but have different fallback order.

This is achieved using Mapping Communities, as below:

  *   R1 advertised with M1 (Color:0:<C1BE>),

     *   maps to Resolution-Scheme1: Transport classes {C1, best-effort}

  *   R2 advertised with M2, (Color:0:<C1C2>) -

     *   maps to Resolution-Scheme2: Transport classes {C1, C2}

  *   R3 advertised with M3, (Color:0:<C1C3>) – Abstract value

     *   maps to Resolution-Scheme3: Transport classes {C1, C3}

Here C1BE, C1C2, C1C3 are abstract values and do not represent C1, C2 or C3 that can be easily agreed between different administrative domains.

NV> ------------End. }

Thx a lot,
R.

Juniper Business Use Only