Re: [Idr] Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

bruno.decraene@orange.com Fri, 15 January 2021 10:00 UTC

Return-Path: <bruno.decraene@orange.com>
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 3FFC73A03F1; Fri, 15 Jan 2021 02:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 0CQxuf3uqFyB; Fri, 15 Jan 2021 02:00:01 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EB13A03EC; Fri, 15 Jan 2021 01:59:58 -0800 (PST)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4DHGrF0QCDz5w52; Fri, 15 Jan 2021 10:59:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610704797; bh=Zxc5PhlRTZV8lbesjC8bydqnF80YO7WZ5GytQsp4f3c=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jSeAWVjq7lwjbcVon2P4omOEStRRD2JpKiyRkGS0kn+DF0rh2S+umxJaNDEuIPUhJ wBZ7lWsCOh6F+KiAzH2lI8Yh/26D+XTvQbI6kbDGmfIDZANcgyD3CZ3um/S/zmaRta ylVg4/7A64Hz+kVOuWoMJmYukTFKi7C/HjgU1cHo+sAXcvEAKP9461oEwl4pO7q95D hBMYklf9rWlofJ3kJsW7ZRIjKdeqwqxC4evYkGxTenaxxUL1uwDD9DeJby94Hz8YG9 v0oDCU2hDtNITNgXZSiEX8fg9SPgZw4Qrk0IMzf9a+njwKw9il7SLSv8tnEF1GzsI4 jupk4YjBt2Wmw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4DHGrD6Nz8zBrM3; Fri, 15 Jan 2021 10:59:56 +0100 (CET)
From: <bruno.decraene@orange.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
CC: "draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org" <draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Thread-Topic: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
Thread-Index: AQHWzJONNefTTYlsd0qoB4E3TnMtOqnrkpVQgAAH7LCAPQZ2cA==
Date: Fri, 15 Jan 2021 09:59:56 +0000
Message-ID: <21119_1610704796_6001679C_21119_489_1_53C29892C857584299CBF5D05346208A490944F7@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <160733163424.31714.2821566109849202386@ietfa.amsl.com> <27215_1607343702_5FCE1E55_27215_76_1_53C29892C857584299CBF5D05346208A490425B6@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <HE1PR0701MB22823F29BCA88BE14B56F46FF0CE0@HE1PR0701MB2282.eurprd07.prod.outlook.com> <2362_1607358623_5FCE589F_2362_75_1_53C29892C857584299CBF5D05346208A49042F77@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <2362_1607358623_5FCE589F_2362_75_1_53C29892C857584299CBF5D05346208A49042F77@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GlwBGNEQwJKjfGAVxh1-vyls5Yk>
Subject: Re: [Idr] Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
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: Fri, 15 Jan 2021 10:00:06 -0000

Hi Daniel,

As a follow up, FYI, we have just published revision -22.

-22 should reflect your comments as per our discussion on the list (copied below)

> The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/
> A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-22

Note that -22, hence the diff, also includes other comments.

Thanks again for your review and comments.

--Bruno
> -----Original Message-----
> From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
> Sent: Monday, December 7, 2020 5:30 PM
> To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
> Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org; idr@ietf.org; rtg-
> dir@ietf.org
> Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-
> reflection-21
> 
> Hi Daniele,
> 
> Please see inline [Bruno2]
> 
> > -----Original Message-----
> > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> > Sent: Monday, December 7, 2020 1:51 PM
> > To: DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com>
> > Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org; idr@ietf.org;
> rtg-
> > dir@ietf.org
> > Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-
> > reflection-21
> >
> > Hi Bruno,
> >
> > Please see in line.
> >
> > BR
> > Daniele
> >
> > -----Original Message-----
> > From: bruno.decraene@orange.com <bruno.decraene@orange.com>
> > Sent: den 7 december 2020 13:22
> > To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
> > Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org; idr@ietf.org;
> rtg-
> > dir@ietf.org
> > Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-
> > reflection-21
> >
> > Daniele,
> >
> > Thanks for your review and comments.
> > Please see inline [Bruno]
> >
> > > From: Daniele Ceccarelli via Datatracker [mailto:noreply@ietf.org]
> > > Sent: Monday, December 7, 2020 10:01 AM
> > > To: rtg-dir@ietf.org
> > > Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org;
> > > idr@ietf.org
> > > Subject: Rtgdir early review of
> > > draft-ietf-idr-bgp-optimal-route-reflection-21
> > >
> > > Reviewer: Daniele Ceccarelli
> > > Review result: Ready
> > >
> > > The draft has been significantly improved since my previous review (v11).
> > > Since the draft progressed till v21 i assume the working group found
> > > an agreement on the usefulness of the idea. Please see my previous
> > comment:
> > >
> > > "My concern, which is something the working group probably already
> > > discussed, is about the complexity and usefulness of the idea. The
> > > goal of draft is: "The core of this solution is the ability for an
> > > operator to specify on a per route reflector basis or per peer/update
> > > group basis or per peer basis the virtual IGP location placement of
> > > the route reflector. This enables having a given group of clients
> > > receive routes with  optimal distance to the next hops from the
> > > position of the configured virtual IGP location.  This also provides
> > > for freedom of route reflector location and allows transient or
> > > permanent migration of such network control plane function to optimal
> > > location.”
> > >
> > > But I understand that there is a number of workarounds and that
> > > different paths are already used for redundancy reasons, hence my
> > > questions is: is it worth defining a new solution? Is the usage of the
> > > actual  mechanisms so disoptimized to require these changes? How many
> > > possible paths  are there between the client and the AS border node?"
> > >
> > [Bruno] I don't read that you are calling for specific changes in the
> > draft/specification.
> > [DC] no. I added that I'm fine with the text added in appendix A.
> >
> > For what it worth, I can offer my personal feedback.
> > In the networks, there are multiple paths to a given destination/NLRI. BGP
> > Route Reflector are a widely deployed tool but they may introduce non
> > optimal routing in some cases. The typical solution to mitigate is to carefully
> > position those BGP Route Reflectors in the IGP topology. This brings
> > operational costs and inflexibilities during maintenance operations,
> > addition/removal of RR for scaling purpose, moving this control plane
> > function out of data plane/chassis routers in particular when 'virtualizing'
> > them on generic x86 servers which are better suited in term of
> > CPU/memory/power/cooling capability. So yes, I believe that the
> extension
> > provided in §3.1 [1] is very useful to decouple the physical location of the
> > BGP RR from the logical selection of the so called best routes. I find this a
> > useful flexibility and don't find the cost of this extension high with regards
> to
> > the benefit.
> > [1] https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-
> > 21#section-3.1
> >
> > I could say more, but given that this document will eventually reach the
> IESG
> > 10 years after its initial version, and multiple implementations, I think that
> the
> > train left the station a while ago.
> >
> > > I see that appendix A has been added with alternative solutions, very
> good.
> > >
> > > I only found minor comment and nits.
> > > - Astract: "to choose the best path for their clients standpoint" i
> > > guess this should be "From their clients standpoint" - Abstract:
> > > "multiple type - multiple types"
> >
> > [Bruno] Corrected *2. Thanks.
> >
> > >- Section 3: there are some issues with bullet items
> >
> > [Bruno] Sorry, could you be more specific? (There are 2*2 bullet items and
> > the issue is not apparent to me).
> >
> > [DC] i was just suggesting to have something as a bullet, eg. a dash.
> 
> [Bruno2] ok. Thanks. Done.
> 
> >
> > > - Section 3: "The
> > > first change is related to the IGP cost to the BGP Next Hop, which is
> > > done in the step e) in the BGP decision process" where is step e)
> > > defined? maybe a missing reference? ...further reading the document i
> > > find a description of step
> > > e) in section 3.1. Maybe just saying "as described in section 3.1 "
> > > would be enugh. - Section 3.1.
> >
> > [Bruno] As you found out, this is step 2) of the BGP decision process
> > https://tools.ietf.org/html/rfc4271#section-9.1.2.2
> >
> > Since the latest version of the draft has more text on this in section 3.1, I
> > would propose:
> > OLD:
> >       The first change is related to the IGP cost to the BGP Next Hop,
> >       which is done in the step e) in the BGP decision process.
> >
> > NEW:
> >       The first change, introduced in section 3.1, is related to the IGP cost to
> the
> > BGP Next Hop,
> >       in the BGP decision process.
> >
> >
> > I've also added the reference of the second bullet.
> > [DC] great. That works.
> >
> > > Since step e) is modified probably the draft should update RFC 4271?
> >
> > [Bruno] I don't believe so.
> > - In the sense that people implementing 4271 but not implementing this
> > document do not need to be aware of this document.
> > - This document is primarily an extension of BGP Route Reflector [2].  Note
> > that BGP Route Reflector also changed the decision process and did not
> > update 4271.
> >
> > That been said, I leave this to the AD/IESG.
> > [DC] indeed. What about compatibility issues with implementations based
> on
> > old step e)?
> 
> [Bruno2]
> There is a text covering this in 3rd paragraph of
> https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-
> 21#section-6
> In general, I'd say that the main issue is coming from/since RR / RFC 4456. Cf
> last paragraph of https://tools.ietf.org/html/rfc4456#section-11  From a
> route selection standpoint, I don't see that it really matters whether the RR is
> physically located on Node 3 as per RFC 4456, or 'logically located' on Node 3
> as per  draft-ietf-idr-bgp-optimal-route-reflection
> 
> Thanks,
> --Bruno
> 
> > [2] https://tools.ietf.org/html/rfc4456
> >
> > > Overall i like the way that the abstract and the introduction have
> > > been updated, with the former introducing the solution and the latter
> > > well explaining the problem to be solved.
> >
> > [Bruno] Thanks. Improvements come from review from new eyes. So
> thank
> > you again for your time, you review and comments.
> > [DC] you're more than welcome.
> > --Bruno
> >
> >
> >
> >
> >
> >
> __________________________________________________________
> >
> __________________________________________________________
> > _____
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites
> > ou copies sans autorisation. Si vous avez recu ce message par erreur,
> veuillez
> > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> > messages electroniques etant susceptibles d'alteration, Orange decline
> toute
> > responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> > information that may be protected by law; they should not be distributed,
> > used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete
> > this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been
> > modified, changed or falsified.
> > Thank you.
> 
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.