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
- [Idr] AD Review of draft-ietf-idr-bgp-optimal-rou… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Robert Raszuk
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… bruno.decraene
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Robert Raszuk
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Gyan Mishra
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Gyan Mishra
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Robert Raszuk
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… UTTARO, JAMES
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Gyan Mishra
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Robert Raszuk
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Gyan Mishra
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… bruno.decraene
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal… bruno.decraene