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

[Jeffrey Haas <[e-mail]>]

> On Jul 3, 2017, at 5:55 PM, Job Snijders <[e-mail]> wrote:
> 
> 
> I'm not sure whether events will be packed together this neatly. 
> 
> Questions that remain: 
> 
> - is it absolutely necessary for the RS to be aware of the entire bfd session topology state?

The draft is written with the idea that some/many devices *won't* be aware.  If the state is Unknown, things still work.

> 
> - is it reasonable to assume there will be BGP speakers that support draft-ietf-idr-rs-bfd, but not RFC 7911?
> 
> - if the RS is not stateless (in this regard), can we reasonable expect things to scale? (As it currently stands the industry has trouble scaling RS services)
> 
> If it was not clear from previous messages: I am supportive of the idea of "assisted BFD" to take away some obvious downsides of route servers. Just not sure the proposed approach will work out good enough. 

The way I suggest reading this:
1. BFD to the BGP nexthops is really desirable.  It lets you avoid blackholing in several well known scenarios, including the RS based distribution of routes.
2. Regular BFD needs both sides of the session to be prepared.  In the absence of full mesh BFD configuration, there needs to be a feature that permits the RS to notify the clients what nexthops are of interest on both sides.
3. The feedback mechanism permits a RS to send alternate paths - when it is capable of doing so - when a given nexthop is unreachable by a given client.

The third mechanism is very optional.  Many RSes need not implement any sort of new path selection if they don't want to; points 1 and 2 are still helpful. 

To the points about add-paths, and statefulness, even if the RS clients spoke add-paths, you have to choose what level of path scaling you want to do.  If you're to the point of sending everything, a RS isn't even necessary.  And clearly, people use RSes partially for "remote policy" - effectively path pruning.

Looked at a somewhat different way, choosing the backup paths is no different than add-paths or diverse paths feature choosing the next best path.  But since the RS and the client could have already conveyed the possible set of nexthops for the view, there's no need for stepwise discovery.  Perhaps this point needs to be made clearer in the draft.

-- Jeff