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

If client talks add-paths you send them two paths. You may send them more
if they wish so.

It is just broken desing to signal failure between nodes to get new paths.
PIC has proven this long time back.

What this is about is really a new idea of sdn controller with bgp and
distributed bfd for weak clients.

Now maybe we could understand what are those weak clients who can not
handle two paths for a given net ?

Thx
R.

On Jul 4, 2017 00:20, "Jeffrey Haas" <jhaas@pfrc.org> 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.
>
> >
> > - 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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>