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

[John Scudder <[e-mail]>]

On Jul 5, 2017, at 11:05 AM, Robert Raszuk <[e-mail]> wrote:
> 
> Hi John,
> 
> You are describing the situation where client notices next hop down, notifies RS but does not get new path till other clients also report the same next hop as down.
> 
> Is this really a good idea ?

If the RS does implement per-client selection, then it gets a new path right away, but concerns have been raised about the computational and storage costs of per-client. The baseline RS as currently deployed will obviously not provide a new path to the client nor will it even know about the client's connectivity issue. I have merely pointed out that there is a middle ground available. Whether it's "really a good idea" or not is for the implementor and operator of the RS to say (and the WG too, I suppose, if we wanted to bake the idea into the draft, though I think that is not necessary).

> 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] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>