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

[Job Snijders <[e-mail]>]

On Tue, Mar 14, 2017 at 06:05:05PM -0400, Jeffrey Haas wrote:
> 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. :-)

Glad we uncovered this discrepancy, it is safe to assume that in many
cases (i say 'many' because we have no well established metric system
for this), both bilateral and multilateral sesions exist. Any
specification will need to be engineered with this in mind.

If someone is looking to receive as many BGP routes and paths as
possible, you'll set up sesions with whoever wants to, this includes
both direct and route servers. With the rise of network automation based
on public peering directories such as peeringdb.com, this process
becomes even more streamlined. The process effort of denying bilateral
peering requests because you can see the remote network through the
route server, or tuning the route server to not be used when there is a
bilateral session, would outweight just setting up bgp indiscriminately. 

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

This is new information for me.

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

gotcha, yes.