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

[[e-mail]]

Daniele,

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

> From: Daniele Ceccarelli via Datatracker [mailto:[e-mail]]
> Sent: Monday, December 7, 2020 10:01 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
> 
> Reviewer: Daniele Ceccarelli
> Review result: Ready
> 
> The draft has been significantly improved since my previous review (v11).
> Since the draft progressed till v21 i assume the working group found an
> agreement on the usefulness of the idea. Please see my previous comment:
> 
> "My concern, which is something the working group probably already
> discussed,
> is about the complexity and usefulness of the idea. The goal of draft is: "The
> core of this solution is the ability for an operator to specify on a per route
> reflector basis or per peer/update group basis or per peer basis the virtual
> IGP location placement of the route reflector. This enables having a given
> group of clients receive routes with  optimal distance to the next hops from
> the position of the configured virtual IGP location.  This also provides for
> freedom of route reflector location and allows transient or permanent
> migration
> of such network control plane function to optimal location.”
> 
> But I understand that there is a number of workarounds and that different
> paths
> are already used for redundancy reasons, hence my
>  questions is: is it worth defining a new solution? Is the usage of the actual
>  mechanisms so disoptimized to require these changes? How many possible
> paths
>  are there between the client and the AS border node?"
>
[Bruno] I don't read that you are calling for specific changes in the draft/specification.

For what it worth, I can offer my personal feedback.
In the networks, there are multiple paths to a given destination/NLRI. BGP Route Reflector are a widely deployed tool but they may introduce non optimal routing in some cases. The typical solution to mitigate is to carefully position those BGP Route Reflectors in the IGP topology. This brings operational costs and inflexibilities during maintenance operations, addition/removal of RR for scaling purpose, moving this control plane function out of data plane/chassis routers in particular when 'virtualizing' them on generic x86 servers which are better suited in term of CPU/memory/power/cooling capability. So yes, I believe that the extension provided in §3.1 [1] is very useful to decouple the physical location of the BGP RR from the logical selection of the so called best routes. I find this a useful flexibility and don't find the cost of this extension high with regards to the benefit.
[1] https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-21#section-3.1

I could say more, but given that this document will eventually reach the IESG 10 years after its initial version, and multiple implementations, I think that the train left the station a while ago.
 
> I see that appendix A has been added with alternative solutions, very good.
> 
> I only found minor comment and nits.
> - Astract: "to choose the best path for their clients standpoint" i guess this
> should be "From their clients standpoint" - Abstract: "multiple type - multiple
> types" 

[Bruno] Corrected *2. Thanks.

>- Section 3: there are some issues with bullet items

[Bruno] Sorry, could you be more specific? (There are 2*2 bullet items and the issue is not apparent to me).


> - Section 3: "The
> first change is related to the IGP cost to the BGP Next Hop, which is done in
> the step e) in the BGP decision process" where is step e) defined? maybe a
> missing reference? ...further reading the document i find a description of
> step
> e) in section 3.1. Maybe just saying "as described in section 3.1 " would be
> enugh. - Section 3.1.

[Bruno] As you found out, this is step 2) of the BGP decision process https://tools.ietf.org/html/rfc4271#section-9.1.2.2

Since the latest version of the draft has more text on this in section 3.1, I would propose:
OLD:
      The first change is related to the IGP cost to the BGP Next Hop,
      which is done in the step e) in the BGP decision process.

NEW:
      The first change, introduced in section 3.1, is related to the IGP cost to the BGP Next Hop,
      in the BGP decision process.


I've also added the reference of the second bullet.

> Since step e) is modified probably the draft should
> update RFC 4271?

[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 [2].  Note that BGP Route Reflector also changed the decision process and did not update 4271.

That been said, I leave this to the AD/IESG.

[2] https://tools.ietf.org/html/rfc4456
 
> Overall i like the way that the abstract and the introduction have been
> updated, with the former introducing the solution and the latter well
> explaining the problem to be solved.

[Bruno] Thanks. Improvements come from review from new eyes. So thank you again for your time, you review and comments.
--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.