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

[Gyan Mishra <[e-mail]>]

Makes sense.

Looks like ORR has already been implemented by vendors.  Good news!! 👍😀

https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7033&fn=BGP%20Optimal%20Route%20Reflection%20(BGP-ORR)

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/212881-border-gateway-protocol-bgp-optimal-ro.html



Kind Regards

Gyan

On Tue, May 25, 2021 at 11:35 AM Robert Raszuk <[e-mail]> wrote:

> Hi Gyan,
>
> >  Has this feature been implemented by any vendor
>
>
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations
>
>
> >  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 reason for this comment is that traditionally (or I should rather say
> historically) when networks were doing hop by hop IP lookup Rs were
> strictly placed either in the POPs or on the IGP paths to the POPs (or
> areas). That sort of assured optimal enough path selection.
>
> However the moment RRs were moved to central locations - or moving to run
> as logical slices in the cloud this is were ORR really helps to make them
> distributed optimal paths to clients.
>
> Thx,
> R.
>
> On Tue, May 25, 2021 at 5:22 PM Gyan Mishra <[e-mail]> wrote:
>
>>
>> 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*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*