From nobody Sat May 22 15:40:41 2021 Return-Path: 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 CA3013A21DE; Sat, 22 May 2021 15:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pmuE3miHYCDj; Sat, 22 May 2021 15:40:32 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 4C4E43A21DD; Sat, 22 May 2021 15:40:32 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id m124so17181926pgm.13; Sat, 22 May 2021 15:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EDcbWPjX5n+Pfdp7OSGwj8NRfItCi5g7qkah5D9oV/Q=; b=hIYEdp4QhB93o70vfTLiY3eO/wq9hPwcqxFi/A832YI2t/3S8yTRDA0ZwT22ytei/o owPvPoQB60HGFxIRl8eMleFaXqeSbk+lmEnaCCge2Cgx9aTO2R+Ol39ZCttvkIqwMm8s wW2LMoJHWkhBmOHRrznVJrd2v30avELFbMaGNWRyxDJ0uK3RUeD2mZXmLMMwbEOh5gW1 JQg3ezdKx5YVcZhMYThHxFTYsg5vYnPbT1cSaFvo53s2pJ5GdyQ8iaW8zgcOqvGNyxLr ipm8wGuhcFwMZhWV+hbVtahcnPeju6EgPnUz3LgIYET27h1TBtIDPjuOdkrdojFdoZr7 euhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EDcbWPjX5n+Pfdp7OSGwj8NRfItCi5g7qkah5D9oV/Q=; b=ZTvAOO/s6qJmJl39DLaOLeiv3ayJ1l/tPEIjiwKqnz0WKoqXNECNBPEyWtF35/HZ9y 2dds3h8YmU0D6ML/UVWmS9O/SyEtRoJBLzIigBRdMCVYFU1CbZI6xXH9MExMsVJSv3Lz LdS79HMRBQ4vLcuHJ5e4XQUHbkOT0Tr6CT0aQSIcSq0c+k2xqYnri8W2my0RK0mP7kOy iqr8B2H+UKV/3HxzC8xZugzJpo9MDSD1qZIptfR6C5mjcUm4nwV0bgT756s/CHsHC4FH cVPqVMMIqNrzyb6JUi7t66T/hhmkiN4kGLwe05MTBNaSMEgZL8UMxqBaY5/egGMsWhyf S8sQ== X-Gm-Message-State: AOAM533m7PM1cOV4Kb0NHaDILqAMolcQY6URo78O7uck43DBvoz59VyS YlxoFVomB5HKJAaoTuV6tB3+4KIBDll3vPNUnrd+m2JMpck= X-Google-Smtp-Source: ABdhPJwHGa9CNzee+jeAQej+REwdzpWUPodvtbTLK7XFumfYA+EZCivXy+NsHxO+lQqzNTiTGV76DXyN3OLLEMUM6pM= X-Received: by 2002:a62:3682:0:b029:2dd:ed69:6e85 with SMTP id d124-20020a6236820000b02902dded696e85mr17374949pfa.20.1621723230737; Sat, 22 May 2021 15:40:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 22 May 2021 18:40:05 -0400 Message-ID: To: Alvaro Retana Cc: IDR List , Susan Hares , draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, "idr-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001797f005c2f2dd8f" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 22:40:39 -0000 --0000000000001797f005c2f2dd8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For VPN SAFI 128 can this solution be applied as with unique RD all paths get advertised by the RR and this solution would cut down on the paths advertised to help with scalability and with many RRs and many exit points. Thanks Gyan On Sat, May 22, 2021 at 6:11 PM Gyan Mishra wrote: > Dear Authors > > I have a few comments on this draft. > > This is a historical well known issue exists where a RR will compute the > best path based on IGP topology metric least cost to the exit point and > will advertise those paths based on the topological position of the RR to > the exit point. The major issue is the best path reflected by the RR > should be based on the Clients IGP shortest path to exit point and the RR= s > shortest path. > > A workaround to this issue is RFC 7911 add paths where all paths are > advertised to all Client PEs as well as all RR as mentioned in section 4 > deployment considerations. What is missing in the Section 4 verbiage is > the add path to both RRs and all clients so advertisement of all paths ar= e > advertised to all clients as well as RR. So to resolve the issue with > the RR making the best path decision the RR must have add paths send / > receive MP Reach capability enabled to all clients and must select and > advertise all paths to all clients so that each client can now make the > best path decision based on its best path lowest IGP metric to the exit > point. > > Using RFC 7911 add paths to all clients the hot potato issue is resolved. > > The caveat with add paths is if you have many RRs and many exist points > you end up with many paths per prefix in the BGP RIB. > > With modern high end routers these days this does not impact scalability > issues that I am aware of. > > With this draft it seems the goal is to only advertise the pertinent path= s > based on the client IGP location rooted topological path to the exit poin= t > and not advertise all paths. This would cut down on the number of paths > advertised by the RR so all paths are not flooded to the clients as the > current solution today to the hot potato issue. > > Am I reading this correctly? > > Kind Regards > > Gyan > > On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana > wrote: > >> Dear authors: >> >> >> Thank you for your work on this document. I know that the draft and >> the related ideas have been around for a long time. >> >> I have a couple of significant issues that I want to highlight >> upfront, and many comments inline (see below). In general, my focus >> is to make sure that the specification of this mechanism is clear, not >> just to the experienced reader, but to the casual one as well. I >> believe that all the issues should be easy to resolve. >> >> (1) Terminology. Please use the terminology already defined in >> rfc4271/rfc4456 instead of creating new one by indirection. My first >> inline comment is about the use of "best path", which is not what >> rfc4271 uses -- there are other occurrences later on. >> >> (2) Deployment Considerations. =C2=A76 says that a compliant >> implementation is one that allows the operator to configure "a logical >> location from which the best path will be computed, on the basis of >> either a peer, a peer group, or an entire routing instance". Please >> spend some time providing guidance so an operator can decide what best >> works for their network. [I pointed below to other places there >> operational guidance would be ideal.] >> >> (3) I don't think that =C2=A75 (CPU and Memory Scalability) and Appendix= A >> (alternative solutions with limited applicability) should be part of >> this document. To start, comparisons are never good and the work has >> already been through the WG so there's no need to keep justifying it >> by comparing it to other work. Both sections contain several claims >> (e.g. "extra cost in terms of CPU", "implemented efficiently", >> "expected to be higher but comparable", "large amount of BGP state and >> churn", "result in tens of paths for each prefix") that don't have >> references, and could be considered subjective because they are >> clearly relative and can change depending on the specific deployment >> and configuration of the network. I am not saying that the claims are >> false, simply requesting to take these two sections out. >> >> >> Thanks! >> >> Alvaro. >> >> >> [Line numbers from idnits.] >> >> ... >> 17 Abstract >> >> 19 This document defines an extension to BGP route reflectors. >> On route >> 20 reflectors, BGP route selection is modified in order to choos= e >> the >> 21 best path from the standpoint of their clients, rather than >> from the >> 22 standpoint of the route reflectors. Multiple types of >> granularity >> 23 are proposed, from a per client BGP route selection or to a >> per peer >> 24 group, depending on the scaling and precision requirements on >> route >> 25 selection. This solution is particularly applicable in >> deployments >> 26 using centralized route reflectors, where choosing the best >> route >> 27 based on the route reflector IGP location is suboptimal. Thi= s >> 28 facilitates, for example, best exit point policy (hot potato >> 29 routing). >> >> [major] "best path" rfc4271 doesn't use the term "best path". The >> terminology used in this document should, at the very least, match >> what the base spec defines. Let's please not create new terminology >> by indirection using the "definition of terms" section. >> >> >> [minor] "proposed" This document is in line to be come an RFC; we're >> far beyond proposing things. There are a couple of places later on >> where this same wording is used. Please change it to specified or at >> least described (the latter probably fits best in this specific case). >> >> >> [nit] s/from a per client BGP route selection or to a per peer >> group/from per client BGP route selection or per peer group >> >> >> [nit] s/precision requirements on route selection./precision requirement= s. >> >> >> [nit] s/route reflector IGP location/route reflector's IGP location >> >> >> [major] "IGP location" Before I forget -- please clearly define (not >> in the Abstract of course) what an "IGP location" is. >> >> >> ... >> 70 1. Definitions of Terms Used in This Memo . . . . . . . . . >> . . 2 >> 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . >> . . 3 >> >> [nit] It would be nice if the Introduction came up before the terminolog= y. >> >> >> ... >> 91 1. Definitions of Terms Used in This Memo >> >> [minor] To avoid repeating some terms, it is good practice to indicate >> which other RFCs the reader should be familiar with. In this case >> rfc4271 and rfc4456 come to mind. >> >> >> ... >> 132 2. Introduction >> ... >> 153 Section 11 of [RFC4456] describes a deployment approach and a >> set of >> 154 constraints which, if satisfied, would result in the >> deployment of >> 155 route reflection yielding the same results as the IBGP full >> mesh >> 156 approach. This deployment approach makes route reflection >> compatible >> 157 with the application of hot potato routing policy. In >> accordance >> 158 with these design rules, route reflectors have traditionally >> often >> 159 been deployed in the forwarding path and carefully placed on >> the POP >> 160 to core boundaries. >> >> [nit] s/have traditionally often/have often >> Redundant... >> >> >> 162 The evolving model of intra-domain network design has enabled >> 163 deployments of route reflectors outside of the forwarding pat= h. >> 164 Initially this model was only employed for new address >> families, e.g. >> 165 L3VPNs and L2VPNs, however it has been gradually extended to >> other >> 166 BGP address families including IPv4 and IPv6 Internet using >> either >> 167 native routing or 6PE. In such environments, hot potato >> routing >> 168 policy remains desirable. >> >> [minor] "new address families, e.g. L3VPNs and L2VPNs" These are not >> the name of the AFs. Maybe call them new services. >> >> >> [minor] "IPv4 and IPv6 Internet" The name of the AF is IP/IP6; again, >> you probably mean service/application. >> >> >> [nit] "native routing or 6PE" Not 4PE applications? ;-) It seems >> to me that you can save some ink by ending the sentence after >> "Internet". >> >> >> ... >> 194 3. Modifications to BGP Best Path selection >> >> 196 The core of this solution is the ability for an operator to >> specify >> 197 the IGP location for which the route reflector should calcula= te >> 198 routes. This can be done on a per route reflector basis, per >> peer/ >> 199 update group basis, or per peer basis. This ability enables >> the >> 200 route reflector to send to a given set of clients routes with >> 201 shortest distance to the next hops from the position of the >> selected >> 202 IGP location. This provides for freedom of route reflector >> physical >> 203 location, and allows transient or permanent migration of this >> network >> 204 control plane function to an arbitrary location. >> >> [major] "ability for an operator to specify the IGP location for which >> the route reflector should calculate routes. This can be done on a >> per route reflector basis, per peer/update group basis, or per peer >> basis." >> >> When should an operator choose per RR vs per peer group vs per peer? >> Choice is good, but providing guidance for the deployment is much >> better. Please consider adding text to =C2=A76 about the considerations= to >> chose one or the other. >> >> >> [minor] "peer/update group" Where is this defined? Is there a >> reference to a non-implementation-specific definition? Can it be >> called "a group of peers"? Maybe you also want to include it in the >> definitions in =C2=A71. >> >> >> ... >> 215 o it can, and usually will, have a different position in the >> IGP >> 216 topology, and >> >> [] "usually will" The position in the topology will *always* be >> different! >> >> >> ... >> 222 This document defines, on BGP Route Reflectors [RFC4456], two >> changes >> 223 to the BGP Best Path selection algorithm: >> >> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflecto= rs >> >> >> ... >> 235 A route reflector can implement either or both of the >> modifications >> 236 in order to allow it to choose the best path for its clients >> that the >> 237 clients themselves would have chosen given the same set of >> candidate >> 238 paths. >> >> [major] Please provide guidance for the operator to consider then one >> or both should be used in their network. >> >> >> 240 A significant advantage of these approaches is that the route >> 241 reflector clients do not need to run new software or hardware= . >> >> [nit] s/do not need to run new software or hardware./do not need to be >> modified. >> >> >> 243 3.1. Best Path Selection from a different IGP location >> >> 245 In this approach, optimal refers to the decision made during >> best >> 246 path selection at the IGP metric to BGP next hop comparison >> step. It >> 247 does not apply to path selection preference based on other >> policy >> 248 steps and provisions. >> >> [major] Please be specific about what is the "IGP metric to BGP next >> hop comparison step". There is no step with that name, or even a >> string match in rfc4271. Later you talk about the step e) tie-breaker >> -- don't wait to be specific! >> >> >> ... >> 263 e) Remove from consideration any routes with less-preferre= d >> 264 interior cost. The interior cost of a route is determined >> by >> 265 calculating the metric from the selected IGP location to t= he >> 266 NEXT_HOP for the route using the shortest IGP path tree >> rooted at >> 267 the selected IGP location. >> >> [major] Note that the specification talks about "interior cost", but >> the descriptions in this document uses "IGP cost" and "IGP metric" to >> refer to the same thing. Please be consistent with existing >> terminology! >> >> >> [major] Related to the definition of "IGP location" and its >> configuration. How does the IGP location (and thus the calculation of >> the interior cost, as above) change when the configuration is done per >> peer/update groups instead than per peer? This is another point where >> operators could benefit from guidance (for the peer/update-group and >> whole RR cases, of course). >> >> >> ... >> 275 The configuration of the IGP location is outside of the scope >> of this >> 276 document. The operator may configure it manually, an >> implementation >> 277 may automate it based on heuristics, or it can be computed >> centrally >> 278 and configured by an external system. >> >> [nit] s/outside of the scope/outside the scope >> >> [major] There are several places later on that talk about the >> configuration, even making it a requirement for compliance (=C2=A76). I >> think that you don't mean the configuration itself, but the way in >> which the configuration is instantiated in the router (which could be >> considered an implementation detail). As written, the text is not >> clear. >> >> >> 280 This solution does not require any change (BGP or IGP) on the >> 281 clients, as all required changes are limited to the route >> reflector. >> >> [] This was also claimed before. >> >> >> 283 This solution applies to NLRIs of all address families that >> can be >> 284 route reflected. >> >> [] Are there AFs that cannot be reflected? Just wondering if you >> really need to say this. >> >> >> 286 3.1.1. Restriction when BGP next hop is BGP prefix >> >> 288 In situations where the BGP next hop is a BGP prefix itself, >> the IGP >> 289 metric of a route used for its resolution SHOULD be the final >> IGP >> 290 cost to reach such next hop. Implementations which can not >> inform >> 291 BGP of the final IGP metric to a recursive next hop SHOULD >> treat such >> 292 paths as least preferred during next hop metric comparison. >> However >> 293 such paths SHOULD still be considered valid for best path >> selection. >> >> [major] The recursive resolution is already covered in rfc4271 >> (=C2=A75.1.3/=C2=A79.1.2.1). Why isn't that enough? >> >> There seems to be a difference: if an implementation "can not inform >> BGP of the final IGP metric to a recursive next hop...SHOULD still be >> considered valid for best path selection." rfc4271 treats these >> routes as unresolvable. Do you want to consider unresolvable routes? >> >> Finally, there are a lot of SHOULDs in this paragraph. Under which >> conditions is it ok to not perform the actions? IOW, why are these >> actions recommended and not required? >> >> >> 295 3.2. Multiple Best Path Selections >> >> 297 BGP Route Reflector as per [RFC4456] runs a single best path >> 298 selection. Optimal route reflection may require calculation = of >> 299 multiple best path selections or subsets of best path >> selection in >> 300 order to consider different IGP locations or BGP policies for >> 301 different sets of clients. >> >> [] It hasn't been mentioned before, but the talk about policy made me >> think about this: Can a client be present on different sets? How is >> that handled in terms of BGP sessions? Do we need multiple sessions? >> Or is add-path required? >> >> >> 303 If the required routing optimization is limited to the IGP >> cost to >> 304 the BGP Next-Hop, only step e) as defined [RFC4271] section >> 9.1.2.2, >> 305 needs to be duplicated. >> >> [major] I'm not sure if this paragraph is referencing =C2=A73.1 (where s= tep >> e) was just modified), or or you're saying that for each subset (from >> the last paragraph) only step e) is considered, or something else. ?? >> >> >> 307 If the routing optimization requires the use of different BGP >> 308 policies for different sets of clients, a larger part of the >> decision >> 309 process needs to be duplicated, up to the whole decision >> process as >> 310 defined in section 9.1 of [RFC4271]. This is for example the >> case >> 311 when there is a need to use different policies to compute >> different >> 312 degree of preference during Phase 1. This is needed for use >> cases >> 313 involving traffic engineering or dedicating certain exit >> points for >> 314 certain clients. In the latter case, the user MAY specify an= d >> apply >> 315 a general policy on the route reflector for a set of clients. >> For a >> 316 given set of clients, the policy SHOULD in that case allow th= e >> 317 operator to select different candidate exit points for >> different >> 318 address families. Regular path selection, including IGP >> perspective >> 319 for a set of clients as per Section 3.1, is then applied to t= he >> 320 candidate paths to select the final paths to advertise to the >> 321 clients. >> >> [] Similar comment as before... The use of "duplicated" is confusing m= e. >> >> >> [major] "the user MAY specify..." s/MAY/may It seems to me that >> you're simply stating a fact (the user can do this), and not >> specifying an optional behavior. >> >> >> [major] "...the policy SHOULD in that case allow the operator to >> select different candidate exit points for different address >> families." There's no interoperable action that "the policy" can >> execute. It sounds as if you're recommending that specific knobs >> ("allow the operator to...") be implemented. Please reword. >> >> >> [] You use "IGP perspective" I guess as equivalent to "IGP location" >> -- is that right? >> >> >> 323 4. Implementation considerations >> >> 325 4.1. Likely Deployments and need for backup >> >> [nit] Do we really need a sub-section if all the text for =C2=A74 is in = it? >> >> >> 327 With IGP based optimal route reflection, even though the IGP >> location >> 328 could be specified on a per route reflector basis or per >> peer/update >> 329 group basis or per peer basis, in reality, it's most likely t= o >> be >> 330 specified per peer/update group basis. All clients with the >> same or >> 331 similar IGP location can be grouped into the same peer/update >> group. >> 332 An IGP location is then specified for the peer/update group. >> The >> 333 location is usually specified as the location of one of the >> clients >> 334 from the peer group or an ABR to the area where clients are >> located. >> 335 Also, one or more backup locations SHOULD be allowed to be >> specified >> 336 for redundancy. Implementations may wish to take advantage o= f >> peer >> 337 group mechanisms in order to provide for better scalability o= f >> 338 optimal route reflector client groups with similar properties= . >> >> [major] "IGP based optimal route reflection" >> >> This is the first time you use "IGP based optimal route reflection"; I >> peeked forward and see that =C2=A75 also mentions "policy based optimal >> route reflection". But you didn't define them anywhere -- in fact, >> the description before now focuses on the IGP location, which makes me >> think about "IGP based". >> >> I could guess that the "policy based" version is related to =C2=A73.2, b= ut >> (1) no one should have to guess (!), and (2) the end of that section >> says that "IGP perspective...is then applied", making it also "IGP >> based". ?? >> >> Please either define these types of ORR earlier in the text, or >> (better yet) don't use the terms. Instead, and given that the names >> are used just a couple of times, change "policy based" to "the case >> where a policy is applied"... >> >> >> [major] "one or more backup locations SHOULD be allowed to be >> specified for redundancy" >> >> (1) =C2=A73.1 says that the "configuration of the IGP location is outsid= e >> of the scope of this document". If that is true, then you can't >> recommend anything related to the configuration. >> >> (2) If there were "backup locations", how would they be used? >> >> >> [minor] This is the only time that "optimal route reflector client >> groups" is used. I had been assuming that a group of clients would >> correspond to a specific peer/update group (as mentioned many times >> before). Is there a difference between a "client group" and grouping >> clients to correspond to a peer/update group? >> >> >> [] "for better scalability of optimal route reflector client groups" >> What exactly does this mean? I asked before about >> references/definitions for peer/update groups; this point may be >> related. >> >> >> ... >> 373 6. Advantages and Deployment Considerations >> >> 375 The solutions described provide a model for integrating the >> client >> 376 perspective into the best path computation for route >> reflectors. >> 377 More specifically, the choice of BGP path factors in either >> the IGP >> 378 cost between the client and the nexthop (rather than the IGP >> cost >> 379 from the route reflector to the nexthop) or other user >> configured >> 380 policies. >> >> [] "solutions"? I only see one, where the "second" one simply adds >> policy, which is a pervasive tool in BGP. >> >> >> 382 The achievement of optimal routing relies upon all route >> reflectors >> 383 learning all paths that are eligible for consideration. In >> order to >> 384 satisfy this requirement, path diversity enhancing mechanisms >> such as >> 385 BGP add-path [RFC7911] may need to be deployed between route >> 386 reflectors. >> >> [mayor] "path diversity enhancing mechanisms...may need to be deployed >> between route reflectors" Given that this is the Deployment >> Considerations section, please provide guidance on when these >> mechanisms are needed, and when they're not. >> >> >> [minor] "path diversity enhancing mechanisms such as BGP add-path >> [RFC7911]" Just out of curiosity, what other mechanisms are you >> thinking of? Are there deployment considerations, when using ORR, to >> prefer one? >> >> >> 388 Implementations considered compliant with this document allow >> the >> 389 configuration of a logical location from which the best path >> will be >> 390 computed, on the basis of either a peer, a peer group, or an >> entire >> 391 routing instance. >> >> [] I guess that "logical location" is another name for IGP location... >> >> >> [major] =C2=A73.1 says that the "configuration of the IGP location is >> outside of the scope of this document". If that is true, then the >> configuration cannot be a consideration for compliance. >> >> A better wording for compliance would be: "An implementation MUST >> allow the configuration..." >> >> >> 393 These solutions can be deployed in traditional hop-by-hop >> forwarding >> 394 networks as well as in end-to-end tunneled environments. In >> networks >> 395 where there are multiple route reflectors and hop-by-hop >> forwarding >> 396 without encapsulation, such optimizations SHOULD be enabled i= n >> a >> 397 consistent way on all route reflectors. Otherwise, clients m= ay >> 398 receive an inconsistent view of the network, in turn leading = to >> 399 intra-domain forwarding loops. >> >> [major] "optimizations SHOULD be enabled in a consistent way on all >> route reflectors" >> >> Is "a consistent way" different than "on all"? s/.../optimizations >> SHOULD be enabled on all route reflectors >> >> When is it ok for all RRs not to be enabled with the optimizations? >> IOW, why is it recommended and not required? Avoiding "intra-domain >> forwarding loops" sounds like a good reason to require it. >> >> >> ... >> 406 As per above, these approaches reduce the amount of state >> which needs >> 407 to be pushed to the edge of the network in order to perform h= ot >> 408 potato routing. The memory and CPU resources required at the >> edge of >> 409 the network to provide hot potato routing using these >> approaches is >> 410 lower than what would be required to achieve the same level o= f >> 411 optimality by pushing and retaining all available paths >> (potentially >> 412 10s) per each prefix at the edge. >> >> [] This paragraph sounds very speculative and doesn't seem necessary. >> In line with =C2=A75. >> >> >> 414 The solutions above allow for a fast and safe transition to a >> BGP >> 415 control plane using centralized route reflection, without >> 416 compromising an operator's closest exit operational >> principle. This >> 417 enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 >> and >> 418 IPv6 prefixes. >> >> [] "allow for a fast and safe transition" Besides this statement >> sounding like a marketing brochure, if you're going to talk about >> transition, please talk about it in detail. Please take a look at >> =C2=A72/rfc5706 and include details about the transition and how it is >> "fast and safe". >> >> >> 420 Regarding Best Path Selection from a different IGP location, = it >> 421 should be self evident that this solution does not interfere >> with >> 422 policies enforced above IGP tie-breaking in the BGP best path >> 423 algorithm. >> >> [minor] Don't assume anything is self evident to anyone. >> >> Suggestion (maybe more appropriate in =C2=A73.1)> >> The modification specified in Section 3.1 does not impact any previou= s >> considerations in the BGP Decision Process. >> >> >> 425 7. Security Considerations >> >> 427 Similarly to [RFC4456], this extension to BGP does not change >> the >> 428 underlying security issues inherent in the existing IBGP >> [RFC4456]. >> >> [minor] No need to reference rfc4456 twice in the same sentence. >> >> >> 430 It however enables the deployment of base BGP Route Reflectio= n >> as >> 431 described in [RFC4456] to be possible using virtual compute >> 432 environments without any negative consequence on the BGP >> routing path >> 433 optimality. >> >> [] I'm not sure how this relates to the specification itself (platform >> independent), but I'm sure the Security ADs will have a lot of >> questions about the security of "virtual compute environments" -- and >> where the details are included in this document. IOW, that sounds >> like an unnecessary assertion. >> >> >> [major] "without any negative consequence" The new functionality >> specified in this document is having the RR run the client's selection >> for them (even specific policy) -- there are risks related to the >> duplication of the policy, the location of the RRs and the blind trust >> that the clients need to have. Or should the clients rerun the policy >> locally? >> >> This behavior is not necessarily different from normal RR, but the >> instantiation is different. It would be very easy for a rogue RR to >> propagate incorrect routing information to its clients -- specially if >> policy is offloaded to them. >> >> In the worst case the result would be a sub-optimal route (maybe even >> worse than what the clients get today), but probably not a "real" >> security issue. It is probably a good idea to explain why it is not a >> security risk. >> >> >> 435 This document does not introduce requirements for any new >> protection >> 436 measures, but it also does not relax best operational >> practices for >> 437 keeping the IGP network stable or to pace rate of policy base= d >> IGP >> 438 cost to next hops such that it does not have any substantial >> effect >> 439 on BGP path changes and their propagation to route reflection >> 440 clients. >> >> [major] "best operational practices" Like what? It would be good to >> provide (at least) informational references. >> >> >> [major] "to pace rate of policy based IGP cost to next hops such that >> it does not have any substantial effect on BGP path changes" You >> will have to explain this further because the operation of an IGP is >> not mentioned anywhere else. >> >> IMHO, there's no need to go into IGP operational details in this >> document. There is nothing special/different about the operation of >> an IGP. >> >> >> [End of Review] >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mishra@verizon.com * > > > > *M 301 502-1347* > > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000001797f005c2f2dd8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

For VPN SAFI 128 can this solution be appl= ied as with unique RD all paths get advertised by the RR and this solution = would cut down on the paths advertised to help with scalability and with ma= ny RRs and many exit points.

Thanks=C2=A0

Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
Dear Authors=C2=A0

=
I have a few comments on this draft.

This is a historical well known issue exists= where a RR will compute the best path based on IGP topology metric least c= ost to the exit point and will advertise those paths based on the topologic= al position of the RR to the exit point.=C2=A0 The major issue is the best = path reflected by the RR should be based on the Clients IGP shortest path t= o exit point and the RRs shortest path. =C2=A0

<= /div>
A workaround to this issue is RFC 7911 add paths whe= re all paths are advertised to all Client PEs as well as all RR as mentione= d in section 4 deployment considerations.=C2=A0 What is missing in the Sect= ion 4 verbiage is the add path to both RRs and all clients so advertisement= of all paths are advertised =C2=A0to all clients as well as RR.=C2=A0 So t= o =C2=A0resolve the issue with the RR making the best path decision the RR = must have add paths send / receive MP Reach capability enabled to all clien= ts and must select and advertise all paths to all clients so that each clie= nt can now make the best path decision based on its best path lowest IGP me= tric to the exit point. =C2=A0=C2=A0

Using RFC 7911 add paths to all clients the hot potato issue i= s resolved.

The caveat w= ith add paths is if you have many RRs and many exist points you end up with= many paths per prefix in the BGP RIB. =C2=A0

With modern high end routers these days this does not= impact scalability issues that I am aware of.

<= /div>
With this draft it seems the goal is to only adverti= se the pertinent paths based on the client IGP location rooted topological = path to the exit point and not advertise all paths.=C2=A0 This would cut do= wn on the number of paths advertised by the RR so all paths are not flooded= to the clients as the current solution today to the hot potato issue.

Am I reading this correctly?=

Kind Regards=C2=A0

Gyan=C2=A0

On Thu, Mar 1= 8, 2021 at 3:32 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
Dear authors:


Thank you for your work on this document.=C2=A0 I know that the draft and the related ideas have been around for a long time.

I have a couple of significant issues that I want to highlight
upfront, and many comments inline (see below).=C2=A0 In general, my focus is to make sure that the specification of this mechanism is clear, not
just to the experienced reader, but to the casual one as well. =C2=A0I
believe that all the issues should be easy to resolve.

(1) Terminology.=C2=A0 Please use the terminology already defined in
rfc4271/rfc4456 instead of creating new one by indirection.=C2=A0 My first<= br> inline comment is about the use of "best path", which is not what=
rfc4271 uses -- there are other occurrences later on.

(2) Deployment Considerations. =C2=A0=C2=A76 says that a compliant
implementation is one that allows the operator to configure "a logical=
location from which the best path will be computed, on the basis of
either a peer, a peer group, or an entire routing instance".=C2=A0 Ple= ase
spend some time providing guidance so an operator can decide what best
works for their network. =C2=A0[I pointed below to other places there
operational guidance would be ideal.]

(3) I don't think that =C2=A75 (CPU and Memory Scalability) and Appendi= x A
(alternative solutions with limited applicability) should be part of
this document.=C2=A0 To start, comparisons are never good and the work has<= br> already been through the WG so there's no need to keep justifying it by comparing it to other work.=C2=A0 Both sections contain several claims (e.g. "extra cost in terms of CPU", "implemented efficiently= ",
"expected to be higher but comparable", "large amount of BGP= state and
churn", "result in tens of paths for each prefix") that don&= #39;t have
references, and could be considered subjective because they are
clearly relative and can change depending on the specific deployment
and configuration of the network.=C2=A0 I am not saying that the claims are=
false, simply requesting to take these two sections out.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
17=C2=A0 =C2=A0 =C2=A0 Abstract

19=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 This document defines an extension to B= GP route reflectors.=C2=A0 On route
20=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 reflectors, BGP route selection is modi= fied in order to choose the
21=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 best path from the standpoint of their = clients, rather than from the
22=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 standpoint of the route reflectors.=C2= =A0 Multiple types of granularity
23=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 are proposed, from a per client BGP rou= te selection or to a per peer
24=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 group, depending on the scaling and pre= cision requirements on route
25=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 selection.=C2=A0 This solution is parti= cularly applicable in deployments
26=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 using centralized route reflectors, whe= re choosing the best route
27=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 based on the route reflector IGP locati= on is suboptimal.=C2=A0 This
28=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 facilitates, for example, best exit poi= nt policy (hot potato
29=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 routing).

[major] "best path" =C2=A0rfc4271 doesn't use the term "= best path".=C2=A0 The
terminology used in this document should, at the very least, match
what the base spec defines.=C2=A0 Let's please not create new terminolo= gy
by indirection using the "definition of terms" section.


[minor] "proposed" =C2=A0This document is in line to be come an R= FC; we're
far beyond proposing things.=C2=A0 There are a couple of places later on where this same wording is used.=C2=A0 Please change it to specified or at<= br> least described (the latter probably fits best in this specific case).


[nit] s/from a per client BGP route selection or to a per peer
group/from per client BGP route selection or per peer group


[nit] s/precision requirements on route selection./precision requirements.<= br>

[nit] s/route reflector IGP location/route reflector's IGP location


[major] "IGP location" =C2=A0Before I forget -- please clearly de= fine (not
in the Abstract of course) what an "IGP location" is.


...
70=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 1.=C2=A0 Definitions of Terms Used in T= his Memo =C2=A0. . . . . . . . . . . =C2=A0 2
71=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 2.=C2=A0 Introduction =C2=A0. . . . . .= . . . . . . . . . . . . . . . . . . =C2=A0 3

[nit] It would be nice if the Introduction came up before the terminology.<= br>

...
91=C2=A0 =C2=A0 =C2=A0 1.=C2=A0 Definitions of Terms Used in This Memo

[minor] To avoid repeating some terms, it is good practice to indicate
which other RFCs the reader should be familiar with.=C2=A0 In this case
rfc4271 and rfc4456 come to mind.


...
132=C2=A0 =C2=A0 =C2=A02.=C2=A0 Introduction
...
153=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 11 of [RFC4456] describes a deployme= nt approach and a set of
154=C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints which, if satisfied, would resul= t in the deployment of
155=C2=A0 =C2=A0 =C2=A0 =C2=A0 route reflection yielding the same results a= s the IBGP full mesh
156=C2=A0 =C2=A0 =C2=A0 =C2=A0 approach.=C2=A0 This deployment approach mak= es route reflection compatible
157=C2=A0 =C2=A0 =C2=A0 =C2=A0 with the application of hot potato routing p= olicy.=C2=A0 In accordance
158=C2=A0 =C2=A0 =C2=A0 =C2=A0 with these design rules, route reflectors ha= ve traditionally often
159=C2=A0 =C2=A0 =C2=A0 =C2=A0 been deployed in the forwarding path and car= efully placed on the POP
160=C2=A0 =C2=A0 =C2=A0 =C2=A0 to core boundaries.

[nit] s/have traditionally often/have often
Redundant...


162=C2=A0 =C2=A0 =C2=A0 =C2=A0 The evolving model of intra-domain network d= esign has enabled
163=C2=A0 =C2=A0 =C2=A0 =C2=A0 deployments of route reflectors outside of t= he forwarding path.
164=C2=A0 =C2=A0 =C2=A0 =C2=A0 Initially this model was only employed for n= ew address families, e.g.
165=C2=A0 =C2=A0 =C2=A0 =C2=A0 L3VPNs and L2VPNs, however it has been gradu= ally extended to other
166=C2=A0 =C2=A0 =C2=A0 =C2=A0 BGP address families including IPv4 and IPv6= Internet using either
167=C2=A0 =C2=A0 =C2=A0 =C2=A0 native routing or 6PE.=C2=A0 In such environ= ments, hot potato routing
168=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy remains desirable.

[minor] "new address families, e.g. L3VPNs and L2VPNs" =C2=A0Thes= e are not
the name of the AFs.=C2=A0 Maybe call them new services.


[minor] "IPv4 and IPv6 Internet" =C2=A0The name of the AF is IP/I= P6; again,
you probably mean service/application.


[nit] "native routing or 6PE" =C2=A0Not 4PE applications? =C2=A0;= -) =C2=A0 It seems
to me that you can save some ink by ending the sentence after
"Internet".


...
194=C2=A0 =C2=A0 =C2=A03.=C2=A0 Modifications to BGP Best Path selection
196=C2=A0 =C2=A0 =C2=A0 =C2=A0 The core of this solution is the ability for= an operator to specify
197=C2=A0 =C2=A0 =C2=A0 =C2=A0 the IGP location for which the route reflect= or should calculate
198=C2=A0 =C2=A0 =C2=A0 =C2=A0 routes.=C2=A0 This can be done on a per rout= e reflector basis, per peer/
199=C2=A0 =C2=A0 =C2=A0 =C2=A0 update group basis, or per peer basis.=C2=A0= This ability enables the
200=C2=A0 =C2=A0 =C2=A0 =C2=A0 route reflector to send to a given set of cl= ients routes with
201=C2=A0 =C2=A0 =C2=A0 =C2=A0 shortest distance to the next hops from the = position of the selected
202=C2=A0 =C2=A0 =C2=A0 =C2=A0 IGP location.=C2=A0 This provides for freedo= m of route reflector physical
203=C2=A0 =C2=A0 =C2=A0 =C2=A0 location, and allows transient or permanent = migration of this network
204=C2=A0 =C2=A0 =C2=A0 =C2=A0 control plane function to an arbitrary locat= ion.

[major] "ability for an operator to specify the IGP location for which=
the route reflector should calculate routes.=C2=A0 This can be done on a per route reflector basis, per peer/update group basis, or per peer
basis."

When should an operator choose per RR vs per peer group vs per peer?
Choice is good, but providing guidance for the deployment is much
better.=C2=A0 Please consider adding text to =C2=A76 about the consideratio= ns to
chose one or the other.


[minor] "peer/update group" =C2=A0Where is this defined?=C2=A0 Is= there a
reference to a non-implementation-specific definition?=C2=A0 Can it be
called "a group of peers"?=C2=A0 Maybe you also want to include i= t in the
definitions in =C2=A71.


...
215=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0it can, and usually will, have a dif= ferent position in the IGP
216=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0topology, and

[] "usually will" =C2=A0 The position in the topology will *alway= s* be different!


...
222=C2=A0 =C2=A0 =C2=A0 =C2=A0 This document defines, on BGP Route Reflecto= rs [RFC4456], two changes
223=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the BGP Best Path selection algorithm:
[nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors<= br>

...
235=C2=A0 =C2=A0 =C2=A0 =C2=A0 A route reflector can implement either or bo= th of the modifications
236=C2=A0 =C2=A0 =C2=A0 =C2=A0 in order to allow it to choose the best path= for its clients that the
237=C2=A0 =C2=A0 =C2=A0 =C2=A0 clients themselves would have chosen given t= he same set of candidate
238=C2=A0 =C2=A0 =C2=A0 =C2=A0 paths.

[major] Please provide guidance for the operator to consider then one
or both should be used in their network.


240=C2=A0 =C2=A0 =C2=A0 =C2=A0 A significant advantage of these approaches = is that the route
241=C2=A0 =C2=A0 =C2=A0 =C2=A0 reflector clients do not need to run new sof= tware or hardware.

[nit] s/do not need to run new software or hardware./do not need to be modi= fied.


243=C2=A0 =C2=A0 =C2=A03.1.=C2=A0 Best Path Selection from a different IGP = location

245=C2=A0 =C2=A0 =C2=A0 =C2=A0 In this approach, optimal refers to the deci= sion made during best
246=C2=A0 =C2=A0 =C2=A0 =C2=A0 path selection at the IGP metric to BGP next= hop comparison step.=C2=A0 It
247=C2=A0 =C2=A0 =C2=A0 =C2=A0 does not apply to path selection preference = based on other policy
248=C2=A0 =C2=A0 =C2=A0 =C2=A0 steps and provisions.

[major] Please be specific about what is the "IGP metric to BGP next hop comparison step".=C2=A0 There is no step with that name, or even a=
string match in rfc4271.=C2=A0 Later you talk about the step e) tie-breaker=
-- don't wait to be specific!


...
263=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e) Remove from consideration an= y routes with less-preferred
264=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interior cost.=C2=A0 The interi= or cost of a route is determined by
265=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0calculating the metric from the= selected IGP location to the
266=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NEXT_HOP for the route using th= e shortest IGP path tree rooted at
267=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the selected IGP location.

[major] Note that the specification talks about "interior cost", = but
the descriptions in this document uses "IGP cost" and "IGP m= etric" to
refer to the same thing.=C2=A0 Please be consistent with existing
terminology!


[major] Related to the definition of "IGP location" and its
configuration.=C2=A0 How does the IGP location (and thus the calculation of=
the interior cost, as above) change when the configuration is done per
peer/update groups instead than per peer?=C2=A0 This is another point where=
operators could benefit from guidance (for the peer/update-group and
whole RR cases, of course).


...
275=C2=A0 =C2=A0 =C2=A0 =C2=A0 The configuration of the IGP location is out= side of the scope of this
276=C2=A0 =C2=A0 =C2=A0 =C2=A0 document.=C2=A0 The operator may configure i= t manually, an implementation
277=C2=A0 =C2=A0 =C2=A0 =C2=A0 may automate it based on heuristics, or it c= an be computed centrally
278=C2=A0 =C2=A0 =C2=A0 =C2=A0 and configured by an external system.

[nit] s/outside of the scope/outside the scope

[major] There are several places later on that talk about the
configuration, even making it a requirement for compliance (=C2=A76). =C2= =A0I
think that you don't mean the configuration itself, but the way in
which the configuration is instantiated in the router (which could be
considered an implementation detail).=C2=A0 As written, the text is not
clear.


280=C2=A0 =C2=A0 =C2=A0 =C2=A0 This solution does not require any change (B= GP or IGP) on the
281=C2=A0 =C2=A0 =C2=A0 =C2=A0 clients, as all required changes are limited= to the route reflector.

[] This was also claimed before.


283=C2=A0 =C2=A0 =C2=A0 =C2=A0 This solution applies to NLRIs of all addres= s families that can be
284=C2=A0 =C2=A0 =C2=A0 =C2=A0 route reflected.

[] Are there AFs that cannot be reflected?=C2=A0 Just wondering if you
really need to say this.


286=C2=A0 =C2=A0 =C2=A03.1.1.=C2=A0 Restriction when BGP next hop is BGP pr= efix

288=C2=A0 =C2=A0 =C2=A0 =C2=A0 In situations where the BGP next hop is a BG= P prefix itself, the IGP
289=C2=A0 =C2=A0 =C2=A0 =C2=A0 metric of a route used for its resolution SH= OULD be the final IGP
290=C2=A0 =C2=A0 =C2=A0 =C2=A0 cost to reach such next hop.=C2=A0 Implement= ations which can not inform
291=C2=A0 =C2=A0 =C2=A0 =C2=A0 BGP of the final IGP metric to a recursive n= ext hop SHOULD treat such
292=C2=A0 =C2=A0 =C2=A0 =C2=A0 paths as least preferred during next hop met= ric comparison.=C2=A0 However
293=C2=A0 =C2=A0 =C2=A0 =C2=A0 such paths SHOULD still be considered valid = for best path selection.

[major] The recursive resolution is already covered in rfc4271
(=C2=A75.1.3/=C2=A79.1.2.1).=C2=A0 Why isn't that enough?

There seems to be a difference: if an implementation "can not inform BGP of the final IGP metric to a recursive next hop...SHOULD still be
considered valid for best path selection." =C2=A0rfc4271 treats these<= br> routes as unresolvable.=C2=A0 Do you want to consider unresolvable routes?<= br>
Finally, there are a lot of SHOULDs in this paragraph.=C2=A0 Under which conditions is it ok to not perform the actions?=C2=A0 IOW, why are these actions recommended and not required?


295=C2=A0 =C2=A0 =C2=A03.2.=C2=A0 Multiple Best Path Selections

297=C2=A0 =C2=A0 =C2=A0 =C2=A0 BGP Route Reflector as per [RFC4456] runs a = single best path
298=C2=A0 =C2=A0 =C2=A0 =C2=A0 selection.=C2=A0 Optimal route reflection ma= y require calculation of
299=C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple best path selections or subsets of = best path selection in
300=C2=A0 =C2=A0 =C2=A0 =C2=A0 order to consider different IGP locations or= BGP policies for
301=C2=A0 =C2=A0 =C2=A0 =C2=A0 different sets of clients.

[] It hasn't been mentioned before, but the talk about policy made me think about this: =C2=A0 Can a client be present on different sets?=C2=A0 H= ow is
that handled in terms of BGP sessions?=C2=A0 Do we need multiple sessions?<= br> Or is add-path required?


303=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the required routing optimization is limi= ted to the IGP cost to
304=C2=A0 =C2=A0 =C2=A0 =C2=A0 the BGP Next-Hop, only step e) as defined [R= FC4271] section 9.1.2.2,
305=C2=A0 =C2=A0 =C2=A0 =C2=A0 needs to be duplicated.

[major] I'm not sure if this paragraph is referencing =C2=A73.1 (where = step
e) was just modified), or or you're saying that for each subset (from the last paragraph) only step e) is considered, or something else. =C2=A0??=


307=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the routing optimization requires the use= of different BGP
308=C2=A0 =C2=A0 =C2=A0 =C2=A0 policies for different sets of clients, a la= rger part of the decision
309=C2=A0 =C2=A0 =C2=A0 =C2=A0 process needs to be duplicated, up to the wh= ole decision process as
310=C2=A0 =C2=A0 =C2=A0 =C2=A0 defined in section 9.1 of [RFC4271].=C2=A0 T= his is for example the case
311=C2=A0 =C2=A0 =C2=A0 =C2=A0 when there is a need to use different polici= es to compute different
312=C2=A0 =C2=A0 =C2=A0 =C2=A0 degree of preference during Phase 1.=C2=A0 T= his is needed for use cases
313=C2=A0 =C2=A0 =C2=A0 =C2=A0 involving traffic engineering or dedicating = certain exit points for
314=C2=A0 =C2=A0 =C2=A0 =C2=A0 certain clients.=C2=A0 In the latter case, t= he user MAY specify and apply
315=C2=A0 =C2=A0 =C2=A0 =C2=A0 a general policy on the route reflector for = a set of clients.=C2=A0 For a
316=C2=A0 =C2=A0 =C2=A0 =C2=A0 given set of clients, the policy SHOULD in t= hat case allow the
317=C2=A0 =C2=A0 =C2=A0 =C2=A0 operator to select different candidate exit = points for different
318=C2=A0 =C2=A0 =C2=A0 =C2=A0 address families.=C2=A0 Regular path selecti= on, including IGP perspective
319=C2=A0 =C2=A0 =C2=A0 =C2=A0 for a set of clients as per Section 3.1, is = then applied to the
320=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate paths to select the final paths to= advertise to the
321=C2=A0 =C2=A0 =C2=A0 =C2=A0 clients.

[] Similar comment as before... =C2=A0 The use of "duplicated" is= confusing me.


[major] "the user MAY specify..." =C2=A0s/MAY/may =C2=A0 It seems= to me that
you're simply stating a fact (the user can do this), and not
specifying an optional behavior.


[major] "...the policy SHOULD in that case allow the operator to
select different candidate exit points for different address
families." =C2=A0There's no interoperable action that "the po= licy" can
execute.=C2=A0 It sounds as if you're recommending that specific knobs<= br> ("allow the operator to...") be implemented.=C2=A0 Please reword.=


[] You use "IGP perspective" I guess as equivalent to "IGP l= ocation"
-- is that right?


323=C2=A0 =C2=A0 =C2=A04.=C2=A0 Implementation considerations

325=C2=A0 =C2=A0 =C2=A04.1.=C2=A0 Likely Deployments and need for backup
[nit] Do we really need a sub-section if all the text for =C2=A74 is in it?=


327=C2=A0 =C2=A0 =C2=A0 =C2=A0 With IGP based optimal route reflection, eve= n though the IGP location
328=C2=A0 =C2=A0 =C2=A0 =C2=A0 could be specified on a per route reflector = basis or per peer/update
329=C2=A0 =C2=A0 =C2=A0 =C2=A0 group basis or per peer basis, in reality, i= t's most likely to be
330=C2=A0 =C2=A0 =C2=A0 =C2=A0 specified per peer/update group basis.=C2=A0= All clients with the same or
331=C2=A0 =C2=A0 =C2=A0 =C2=A0 similar IGP location can be grouped into the= same peer/update group.
332=C2=A0 =C2=A0 =C2=A0 =C2=A0 An IGP location is then specified for the pe= er/update group.=C2=A0 The
333=C2=A0 =C2=A0 =C2=A0 =C2=A0 location is usually specified as the locatio= n of one of the clients
334=C2=A0 =C2=A0 =C2=A0 =C2=A0 from the peer group or an ABR to the area wh= ere clients are located.
335=C2=A0 =C2=A0 =C2=A0 =C2=A0 Also, one or more backup locations SHOULD be= allowed to be specified
336=C2=A0 =C2=A0 =C2=A0 =C2=A0 for redundancy.=C2=A0 Implementations may wi= sh to take advantage of peer
337=C2=A0 =C2=A0 =C2=A0 =C2=A0 group mechanisms in order to provide for bet= ter scalability of
338=C2=A0 =C2=A0 =C2=A0 =C2=A0 optimal route reflector client groups with s= imilar properties.

[major] "IGP based optimal route reflection"

This is the first time you use "IGP based optimal route reflection&quo= t;; I
peeked forward and see that =C2=A75 also mentions "policy based optima= l
route reflection".=C2=A0 But you didn't define them anywhere -- in= fact,
the description before now focuses on the IGP location, which makes me
think about "IGP based".

I could guess that the "policy based" version is related to =C2= =A73.2, but
(1) no one should have to guess (!), and (2) the end of that section
says that "IGP perspective...is then applied", making it also &qu= ot;IGP
based". =C2=A0??

Please either define these types of ORR earlier in the text, or
(better yet) don't use the terms.=C2=A0 Instead, and given that the nam= es
are used just a couple of times, change "policy based" to "t= he case
where a policy is applied"...


[major] "one or more backup locations SHOULD be allowed to be
specified for redundancy"

(1) =C2=A73.1 says that the "configuration of the IGP location is outs= ide
of the scope of this document".=C2=A0 If that is true, then you can= 9;t
recommend anything related to the configuration.

(2) If there were "backup locations", how would they be used?


[minor] This is the only time that "optimal route reflector client
groups" is used.=C2=A0 I had been assuming that a group of clients wou= ld
correspond to a specific peer/update group (as mentioned many times
before).=C2=A0 Is there a difference between a "client group" and= grouping
clients to correspond to a peer/update group?


[] "for better scalability of optimal route reflector client groups&qu= ot;
What exactly does this mean?=C2=A0 I asked before about
references/definitions for peer/update groups; this point may be
related.


...
373=C2=A0 =C2=A0 =C2=A06.=C2=A0 Advantages and Deployment Considerations
375=C2=A0 =C2=A0 =C2=A0 =C2=A0 The solutions described provide a model for = integrating the client
376=C2=A0 =C2=A0 =C2=A0 =C2=A0 perspective into the best path computation f= or route reflectors.
377=C2=A0 =C2=A0 =C2=A0 =C2=A0 More specifically, the choice of BGP path fa= ctors in either the IGP
378=C2=A0 =C2=A0 =C2=A0 =C2=A0 cost between the client and the nexthop (rat= her than the IGP cost
379=C2=A0 =C2=A0 =C2=A0 =C2=A0 from the route reflector to the nexthop) or = other user configured
380=C2=A0 =C2=A0 =C2=A0 =C2=A0 policies.

[] "solutions"? =C2=A0 I only see one, where the "second&quo= t; one simply adds
policy, which is a pervasive tool in BGP.


382=C2=A0 =C2=A0 =C2=A0 =C2=A0 The achievement of optimal routing relies up= on all route reflectors
383=C2=A0 =C2=A0 =C2=A0 =C2=A0 learning all paths that are eligible for con= sideration.=C2=A0 In order to
384=C2=A0 =C2=A0 =C2=A0 =C2=A0 satisfy this requirement, path diversity enh= ancing mechanisms such as
385=C2=A0 =C2=A0 =C2=A0 =C2=A0 BGP add-path [RFC7911] may need to be deploy= ed between route
386=C2=A0 =C2=A0 =C2=A0 =C2=A0 reflectors.

[mayor] "path diversity enhancing mechanisms...may need to be deployed=
between route reflectors" =C2=A0Given that this is the Deployment
Considerations section, please provide guidance on when these
mechanisms are needed, and when they're not.


[minor] "path diversity enhancing mechanisms such as BGP add-path
[RFC7911]" =C2=A0Just out of curiosity, what other mechanisms are you<= br> thinking of?=C2=A0 Are there deployment considerations, when using ORR, to<= br> prefer one?


388=C2=A0 =C2=A0 =C2=A0 =C2=A0 Implementations considered compliant with th= is document allow the
389=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration of a logical location from whi= ch the best path will be
390=C2=A0 =C2=A0 =C2=A0 =C2=A0 computed, on the basis of either a peer, a p= eer group, or an entire
391=C2=A0 =C2=A0 =C2=A0 =C2=A0 routing instance.

[] I guess that "logical location" is another name for IGP locati= on...


[major] =C2=A73.1 says that the "configuration of the IGP location is<= br> outside of the scope of this document".=C2=A0 If that is true, then th= e
configuration cannot be a consideration for compliance.

A better wording for compliance would be: "An implementation MUST
allow the configuration..."


393=C2=A0 =C2=A0 =C2=A0 =C2=A0 These solutions can be deployed in tradition= al hop-by-hop forwarding
394=C2=A0 =C2=A0 =C2=A0 =C2=A0 networks as well as in end-to-end tunneled e= nvironments.=C2=A0 In networks
395=C2=A0 =C2=A0 =C2=A0 =C2=A0 where there are multiple route reflectors an= d hop-by-hop forwarding
396=C2=A0 =C2=A0 =C2=A0 =C2=A0 without encapsulation, such optimizations SH= OULD be enabled in a
397=C2=A0 =C2=A0 =C2=A0 =C2=A0 consistent way on all route reflectors.=C2= =A0 Otherwise, clients may
398=C2=A0 =C2=A0 =C2=A0 =C2=A0 receive an inconsistent view of the network,= in turn leading to
399=C2=A0 =C2=A0 =C2=A0 =C2=A0 intra-domain forwarding loops.

[major] "optimizations SHOULD be enabled in a consistent way on all route reflectors"

Is "a consistent way" different than "on all"? =C2=A0 s= /.../optimizations
SHOULD be enabled on all route reflectors

When is it ok for all RRs not to be enabled with the optimizations?
IOW, why is it recommended and not required?=C2=A0 Avoiding "intra-dom= ain
forwarding loops" sounds like a good reason to require it.


...
406=C2=A0 =C2=A0 =C2=A0 =C2=A0 As per above, these approaches reduce the am= ount of state which needs
407=C2=A0 =C2=A0 =C2=A0 =C2=A0 to be pushed to the edge of the network in o= rder to perform hot
408=C2=A0 =C2=A0 =C2=A0 =C2=A0 potato routing.=C2=A0 The memory and CPU res= ources required at the edge of
409=C2=A0 =C2=A0 =C2=A0 =C2=A0 the network to provide hot potato routing us= ing these approaches is
410=C2=A0 =C2=A0 =C2=A0 =C2=A0 lower than what would be required to achieve= the same level of
411=C2=A0 =C2=A0 =C2=A0 =C2=A0 optimality by pushing and retaining all avai= lable paths (potentially
412=C2=A0 =C2=A0 =C2=A0 =C2=A0 10s) per each prefix at the edge.

[] This paragraph sounds very speculative and doesn't seem necessary. In line with =C2=A75.


414=C2=A0 =C2=A0 =C2=A0 =C2=A0 The solutions above allow for a fast and saf= e transition to a BGP
415=C2=A0 =C2=A0 =C2=A0 =C2=A0 control plane using centralized route reflec= tion, without
416=C2=A0 =C2=A0 =C2=A0 =C2=A0 compromising an operator's closest exit = operational principle.=C2=A0 This
417=C2=A0 =C2=A0 =C2=A0 =C2=A0 enables edge-to-edge LSP/IP encapsulation fo= r traffic to IPv4 and
418=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 prefixes.

[] "allow for a fast and safe transition" =C2=A0Besides this stat= ement
sounding like a marketing brochure, if you're going to talk about
transition, please talk about it in detail.=C2=A0 Please take a look at
=C2=A72/rfc5706 and include details about the transition and how it is
"fast and safe".


420=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regarding Best Path Selection from a differe= nt IGP location, it
421=C2=A0 =C2=A0 =C2=A0 =C2=A0 should be self evident that this solution do= es not interfere with
422=C2=A0 =C2=A0 =C2=A0 =C2=A0 policies enforced above IGP tie-breaking in = the BGP best path
423=C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithm.

[minor] Don't assume anything is self evident to anyone.

Suggestion (maybe more appropriate in =C2=A73.1)>
=C2=A0 =C2=A0The modification specified in Section 3.1 does not impact any = previous
=C2=A0 =C2=A0considerations in the BGP Decision Process.


425=C2=A0 =C2=A0 =C2=A07.=C2=A0 Security Considerations

427=C2=A0 =C2=A0 =C2=A0 =C2=A0 Similarly to [RFC4456], this extension to BG= P does not change the
428=C2=A0 =C2=A0 =C2=A0 =C2=A0 underlying security issues inherent in the e= xisting IBGP [RFC4456].

[minor] No need to reference rfc4456 twice in the same sentence.


430=C2=A0 =C2=A0 =C2=A0 =C2=A0 It however enables the deployment of base BG= P Route Reflection as
431=C2=A0 =C2=A0 =C2=A0 =C2=A0 described in [RFC4456] to be possible using = virtual compute
432=C2=A0 =C2=A0 =C2=A0 =C2=A0 environments without any negative consequenc= e on the BGP routing path
433=C2=A0 =C2=A0 =C2=A0 =C2=A0 optimality.

[] I'm not sure how this relates to the specification itself (platform<= br> independent), but I'm sure the Security ADs will have a lot of
questions about the security of "virtual compute environments" --= and
where the details are included in this document. =C2=A0 IOW, that sounds like an unnecessary assertion.


[major] "without any negative consequence" =C2=A0The new function= ality
specified in this document is having the RR run the client's selection<= br> for them (even specific policy) -- there are risks related to the
duplication of the policy, the location of the RRs and the blind trust
that the clients need to have.=C2=A0 Or should the clients rerun the policy=
locally?

This behavior is not necessarily different from normal RR, but the
instantiation is different. =C2=A0 It would be very easy for a rogue RR to<= br> propagate incorrect routing information to its clients -- specially if
policy is offloaded to them.

In the worst case the result would be a sub-optimal route (maybe even
worse than what the clients get today), but probably not a "real"=
security issue.=C2=A0 It is probably a good idea to explain why it is not a=
security risk.


435=C2=A0 =C2=A0 =C2=A0 =C2=A0 This document does not introduce requirement= s for any new protection
436=C2=A0 =C2=A0 =C2=A0 =C2=A0 measures, but it also does not relax best op= erational practices for
437=C2=A0 =C2=A0 =C2=A0 =C2=A0 keeping the IGP network stable or to pace ra= te of policy based IGP
438=C2=A0 =C2=A0 =C2=A0 =C2=A0 cost to next hops such that it does not have= any substantial effect
439=C2=A0 =C2=A0 =C2=A0 =C2=A0 on BGP path changes and their propagation to= route reflection
440=C2=A0 =C2=A0 =C2=A0 =C2=A0 clients.

[major] "best operational practices" =C2=A0Like what?=C2=A0 It wo= uld be good to
provide (at least) informational references.


[major] "to pace rate of policy based IGP cost to next hops such that<= br> it does not have any substantial effect on BGP path changes" =C2=A0 Yo= u
will have to explain this further because the operation of an IGP is
not mentioned anywhere else.

IMHO, there's no need to go into IGP operational details in this
document.=C2=A0 There is nothing special/different about the operation of an IGP.


[End of Review]

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--


Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 301 502-1347


--
--0000000000001797f005c2f2dd8f--