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

Jeff,

Running add paths for common policy paths vs per client best path are
orders of magnitude more work.

I can not believe why you would think otherwise ...

Thx
RR

On Jul 4, 2017 19:44, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

> On Tue, Jul 04, 2017 at 12:48:40PM +0200, Job Snijders wrote:
> > On Mon, Jul 03, 2017 at 06:20:28PM -0400, Jeffrey Haas wrote:
> > > > On Jul 3, 2017, at 5:55 PM, Job Snijders <job@ntt.net> 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 ;-)
>
> It's BGP.  You have to deal with what incremental deployment looks like.
>
> [...]
> > > 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).
>
> I believe you are confused about the CPU work associated with providing
> add-paths actually is.
>
> Add-paths implementations already run N-best calculations.  They must
> already include the work of running policy and BGP loop checks.  Adding an
> additional exclusion list based on nexthop viability for the view isn't
> significantly more work for a given round of route selection.
>
> If you'd like to argue "send them 2, and if they both don't work, let god
> and their backup paths sort it out", fine.  You're welcome to run your RS
> that way - if you run a RS.  What I don't understand is why you object to
> someone else doing something different.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>