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

[Jeffrey Haas <[e-mail]>]

On Wed, Mar 15, 2017 at 12:08:50AM +0100, Robert Raszuk wrote:
> 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

But then you're not using a secondary RS for redundancy of your best path.
(That may be fine.)

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

RS operators will have to speak to what sort of policies they want, but this
*does* impact what a RS chooses to do with a declaration of unreachability
from one peer in a peer group:
- Does it try to split the group for that peer? (Unrealistic, IMO.)
- Does it de-pref routes with that nexthop for *all* peers on the
  presumption that something bad has happened that the other peers haven't
  noticed yet?

Etc.

Good topic for further discussion.

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

The use of BFD security mechanisms in general is an interesting question.
Thankfully the suggested BFD timers here are very slow which helps the
session scaling.

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

A significant enough fabric event will simply lose the peering sessions to
the RS in the first place.  But losing entire "sides" of clients happens.  

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

This is no worse than an IGP event.

> - BFD on clients needs to work in non protocol associated mode.
> 
> ... and I am pretty sure this is just the starter.

And good fodder for discussion from IX operators.

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