LC comments single hop

Carlos Garcia Braschi <> Fri, 08 July 2005 10:05 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1Dqpjj-0006qA-0Y; Fri, 08 Jul 2005 06:05:35 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1Dqpji-0006q5-0j for; Fri, 08 Jul 2005 06:05:34 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id GAA16879 for <>; Fri, 8 Jul 2005 06:05:31 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1DqqB3-0007q1-UR for; Fri, 08 Jul 2005 06:33:51 -0400
Received: by with SMTP id n15so99946nfc for <>; Fri, 08 Jul 2005 03:05:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mCgN2wkeJGxVivZfFNUMpedr/nVbnScWUe2hFY/qfSBKThUWnv5XgxOBmJZ+FaVGsWZCW7AvoIgGwxr7+EeIEqybK9u9QK1k1aoETb93nzHS+kttn8ppjPiZhdGUEAuzQ+ZN8wqj3HlE4IfCBF42f0ZQkc/G2Js7lfEfUUPXMMs=
Received: by with SMTP id u20mr64120nfh; Fri, 08 Jul 2005 03:05:22 -0700 (PDT)
Received: by with HTTP; Fri, 8 Jul 2005 03:05:22 -0700 (PDT)
Message-ID: <>
Date: Fri, 08 Jul 2005 12:05:22 +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: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
Subject: LC comments single hop
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: <>, <>


It may be a contrived case, but:
In the context of using BFD with RIP
- The RIP messages are used to detect with whom to establish BFD
sessions. That is, BFD sessions are established with senders from
which announcements are received.
- One of the two sides is a passive RIP listener.

(This may make sense where the passive listener is redistributing the
received routes to another protocol).

The non-passive side cannot take the "Active" role in the BFD session,
as it does not know where to send the BFD packets (until it receives
one with My Discriminator different from zero).

A similar case may happen with static routes (when they are not symmetrical).

I don't know if this contrived case warrants changing the wording on
point 3 of the 1-hop draft, from:
'As such, both sides of a session MUST take the "Active" role'
'As such, both sides of a session SHOULD take the "Active" role'


> Date: Wed, 6 Jul 2005 11:09:38 -0500
> From: David Ward <>
> Subject: WG Last call on base and single hop
> To:,,
> Cc:
> Message-ID: <>
> Content-Type: text/plain; charset=us-ascii
> All -
>         As the base specifiction for BFD has stabilized as well as the
> single hop specification, we are going to have a 3 week WG Last Call ending
> July 31st. Assuming no major revisions (famous last words) will be required,
> we will shepherd the drafts forward at that time.
> If you have comments, please reply to the WG and authors with the subject line:
> subject: LC comments < base spec | single hop>
> Here are the pointers to the docs.
> In other news, as Dave and I agreed in the last WG meeting, we will be
> submitting a "generic applicability" draft on how an app can boostrap BFD
> sessions so that we don't need individual drafts for each of our favorite
> protocols. Stay tuned.
> The new draft MIB may or may not be published in time for Paris.
> -DWard