Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

[Gyan Mishra <[e-mail]>]

Hi Robert

This is an excellent optimization concept for RR scalability as well as
limiting the number of paths per prefix reflected to the clients which can
be enormous.

Verizon as well as other internet providers can take advantage of this
solution and help reduce the number of paths being reflected to clients.

I support advancement of this draft.

Minor comments on the draft text below:

Introduction paragraph 4 -
I don’t think hot potato routing is ever desirable where the RR is making
the best path decision instead of the client is ever better in the case
where the RR is not in the forwarding plane.

The evolving model of intra-domain network design has enabled
deployments of route reflectors outside of the forwarding path.
   Initially this model was only employed for new services, e.g.  IP
   VPNs [RFC4364 <https://datatracker.ietf.org/doc/html/rfc4364>],
however it has been gradually       extended to other BGP services
including IPv4 and IPv6 Internet.  In such environments, hot
   potato routing policy remains desirable.



Has this feature been implemented by any vendor to test the viability and
CPU resources necessary related to multiple decision processes due to IGP
location change?

Thanks

Gyan
On Mon, May 24, 2021 at 12:25 PM Robert Raszuk <[e-mail]> wrote:

> Gyan,
>
> This solution selects optimal paths for a given net. As RD is part of the
> net we would not select paths between nets.
>
> Note that tp the best of my knowledge we still have a day one option-B
> problem where two or more ASBRs may give us same net and VPNv4 RRs may
> choose single one only before advertising to peers. ORR may help here a bit
> to give different paths to different clients.
>
> To your other comment sure ORR is not required if we use "add-paths all"
> or have full IBGP mesh. But I know about networks where for each net there
> is 100s of paths hence add-path all is not a practical starter.
>
> Cheers,
> R.
>
> On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <[e-mail]>
> wrote:
>
>> 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 <[e-mail]>
>> 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
>> RRs
>> > 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
>> are
>> > 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
>> paths
>> > based on the client IGP location rooted topological path to the exit
>> point
>> > 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 <[e-mail]>
>> > 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.  §6 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 §5 (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
>> choose
>> >> 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.
>> This
>> >> 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
>> requirements.
>> >>
>> >>
>> >> [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
>> terminology.
>> >>
>> >>
>> >> ...
>> >> 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
>> path.
>> >> 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
>> calculate
>> >> 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 §6 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 §1.
>> >>
>> >>
>> >> ...
>> >> 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
>> Reflectors
>> >>
>> >>
>> >> ...
>> >> 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
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*