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

[Jeffrey Haas <[e-mail]>]

On Tue, Mar 14, 2017 at 10:48:32PM +0100, Job Snijders wrote:
> On Tue, Mar 14, 2017 at 05:36:07PM -0400, Jeffrey Haas wrote:
> > On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote:
> > > Is the assumption here that the client routers have routing view
> > > limited to what’s provided by the Route Server? If not, then
> > > wouldn’t Client Routers benefit from having to invalidate the path
> > > learned from the remote client router as soon as the connectivity
> > > check failed?
> > 
> > This is what I believe the procedure says.  See section 6.
> > 
> > > Of course, Client Routers conveying the lack of NLRI reachability
> > > per NH to the Route Server, and expecting Route Server to provide a
> > > different NHs of the NLRIs, and expecting it to be functional, while
> > > still attracting the traffic for unreachable destinations since the
> > > Loc-RIB is still pointing to the unreachable NH for the affected
> > > NLRIs.
> > 
> > The thing that is somewhat different for a IXP environment running a
> > route server than normal eBGP is the low (to zero) likelihood of
> > having a backup path. If 10/8 was learned from the route server for
> > nexthop 192.0.2.1, and you stop being able to reach that nexthop,
> > removing it from your forwarding (unreachable) is your only choice.
> > 
> > You *might* have a source of that path internally.  In that case, you
> > can use it.
> 
> I might be misunderstanding you, but a route server is considered (at
> best) a supplementary partial view on the default-free zone. If the
> route server doesn't have the route, you will have learned an
> alternative route through either bilateral sessions on the IXP or
> through other sources such as transit sessions, or through ebgp paths
> distributed over ibgp.

The RS client having a source of a path via its iBGP from its internal
network is exactly what I had in mind.

RS clients having bilateral sessions with other IXP clients was somewhat
less than common when I last operated a route server, so forgive my myopia
on that point. :-)

>  Any path that does not exist in the 'DFZ', but
> _does_ exist on the route server, is either an artifact of hyper local
> traffic engineering through deaggregation, or is a bgp hijack for the
> purpose of spamming a specific subset of route server participants.

I would also caution against Internet-operations focused myopia as well
here.  RSes are deployed in environments that aren't IXPs.

For the IXP case, I tend to agree with you.  (And have been half following
the GROW threads about having the RS participate in route validation.)

> > But more importantly, you'll stop sending it toward your own peering
> > and attracting blackholed traffic.
> 
> i'm not sure i follow this scenario 

Receiving a path from the RS that is blackholing and propagating it
internally via iBGP.

-- Jeff