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

[Robert Raszuk <[e-mail]>]

Jeff,

This has nothing to do with the major point of contention, but nice try ;).

Bringing in some cosmetics is in no way helpfull to address fundamental
flows of the proposal.

But I must ask ... this appears in spite of major comments against to be a
wg doc. Well so be it. But  do we have multiple implementations of both RS
and clients supporting this proposal ?

Cheers
R.

On Jul 4, 2017 21:19, "Jeffrey Haas" <[e-mail]> wrote:

>
> > 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
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>