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

["Jerome Durand (jerduran)" <[e-mail]>]

Hi Jeffrey,

Thank you for taking the time to read the document and providing comments.

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

Idea is that it is up to admin to decide what we wants to do with routes for any next-hop depending on its corresponding BFD session state. As an example one could decide to keep accepting routes if BFD never reaches an up state, but with a lower local-pref if desired. This point could be let to implementation. This is a good point we can try to document this in next versions.

> - What about if you see the remote nexthop but the remote nexthop doesn't
>  see you?

Remote next-hop would signal BFD session state in next control messages and everyone would agree that session state is now down. At this point policy can be applied on corresponding routes. We could detail how solution solves various types of problems that can be met on IXPs if this can help global understanding.

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

Well we do this for session ageing which we believe is crucial for scalability and manageability. We are trying to signal that BFD session is needed or not needed locally. This is different from BFD session state and that’s why we kept that at another level. In other words we say: « Session is UP but personnaly I don’t need a session with you anymore. Do you need to keep the session with me? » Idea of using diag codes is to do this signalling without changing BFD protocol definition.

Thanks,

Jerome