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

[Daniele Ceccarelli <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: mercoledì 22 giugno 2016 19:47
To: Daniele Ceccarelli <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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.


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.