Single-hop BFD for RIP routing protocol

Carlos Garcia Braschi <> Wed, 08 June 2005 16:43 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1Dg3e3-0003OB-A9; Wed, 08 Jun 2005 12:43:11 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1Dg3e2-0003O1-I1 for; Wed, 08 Jun 2005 12:43:10 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA15742 for <>; Wed, 8 Jun 2005 12:43:07 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1Dg3zJ-0000dF-O0 for; Wed, 08 Jun 2005 13:05:11 -0400
Received: by with SMTP id n15so184285nfc for <>; Wed, 08 Jun 2005 09:42:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=mzL5DKnc266BrKObplOTUZ7YC8jR2VztL7DKut7Lie8TunQDQ6bDgIFZJ85BXmY71Foy0Tdqwf6QmdSgCVI3+FEh6ABmJVbvncljFV4zxhhMyvVy1xWDrWxrWIeFk/8wcMm9+afu9t2wFSW+tXuDy9Yn0bXD/ULZ2HaDVWFGYLU=
Received: by with SMTP id v5mr103716nfh; Wed, 08 Jun 2005 09:42:57 -0700 (PDT)
Received: by with HTTP; Wed, 8 Jun 2005 09:42:57 -0700 (PDT)
Message-ID: <>
Date: Wed, 08 Jun 2005 18:42:57 +0200
From: Carlos Garcia Braschi <>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: quoted-printable
Cc: David Ward <>, Dave Katz <>
Subject: Single-hop BFD for RIP routing protocol
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Carlos Garcia Braschi <>
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


We see a need in our network to also have a BFD single hop
implementation to help the RIP protocol, as an alternative to BGP for
simple cases where the amount of routes announced is small, as it
allows less protocol overhead and more predictable and somewhat
simpler implementations.

Could this be an item for this working group?

I'd like to have a standard way to do that, so that it is
interoperable among vendors. Although to me it seems quite obvious and
on previous discussions in the group seems that most of this
applications of BFD to routing protocols are quite simple, I have
written down a description of the expected behaviour, although is not
probably in a situation to be part of a draft, it could be a starting

"Any host or router (I'll stick with router from now on, but it
applies to both) that receives a RIP route update and has the BFD
feature enabled, tries to establish a BFD session with the next-hop IP
address for each route (be it the source of the update or a next-hop
in a route), if it does not have a suitable BFD session already
When a router has a BFD session established, and the session changes
to the "Down" state, all the routes that have the other side as
next-hop have to be deleted, and a route update should be sent
following the procedure for a triggered RIP update.
When the RIP timeout timer for a route expires, and that route is the
last one to point to a next hop with which there is a BFD session,
that session must be torn down.
While a router cannot establish a BFD session with a next-hop, it
behaves like it would with a non-BFD RIP implementation, allowing in
this way a mix of BFD and non-BFD routers in a subnet. BFD session
establishment attempts should do an exponential back-off and not retry
establishment if an ICMP port unreachable message is received (should
this be left to implementations?).
A router with the RIP BFD extension must accept BFD sessions from any
router that belongs to any subnet to which it is annnouncing RIP
updates. All authentication mechanisms in BFD may be used to mitigate
the possibilities of abuse."

BTW, what happened to the static route and BGP case? Will they be in a
separate draft?

Telefonica Empresas.