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

Robert Raszuk <robert@raszuk.net> Mon, 24 May 2021 16:26 UTC

Return-Path: <robert@raszuk.net>
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 A4AC13A2E22 for <idr@ietfa.amsl.com>; Mon, 24 May 2021 09:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 y_Kyo6cai4R8 for <idr@ietfa.amsl.com>; Mon, 24 May 2021 09:26:06 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 CB8ED3A2E24 for <idr@ietf.org>; Mon, 24 May 2021 09:26:04 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id q3so11339366lfu.2 for <idr@ietf.org>; Mon, 24 May 2021 09:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RFk79go50b4tyDzbbwsiuGHyjZpfrIqiLFswluc7ct0=; b=VYktaO9gzhyJ62p1NYcG1dbTloYYiEe6h7h60xKBU3INAg8HxdenM6uih5y9hnLXJA p84J0Bwn8ZGGGrFJjD1+KWQVBPegV9RaMs+dMFFvnExtVKL8fnQO/9uXUl6AxNKXbsla TxluwWy8cROBml/Otj4qWqsVNbZLeazoEFMxeTd0sDBzyznjatZhdrEcHg2f9QU7z8Au ERhmTt/ST8rKAgB+xLDyGHEf/HbhybHFS9RIVhdArF6MW6aiSSjP1IudfNQnveteDiyX ZhkaMaywlWMtHsxnT27utsV6tAODvAl1HRHDHstXk6yJw6coyHdyLq+kEzhn3cA7t3/z sZWw==
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=RFk79go50b4tyDzbbwsiuGHyjZpfrIqiLFswluc7ct0=; b=R1q8ktEN+AwdSTmnQZHCQXYA2FXtoaOQV9tAgVWx8JN5k/oUsV2FbsCE3h/ILP2UXb fkc4LiRIvWa+rsjHShpZY73EIDfEz531p+MRBbaVHrNo9Zrk0fCmEhB3Y5CHA3W+Tcio FyJ9XCZef9qh/+7W0C+RNy1VvLG9iVo5H42Fm6OusVtgqGgoV8QraSEbJwOgKsPPXllQ X91/1eyTe8bsKa9W+TvsGHjgXuod43XW4Lx15/v8xFdxGligJvkqR4JrExwvqcwuN3MT 7O14Vn+bbQUXymYDXzuQY0t9nL/rcchhro3ljQeK3YlQoTJitjf/Nob//9OgY5ADvrgC cNkw==
X-Gm-Message-State: AOAM532Rz1yYKIs7O7+i/bL7rT2zt3qcRMxFov9zL5J4eLnGx4M2B2/t QM0E3tjaHeAWIFtQLIQgXa1ib8UkPCxNo13wNAQWLoEWBz+NUw==
X-Google-Smtp-Source: ABdhPJza6vHM/nOsR2NX9xoD9kZ7rgSpBiuvktF/Df+scVOF1+RLgKCHrp7DF1l62Ad9EAxdOVP8UQnmeCtqPgqJA84=
X-Received: by 2002:ac2:561a:: with SMTP id v26mr11451147lfd.602.1621873557835; Mon, 24 May 2021 09:25:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESswK38j+PXQAJ4rDZSNSN-ZjutUSE=fSO0QvoYS3sLRgfA@mail.gmail.com> <CABNhwV2t-OUuYgF-xUsYgOoiDSnkN_NY2zxWHyBBoufaUOqA1g@mail.gmail.com> <CABNhwV3j8cZGKA1st_erTvQKWstrs_=5EgYUPyx0+Vg=p-Vwew@mail.gmail.com>
In-Reply-To: <CABNhwV3j8cZGKA1st_erTvQKWstrs_=5EgYUPyx0+Vg=p-Vwew@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 24 May 2021 18:25:47 +0200
Message-ID: <CAOj+MMG7xjONhGVXG10RK4n1SXJs4s+RtM7Z51UjjtP6W-YjHQ@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, IDR List <idr@ietf.org>, Susan Hares <shares@ndzh.com>, draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049254005c315dd90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/z4gADlG1uTQXcJcnJCP09Iasydc>
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 <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2021 16:26:11 -0000

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 <hayabusagsm@gmail.com> 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 <hayabusagsm@gmail.com> 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 <aretana.ietf@gmail.com>
> > 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