Re: [Idr] Opsdir 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 BE1703A03F3; Fri, 15 Jan 2021 02:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level:
X-Spam-Status: No, score=-2.116 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-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 QOf4vvtk1Gsc; Fri, 15 Jan 2021 02:00:02 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F4F3A03F1; Fri, 15 Jan 2021 02:00:01 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4DHGrJ0bvGzCrDV; Fri, 15 Jan 2021 11:00:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610704800; bh=XfYLyABkfiWSEl9ykaZ2T1bFew7dGr0GnniMJGvKGX4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=GVnKukqG2Yj/PmDDg/i0WXVSv3yZjQedk64pzkWERKaFG1eA0sFORnvXnkWq4AHyM /DMg5Gf0F1Ju6C1GJDzpATFvNcG30dkghnNHrZSd+KPwUFosU3wDPDFNb3/kbkIhqq kGCZjX7ieGbcM6e+J8Vy1CnkPPoP/3efN8j4TsdOJzp3d9R9EmxP50BXW4lfvuB9ws 6hvBLozkj38vCqSXfsB57n3wc0D7IQz87cSaz8oqLimnABDe0uHgZafeLo2SoVwIkz SLuVJYNvIANTS/F9314cpdMBOAWoK5WeNxl7GG0r2xn7SiWtNceDcOPhp6PmBPBTyh F5O8EKnQqCHlw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4DHGrH6dNqzDq7S; Fri, 15 Jan 2021 10:59:59 +0100 (CET)
From: <bruno.decraene@orange.com>
To: Dan Romascanu <dromasca@gmail.com>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "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>
Thread-Topic: Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
Thread-Index: AQHWyYgkjpML2ewQn0mNqp9qQi39x6ooqE7w
Date: Fri, 15 Jan 2021 09:59:59 +0000
Message-ID: <5567_1610704800_6001679F_5567_432_1_53C29892C857584299CBF5D05346208A490944FF@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <160699217439.12968.15167518753403970194@ietfa.amsl.com> <27284_1607002256_5FC8E88F_27284_93_1_53C29892C857584299CBF5D05346208A4903BA78@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAFgnS4UavotVxYVBYKth_S+GkPBXts8zv1E2dynxGQgN9SEq3w@mail.gmail.com>
In-Reply-To: <CAFgnS4UavotVxYVBYKth_S+GkPBXts8zv1E2dynxGQgN9SEq3w@mail.gmail.com>
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: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A490944FFOPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/B7lEsRcCtzSbF_rn4coP8oB4FPc>
Subject: Re: [Idr] Opsdir 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 Dan,



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

From: Dan Romascanu [mailto:dromasca@gmail.com]
Sent: Thursday, December 3, 2020 4:23 PM
To: DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com>
Cc: ops-dir@ietf.org; draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org; idr@ietf.org
Subject: Re: Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

Hi Bruno (and Robert),

Thanks for your quick responses and for addressing my comments.

Please see in-line.

Regards,

Dan




On Thu, Dec 3, 2020 at 3:30 PM <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
Dan,

Thanks for your review and comments.
Please see inline [Bruno]

> From: Dan Romascanu via Datatracker [mailto:noreply@ietf.org<mailto:noreply@ietf.org>]
> Sent: Thursday, December 3, 2020 11:43 AM
>
> Reviewer: Dan Romascanu
> Review result: Has Issues
>
> This document defines an extension to BGP route reflectors by which BGP
> route
> selection is modified in order to choose the best path for their clients
> standpoint, rather than from the route reflectors standpoint. The
> Introduction
> includes text that describes in what situations these extensions are
> applicable.
>
> >From the operators perspective, Section 4 and Section 6 includes important
> recommendations for SP operators, as well as deployment considerations.
>
> The document is Almost Ready from an OPS perspective. I would suggest
> however
> to clarify the following two issues before approval:
>
> 1. In Section 3:
>
> > Both modifications rely upon all route reflectors learning all paths
>    that are eligible for consideration.  In order to satisfy this
>    requirement, path diversity enhancing mechanisms such as add-path may
>    need to be deployed between route reflectors.
>
> What are the consequences of this condition not being met? Are there any
> requirements or recommendations for operators in deployment? Some
> clarification
> text would be useful, did I miss something?

[Bruno] Good point.

I'd propose the following change:
OLD:
<t>Both modifications rely upon all route reflectors learning all paths
that are eligible for consideration. In order to
satisfy this requirement, path diversity enhancing mechanisms such as
add-path may need to be deployed between route
reflectors.</t>

NEW:
<t>For both modifications, the achievement of optimal routing relies upon all route reflectors learning all paths
that are eligible for consideration. In order to
satisfy this requirement, path diversity enhancing mechanisms such as
BGP add-path <xref target="RFC7911" /> may need to be deployed between route
reflectors.</t>


Do you think that the consequences of not doing so (i.e. not achieving optimal routing) are clear enough, or should we add another sentence?
As this text if for network operator more than implementers, I would propose to move it to section " 6.  Advantages and Deployment Considerations". More specifically after the first paragraph. I which case I would remove " For both modifications," which act as a liaison with previous text in section 3.

These edits look good and clarify the issue.


> 2. In Section 3.1:
>
> > In addition to the change specified in [RFC4456] section 9, the BGP
>    Decision Process Tie Breaking rules ([RFC4271] Sect.  9.1.2.2) are
>    modified as follows.
>
> Should not the document UPDATE RFC 4271 (when approved)?

[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 [1].  BGP Route Reflector did change the decision process but  did not update 4271.

That been said, I leave this to the AD/IESG.

Leaving the decision to the AD/IESG is fine with me. I would just observe that the document is targeting not only implementers but also operators - people who use this document, deploy and debug the protocol. This being said, I recognize that there is a precedent in the fact that RFC 4456 did not update RFC4271 even though it also modified section 9.1.2.2 there.


[1] https://tools.ietf.org/html/rfc4456


Somewhat related I moved RFC 4456 (BGP RR) from Informative to Normative Reference.

Yes, this would indeed help.


Thanks,

--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.