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

"Jerome Durand (jerduran)" <> Tue, 17 March 2015 22:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3D0C1A8930 for <>; Tue, 17 Mar 2015 15:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GvjVd-qOKj9M for <>; Tue, 17 Mar 2015 15:11:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 557991A892C for <>; Tue, 17 Mar 2015 15:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1756; q=dns/txt; s=iport; t=1426630291; x=1427839891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FFicgrOYgmgdDLUUgJRY/nVlK/EmO8X318rmhrna4Ik=; b=RQqSHOd8MmLf7GquI3HIp6TQDHmI8bKgsb+GFyD64e50ixeoDF8LJV8r YtwXV6sUwuKVS/Epd8t6+0tFU1mbekZuL+sWweodxNaHgPT24z82pUG32 b2N2Ci3I57S5NFc14Bl3+hVUOVLZpDxJ1ZnGpwMkYOhogCY85flypT8/m w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,418,1422921600"; d="scan'208";a="401348673"
Received: from ([]) by with ESMTP; 17 Mar 2015 22:11:30 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t2HMBU2P005491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 22:11:30 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 17:11:30 -0500
From: "Jerome Durand (jerduran)" <>
To: Jeffrey Haas <>
Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)
Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050fq6KAgAHoCoA=
Date: Tue, 17 Mar 2015 22:11:30 +0000
Message-ID: <>
References: <> <20150316170441.GB23077@pfrc>
In-Reply-To: <20150316170441.GB23077@pfrc>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, David Freedman <>
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: Tue, 17 Mar 2015 22:11:32 -0000

Hi Jeffrey,

Thank you for taking the time to read the document and providing comments.

> Things that need a bit of clarification:
> - What procedures do you do if the remote side doesn't support BFD? 

Idea is that it is up to admin to decide what we wants to do with routes for any next-hop depending on its corresponding BFD session state. As an example one could decide to keep accepting routes if BFD never reaches an up state, but with a lower local-pref if desired. This point could be let to implementation. This is a good point we can try to document this in next versions.

> - What about if you see the remote nexthop but the remote nexthop doesn't
>  see you?

Remote next-hop would signal BFD session state in next control messages and everyone would agree that session state is now down. At this point policy can be applied on corresponding routes. We could detail how solution solves various types of problems that can be met on IXPs if this can help global understanding.

> Things I don't like:
> - You're trying to use BFD diag codes without state changes as state for the
>  session.  Wearing my BFD chair hat, I have some reservations about this.

Well we do this for session ageing which we believe is crucial for scalability and manageability. We are trying to signal that BFD session is needed or not needed locally. This is different from BFD session state and that’s why we kept that at another level. In other words we say: « Session is UP but personnaly I don’t need a session with you anymore. Do you need to keep the session with me? » Idea of using diag codes is to do this signalling without changing BFD protocol definition.