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

[Job Snijders <[e-mail]>]

On Mon, Jul 03, 2017 at 12:19:08PM -0400, John G. Scudder wrote:
> 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).

Ah, yes of course WG consensus is important. I had assumed that the
authors were expressing their 100% agreement with all my points through
silence. ;-)

I look forward to hearing counterpoints as to why it is useful to
communicate reachability state back to the route server, and how the
authors (or other working group participants) envision the scalability
cost aspect.

Kind regard,

Job