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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>