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

[Jeffrey Haas <[e-mail]>]

On Tue, Mar 14, 2017 at 09:45:28PM +0100, Robert Raszuk wrote:
> In fact to me this is basic 4271 as you should not use a path (even single
> path) if you can not validate if the next hop to it is reachable.
> 
> I think we all in BGP did not pay that much attention to reachability on
> multiaccess LANs ​as most peering happens on p2p links where the same
> problem does not happen.

For first party nexthops, BGP timers can address this to some extent.

BGP timers are too long, hence BFD.

For third party nexthops, you can have persistant bad forwarding.  Normal
BGP procedure doesn't help you here.

So, we agree that the case isn't given good attention in the core specs.

> > The one "common" use case where this may be of benefit outside of a
> > route-server environment is BGP "VPNs" that are constructed using IPSEC
> > tunnels with the network effectively an NBMA subnet.
> >
> 
> ​See all SD-WANs today need more then one path such that they make
> forwarding decision by probing all alternative overlay links and based on
> the applied logic switch over to better or lower cost or less delay path.
> If you give them just single path this is all no longer possible. That is
> what worries me in this the most if you would like to utlize this new NH
> NOTIFCATION SAFI for WAN VPNs.

The new SAFI is targeted specifically for the RS case and hasn't received
specific consideration for other use cases yet.  Feel free to kick off that
as a topic, although I'd suggest doing so separably from the rs-bfd thread.

-- Jeff