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

From: <[email-masked]>
Date: Fri, 15 Jan 2021 09:59:59 +0000

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:[email-masked]]
Sent: Thursday, December 3, 2020 4:23 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Dan,

Thanks for your review and comments.
Please see inline [Bruno]

> From: Dan Romascanu via Datatracker [mailto:[email-masked]<mailto:[email-masked]>]
> 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.

---

From: Dan Romascanu <[email-masked]>
Date: Sat, 16 Jan 2021 00:33:44 +0200

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

Regards,

Dan

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

> > 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
>
>
>
> *From:* Dan Romascanu [mailto:[email-masked]]
> *Sent:* Thursday, December 3, 2020 4:23 PM
> *To:* DECRAENE Bruno TGI/OLN <[email-masked]>
> *Cc:* [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Opsdir early review of
> draft-ietf-idr-bgp-optimal-route-reflection-21
>
>
>
> Hi Bruno (and Robert),
>
>
>
> On Thu, Dec 3, 2020 at 3:30 PM <[email-masked]> wrote:
>
> Dan,
>
> > From: Dan Romascanu via Datatracker [mailto:[email-masked]]
> 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.
>
>
>
> - 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.
>
> 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.
>
>
>
>