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

[Job Snijders <[e-mail]>]

On Tue, Mar 14, 2017 at 11:02:02PM +0100, Robert Raszuk wrote:
> > 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.
> 
> Interesting ... why would you think so ?

It is my observation that some networks will announce for instance a /16
to their upstream providers, but a /17 to their 'settlement free peers'
(which could be found at an IXP).

While there is no one single version of view of the Default-Free Zone,
we do have a an understanding of what global reachability means vs local
visibility. Through services such as http://stat.ripe.net/ you can see
instances where the /16 enjoys good visiblity on the RIS/routeviews
collectors but that more specifics also exist, which are not seem on all
collectors.

While the practise of announcing more specifics to certain classes of
BGP neighbors does not have my preference, I can follow the rationale.

The hijack case is discussed here https://ripe72.ripe.net/archives/video/203/ -
https://ripe72.ripe.net/presentations/165-invisiable-hijacking-follow-up.pdf 

To summarize: if a route server has a unique route (either by virtue of
being a more-specific of something learned over ibgp, or by being a
hijack), that route in and of itself might not be of any value.

I'd argue that for the public internet use case, it is fine to design a
solution which assumes that route servers never contain 'unique'
information, and that any participanting autonomous system will have
alternative paths either to the same prefix or a less specific.

> Imagine I connect to an IX and also have direct Transit with NTT. To
> the same IX also customers of NTT connect such that I can use IX
> switch to get to them without going via longer path of transit
> provider.

This is a valid and common scenario.

> To me their direct routes are better (BGP path selection wise) and I
> go via IX to reach them (or they go via IX to reach my content).

Correct.

> > 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.
> 
> Well that is indeed very important to verify. I am also inclined to
> the same. But have no data to validate how many paths for all nets
> RSes carry in major IXes.
>
> Moreover IXes normally use two RS today so it is trivial to make sure one
> RS sends first best the other second best to the clients (if they have
> more then one). Signalling client to RS that NH is down seems at best
> redundant.

I believe it is a common practise amongst IXP Route Server operators to
let the two (or more) route servers operate entirely _independent_ from
each other, e.g. with no BGP sessions amongest the RS's themselves.

Kind regards,

Job