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

Hi Randy & authors of this document,

Major comment:

Let's observe that the ultimate objective of this draft (and in fact much
more) can be achieved by assuring that clients receive more then one path
to given bgp destinations at normal operation.

That direction has been proven to work much more effectively in all other
scenarios which require fast connectivity restoration as opposed to
counting on control plane "convergence".

The following alternative techniques can be used to distribute more then
just best path between BGP clients:

*A* Use of add-paths RFC7911 from RS to clients (with eBGP support
extension)

*B* Use of diverse-path RFC6774 from RS to clients

*C* Direct EBGP peering between clients with the help of BGP Auto Discovery
https://goo.gl/KKgqfU  (now with merged work of Automagic peering at IXPs:
https://goo.gl/RJIKYM)

Let's also notice that in IX folks peering via RS have open or selective
peering policy and they send at most their clients + internal routes.
Therefor for any given b_net there will be no more then few paths. There is
no Transit Internet open peering via RS or very often even via IX.

This will allow all clients to quickly switch over to backup path which
would be with PIC already present in their data plane ahead of failure.

Moreover this will reduce churn and convergence delay when say 1000 clients
in one shot is bombarding RS using new proposed SAFI of the very same
client router going down.

Also let's keep in mind that modern routing stacks allow to much more
intelligent routing by actively and passively monitoring all alternative
paths to your interesting destinations and based on the quality of the data
plane via any peer choose the best path. That with just getting a single
path at a time is simply not possible as those "interesting destinations"
are not BGP next hops, but applications servers sitting one or more ASes
far from client.

Minor comment:

Today BFD sessions last time I checked must be bounded to a protocol. In
current IX+RS model there is no direct protocol between clients. Hence BFD
implementations on the clients needs to be augmented to auto peer with all
BGP next hops received over eBGP sessions to RS. Not impossible and in fact
perhaps good feature on its own .. but needs to be supported on all clients
just like the new SAFI draft proposes.

Kind regards,
Robert

On Mon, Mar 13, 2017 at 6:01 AM, Randy Bush <randy@psg.com> wrote:

> note that this version is rather different and warrants reading.
>
> randy
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>