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

[Nick Hilliard <[e-mail]>]

Gert Doering wrote:
> Nick was proposing "just do not bother using route-servers and always
> set up direct peerings, using automatization to solve all the problems
> caused by non-responsive / non-caring peers".

here's what I'm proposing:

- it would be a great idea for route servers to broker BFD sessions

- the gain provided by implementation of proposals like this will be
measured in minutes per year.

- the NH reachability feedback mechanism defined in
draft-ietf-idr-rs-bfd is too complicated for its own good and goes well
past the point of diminishing returns

- draft-chen-bfd-unsolicited is slightly too naive an approach to this
problem and ixp participants will end up being unhappy with its results

- if the NH reachability mechanism is cut out of draft-ietf-idr-rs-bfd
and replaced with a BFD candidacy mechanism, it would provide an very
good all-round fit for most peoples' bfd requirements

- the remaining small segment of organisations whose requirements cannot
be satisfied by this should use bilateral peering sessions

- organisations who feel strongly about fast convergence and
connectivity commutativity problems at IXPs need to think very carefully
about whether route servers are the best approach for their requirements
in the first place

- these last two sets of organisations are probably clued in enough to
be able to handle their peering requirements via automation (i.e.
hooking euro-ix json schema / peeringdb / etc into tools like napalm).

Nick