Re: [Idr] BGP CAR - multiple color domains
Susan Hares <shares@ndzh.com> Thu, 24 March 2022 16:54 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7603A0D24 for <idr@ietfa.amsl.com>; Thu, 24 Mar 2022 09:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.04
X-Spam-Level: *
X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryxIdpGKR3SJ for <idr@ietfa.amsl.com>; Thu, 24 Mar 2022 09:54:31 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DB73A0D62 for <idr@ietf.org>; Thu, 24 Mar 2022 09:54:31 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.114.225;
From: Susan Hares <shares@ndzh.com>
To: 'Kaliraj Vairavakkalai' <kaliraj=40juniper.net@dmarc.ietf.org>, bruno.decraene@orange.com, idr@ietf.org
References: <10630_1647971106_623A0B22_10630_297_1_e1284ad83ee8491997b4567d7c5d0631@orange.com> <SJ0PR05MB8632992AAB38550BE45F2CAEA2189@SJ0PR05MB8632.namprd05.prod.outlook.com> <00f501d83ee0$2ebdb290$8c3917b0$@ndzh.com> <SJ0PR05MB86324E9E28C6C3DF1CD2A91CA2189@SJ0PR05MB8632.namprd05.prod.outlook.com>
In-Reply-To: <SJ0PR05MB86324E9E28C6C3DF1CD2A91CA2189@SJ0PR05MB8632.namprd05.prod.outlook.com>
Date: Thu, 24 Mar 2022 12:54:24 -0400
Message-ID: <015901d83f9f$d1267ca0$737375e0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015A_01D83F7E.4A1C56B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIlgBZiz1bDN6sPVZSuYKtrbkfplAL7uwbOAd5FEkwBerBglawBj0sQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jARHMui4FI31_erWiGyPkX4L45c>
Subject: Re: [Idr] BGP CAR - multiple color domains
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2022 16:54:36 -0000
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:idr-bounces@ietf.org] On Behalf Of Kaliraj Vairavakkalai Sent: Wednesday, March 23, 2022 3:20 PM To: Susan Hares; 'Kaliraj Vairavakkalai'; bruno.decraene@orange.com; idr@ietf.org Subject: Re: [Idr] BGP CAR - multiple color domains Pls see inline.. KV> Thanks Kaliraj From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com> Date: Wednesday, March 23, 2022 at 11:03 AM To: 'Kaliraj Vairavakkalai' <kaliraj=40juniper.net@dmarc.ietf.org>, bruno.decraene@orange.com <bruno.decraene@orange.com>, idr@ietf.org <idr@ietf.org> Subject: Re: [Idr] BGP CAR - multiple color domains [External Email. Be cautious of content] Kaliraj: You have two communities for (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. But C1 becomes the Effective color in both cases. 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. 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). 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. 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 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Kaliraj Vairavakkalai Sent: Tuesday, March 22, 2022 9:11 PM To: bruno.decraene@orange.com; idr@ietf.org 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 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gred ler-idr-bgplu-epe-14__;!!NEt6yMaO-gk!SWHz_E5D6LnjRWtWKEUuLcEWYgMxzZPW35IVqn9 NSPQiZu5db0DvNHHeRpz1fbNh$> From: Idr <idr-bounces@ietf.org> on behalf of bruno.decraene@orange.com <bruno.decraene@orange.com> Date: Tuesday, March 22, 2022 at 10:45 AM To: idr@ietf.org <idr@ietf.org> 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 Juniper Business Use Only
- [Idr] BGP CAR - multiple color domains bruno.decraene
- Re: [Idr] BGP CAR - multiple color domains Kaliraj Vairavakkalai
- Re: [Idr] BGP CAR - multiple color domains Susan Hares
- Re: [Idr] BGP CAR - multiple color domains Kaliraj Vairavakkalai
- Re: [Idr] BGP CAR - multiple color domains Susan Hares
- Re: [Idr] BGP CAR - multiple color domains Kaliraj Vairavakkalai
- Re: [Idr] BGP CAR - multiple color domains bruno.decraene
- Re: [Idr] BGP CAR - multiple color domains Kaliraj Vairavakkalai
- Re: [Idr] BGP CAR - multiple color domains Natrajan Venkataraman
- Re: [Idr] BGP CAR - multiple color domains Dhananjaya Rao (dhrao)
- Re: [Idr] BGP CAR - multiple color domains Susan Hares
- Re: [Idr] BGP CAR - multiple color domains Dhananjaya Rao (dhrao)
- Re: [Idr] BGP CAR - multiple color domains Nagarajah, Moses
- Re: [Idr] BGP CAR - multiple color domains Dhananjaya Rao (dhrao)