[Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 16 June 2021 16:19 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3798A3A1E29; Wed, 16 Jun 2021 09:19:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, idr-chairs@ietf.org, idr@ietf.org, John Scudder <jgs@juniper.net>, Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.32.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162386038468.2054.10058025206181569780@ietfa.amsl.com>
Date: Wed, 16 Jun 2021 09:19:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_ybpBt_yhPpPEoq29K9REijAcfA>
Subject: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 16 Jun 2021 16:19:46 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-idr-bgp-optimal-route-reflection-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document; it gives a clear explanation of what is to be done and why, and I basically only have nit-level comments, with the exception of the first remark. Section 4 This solution can be deployed in traditional hop-by-hop forwarding networks as well as in end-to-end tunneled environments. In networks where there are multiple route reflectors and hop-by-hop forwarding without encapsulation, such optimizations SHOULD be consistently enabled on all route reflectors. Otherwise, clients may receive an inconsistent view of the network, in turn leading to intra-domain forwarding loops. The scope of "forwarding loops" as a potential problem makes me wonder if the "SHOULD"-level requirement for this avoidance mechanism is the right choice. Section 5 Thank you for accepting the wording suggestion from Roman; it's a good improvement. I might consider reiterating that there are risks if multiple route reflectors are present but using different policy/procedures, though the earlier discussion may suffice. Section 9.2 Whether RFC 7911 should be normative or informative seems potentially subject to debate, if deployment of add-path is required in order for correct operation of optimal route reflectors. NITS This ability enables the route reflector to send to a given set of clients routes with shortest distance to the next hops from the position of the selected IGP location. [...] This feels a bit like a garden-path sentence that makes the reader backtrack to fix their parse tree; commas around "to a given set of clients" might help but a more substantive restructuring might be preferred. This provides for freedom of route reflector physical location, and allows transient or permanent migration of this network control plane function to an arbitrary location. Pedantically, such a migration seems like it would always have been possible, just with a potentially significant impact on performance and route quality; I'd suggest appending a phrase such as "with negligible impact on performance". The choice of specific granularity (route reflector, set of clients, or client) is configured by the network operator. An implementation is considered compliant with this document if it supports at least one listed grouping of IGP location. It's not entirely clear to me how a "listed grouping of IGP location" maps to the previous text. Section 3.2 If the required routing optimization is limited to the IGP cost to the BGP Next-Hop, only step e) and below as defined [RFC4271] section 9.1.2.2, needs to be run multiple times. I think maybe s/and below/and subsequent steps/, and s/as defined/as defined in/. Section 4 route reflectors. More specifically, the choice of BGP path factors in either the IGP cost between the client and the NEXT_HOP (rather I suggest s/factors in/takes into account/, since "factors in" is something of a colloquialism. Modifying the IGP location of BGP ORR does not interfere with policies enforced before IGP tie-breaking (step e) in the BGP Decision Process Route. I think "step e" has to be scoped to §9.1.2.2 of RFC 4271. Similarly, if an IGP location is selected for the whole routing instance, the lowest precision is achieved, but the performance impact is minimal (both should be equal to the [RFC4456] ones). [...] The phrasing in the parenthetical seems surpising to me -- what does "both" refer to? I can only see the one "performance of the single-IGP-location-for-the-whole-routing-instance" situation, which of course should have equivalent performance to the stock RFC 4456 case. Section 5 This extension provides a new metric value using additional information for computing routes for BGP router reflectors. While s/router/route/
- [Idr] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Alvaro Retana
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Nick Hilliard
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Alvaro Retana