Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

[Robert Raszuk <[e-mail]>]

Hi,

I think it does apply.

Reason is that you can't (well shouldn't) delay to send a client a path
with different next hop when previous next hop is down and you know (by
learning per prefix policies) that no other client got such next hop.

Of course implementation wise there can be per nh global counter
incremented when you advertise given path to the client.

Good luck troubleshooting those cases on RS ;).

Cheers,
R.




Note that due to selective policy only very few clients may get given path
so your heuristic would now also need to account for static or dynamic
(signalled with communities) policies.


What I described was per next hop, not per route, so I don't think your
critique applies.





Well I have nothing against machine learning or AI, but do we really need
it here on RSes ?


This is a straw man of course.

--John


Thx
R.

On Jul 4, 2017 17:55, "John G. Scudder" <[e-mail]> wrote:

> One observation regarding the "RR won't scale if it has to do per-client
> route selection" concern -- it seems to me it would be entirely feasible
> for an implementation to associate some figure-of-merit with each next hop,
> a function of its reported reachability by each of its indirect peers. That
> figure-of-merit could be used during traditional (not per-client) route
> selection. The general idea would be "if one other client can't reach you,
> that's their problem, if dozens of other clients can't reach you, maybe we
> should choose a different next hop if we've got one" [*]. Think of it as
> making the binary resolvability condition of RFC 4271 9.1.2.1 fuzzy.
>
> I think specifying the function would be beyond the scope of this (or
> really, any) draft since it's "just policy". But it demonstrates there's
> some potential benefit from the proposal without going all the way down to
> per-client route selection.
>
> --John
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>