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

[Jared Mauch <[e-mail]>]

On Tue, Jul 04, 2017 at 11:02:55AM +0200, Robert Raszuk wrote:
> John,
> 
> Today vast majority of OPEN policy clients share single RS view/table so
> you do best path and update generation once for all of them.
> 
> The moment you introduce per client state you are braking those apart into
> individual views.
> 
> Even those with policy today have subset of nets in their own tables not
> all. So this optimization also goes away.
> 
> So if you send clients real paths they locally can repair failures without
> any additional state per client on RS. That is why I called it "a waist".

	I suspect you mean the homophone waste.

> And this is not 100 it is 100 x number of clients say 1000 of dynamic state
> which triggers 1000 best paths and update generations on propagated
> failures of best path.

	Something I've observed in the past ~20 years is the relative compute
power has gone up significantly for a BGP speaker, as many platforms may even
do hardware offload of BFD, this part isn't what worries me.

	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.

	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.

	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).

	Section 5 text comment:

   "Again, since the
   contents of ReachAsk are simply a set of host routes to be tested,
   route selection over a combined ReachAsk MAY be omitted."

	Suggest dropping Again.

	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.
	
	- jared

-- 
Jared Mauch  | pgp key available via finger from [e-mail]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.