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

[Robert Raszuk <[e-mail]>]

Ok so we have history covered :)

- - -

Apart of that the more I think about this the more reasons pop-up which
question both justification and value in informing RS about next hop
reachability from clients to clients of Internet Exchanges.

Let's summarize those again:

- RS may not have other paths

- RS may send more then best path to clients

- RS come in pairs and it is trivial to send different paths from each of
the RS with zero upgrade to clients

- RS clients are grouped per their policies .. per client RIB requires a
lot of overhead on route servers to address the case where only one client
in the group suffers from some unreachable next hop

- BFD sessions to next hops will require per next hop MD5 for security

- IX have often more then one lan ... say 1500 and 9000 MTU. Next hops
again may be different on both.

- BFD session timers can't be unified on the clients as some clients are
local and some remote. Remote both in the case of distributed IX as well as
in the case of IX customers just connecting to IX with fiber without any
*local* metal.

- Clients will likely report churn of the same next hop being unreachable
reasonable in the same time

- When client reports unreachable next hop to RS .. it removes the path
from client's RIB. But when does it add it again ? Note eBGP to RS are all
fine .. would clients now not only keep BFD sessions to active peers but
also trying to establish BFD to unreachable peers then notify RS that the
peer is back ?

- BFD on clients needs to work in non protocol associated mode.

... and I am pretty sure this is just the starter.

r.





On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas <[e-mail]> wrote:

> On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote:
> > And just for the record here the idea for NH SAFI has been proposed by
> Ilya
> > & myself in 2012 ...
> >
> > https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00
>
> rs-bfd started with that as a likely way to handle carrying the RS state.
> However, we reached two conclusions:
> - the draft was inactive.
> - and even if we used it, it was an awkward fit for the mechanism.
>
> https://www.ietf.org/proceedings/93/slides/slides-93-idr-3.pdf
>
> Similarly, BGP-LS was given a try and decided to be too heavy weight.
>
> So, we're closer to where we started. :-)
>
> -- Jeff
>