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

[Robert Raszuk <[e-mail]>]

Hi Gert,

There's large ISPs connecting with up to 4 routers to the IXP (so, same
> peer AS has multiple possible nexthops).
>
> There's also smaller ASes buying upstream from two or more ISPs that are
> all connected to the same IXP (so, same origin AS has paths through
> different neighbouring ASes at the same IXP).
>

Well ​for one I just went through talking to multiple large ISPs to get
transit via IXes and the answer is NO. They all (except one) said only
direct peering with fiber. And the one who accepts to come via IX clearly
requires direct eBGP session.

So even if ISP is connecting to IX he is not offering free transit so his
routes will not be downloadable from RS. That is the main point here.



> Optimizing the "route server shall distribute multiple paths" is only
> half of the solution.  More interesting for me is "where do I need to
> point my vendors to, to get them to implement proper black-hole
> detection in the forwarding path, so the BGP NH can be invalidated?"
> (I'm not aware of any gear that will do this right now, as in "if
> IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths
> in BGP" - but I'm always willing to learn)
>

​Cisco IOS classic/XE + NX object tracking is a cool feature quite unknown
as no marketing force was promoting it. You can run it even on Sup720 and
set frequency of probing accordingly :) ​I use it every day.

Juniper have had similar tool, but less flexible.

Asking vendors (or extend BFD spec) to support BFD livness detection to set
of destinations (say your current active next hops) without protocol may be
a wise move too.

But if we know that in real deployments only 0%, 33% or 50% nets have path
redundancy on RS sending information there in the new SAFI .. such that
single path nets lost reachability to next hops on all or some clients will
do no good.

​Thx,
r.​