Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)

[David Freedman <[e-mail]>]

>Many networks will not use Route Servers due to this problem which did
>hit quite a few operators over the years on large internet exchanges.
>This is a reason why some large operators refuse to peer with smaller
>ones via RS.

Yes, I can speak as such an operator, our default policy is not to use RS after
suffering repeated L2 partitioning on a particular exchange many years ago.

>This draft means that a network should be able to prevent loss on
>outgoing traffic. However should the peer not have the feature enabled,
>return traffic could still suffer: BFD notice the session is down, the

The idea in this draft requires both sides to support it, the BFD sessions
are set up from both sides, toward the other side (i.e really bi-directional) 
we don't care about the RS other than for a BGP session to bind the next
hop discovery to. 

>This case does not remove any of the merit of this draft, operators are
>still better with it than without, but seems to indicate that other
>mechanisms could be considered to complement it.
>Naively, I would thing that something which would for example allow the
>tagging of routes with no-export to the RS(or a removal) should a number
>of peers on a same L2 suddenly became unreachable due to BFD be
>acceptable in a RS scenario.

I know of an operator which has set up a number of static BFD sessions
across an exchange, and has a script, which, if a number of these
are seen to go down, shuts down the RS session.

Dave.