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

[Job Snijders <[e-mail]>]

On Tue, Jul 04, 2017 at 10:38:53AM +0200, Gert Doering wrote:
> On Tue, Jul 04, 2017 at 12:31:17AM +0200, Robert Raszuk wrote:
> > 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 ?
> 
> What makes you assume that these two paths will *work*?
> 
> IXPs are big (like, 600 nodes), and there might be a partial outage
> that kills off everything behind one 100G link in a 4x 100G bundle ->
> 100+ remotes are gone.
> 
> Two paths won't do much good then, if both next-hops are in that set.

Yes, two paths won't help when faced with catastrophic events (where
large clusters of participants of the IXP go offline). But should it?

In that case the IXP participant will have to use other means (IP
transit, private peering) until the IXP has been repaired (usually done
within a few hours?)

We already observed that path _diversity_ isn't that great at IXPs in
the sense that often there is only a single path towards a prefix:
https://mailarchive.ietf.org/arch/msg/idr/qhgG2cCs0UuDHdPRdfDIMs7jeHs

I posit that it is safe to assume that other (non-RS) paths will always
exist (via transit, other peering), and as such in the trade-off between
keeping more state at the RS vs trying to keep the RS lean and mean, the
design parameters should be as following:

    - the main purpose of this draft is to ensure that each RS
      participant sets up BFD sessions to the other participants of
      interest, the main purpose is _not_ to ensure there are always
      paths even if half the IX is on fire. The priority should be quick
      fault detection, not to "make the best use of the IX under any and
      all circumstances".

    - we should work from the assumption that if a client supports
      draft-ietf-idr-rs-bfd, it will also have support for ADD-PATH. If
      we cannot assume this, I'd like to understand why.

    - explicitly consider scalability issues. The bigger internet
      exchanges are struggling with their current route server load, so
      if IDR adds any computational cost to their list of tasks, it'll
      need to properly justify that.

    - The technology facilitate setting up the minimum required set of
      BFD sessions, not the maximum.

Kind regards,

Job