Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

["John G. Scudder" <[e-mail]>]

On Jul 3, 2017, at 12:08 PM, Job Snijders <[e-mail]> wrote:
> 
> Does this version include anything related to my remarks in this
> message?
> 
>    https://mailarchive.ietf.org/arch/msg/idr/2LgFxEqjmWSVuAC5PM103pR7buU

Yes, at least in some small way:

   Throughout this document, we generally assume that the route server
   being discussed is able to represent different RIBs towards different
   clients, as discussed in section 2.3.2.1 of [RFC7947].  If this is
   not the case, the procedures described here to allow BFD to be
   automatically provisioned between clients still have value; however,
   the procedures for signaling reachability back to the route server
   may not.

My summary of the major points in your your wall-of-text :-) is

a. There is value in the provisioning BFD part,
b. There is not value in the communicating reachability state back to the server part.

The paragraph above hopefully captures (a). As for (b), I (as an author) didn't see WG consensus to get rid of that element of the draft. Since that was exactly the raison d'être of the draft, it would have been pretty cheeky to cut it out without WG consensus to make that kind of major course change (more than just an "optimalisation" as you described it).

A possible middle ground would be to more clearly divide the procedural elements of (a) and (b) in the draft, so that an implementation could clearly say it does (a) but not (b). If the WG wants to do this, I think it may be easier with the refactored version.

HTH,

--John