IETF Logo Mail Archive

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

"Jerome Durand (jerduran)" <jerduran@cisco.com> Sun, 15 March 2015 20:56 UTC

Return-Path: <jerduran@cisco.com>
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 D352A1A1B80 for <idr@ietfa.amsl.com>; Sun, 15 Mar 2015 13:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 6F6IacM_b3X9 for <idr@ietfa.amsl.com>; Sun, 15 Mar 2015 13:56:54 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B301A1B74 for <idr@ietf.org>; Sun, 15 Mar 2015 13:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1263; q=dns/txt; s=iport; t=1426453014; x=1427662614; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SAnNdjzWqz6EMuR7zt6XklS3aNP9hjPaBeLMAkTfAoU=; b=BOWWhbnykc5ulDCbq6pSb94C2OWSirIdg8ToJZYRCDUWB17tHzZrNoFQ 1R64GROQVvxoOnEWkKT6MDNz58jO7jYucFJY1f4XaKf6u8uuyA8hg+DiZ oaM8S69Tjj37HAyI2YCpUyr/rwVSWvlfr/B10ddXSjXCBAZ+Fn8nFqGEG 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BRBQCqaeJU/5NdJa1bgwZSWgTCPIVxgRpDAQEBAQEBfIQTHVcFEgGBACcEDiCIEg3OKAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3mDHYEUBY84g1eFYJMNIoNubwGBQ38BAQE
X-IronPort-AV: E=Sophos;i="5.11,405,1422921600"; d="scan'208";a="403599161"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 15 Mar 2015 20:56:53 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2FKurb1018853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Mar 2015 20:56:53 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 15 Mar 2015 15:56:53 -0500
From: "Jerome Durand (jerduran)" <jerduran@cisco.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)
Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf0w==
Date: Sun, 15 Mar 2015 20:56:52 +0000
Message-ID: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.86.135]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2697643AA39EEC4285C81B89DEDEBE8D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/jxaBQfetFfqkNropP3bAg5oaxzY>
Cc: David Freedman <david.freedman@uk.clara.net>
Subject: [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: Sun, 15 Mar 2015 20:56:56 -0000

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

v2.23.0 | Report a Bug | By Email