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

[Robert Raszuk <[e-mail]>]

>
> Oh, I can, and I can tie other stuff into it (like, static routes).  But
> does *BGP* know, and invalidate its nexthops, if object tracking tells
> it "does not ping anymore"?  Can I tell BGP "please run this automatically
> for all nexthops seen on this interface"?
>

​You can today say run it for all the peers which match a route map. It is
just a little extension to BGP Next Hop Tracking feature (which already
have table of all next hops) to actually also automate tracking next hops.

In fact one customer in the past requested that already .. but I don't know
if this was implemented in IOS already. I am sure folks from C vendor will
tell us :)​


> Manually configuring this for each peer address I *might* receive over the
> RS is operationally insane - 600+ devices on DECIX, with next-hop addresses
> I might not even know about until I receive a route for it, from the RS.
>

​No manual stuff.

All you need is a single knob which will force only /32 next hop for
resolution (already available) + do the tracking for all next hops received
over given eBGP peer. ​

This is why I'm asking for "do we have a document to point vendors so,
> so this magic would be available for me to use"?
>
> Until then, the proposed draft is a good start.
>

​The feature request is one liner stated above. I am not sure if IETF
document is needed for that​. IMHO it is more of topic for Nanog/RIPE.

This is rather very much implementation specific.

Cisco will tell we will extend object + next hop tracking, Juniper will do
nice trick with rib-groups, linux based vendors will recommend to base nh
liveness detection based on arp tracking which is already in all linux
kernels.

The fundamental question is should it be unidirectional (no session
established of any sort between any to any) or we would like to keep the
state associated with tracked object (BFD, symmetric or asymmetric
echo/seamless etc ...).

​r.​