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

[Robert Raszuk <[e-mail]>]

​Hi Jeff,​

> I said RS does not need to bothered with that information.
>
> The relevant bit of procedure within this document to run BFD toward an
> eBGP
> nexthop and use it in the local decision process is of potential value even
> without the RS SAFI part of the protocol.  So, in this respect, I agree.
>

​Completely agree !

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.



> The authors had previously discussed extracting this procedure from the
> document and are fine with doing so if it makes sense.
>

Makes sense. It should be done by default one way or another. /* Not sure
if BFD considering those "weak customer peering routers" is the best idea.
*/


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.

​Thx,
R.​