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

Thomas Mangin <thomas.mangin@exa-networks.co.uk> Mon, 16 March 2015 08:56 UTC

Return-Path: <thomas.mangin@exa-networks.co.uk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315F11A8547; Mon, 16 Mar 2015 01:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuNIC64IePVs; Mon, 16 Mar 2015 01:56:21 -0700 (PDT)
Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50751A8032; Mon, 16 Mar 2015 01:56:20 -0700 (PDT)
Received: from smtp-5.exa.net.uk (unknown [82.219.5.5]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id EE9471C005C; Mon, 16 Mar 2015 08:56:18 +0000 (GMT)
Received: from smtp-5.exa.net.uk (localhost [127.0.0.1]) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTP id DE3A7411F7; Mon, 16 Mar 2015 08:56:18 +0000 (GMT)
Received: from mangin.local (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTPSA; Mon, 16 Mar 2015 08:56:18 +0000 (GMT)
Message-ID: <55069AAF.2050801@exa-networks.co.uk>
Date: Mon, 16 Mar 2015 08:56:15 +0000
From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: idr-bounces@ietf.org
References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com>
In-Reply-To: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/GYtyEvzsESh6D4T_3xxZGZlIZF8>
Cc: "idr@ietf.org" <idr@ietf.org>, David Freedman <david.freedman@uk.clara.net>
Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2015 08:56:23 -0000

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