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

[Robert Raszuk <[e-mail]>]

> This is no worse than an IGP event.

Well that in fact brings another alternative ... why not to simply run a
separate instance of ISIS over IX open LAN fabric interfaces ?

DIS could be on RS and even with basic hellos both RS and remote clients
will know about client being unreachable. If someone wants you can run BFD
to speed things up as well.

That addresses the reported problem without need for RS SAFI and for those
who do not want more then single path speeds up connectivity restoration
etc ... Even for those who have more then one path if ISIS timers are
enough they do not need to run BFD any more to all next hops.

Moreover *modern* IX operators will soon start adding value add services
(example: DDoS protection) for their customers for a little extra fee per
month. That in turn will be much simpler to be deployed with service chain
and IGP local flooding of for example SIDs.

Has that approach been considered here ? Again just like with data plane
gateway proposal this requires zero change on the client side and is just a
control plane config touch.

Best,
r.


On Wed, Mar 15, 2017 at 1:03 AM, Jeffrey Haas <[e-mail]> wrote:

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