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

[Robert Raszuk <[e-mail]>]

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.