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

[Jeffrey Haas <[e-mail]>]

> On Jul 4, 2017, at 3:13 PM, Job Snijders <[e-mail]> wrote:
> 
> On Tue, Jul 04, 2017 at 02:36:10PM -0400, Jeffrey Haas wrote:
>> My point here is that at no point does this document mandate the RS
>> implement path selection mechanisms in response to the reported state
>> from the clients.  However, this shouldn't preclude implementations
>> that desire to make use of such state.
>> 
>> Thus, I don't understand the proscriptive desires.
> 
> Interesting, my perception of the document was different. From section 4
> it is not clear to me that this behaviour is optional:

I see the issue now.  Some of the language got simplified out of -03 from -02.  My fault as one of the contributors in not catching this in John's rewrite.  

In -02:

3.  Advertising Client Router Connectivity to the Route Server

   As discussed above, a client router will advertise its Adj-NHIB-Out
   to the route server.  The route server SHOULD update the reachability
   information of next hops in the client's NHIB table accordingly.
   Furthermore, the route server SHOULD use reachability information
   from the NHIB as input to its own decision process when computing the
   Adj-RIB-Out for this client. 

The lack of the SHOULD appears to be the point of contention.

-- Jeff