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

[Gert Doering <[e-mail]>]

Hi,

On Thu, Mar 16, 2017 at 10:29:29AM +0100, Robert Raszuk wrote:
> 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.

Terminology seems to be funky here.

"transit" is, for me, "I can use you to access the full Internet", not
"I can use your network to reach your customers" - which would be "peering".

So, except for 6939, I wouldn't expect anyone ever to give me "free transit",
no matter whether on an exchange or otherwise.


Now, at an IXP, there are participants (of course) that consider me too
small to peer with them - that's a political and marketing decision, but
not truly relevant for this discussion.  At DECIX, there are something
like 300+ ASes connected, some with multiple routers, and many of them
are quite happy to peer with the RS, offering connectivity to their
customer ASes.

Whether or not a few of them are not using the RS, or not sending routes
to the RS, can hardly be considered "the main point here", if we're
discussing enhancing RS functionality.


> > 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.

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"?

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.

> 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.

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.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: [phone]           USt-IdNr.: DE813185279