Single-hop BFD for RIP routing protocol

Carlos Garcia Braschi <cgbraschi@gmail.com> Wed, 08 June 2005 16:43 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; 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=
Message-ID: <9e31186f0506080942535037a4@mail.gmail.com>
Date: Wed, 08 Jun 2005 18:42:57 +0200
From: Carlos Garcia Braschi <cgbraschi@gmail.com>
To: rtg-bfd@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Cc: David Ward <dward@cisco.com>, Dave Katz <dkatz@juniper.net>
Subject: Single-hop BFD for RIP routing protocol
Precedence: list
Reply-To: Carlos Garcia Braschi <cgbraschi@gmail.com>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

Hi,

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
point:

"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
established.
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?

Regards,
Carlos.
Telefonica Empresas.

Single-hop BFD for RIP routing protocol Carlos Garcia Braschi