Subject: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 16 Jun 2021 09:19:45 -0700

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/

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Jun 2021 20:38:39 +0200

Hi Benjamin,

Many thx for your review.

Great catch on SHOULD vs MUST !  Changed.

On the point regarding the Security Considerations  section 5 the
inconsistent policies would only be of a problem in those networks which do
not encapsulate packets in some way between ingress and egress. So to
restate this the significant portion of Deployment Considerations would
have to be repeated. Also while clearly a valid point in regards to routing
correctness it is debatable if this is a security risk as such even if
policy would be completely wrong between participating route reflectors.

Regarding moving referencing of RFC7911 to normative let's observe that it
may be required only in one specific deployment scenario of using multiple
clusters in non encapsulating networks for IPv4/IPv6 AFs. It is clearly not
required for other deployment models of BGP ORR. Therefore I am not sure if
it deserves the elevated level of referencing in the document. But if the
above use is a sufficient reason to treat it as normative reference I
personally have no problem moving it.

All other NITS were fixed. Thank you so much for help in spotting those
unclear sentences.

I will be posting the next version shortly.

Kind regards,
Robert,

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Jun 2021 13:36:26 -0700

Hi Robert,

> Great catch on SHOULD vs MUST !  Changed.

Thanks!

> policy would be completely wrong between participating route reflectors.

Understood; it does not seem worth duplicating so much of the deployment
considerations just for this point.

> personally have no problem moving it.

I'm happy to leave this to the responsible AD; my comment stems from the
IESG statement at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
that points out that "even references that are relevant only for optional
protocol features must be classified as normative" (if they would otherwise
meet the criteria.  Only needed in some deployment scenarios is not quite
the same as being an optional feature, though, so I think there's still
some element of judgment needed.

> I will be posting the next version shortly.

Sounds good, and thanks!

-Ben

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Jun 2021 23:07:53 +0200

> Hello Ben & Alvaro,

In the case of this work the situation is not really about Add-Paths RFC
being necessary for the proposed enhancement/protocol feature either
mandatory or optional. It is helpful to some Route Reflector deployment
scenarios with or without this extension. ORR only observes that to get
consistent IBGP paths Add-Paths may be used between RR clusters. So could
Diverse-Path technique and in some cases perhaps also consistent controller
based path installation. There can be even more ways to accomplish
consistent path selection pool across clusters.

But as you suggest I think moving RFC7911 to the normative reference should
not be a problem if AD or anyone else finds this appropriate.

I will therefore hold publishing -26 till we get some clarity on this point
from an AD.

Many thx,
Robert

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 16 Jun 2021 14:28:14 -0700

Robert:

Hi!

Given the text in §4:

   The achievement of optimal routing between clients of different
   clusters relies upon all route reflectors learning all paths that are
   eligible for consideration.  In order to satisfy this requirement,
   BGP add-path [RFC7911] needs to be deployed between route reflectors.

...making rfc7911 a Normative reference makes sense to me.

Thanks!

Alvaro.

On June 16, 2021 at 5:08:03 PM, Robert Raszuk ([email-masked]) wrote:

Hello Ben & Alvaro,

Many thx,
Robert

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Jun 2021 23:30:02 +0200

Ok - Will update the draft accordingly.

Many thx !
Robert.

On Wed, Jun 16, 2021 at 11:28 PM Alvaro Retana <[email-masked]>
wrote:

> But as you suggest I think moving RFC7911 to the normative reference
> should not be a problem if AD or anyone else finds this appropriate.
>
> I will therefore hold publishing -26 till we get some clarity on this
> point from an AD.
>
> Many thx,
> Robert
>
>
>
>
>
>
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 Jun 2021 08:49:46 +0100

> Great catch on SHOULD vs MUST !  Changed.

there's no compelling need to change this - it's operational advice, not 
part of the protocol spec.  As it's operational advice, a) no-one will 
read the rfc, but if they do there are already enough warning signs in 
place and b) if it's ignored, the network won't work properly anyway. 
An operational guidelines RFC may be useful here.

Nick

> inconsistent policies would only be of a problem in those networks which 
> do not encapsulate packets in some way between ingress and egress. So to 
> have to be repeated. Also while clearly a valid point in regards to 
> routing correctness it is debatable if this is a security risk as such 
> even if policy would be completely wrong between participating route 
> reflectors.
> 
> Regarding moving referencing of RFC7911 to normative let's observe that 
> it may be required only in one specific deployment scenario of using 
> multiple clusters in non encapsulating networks for IPv4/IPv6 AFs. It is 
> clearly not required for other deployment models of BGP ORR. Therefore I 
> am not sure if it deserves the elevated level of referencing in the 
> document. But if the above use is a sufficient reason to treat it as 
> normative reference I personally have no problem moving it.
> 
> On Wed, Jun 16, 2021 at 6:19 PM Benjamin Kaduk via Datatracker 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>                                                          This ability
>     enables
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Jun 2021 11:46:15 +0200

Hi Nick,

I am not sure if use of special keywords applies to deployment
consideration sections or not. I was under impression that they do hence
original SHOULD changed to MUST, however if there is consensus that it does
not I am more then happy to change it to lower case must or for that matter
replace IETF keywords with some other wording to make it not controversial.

We are also discussing with authors if this sentence deserves a bit more
clarity to narrow down the applicability scope. The point being as
correctly pointed out by Bruno that network can be global and one region
may deploy ORR and other may not and nothing will break.

Many thx,
Robert

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 17 Jun 2021 04:21:45 -0700

On June 17, 2021 at 5:46:48 AM, Robert Raszuk wrote:

> clarity to narrow down the applicability scope. The point being as correctly
> pointed out by Bruno that network can be global and one region may deploy
> ORR and other may not and nothing will break.

FWIW, that was my interpretation when I read the draft: it is not
necessary to deploy ORR across all clusters in the network.  The
sentence could use clarification.

Thanks!

Alvaro.