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

[Dan Romascanu <[e-mail]>]

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 <[e-mail]> wrote:

> Dan,
>
> Thanks for your review and comments.
> Please see inline [Bruno]
>
> > From: Dan Romascanu via Datatracker [mailto:[e-mail]]
> > 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
>
>
>
>