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

bruno.decraene@orange.com Thu, 03 December 2020 13:30 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 62AA33A0A83; Thu, 3 Dec 2020 05:30:59 -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_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 pffV4brlq3er; Thu, 3 Dec 2020 05:30:57 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AA63A0A96; Thu, 3 Dec 2020 05:30:57 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4CmxYX0wVgz5w6v; Thu, 3 Dec 2020 14:30:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607002256; bh=u79HEo6XzX5SvGeREt3LEkFEctc60lGcel0uzmqLSxg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=guVspbW3Bi7m3P8JxbTFFizIB5p+GeeYw/YosdXubIAC9jAtRznoRU1S6ij7bXJWy lcLKXJPcxyQF4V9gQ9Q6uBpP4O9e5nl1SW9mwpdQMNdhKhG8wjArYb8QCrdoowQndf pHSqFepQq7W/NF4u+O7jN7tatYY7kLsMwti33uXN2XOS5P6IGT8TyVImp9u827+J4p 2k3pLHWGXf3qNHlZO75t9ZOD2WD+SgcvOrGDLT/tuPe3eHdVdj2qT7bxNXgBuGFwH8 AAb4K8JyiVhmqR+HunEiqHJlurtjVLYQsasnYAJhL3QAjUgiGkheFpMXbrEsiMGUoh XfBDPSYDLL4YQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4CmxYW6wVlzDq7C; Thu, 3 Dec 2020 14:30:55 +0100 (CET)
From: <bruno.decraene@orange.com>
To: Dan Romascanu <dromasca@gmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
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>
Thread-Topic: Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
Thread-Index: AQHWyWEQjpML2ewQn0mNqp9qQi39x6nlNr1g
Date: Thu, 3 Dec 2020 13:30:54 +0000
Message-ID: <27284_1607002256_5FC8E88F_27284_93_1_53C29892C857584299CBF5D05346208A4903BA78@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <160699217439.12968.15167518753403970194@ietfa.amsl.com>
In-Reply-To: <160699217439.12968.15167518753403970194@ietfa.amsl.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0BMhIC7vD3OhjG4DW4yrRY7iicQ>
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: Thu, 03 Dec 2020 13:31:00 -0000

Dan,

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

> From: Dan Romascanu via Datatracker [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.

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

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


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

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.