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

[Job Snijders <[e-mail]>]

On Mon, Jul 03, 2017 at 06:20:28PM -0400, Jeffrey Haas wrote:
> > 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.

Like with today's RS? "This draft doesn't make it worse" is hardly an
impressive statement ;-)

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

yes.

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

yes

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

agreed.

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

But any churn in the possible set of nexthops, directly results in BGP
churn, where as when the route server is not kept in the loop about who
can reach who, there will not be any churn at the route server level
when 2 RS participants cannot reach each other (temporarily).

Kind regards,

Job