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

Jeffrey Haas <> Mon, 16 March 2015 17:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E76231A88E0 for <>; Mon, 16 Mar 2015 10:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tdKE75v9DKmu for <>; Mon, 16 Mar 2015 10:04:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46FBA1A88E6 for <>; Mon, 16 Mar 2015 10:04:42 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 0D213C0B9; Mon, 16 Mar 2015 13:04:42 -0400 (EDT)
Date: Mon, 16 Mar 2015 13:04:41 -0400
From: Jeffrey Haas <>
To: "Jerome Durand (jerduran)" <>
Message-ID: <20150316170441.GB23077@pfrc>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Mon, 16 Mar 2015 17:04:44 -0000

[Responding from the top of the thread intentionally.]

On Sun, Mar 15, 2015 at 08:56:52PM +0000, Jerome Durand (jerduran) wrote:
> 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:

Things I like about your draft:
- Autodiscovery of the endpoint for BFD just by gleaning the nexthops.

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

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.

The point raised in the thread about draft-ymbk is something I think is
worth addressing: Give the RS a chance to unhide paths if you can't use

All of this said, I think the core behavior of getting nexthop validation
via BFD is the key property that gets the best improvement.  I think this
gives us a basis to refine both proposals.

-- Jeff