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

[Robert Raszuk <[e-mail]>]

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


On Thu, Jun 17, 2021 at 9:50 AM Nick Hilliard <[e-mail]> wrote:

> Robert Raszuk wrote on 16/06/2021 19:38:
> > 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
>
> > 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,
> >
> >
> > On Wed, Jun 16, 2021 at 6:19 PM Benjamin Kaduk via Datatracker
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     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 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >
>