Re: [Idr] comments on draft-ietf-idr-rs-bfd

[Nick Hilliard <[e-mail]>]

Jeffrey Haas wrote:
> On Tue, Aug 01, 2017 at 02:07:42PM +0100, Nick Hilliard wrote:
>> It's unnecessary because if there is a mechanism available to broker bfd
>> sessions between rsclients, then this allows each rsclient to make their
>> own decision about whether they want to use this and make their own
>> decisions about NH reachability.  If this is in place, the RS doesn't
>> need to augment this information because the client has all the tools
>> they need to be able to do this.
> 
> In the absence of multiple paths from the RS, the only choice the client
> gets to make is use/don't use.

that's an acceptable compromise.  IXPs provide alternative / nearer
paths, but never the only path.  Add-path is orthogonal to this problem:
 it would be a useful addition for providing alternatives, but the
nature of IXPs is such that it's not necessary.

>> - it puts the ixp in the position of making pronouncements about the
>> reachability of its rsclient base.  From a layer 9 point of view, it
>> could be argued that there might be liability problems if it gets this
>> wrong due to e.g. poisoned / late / incorrect data from rsclients.
> 
> Vs. announce stuff that is blackholing?  Recall we're having this
> conversation for a reason.

this is a policy / optics point: the difference between the two things
is that a baseline RS announces a NH without making any pronouncement
about the NH's reachability. draft-ietf-idr-rs-bfd is making a statement
about the NH's reachability, but based on heuristics which we know will
not take into account all failure modes of an IXP fabric, particularly
some of the more common ones (i.e. partial reachability).

The baseline RS performance will not perform as well from a technical
point of view.

The draft-ietf-idr-rs-bfd could potentially open the IXP operator up to
service loss liability if a statement is made about NH reachability
which is not true from the point of view of any pair of RS clients.

[...]

> It's not clear what you're suggesting.

see my earlier reply to Gert.

Nick