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

David Freedman <> Mon, 16 March 2015 09:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C768A1A86EC for <>; Mon, 16 Mar 2015 02:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cjV5cyjiL2bo for <>; Mon, 16 Mar 2015 02:20:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CC721A86EB for <>; Mon, 16 Mar 2015 02:20:29 -0700 (PDT)
Received: from [] by id 9E/A1-09550-C50A6055; Mon, 16 Mar 2015 09:20:28 +0000
X-Originating-IP: []
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23021 invoked from network); 16 Mar 2015 09:20:28 -0000
Received: from (HELO ( by with SMTP; 16 Mar 2015 09:20:28 -0000
Received: from [] (port=38599 helo=SRVGREXCAS05.claranet.local) by ( []:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1YXRCF-00063m-C3 (return-path <>); Mon, 16 Mar 2015 09:20:27 +0000
Received: from SRVGREXMB06.claranet.local ([fe80::70d4:3322:86e0:c10c]) by SRVGREXCAS05.claranet.local ([fe80::3915:cdff:95ac:dcdb%11]) with mapi id 14.03.0224.002; Mon, 16 Mar 2015 09:20:16 +0000
From: David Freedman <>
To: Thomas Mangin <>
Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)
Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050ez1mAgAAC6kI=
Date: Mon, 16 Mar 2015 09:20:15 +0000
Message-ID: <E2B120470A420C49A1CB4F6D01C013F8C0BF8EDA@SRVGREXMB06.claranet.local>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Clara-Helo: SRVGREXCAS05.claranet.local
X-BorderScout: cm=0.00 ca=0.00 time=4270 size=2934
X-BorderScout-CM-Score: 0
X-BorderScout-CA-Score: 0
X-ClamAV: clean
X-Cloudmark: 0.00
Archived-At: <>
Cc: "" <>
Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Mar 2015 09:20:38 -0000

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