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

[Jeffrey Haas <[e-mail]>]

> On Jul 4, 2017, at 2:21 PM, Jared Mauch <[e-mail]> wrote:
> 
> 	Tracking the N to N-1 BFD state worries me more, I've seen significant
> operational issues on multiple vendors with BFD.  These of course are bugs and
> should be fixed.

Most of the issues I've seen here tend to be in a modest number of categories:
- Session scaling with regard to high speed timers.  This proposal suggests very sedate timers, really in the same lines as the ones of BFD in its Down/Init state.
- Session scaling for number of sessions.  This might be an issue for lower end hardware implementations with fixed session tables.  For such issues, it's reasonable for an implementation of this proposal to provide filtering (policy) to select which sessions it desires to form BFD adjacencies with.
- Async vs. Echo mode.  Not every implementation supports Echo.
- Inappropriate BGP behaviors with regard to AdminDown transitions.  I'll even own to the fact we've had this class of bug in our implementation.

> 
> 	While I'm not a big fan of route servers personally, many people do use
> them in high cost areas to reduce their operational load.  I'm also concerned
> about 3rd parties tasking me with unexpected work without constraints.

As noted above, policy/configuration to limit work is quite reasonable.  "If it hurts, don't do that."

> 
> 	Section 4 comment:
> 
> 	Any thoughts on rate-limiting for the messages?  Some IX fabrics are
> large and I cound envison a lot of results.  I'd suggest limiting ReachAsk to
> once every 1,3 or possibly even 6 seconds.  Was any thought given to the min/max
> rate of ReachAsk?  (I could also see non-rs peers wanting me to send them ReachTell
> in the event of someone selling transit over an IX as well).

I had considered this a consequence of the hysteresis comment later in the document.  Perhaps this could be spelled out in further detail if necessary.

> 
> 	Section 6 comment:
> 
> 	Prohibition of fe80:: next-hops may make sense here.  One may
> not know what outbound interface is in-use.  I'm always wary when I see fe80
> addresses being used.

I'm supportive of this.  Link scoping is tricky at the best of times.

-- Jeff