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

[Dan Romascanu <[e-mail]>]

Thanks for addressing my comments. This version looks good to me.

Regards,

Dan


On Fri, Jan 15, 2021 at 12:00 PM <[e-mail]> wrote:

> Hi Dan,
>
>
>
> As a follow up, FYI, we have just published revision -22.
>
>
>
> -22 should reflect your comments as per our discussion on the list (copied
> below)
>
>
>
> > The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/
>
> > A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-22
>
>
>
> Note that -22, hence the diff, also includes other comments.
>
>
>
> Thanks again for your review and comments.
>
>
>
> --Bruno
>
>
>
> *From:* Dan Romascanu [mailto:[e-mail]]
> *Sent:* Thursday, December 3, 2020 4:23 PM
> *To:* DECRAENE Bruno TGI/OLN <[e-mail]>
> *Cc:* [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: Opsdir early review of
> draft-ietf-idr-bgp-optimal-route-reflection-21
>
>
>
> 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
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>