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

Hello Jerome,
Hello David,

Thank you for this work.

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.

The first time I heard about the idea, I thought that this mechanism was
an elegant solution to prevent traffic black-holing.

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
routes are removed from the FIB, traffic goes via another path, but
still tries to come back via the dead L2 as the peer does not implement
the feature. Was it what you had in mind when speaking of asymmetric
routing, or was it something else ?

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.

Sincerely,

Thomas
> Dear all,
>
> I think draft-ymbk-idr-rs-bfd-00.txt addresses real issues that need to be solved somehow and I’m happy to see work conducted on the topic.
>
> However the approach chosen implies that IXP members rely on a mechanism to be implemented on the route-server, while we believe a direct approach could be simpler and quicker to implement, and much more reliable. David Freedman and I have worked on finding a solution for quite some time now and we are proposing an approach based on BFD, which can be found here:
>
> https://tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt
>
> The Idea is simple and it only requires a basic BFD capability between IXP members. Based on the BFD session state of the learnt BGP next-hop, routes can be accepted and BFD backed by a member, the decision remains local.
>
> While we elaborated this document we discovered that there are real challenges in the BFD implementation, for example when there is asymmetric routing. This is documented in our draft. I believe on the other hand that there is a lack of this information in draft-ymbk-idr-rs-bfd-00 at this stage. we would like to see more information on that in future versions.
>
> Thank you,
>
> Jerome Durand
> and 
> David Freedman
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

-- 

Thomas Mangin
Director - Exa Networks
http://exa.net.uk/about/contact-us