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

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Thu, 03 Dec 2020 02:42:54 -0800

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?

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)?

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 3 Dec 2020 14:25:43 +0100

Hi Dan,

Many thx for the review.

> text would be useful, did I miss something?

If the route reflector does not contain all eligible paths its decision may
be suboptimal in the sense of choosing the exit path still perhaps closer
in metric to logical placement of the RR (better then overall best). In
general if route reflectors even without this extension do not contain all
eligible paths for a given net and clients are connected without strict
topology awareness in basic IP hop by hop forwarding loops can easily
happen.

Original RR design was to place them in the data path (typically at or near
are boundaries or POP boundaries). With networks moving away from hop by
hop IP lookup to ingress-egress encapsulation that MUST condition or design
rule has been safely relaxed and RRs have moved to central positions.

BGP Optimal Route Reflection does not really place any additional burden on
the RR design as such. Contrary it allows to place RRs (perhaps running on
general compute x86 blades) anywhere in the network and still be able to
accomplish the optimal choice of path(s).

With all of that said I recognize that the current text may sound a bit too
scary :) I will talk with co-authors on rewording or removing it.

> Should not the document UPDATE RFC 4271 (when approved)?

Well I don't think so. See this is not modification to BGP protocol as such
.. just an optional functional enhancement.

Just like original route reflection RFC 4456 did not update RFC4271 even
though it also modified section 9.1.2.2 there.

Likewise Add-paths RFC 7911 did not update neither RFC4456 nor RFC4271, but
obviously does change best path selection when choosing more then best path
for advertisement irrespective of metric to the next hop.

Many thx,
Robert.

---

From: <[email-masked]>
Date: Thu, 3 Dec 2020 13:30:54 +0000

Dan,

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

> From: Dan Romascanu via Datatracker [mailto:[email-masked]]
> Sent: Thursday, December 3, 2020 11:43 AM
> 
> Reviewer: Dan Romascanu

[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.

> 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.

[1] https://tools.ietf.org/html/rfc4456

Somewhat related I moved RFC 4456 (BGP RR) from Informative to Normative Reference.

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: Thu, 3 Dec 2020 17:22:42 +0200

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]> wrote:

> 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.

> - 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.

> Somewhat related I moved RFC 4456 (BGP RR) from Informative to Normative

Yes, this would indeed help.