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

[[e-mail]]

Hi Daniele,

Please see inline [Bruno2]

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: Monday, December 7, 2020 1:51 PM
> To: DECRAENE Bruno TGI/OLN <[e-mail]>
> Cc: [e-mail]; [e-mail]; rtg-
> [e-mail]
> Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-
> reflection-21
> 
> Hi Bruno,
> 
> Please see in line.
> 
> BR
> Daniele
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: den 7 december 2020 13:22
> To: Daniele Ceccarelli <[e-mail]>
> Cc: [e-mail]; [e-mail]; rtg-
> [e-mail]
> Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-
> reflection-21
> 
> 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.
> [DC] no. I added that I'm fine with the text added in appendix A.
> 
> 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).
> 
> [DC] i was just suggesting to have something as a bullet, eg. a dash.

[Bruno2] ok. Thanks. Done.

> 
> > - 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.
> [DC] great. That works.
> 
> > 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.
> [DC] indeed. What about compatibility issues with implementations based on
> old step e)?

[Bruno2]
There is a text covering this in 3rd paragraph of https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-21#section-6
In general, I'd say that the main issue is coming from/since RR / RFC 4456. Cf last paragraph of https://tools.ietf.org/html/rfc4456#section-11  From a route selection standpoint, I don't see that it really matters whether the RR is physically located on Node 3 as per RFC 4456, or 'logically located' on Node 3 as per  draft-ietf-idr-bgp-optimal-route-reflection

Thanks,
--Bruno

> [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.
> [DC] you're more than welcome.
> --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.


_________________________________________________________________________________________________________________________

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.