Re: [Idr] draft-ietf-idr-rs-bfd-05

Robert,

I can't help feeling that you're throwing things at this draft to see 
what sticks.

Nick

Robert Raszuk wrote on 05/06/2018 22:24:
> Hi Nick,
> 
>> In theory, yes.  In practice, there are very few ebgp add-path implementations.  
> 
> Are you saying that enabling add-paths for eBGP especially for 
> route-server-client neighbors is going to be any harder then coming with 
> new SAFI  ? This draft requires OS upgrade and most if not all router 
> vendors support iBGP add-paths today. If the draft would spell such 
> alternative solution it would be brilliant.
> 
>> Also in practice, if you want fail failover, you need bfd.
> 
> And what is stopping you to use it since you have next hops anyway ? 
> Ref: https://tools.ietf.org/html/draft-chen-bfd-unsolicited-02
> 
> Thx,
> R.
> 
> 
> 
> On Tue, Jun 5, 2018 at 11:06 PM, Nick Hilliard <nick@foobar.org 
> <mailto:nick@foobar.org>> wrote:
> 
>     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
> 
> 
>     _______________________________________________
>     Idr mailing list
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr>
> 
> 

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