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

[Jeffrey Haas <[e-mail]>]

Robert and Job answered some of the points already.  I'll skip those.

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.

> - 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.

> - the draft makes an implicit assumption that reachability between each
> rsclient is a ternary state, which it is not.  E.g. one of the most
> common ixp commutativity failure situations is where you have an
> ecmp/lag bundle between rsclient A and B, and a single member link dies,
> leading to partial failure between A and B.  If BFD and BGP work fine,
> then the IXP has just made a pronouncement that NH reachability is good,
> which it is not.  Awkward.

Already an existing issue.  Perfect? No.  Not trying to be.

> - this proposal adds a good deal of complication to the interaction
> between RS, rsclients and the routing decision engine functionality.

Route selection using proxied reachability state in a RS view is hard?  No,
same as existing RS cost.

The one valid criticism is what to do when a RS view contains multiple
peers.  In such cases, this proposal is less useful except in the clear case
where all peers in the view are unable to reach the relevant nexthop.

> - route server connectivity brokerage is generally considered to be the
> poor first cousin of bilateral connectivity over an IXP and the poor
> second cousin of a private network interconnection.  If an rsclient
> cares enough about its data flows that reachability is sufficiently
> important to justify being protected by BFD, then I'd argue that they
> should just do this rather than outsourcing the problem to someone else.

The issue is fundamental to BGP third-party nexthops.  It's particularly the
case when such nexthops are available across a fundamentally NBMA
environment.

>  There are plenty of automation tools out there and it's not that hard
> to do.

It's not clear what you're suggesting.

-- Jeff