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

[Robert Raszuk <[e-mail]>]

​Hi Job,​


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

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.

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



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

​Thx,
r.