Subject: [RTG-DIR] Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

From: Daniele Ceccarelli via Datatracker <[email-masked]>
Date: Mon, 07 Dec 2020 01:00:34 -0800

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

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" - Section 3: there are some issues with bullet items - 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. Since step e) is modified probably the draft should
update RFC 4271?

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.

---

From: <[email-masked]>
Date: Mon, 7 Dec 2020 12:21:41 +0000

Daniele,

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

> From: Daniele Ceccarelli via Datatracker [mailto:[email-masked]]
> Sent: Monday, December 7, 2020 10:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
> 
[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.
 
> 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
> 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
 
> 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.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 7 Dec 2020 12:51:08 +0000

Hi Bruno,

Please see in line.

BR
Daniele  

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: den 7 december 2020 13:22
To: Daniele Ceccarelli <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

Daniele,

> Subject: Rtgdir early review of 
> draft-ietf-idr-bgp-optimal-route-reflection-21
> 
> 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.

 
> - Astract: "to choose the best path for their clients standpoint" i 
> guess this should be "From their clients standpoint" - Abstract: 
> "multiple type - multiple types"

[DC] i was just suggesting to have something as a bullet, eg. a dash.

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

NEW:

[DC] great. That works.

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

That been said, I leave this to the AD/IESG.
[DC] indeed. What about compatibility issues with implementations based on old step e)?

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

---

From: <[email-masked]>
Date: Mon, 7 Dec 2020 16:30:22 +0000

Hi Daniele,

Please see inline [Bruno2]

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: Monday, December 7, 2020 1:51 PM
> To: DECRAENE Bruno TGI/OLN <[email-masked]>
> 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.
> 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.
> 

[Bruno2] ok. Thanks. Done.

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

[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

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