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

[Nick Hilliard <[e-mail]>]

>    2.  Client routers must have a means of communicating the knowledge
>        of the failure (and restoration) back to the route server.

I don't see why this is necessary.

It would be useful to have a mechanism for a RS to broker bfd
connectivity between rsclients, but that's about as far as it should go.
 Having this information relayed back to and processed by the RS itself
is both unnecessary and unwise.

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.

It's unwise because:

-  the proposal allows rsclient A to influence reachability for their
competitor, rsclient B.  This is a show-stopper in my books but other
people may have different opinions.

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

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

- maintaining state, particularly derived state, is generally a poor
idea, particularly when based on slightly vague data inputs, and where
the consequences of either misinformation or misinterpretation of this
state would be dropped packets.

- this proposal adds a good deal of complication to the interaction
between RS, rsclients and the routing decision engine functionality.
This stuff is complicated enough already, and there would have to be
unusually clear and compelling arguments to make it worth adding in the
extra failure modes that complication like this is going to create.

- 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.
 There are plenty of automation tools out there and it's not that hard
to do.

Please let's keep rs bfd brokerage as simple as possible. I don't want
front-line ixp support issues to have to be dealt with by 3rd line
engineering.

Nick