Subject: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 22 Jun 2016 15:57:20 +0000

Hello,

I am the Routing Area Directorate member that was assigned the QA review of draft-ietf-idr-bgp-optimal-route-reflection.

If you're not familiar with the QA review process please see:  https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

BR
Daniele

-          General comment:
The draft is understandable and does not require any major modification in addition to the minor edits and clarifications suggested below.
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?

-          Abstract

"   This document proposes a solution for BGP route reflectors to allow
   them to choose the best path their clients would have chosen under
   the same conditions, without requiring further state or any new
   features to be placed on the clients"
This is really hard to read. Maybe it could be improved stating what is the problem and what the solution is. You could copy a couple of sentences from section 1.1. which is much clear.

-          Introduction:

" In some situations, this method suffers from non-optimal path selection". Which path? The one used to forward the packets? The one used to redistribute the route? Or?
---
In a number of occurrences acronyms are not explained at first usage, e.g. POP, L3VPN, 6PE...
---

Another general comment: I like the rich intro full of details on the problem statement, the existing solutions and the proposed one. However I'm struggling to understand how an implementation could be declared to be compliant to this ID. The only thing I see is "the implementation MUST NOT prevent reflecting more than one path" and an analog requirement which is "the route reflector MUST reflect N optimal paths". I would have expected this to be an amendment to the existing RFC that states that a single path can be reflected.

---

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Jun 2016 19:46:42 +0200

Hi Daniele,

Many thx for your review. While I will clarify some text you pointed to in
the draft let me also answer some of your questions below.

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

​Actually current workarounds are very limited to either installing
​physical hardware at various IGP locations or what is quite unlikely to
attach Route Reflectors over manually created tunnels.

Let's also observe here that the paradigm of control plane is shifting from
traditional routers to x86 virtual space or even cloud. As result without
this proposal operators have choice of their route reflectors distributing
suboptimal paths or distributing all paths and in turn allowing clients to
make independent best path selection.

Now while the latter could be even an option in router's world more and
more BGP is being observed on the compute servers where sending there all
present in an AS BGP paths would be for one undesired as well would require
to run also IGP on those compute machines. Of course I am talking about the
case where we use IBGP in such setup.

Is the usage of the actual mechanisms so disoptimized to require these
> changes?

​It is unfortunately. Traditionally RRs were all fine as they were in the
data path. Then came MPLS and later other encapsulations where only ingress
node started to make a decision to which next hop tunnel the packet hece
RRs migrated from data plane to somewhere on the stick.

And that was the origin of the problem we face today that either each
ingress much have all the paths or it get's to exit via suboptimal egress.

How many possible paths are there between the client and the AS border node?

​That depends. I have seen anywhere from 2-4 to 100s where say each AS (out
of three major SPs in the country) is EBGP peering locally with other two
in each metro or in each prefecture - and they do it to optimize exit
rather then always traverse Tokyo or Osaka.

Another general comment: I like the rich intro full of details on the
> problem statement, the existing solutions and the proposed one. However I’m
> struggling to understand how an implementation could be declared to be
> compliant to this ID. The only thing I see is “the implementation MUST NOT
> prevent reflecting more than one path” and an analog requirement which is
> “the route reflector MUST reflect N optimal paths”. I would have expected
> this to be an amendment to the existing RFC that states that a single path
> can be reflected.
>

​Implementation basically should allow ​to configure per instance or per
group of peers logical location from which either for the entire instance
or for set of peers best path will be computed.

Many thx once again,
Robert.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 23 Jun 2016 13:26:41 +0000

Hi Robert,

Thanks a lot for the useful info. I guess this is well known to IDR experts but adding this explanation content to the draft would be extremely helpful for newbies.

BR
Daniele

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: mercoledì 22 giugno 2016 19:47
To: Daniele Ceccarelli <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection

Hi Daniele,

Many thx for your review. While I will clarify some text you pointed to in the draft let me also answer some of your questions below.

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?

​Actually current workarounds are very limited to either installing ​physical hardware at various IGP locations or what is quite unlikely to attach Route Reflectors over manually created tunnels.

Let's also observe here that the paradigm of control plane is shifting from traditional routers to x86 virtual space or even cloud. As result without this proposal operators have choice of their route reflectors distributing suboptimal paths or distributing all paths and in turn allowing clients to make independent best path selection.

Now while the latter could be even an option in router's world more and more BGP is being observed on the compute servers where sending there all present in an AS BGP paths would be for one undesired as well would require to run also IGP on those compute machines. Of course I am talking about the case where we use IBGP in such setup.

Is the usage of the actual mechanisms so disoptimized to require these changes?

​It is unfortunately. Traditionally RRs were all fine as they were in the data path. Then came MPLS and later other encapsulations where only ingress node started to make a decision to which next hop tunnel the packet hece RRs migrated from data plane to somewhere on the stick.

And that was the origin of the problem we face today that either each ingress much have all the paths or it get's to exit via suboptimal egress.

​That depends. I have seen anywhere from 2-4 to 100s where say each AS (out of three major SPs in the country) is EBGP peering locally with other two in each metro or in each prefecture - and they do it to optimize exit rather then always traverse Tokyo or Osaka.

Another general comment: I like the rich intro full of details on the problem statement, the existing solutions and the proposed one. However I’m struggling to understand how an implementation could be declared to be compliant to this ID. The only thing I see is “the implementation MUST NOT prevent reflecting more than one path” and an analog requirement which is “the route reflector MUST reflect N optimal paths”. I would have expected this to be an amendment to the existing RFC that states that a single path can be reflected.

​Implementation basically should allow ​to configure per instance or per group of peers logical location from which either for the entire instance or for set of peers best path will be computed.

Many thx once again,
Robert.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 24 Jun 2016 16:07:09 +0000

Daniele,

There are frequently more than 10 paths per net in a route reflector. Sending all those paths to clients exceeds their memory. It is not cost effective to upgrade all the clients to be able to consume all the paths.

Thanks,
Jakob.

On Jun 22, 2016, at 9:07 AM, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

BR
Daniele

-          General comment:

-          Abstract

-          Introduction:

---

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr