Re: [Idr] I-D Action: draft-ietf-idr-bgp-nh-cost-02.txt

Hi Nick,

draft-ietf-idr-bgp-nh-cost is just a helper and companion document
to draft-ietf-idr-bgp-optimal-route-reflection.

The observation you make is already described in the latter one.

Moreover as of the current version of the draft there are three modes of
optimality from the perspective of RR:

-A- per RR logical placement
-B- per (peer/update) group logical placement
-C- per client logical placement

See section 2 of draft-ietf-idr-bgp-optimal-route-reflection for more
details.

draft-ietf-idr-bgp-nh-cost helps with all three cases eliminating the need
for remote SPF computation(s) which to some folks was the fundamental
concern in moving further with ORR :).

As of today I am aware of one large implementation which did all -A-, -B- &
-C- options as well as other implementation which did only -A-.

As far as your concern about implementation issues let's observe that
finnaly RRs are moving to x86 compute blades (where they always really
belonged). With that scalability of their processing does significantly
increses.

Best,
r.

On Sun, May 17, 2015 at 2:42 PM, Nick Hilliard <nick@foobar.org> wrote:

> On 16/05/2015 10:58, internet-drafts@ietf.org wrote:
> >    This draft augments BGPLS and defines a new extensions to exchange
> >    cost information to next-hops for the purpose of calculating best
> >    path from a peer perspective rather than local BGP speaker own
> >    perspective.
>
> correct me if I'm wrong, but if a RR starts calculating best path from the
> point of view of its clients rather than from its own perspective, this
> will require best path calculation per client on the RR (ala what goes on
> with multiple ribs in bgp route servers).  If this is the case, it might be
> worth mentioning it in the draft, because it creates significant
> implementation issues.
>
> Nick
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>