Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)

[Jeffrey Haas <[e-mail]>]

[Responding from the top of the thread intentionally.]

On Sun, Mar 15, 2015 at 08:56:52PM +0000, Jerome Durand (jerduran) wrote:
> Dear all,
> 
> I think draft-ymbk-idr-rs-bfd-00.txt addresses real issues that need to be solved somehow and I?m happy to see work conducted on the topic.
> 
> However the approach chosen implies that IXP members rely on a mechanism to be implemented on the route-server, while we believe a direct approach could be simpler and quicker to implement, and much more reliable. David Freedman and I have worked on finding a solution for quite some time now and we are proposing an approach based on BFD, which can be found here:
> 
> https://tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt

Things I like about your draft:
- Autodiscovery of the endpoint for BFD just by gleaning the nexthops.

Things that need a bit of clarification:
- What procedures do you do if the remote side doesn't support BFD? 
- What about if you see the remote nexthop but the remote nexthop doesn't
  see you?

Things I don't like:
- You're trying to use BFD diag codes without state changes as state for the
  session.  Wearing my BFD chair hat, I have some reservations about this.

The point raised in the thread about draft-ymbk is something I think is
worth addressing: Give the RS a chance to unhide paths if you can't use
them. 

All of this said, I think the core behavior of getting nexthop validation
via BFD is the key property that gets the best improvement.  I think this
gives us a basis to refine both proposals.

-- Jeff