Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27

[Nick Hilliard <[e-mail]>]

Robert,

Robert Raszuk wrote on 04/06/2018 09:38:
> * It has been demonstrated with real RS data that vast majority of RS 
> carry single path for given prefix. This draft will not help in such cases.

the bfd brokerage aspect of draft-ietf-idr-rs-bfd will help enormously 
in this case.

> * If there is second path available for a given prefix the simple 
> solution is to observe that most IXes offer two Route Servers. Therefor 
> it is trivial to make such secondary RS to distribute second best path 
> ahead of any failure (knob for this does exist already in number of 
> shipping implementations) - so this would be one line config change on 
> RS and no upgrade(s) to the IX clients needed.

offering inconsistent views from a route server cluster is difficult. 
The best thing for an ixp to do is to provide a consistent and 
predictable service.

> * It has also been pointed out that distributing 2 or even 3 or more 
> paths with add-paths will not cause any customer CE meltdown. So simply 
> configure "add-paths 2" on those clients who need two paths from single 
> RS and be done.

In theory, yes.  In practice, there are very few ebgp add-path 
implementations.  Also in practice, if you want fail failover, you need bfd.

> * Let's not forget the bigger picture here. IX peering is an 
> optimization. To provide redundancy across IX with failing fabric 
> connectivity, different IX peering can be used or destinations can be 
> reached over native Internet path.

yes, but in order to use that alternative path, the client network needs 
to detect the failure at the IXP, which is what this draft is trying to 
achieve.

> * Last getting different path does not guarantee any level  success if 
> IX fabric failure location is close to the client.

this point is out of scope for this discussion, which deals with 
arbitrary failures of the ixp fabric.

Nick