Re: [Idr] BGP CAR - multiple color domains

[Susan Hares <[e-mail]>]

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:[e-mail]] On Behalf Of Kaliraj Vairavakkalai
Sent: Tuesday, March 22, 2022 9:11 PM
To: [e-mail]; [e-mail]
Subject: Re: [Idr] BGP CAR - multiple color domains

 

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 <[e-mail]> on behalf of [e-mail]
<[e-mail]>
Date: Tuesday, March 22, 2022 at 10:45 AM
To: [e-mail] <[e-mail]>
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.

 

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.

 

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-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.

 

Juniper Business Use Only