Subject: [Idr] BGP CAR - multiple color domains

From: <[email-masked]>
Date: Tue, 22 Mar 2022 17:45:06 +0000

Hi BGP CT authors,

As the subject is a bit vast, I'd like to better understand your operational concern with multiple colors domains.

At your convenience, I think that three texts could be used to support our discussion

  1.  Please feel free to explain the issue your seeing with you own text.
  2.  This 1 page is probably a good start https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8
  3.  I've tried to describe the whole route journey in the below text using an example from a requirement document https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2.9 and you can raise the issue when you see it.

So below is option 3 text. It's much longer and painful so if "2" is good enough you could skip the below text.

Please note that I'll use a terminology from https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2 and that colored route are not to be confused with color-aware route.

Let's consider option C with 2 domains:

     +----------------+  +----------------+
     |            E3  |  |                | V/v with C1
     |----+          +----+          +----|/
     | E1 |          | N2 |          | E2 |\
     |----+          +----+          +----| W/w with C2
     |                |  |                |
     |    Domain 1    |  |    Domain 3    |
     +----------------+  +--- ------------+

   *  Service routes MUST be colored using BGP Color Extended-Community
      to request intent

      -  V/v via E, colored with C

   *  Colored service routes MUST be automatically steered on an
      appropriate color-aware path

      -  V/v via E with C is steered via (E, C)

First color resolution seem the above one.
A priori the color from the VPN route (V/v via E with C) is the same as the color from the transport route (E, C) as both are chosen by the Egress domain (Domain 3).
Agreed or am I missing something?

Now in domain 1 and let's assume that domain 1 uses color C to mean "high bandwidth" while domain 3 use color C to mean "low delay"
First, let's notice that key is (E,C) so we are not going to mix/compare color C between (E2, C) and (E3, C). We are interested in different colors to reach a specific destination E, and all colors for that destination are consistent (defined in the domain of E). So I don't see any issue with ECMP or protection that have been raised during the meeting.

Let's continue with next steps

   *  Color-aware routes MAY resolve recursively via other color-aware

      routes

      -  (E, C) via N recursively resolves via (N, C)

Here I can see the mismatch as C from (E,C) from domain 3 while C from (N,C) is from domain 1 and hence may not be directly comparable without a mapping. So mapping is needed (I think all solutions will require a (re)mapping).
Except for this remapping, is there a big issue such as confusion?

Coming back to the remapping, this seems to depend on the internal routing solution used in Domain 1:
- If FlexAlgo, N2 can probably do the mapping : N2, C1 is advertised in Domain 1 FA associated with the right meaning (e.g. low delay)
- worst case we need to re-color i.e. express that the color-aware route (E,C) need to be resolved using a specific color. Personally, I'm not sure why the same BGP Color Extended community can't be reused just like https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2.3

but that's a detail and defining a different community Local-Color-Mapping-Extended-Community https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8  which seems to indicate the same thing (the color of the color-aware route to use when resolution is done).

That's all for the route journey. Hopefully all that text will be useful to pinpoint the issue that you have in mind.

--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Wed, 23 Mar 2022 01:10:41 +0000

Hi Bruno,

Please consider the following topology.

Two parallel Cores Domain2, Domain3. Domain1 having ingress node PE1. EBGP peer Peer1 multihomed to two core domains as shown below.

Traffic direction is PE1->Peer1. In each domain left side is ingress, right side is egress.

Usecase is: EPE forwarding towards Peer1.

Domain2, Domain3 egress ASBRs originate Peer1/32 route in the Transport-family (CAR for this discussion).
Similar to how we do with BGP-LU today (BGP-LU EPE1).

                                          Color C1
                                     +----------------+
                                     |  Core Domain2  |
                                    /+----------------+\
            +--------------------+/                     \+--------+
            |  Ingress  Domain1  |                       | Peer1  |
           PE1                   |                       +--------+
            +--------------------+\                     /
                Color  C1          \+-- --------------+/
                                    |   Core Domain3  |
                                    +-----------------+
                                          Color C2

Domain1, Domain2 use color C1 value to indicate a certain Transport-class (eg. 'high-bandwidth'). Domain3 uses C2 for same.

Now, the ingress ASBRs in Domain3 will use LCM(Color=C2) in (Peer1, C2) advertisement towards Domain1, such that Domain1
will remap to LCM(C1). So Domain1 egress ASBR will have the following routes in the BGP-RIB for CAR family:

        (Peer1, C1)
        (Peer1, C2), LCM(C1).

As you can see, Multipath/Protection can no longer be computed on the BGP NLRI prefix (Peer1, Cx). It needs to be computed
based on (Peer1, Effective-color C1). This is what I was trying to point out.

Further, Ingress PE1 will have the same information at transport-layer. And when resolving a Service-route received with
Nexthop Peer1, Color:0:C1, it cannot use just the BGP-NLRI prefix (Peer1, C1) as the resolving route. Doing so will miss
the Multipath/Protection. It will need to resolve over the (Peer1, Effective color C1). So that the service prefix gets
Multipath/Protection towards the two domains Domain2, Domain3.

Similar usecase can be constructed for Anycast EP in Domain2, Domain3 also.

So, though one may argue that EPE and Anycast Endpoints are not the common-case, I strongly believe such deployment scenarios
should be supported. Thanks to Ben for bringing up EPE as a use-case customers are interested in.

What we think of as corner case or may not happen - will certainly happen in the field. Nature has its way! Murphys Law!. :)

Thanks
Kaliraj

1 BGP-LU EPE: https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14

From: Idr <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Tuesday, March 22, 2022 at 10:45 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] BGP CAR - multiple color domains
[External Email. Be cautious of content]

Hi BGP CT authors,

As the subject is a bit vast, I’d like to better understand your operational concern with multiple colors domains.

  1.  Please feel free to explain the issue your seeing with you own text.
  2.  This 1 page is probably a good start https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*section-2.8__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2atrcsQQ$>
  3.  I’ve tried to describe the whole route journey in the below text using an example from a requirement document https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2.9<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement*section-1.2.9__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2ZKQ6JLD$> and you can raise the issue when you see it.

So below is option 3 text. It’s much longer and painful so if “2” is good enough you could skip the below text.

Please note that I’ll use a terminology from https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement*section-1.2__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2QNUDSgu$> and that colored route are not to be confused with color-aware route.

Let’s consider option C with 2 domains:

Now in domain 1 and let’s assume that domain 1 uses color C to mean “high bandwidth” while domain 3 use color C to mean “low delay”
First, let’s notice that key is (E,C) so we are not going to mix/compare color C between (E2, C) and (E3, C). We are interested in different colors to reach a specific destination E, and all colors for that destination are consistent (defined in the domain of E). So I don’t see any issue with ECMP or protection that have been raised during the meeting.

Let’s continue with next steps

      routes

Coming back to the remapping, this seems to depend on the internal routing solution used in Domain 1:
- If FlexAlgo, N2 can probably do the mapping : N2, C1 is advertised in Domain 1 FA associated with the right meaning (e.g. low delay)
- worst case we need to re-color i.e. express that the color-aware route (E,C) need to be resolved using a specific color. Personally, I’m not sure why the same BGP Color Extended community can’t be reused just like https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement*section-1.2.3__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2X3yl744$>

but that’s a detail and defining a different community Local-Color-Mapping-Extended-Community https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*section-2.8__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2atrcsQQ$>  which seems to indicate the same thing (the color of the color-aware route to use when resolution is done).

That’s all for the route journey. Hopefully all that text will be useful to pinpoint the issue that you have in mind.

--Bruno

Thank you.

Juniper Business Use Only

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 14:02:31 -0400

Kaliraj: 

You have two communities for 

        (Peer1, C2), LCM(C1). 

But C1 becomes the Effective color in both cases.  

As you can see, Multipath/Protection can no longer be computed on the BGP
NLRI prefix (Peer1, Cx). It needs to be computed 

based on (Peer1, Effective-color C1).

When you are merging the two paths due LCM, explain why the algorithm is not
merging the multipath protection based on LCM?  

Where am I lost?  

After I've grasp this small point, I'll go on to the transport questions. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Kaliraj Vairavakkalai
Sent: Tuesday, March 22, 2022 9:11 PM
To: [email-masked]; [email-masked]
Subject: Re: [Idr] BGP CAR - multiple color domains

Hi Bruno, 

Two parallel Cores Domain2, Domain3. Domain1 having ingress node PE1. EBGP
peer Peer1 multihomed to two core domains as shown below.

Traffic direction is PE1->Peer1. In each domain left side is ingress, right
side is egress. 

Domain2, Domain3 egress ASBRs originate Peer1/32 route in the
Transport-family (CAR for this discussion). 

                                          Color C1

                                     +----------------+

                                     |  Core Domain2  |

                                    /+----------------+\

           PE1                   |                       +--------+

                                    |   Core Domain3  |

                                    +-----------------+

                                          Color C2

Domain1, Domain2 use color C1 value to indicate a certain Transport-class
(eg. 'high-bandwidth'). Domain3 uses C2 for same.

Now, the ingress ASBRs in Domain3 will use LCM(Color=C2) in (Peer1, C2)
advertisement towards Domain1, such that Domain1 

will remap to LCM(C1). So Domain1 egress ASBR will have the following routes
in the BGP-RIB for CAR family:  

        (Peer1, C1)

        (Peer1, C2), LCM(C1). 

As you can see, Multipath/Protection can no longer be computed on the BGP
NLRI prefix (Peer1, Cx). It needs to be computed 

based on (Peer1, Effective-color C1). This is what I was trying to point
out. 

Further, Ingress PE1 will have the same information at transport-layer. And
when resolving a Service-route received with 

Nexthop Peer1, Color:0:C1, it cannot use just the BGP-NLRI prefix (Peer1,
C1) as the resolving route. Doing so will miss 

the Multipath/Protection. It will need to resolve over the (Peer1, Effective
color C1). So that the service prefix gets 

So, though one may argue that EPE and Anycast Endpoints are not the
common-case, I strongly believe such deployment scenarios 

should be supported. Thanks to Ben for bringing up EPE as a use-case
customers are interested in.

What we think of as corner case or may not happen - will certainly happen in
the field. Nature has its way! Murphys Law!. :)

Thanks

Kaliraj

1 BGP-LU EPE:
https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14 

From: Idr <[email-masked]> on behalf of [email-masked]
<[email-masked]>
Date: Tuesday, March 22, 2022 at 10:45 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] BGP CAR - multiple color domains

Hi BGP CT authors,

As the subject is a bit vast, I'd like to better understand your operational
concern with multiple colors domains.

At your convenience, I think that three texts could be used to support our
discussion

1.	Please feel free to explain the issue your seeing with you own text.
2.	This 1 page is probably a good start
https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc
-bess-bgp-car-03*section-2.8__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz
_MeeS11L5-pq_RckcjiDJdGhd0N2atrcsQQ$> 
3.	I've tried to describe the whole route journey in the below text
using an example from a requirement document
https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statem
ent#section-1.2.9
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc
-bess-bgp-car-problem-statement*section-1.2.9__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE
6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2ZKQ6JLD$>  and you can raise
the issue when you see it.

So below is option 3 text. It's much longer and painful so if "2" is good
enough you could skip the below text.

Please note that I'll use a terminology from
https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statem
ent#section-1.2
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc
-bess-bgp-car-problem-statement*section-1.2__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6c
lhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2QNUDSgu$>  and that colored route
are not to be confused with color-aware route.

 

     |            E3  |  |                | V/v with C1

     |----+          +----+          +----|/

     | E1 |          | N2 |          | E2 |\

     |                |  |                |

 

      to request intent

 

A priori the color from the VPN route (V/v via E with C) is the same as the
color from the transport route (E, C) as both are chosen by the Egress
domain (Domain 3).

Now in domain 1 and let's assume that domain 1 uses color C to mean "high
bandwidth" while domain 3 use color C to mean "low delay"

First, let's notice that key is (E,C) so we are not going to mix/compare
color C between (E2, C) and (E3, C). We are interested in different colors
to reach a specific destination E, and all colors for that destination are
consistent (defined in the domain of E). So I don't see any issue with ECMP
or protection that have been raised during the meeting.

 

 

Here I can see the mismatch as C from (E,C) from domain 3 while C from (N,C)
is from domain 1 and hence may not be directly comparable without a mapping.
So mapping is needed (I think all solutions will require a (re)mapping).

Coming back to the remapping, this seems to depend on the internal routing
solution used in Domain 1:

- If FlexAlgo, N2 can probably do the mapping : N2, C1 is advertised in
Domain 1 FA associated with the right meaning (e.g. low delay)

- worst case we need to re-color i.e. express that the color-aware route
(E,C) need to be resolved using a specific color. Personally, I'm not sure
why the same BGP Color Extended community can't be reused just like
https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statem
ent#section-1.2.3
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc
-bess-bgp-car-problem-statement*section-1.2.3__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE
6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2X3yl744$> 

but that's a detail and defining a different community
Local-Color-Mapping-Extended-Community
https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc
-bess-bgp-car-03*section-2.8__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz
_MeeS11L5-pq_RckcjiDJdGhd0N2atrcsQQ$>   which seems to indicate the same
thing (the color of the color-aware route to use when resolution is done).

That's all for the route journey. Hopefully all that text will be useful to
pinpoint the issue that you have in mind.

--Bruno

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Wed, 23 Mar 2022 19:19:49 +0000

Pls see inline.. KV>

Thanks
Kaliraj
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, March 23, 2022 at 11:03 AM
To: 'Kaliraj Vairavakkalai' <kaliraj=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Idr] BGP CAR - multiple color domains
[External Email. Be cautious of content]

Kaliraj:

        (Peer1, C2), LCM(C1).

KV> Here, there is only one community, the LCM(C1). C2 is part of CAR NLRI (Peer1:C2).
KV> Let me use the notation: [ EP:ColorX,  LCM(ColorY)] to identify one CAR route. Where EP:ColorX is NLRI portion. LCM(ColorY) is the optional community carrying effective color.

KV> Yes, both the routes [Peer1:C1] and [Peer1:C2, LCM(C1)]  have the same effective color C1. But the NLRI prefix are not the same (highlighted parts on this line). So CAR BGP RIB prefix is also not the same.

When you are merging the two paths due LCM, explain why the algorithm is not merging the multipath protection based on LCM?
Where am I lost?

KV> CAR suggests to do the multipath/protection computations based on CAR NLRI key, which are not the same here. So the merging will not happen.
KV> IOW, It is not being done based on LCM.  Like Bruno also confirms in below email.
KV> Also, I see that the CAR documents (draft or the presentation) are underspecified on these aspects.

After I’ve grasp this small point, I’ll go on to the transport questions.

KV> Pls let me know if I got your question right. Thanks.

Sue

Hi Bruno,

                                          Color C1
                                     +----------------+
                                     |  Core Domain2  |
                                    /+----------------+\

        (Peer1, C1)
        (Peer1, C2), LCM(C1).

Thanks
Kaliraj

1 BGP-LU EPE: https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14__;!!NEt6yMaO-gk!SWHz_E5D6LnjRWtWKEUuLcEWYgMxzZPW35IVqn9NSPQiZu5db0DvNHHeRpz1fbNh$>

Hi BGP CT authors,

      routes

--Bruno

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Mar 2022 12:54:24 -0400

Kaliraj: 

Would you mind if I confirmed a few details you are stating?  

I'm trying to link your statements to CAR text 

so I can understand your opinions.  

Thanks, 

Sue 

PS - These questions are standing on the shoulders of Q1/Q2 exchange by
Jeff.  

As you noted, I agree with his analysis. 

From: Idr [mailto:[email-masked]] On Behalf Of Kaliraj Vairavakkalai
Sent: Wednesday, March 23, 2022 3:20 PM
To: Susan Hares; 'Kaliraj Vairavakkalai'; [email-masked];
[email-masked]
Subject: Re: [Idr] BGP CAR - multiple color domains

Pls see inline.. KV>

Thanks

Kaliraj 

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, March 23, 2022 at 11:03 AM
To: 'Kaliraj Vairavakkalai' <kaliraj=[email-masked]>,
[email-masked] <[email-masked]>, [email-masked]
<[email-masked]>
Subject: Re: [Idr] BGP CAR - multiple color domains

Kaliraj: 

        (Peer1, C2), LCM(C1). 

KV> Here, there is only one community, the LCM(C1). C2 is part of CAR NLRI
(Peer1:C2). 

KV> Let me use the notation: [ EP:ColorX,  LCM(ColorY)] to identify one CAR
route. Where EP:ColorX is NLRI portion. LCM(ColorY) is the optional
community carrying effective color. 

KV> Yes, both the routes [Peer1:C1] and [Peer1:C2, LCM(C1)]  have the same
effective color C1. But the NLRI prefix are not the same (highlighted parts
on this line). So CAR BGP RIB prefix is also not the same. 

KV> CAR suggests to do the multipath/protection computations based on CAR
NLRI key, which are not the same here. So the merging will not happen. 

Sue:  When you are merging the two paths using LCM, explain why the
algorithm is not merging the multipath protection based on LCM for that
domain?  

Or are you simply concerned with an end-to-end diversity which is lost in
the domain with Effective-color?

Are you envisioning this this problem due to section 2.7 in CAR? 

2.7
<https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.
7> .  Path Availability
 
   The (E, C) route inherently provides availability of redundant paths
   at every hop.  For instance, BGP CAR routes originated by two egress
   ABRs in a domain are advertised as multiple paths to ingress ABRs in
   the domain, where they become equal-cost or primary-backup paths.  A
   failure of an egress ABR is detected and handled by ingress ABRs
   locally within the domain for faster convergence, without any
   necessity to propagate the event to upstream nodes for traffic
   restoration.
 
I'd like to see what text your opinion comes from in CAR document.  

KV> IOW, It is not being done based on LCM.  Like Bruno also confirms in
below email. 

This 

KV> Also, I see that the CAR documents (draft or the presentation) are
underspecified on these aspects. 

Yes - the IDR chairs have noted  places in both the CAR and CT specification
that can be improved. 

We're trying to drill down and get these documents upgraded in the next 2
weeks 

So we can start the final WG adoption poll.  

Thanks for being kind and explaining your viewpoint.  

The IDR chairs (Jeff, Keyur and Sue) want to make sure we've heard your
viewpoints. 

Sue 

Hi Bruno, 

                                          Color C1

                                     +----------------+

                                     |  Core Domain2  |

                                    /+----------------+\

           PE1                   |                       +--------+

                                    |   Core Domain3  |

                                    +-----------------+

                                          Color C2

        (Peer1, C1)

        (Peer1, C2), LCM(C1). 

Thanks

Kaliraj

1 BGP-LU EPE:
https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gred
ler-idr-bgplu-epe-14__;!!NEt6yMaO-gk!SWHz_E5D6LnjRWtWKEUuLcEWYgMxzZPW35IVqn9
NSPQiZu5db0DvNHHeRpz1fbNh$>  

Hi BGP CT authors,

 

 

     |            E3  |  |                | V/v with C1

     |----+          +----+          +----|/

     | E1 |          | N2 |          | E2 |\

     |                |  |                |

 

      to request intent

 

 

 

 

--Bruno

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Thu, 24 Mar 2022 19:52:13 +0000

Sue,

>Sue:  When you are merging the two paths using LCM, explain why the algorithm is not merging the multipath protection based on LCM for that domain?

2.7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*section-2.7__;Iw!!NEt6yMaO-gk!W_3H1a3mTY8i5o6sFraHZcGvamWIl9uLlJD4s4izmT8puFLozJtic1-wtAEHVI1n$>.  Path Availability

   restoration.

Yes, this is the section.

As you can see in this section, the equal-cost or primary-backup paths are computed based on (E, C). Not LCM.

Thanks
Kaliraj
From: Susan Hares <[email-masked]>
Date: Thursday, March 24, 2022 at 9:54 AM
To: Kaliraj Vairavakkalai <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: [Idr] BGP CAR - multiple color domains
[External Email. Be cautious of content]

Kaliraj:

Would you mind if I confirmed a few details you are stating?
I’m trying to link your statements to CAR text
so I can understand your opinions.

Thanks,
Sue

PS - These questions are standing on the shoulders of Q1/Q2 exchange by Jeff.
As you noted, I agree with his analysis.

From: Idr [mailto:[email-masked]] On Behalf Of Kaliraj Vairavakkalai
Sent: Wednesday, March 23, 2022 3:20 PM
To: Susan Hares; 'Kaliraj Vairavakkalai'; [email-masked]; [email-masked]
Subject: Re: [Idr] BGP CAR - multiple color domains

Pls see inline.. KV>

Thanks
Kaliraj

Kaliraj:

        (Peer1, C2), LCM(C1).

Sue:  When you are merging the two paths using LCM, explain why the algorithm is not merging the multipath protection based on LCM for that domain?
Or are you simply concerned with an end-to-end diversity which is lost in the domain with Effective-color?

2.7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*section-2.7__;Iw!!NEt6yMaO-gk!W_3H1a3mTY8i5o6sFraHZcGvamWIl9uLlJD4s4izmT8puFLozJtic1-wtAEHVI1n$>.  Path Availability

   restoration.

I’d like to see what text your opinion comes from in CAR document.

KV> Also, I see that the CAR documents (draft or the presentation) are underspecified on these aspects.
Yes - the IDR chairs have noted  places in both the CAR and CT specification that can be improved.
We’re trying to drill down and get these documents upgraded in the next 2 weeks
So we can start the final WG adoption poll.

KV> Pls let me know if I got your question right. Thanks.
Thanks for being kind and explaining your viewpoint.
The IDR chairs (Jeff, Keyur and Sue) want to make sure we’ve heard your viewpoints.

Sue

Hi Bruno,

                                          Color C1
                                     +----------------+
                                     |  Core Domain2  |
                                    /+----------------+\

        (Peer1, C1)
        (Peer1, C2), LCM(C1).

Thanks
Kaliraj

Hi BGP CT authors,

      routes

--Bruno

Thank you.

---

From: <[email-masked]>
Date: Wed, 30 Mar 2022 13:59:25 +0000

Hi Kaliraj,

Sorry for the delay.
Please see inline [Bruno]

Orange Restricted
From: Kaliraj Vairavakkalai <[email-masked]>
Sent: Wednesday, March 23, 2022 2:11 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]
Subject: Re: BGP CAR - multiple color domains

Hi Bruno,

                                          Color C1
                                     +----------------+
                                     |  Core Domain2  |
                                    /+----------------+\

[Bruno] We are probably having different point of view, but I'm having difficulties mapping your above example in deployments that I'm aware of.
I could imagine 2 options:
I) If Peer1/domain4  is using color I would imagine that it originates its own color route (Peer1, C4) that would be distributed in domain2 and domain3 which would resolve C4 using their own local color (resp. C1, C2). Cf https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#appendix-B.2
II) Peer1/domain4  is not using color. Color route Peer1 is originated by Domain2 and Domain3 for domain1 to use as per its request. If so, routes are originated on ingress Domain2/3 ASBR with color chosen by Domain 1 (C1). Again, Domain2 and Domain3 would resolve next-hop using their own color schema.

You seem describe a third option where Peer1/domain4 is not using color but domain2/3 would need to originate color routes on the egress domain2/3 ASBR. But I'm not seeing why/what for.

Thanks for clarifying as I'm probably missing something (hopefully not so obvious).

--Bruno

        (Peer1, C1)
        (Peer1, C2), LCM(C1).

Thanks
Kaliraj

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 22, 2022 at 10:45 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] BGP CAR - multiple color domains
[External Email. Be cautious of content]

Hi BGP CT authors,

  1.  Please feel free to explain the issue your seeing with you own text.
  2.  This 1 page is probably a good start https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*section-2.8__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2atrcsQQ$>
  3.  I've tried to describe the whole route journey in the below text using an example from a requirement document https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2.9<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement*section-1.2.9__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2ZKQ6JLD$> and you can raise the issue when you see it.

Please note that I'll use a terminology from https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement*section-1.2__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2QNUDSgu$> and that colored route are not to be confused with color-aware route.

      routes

Coming back to the remapping, this seems to depend on the internal routing solution used in Domain 1:
- If FlexAlgo, N2 can probably do the mapping : N2, C1 is advertised in Domain 1 FA associated with the right meaning (e.g. low delay)
- worst case we need to re-color i.e. express that the color-aware route (E,C) need to be resolved using a specific color. Personally, I'm not sure why the same BGP Color Extended community can't be reused just like https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement#section-1.2.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-problem-statement*section-1.2.3__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2X3yl744$>

but that's a detail and defining a different community Local-Color-Mapping-Extended-Community https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#section-2.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*section-2.8__;Iw!!NEt6yMaO-gk!VQI-5zbHY7CE6clhUhOhP9Z_PljSz_MeeS11L5-pq_RckcjiDJdGhd0N2atrcsQQ$>  which seems to indicate the same thing (the color of the color-aware route to use when resolution is done).

--Bruno

Thank you.

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Wed, 30 Mar 2022 18:49:24 +0000

> If so, routes are originated on ingress Domain2/3 ASBR with color chosen by Domain 1 (C1)

Domain2,3 are egress-domains (traffic direction PE1->Peer1), which originate the Peer1/32 EPE route for the external peer.

So they would originate the route with color-namespace used in these respective domains only, not with color chose by domain1. E.g. Color C1 may have a different meaning in Domain3. So Domain3 cannot use C1 to describe the desired intent.

Thanks
Kaliraj
From: [email-masked] <[email-masked]>
Date: Wednesday, March 30, 2022 at 6:59 AM
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: BGP CAR - multiple color domains
[External Email. Be cautious of content]

Hi Kaliraj,

Sorry for the delay.

Orange Restricted

Hi Bruno,

                                          Color C1
                                     +----------------+
                                     |  Core Domain2  |
                                    /+----------------+\

[Bruno] We are probably having different point of view, but I’m having difficulties mapping your above example in deployments that I’m aware of.
I could imagine 2 options:
I) If Peer1/domain4  is using color I would imagine that it originates its own color route (Peer1, C4) that would be distributed in domain2 and domain3 which would resolve C4 using their own local color (resp. C1, C2). Cf https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03#appendix-B.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-03*appendix-B.2__;Iw!!NEt6yMaO-gk!TqcthKTo6nLwSNq051Xus2lTb5O9Qv-AbGx5FWy636W50NJYBn9exG92Uqf92kYV$>
II) Peer1/domain4  is not using color. Color route Peer1 is originated by Domain2 and Domain3 for domain1 to use as per its request. If so, routes are originated on ingress Domain2/3 ASBR with color chosen by Domain 1 (C1). Again, Domain2 and Domain3 would resolve next-hop using their own color schema.

You seem describe a third option where Peer1/domain4 is not using color but domain2/3 would need to originate color routes on the egress domain2/3 ASBR. But I’m not seeing why/what for.

Thanks for clarifying as I’m probably missing something (hopefully not so obvious).

--Bruno

        (Peer1, C1)
        (Peer1, C2), LCM(C1).

Thanks
Kaliraj

1 BGP-LU EPE: https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-14__;!!NEt6yMaO-gk!TqcthKTo6nLwSNq051Xus2lTb5O9Qv-AbGx5FWy636W50NJYBn9exG92UoZiuIB4$>

Hi BGP CT authors,

      routes

--Bruno

Thank you.

Thank you.

---

From: Natrajan Venkataraman <[email-masked]>
Date: Wed, 30 Mar 2022 20:07:57 +0000

Hi Bruno,

As Kaliraj just mentioned, I’m listing the following use-cases which we are currently deployed by customers and it would be really helpful to understand how CAR will handle these scenarios. I wasn’t able to find this in section 2.7 of the CAR draft. It would be good to describe how LCM will be use to merge the paths for ECMP/FRR.

UseCase 1:  EPE forwarding towards two AS domains with color disagreement for Multihomed Peer CE1
-------------------------------------------------------------------------------------------------

                                     Gold = 100 Bronze = 200
                            +--------[ASBR2     (AS2)     PE2]--+
    Gold = 100 Bronze = 200 |                                   |
    [PE1      (AS1)     ASBR1]                                 CE1 (1.1.1.1)
          INGRESS DOMAIN    |                                   |   Multihomed onto PE2,PE3
                              +--------[ASBR3     (AS3)     PE3]--+
                                     Gold = 200 Bronze = 100

UseCase 2:  Anycast forwarding to two domains with color disagreement
---------------------------------------------------------------------

    |--------ADMINISTRATIVE DOMAIN A ---------------------------|
                                     Gold = 100 Bronze = 200
                            +--------[ASBR2     (AS2)     PE2-1.1.1.1]
    Gold = 100 Bronze = 200 |
    [PE1      (AS1)     ASBR1]
          INGRESS DOMAIN    |
                              +--------[ASBR3     (AS3)     PE3-1.1.1.1]
                                     Gold = 200 Bronze = 100

Service Route (With color community): (PE1 Only)

  R1, Color:0:100
  R2, Color:0:200

CAR Routes: (PE1 and ASBR1)

      1.1.1.1:100

            Add-Path 1: 1.1.1.1:100          from AS2 (Gold)
            Add-Path 2: 1.1.1.1:100, LCM 200 from AS3 (Bronze)

      1.1.1.1:200

            Add-Path 1: 1.1.1.1:200          from AS2 (Gold)
            Add-Path 2: 1.1.1.1:200, LCM 100 from AS3 (Bronze)

Stating the following as per CAR draft:

      NLRI key                      = EP:Color
      Effective Resolution key      = EP:EffectiveColor (LCM overrides NLRI color)

      - CAR route multipath/protection creation is based on CAR NLRI key and
      - CAR route resolution is based on Effective Resolution Key.

Observed Behavior:

    - In PE1, using NLRI key misses ECMP/FRR computation for Ingress routes
    - In ASBR1, using NLRI key misses ECMP/FRR computation for Transit routes

A clarification of how these scenarios are handled in CAR would be really helpful.

-Nats-

From: Idr <[email-masked]> on behalf of Kaliraj Vairavakkalai <kaliraj=[email-masked]>
Date: Wednesday, March 30, 2022 at 11:50 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Idr] BGP CAR - multiple color domains
[External Email. Be cautious of content]

Thanks
Kaliraj

Hi Kaliraj,

Sorry for the delay.

Orange Restricted

Hi Bruno,

                                          Color C1
                                     +----------------+
                                     |  Core Domain2  |
                                    /+----------------+\

--Bruno

        (Peer1, C1)
        (Peer1, C2), LCM(C1).

Thanks
Kaliraj

Hi BGP CT authors,

      routes

--Bruno

Thank you.

Thank you.