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

[Job Snijders <[e-mail]>]

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. 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'm somewhat inclined to accept that the route server itself may not
have alternative paths for anything it received from one of its
participants. however the likelihood of having an alternative path might
increase as the route server's constituency increases (a growth
trajectory which in turn might go hand in hand with increased chances of
intra-fabric partial unreachability between participants of the fabric).

either way, since we accepted that path hiding is an issue, we've
implicitly accepted that backup paths may exist.

> But more importantly, you'll stop sending it toward your own peering
> and attracting blackholed traffic.

i'm not sure i follow this scenario