From exim@www1.ietf.org  Wed Oct  1 10:59:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16726
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 10:59:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iRT-0005K3-OL
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 10:59:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Ex3La020459
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 10:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iRT-0005Ju-Ki
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:59:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16710
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 10:58:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iRR-0000F8-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 10:59:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iRQ-0000F4-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 10:59:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iRR-0005Ja-Ey; Wed, 01 Oct 2003 10:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iQr-0005JA-3R
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 10:58:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16607
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 10:58:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iQo-0000Ea-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 10:58:22 -0400
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iQo-0000E3-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 10:58:22 -0400
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h91EvpIJ020624
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 10:57:51 -0400 (EDT)
Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com
 (Content Technologies SMTPRS 4.3.10) with ESMTP id <T6503b4a4200a80205d418@sonusms1.sonusnet.com>;
 Wed, 1 Oct 2003 10:57:47 -0400
Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id <RF5N43SL>; Wed, 1 Oct 2003 10:57:47 -0400
Message-ID: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E4476@sonusmail01.sonusnet.com>
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "Dave Katz (E-mail)" <dkatz@juniper.net>
Cc: "Bill Tarvin (E-mail)" <tarvin@juniper.net>,
        "Rahul Aggarwal (E-mail)"
	 <rahul@juniper.net>,
        "Sastry, Ravi" <rsastry@sonusnet.com>,
        "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
Subject: BFD questions
Date: Wed, 1 Oct 2003 10:57:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>

Hi Dave,

I have some questions about BFD:

When you aren't in the UP state, bfd.DesiredMinTxInterval MUST be at least
one second.  To get sub-second failure detections, then, you need to change
bfd.DesiredMinTxInterval when you enter the UP state.  Does that change mean
you need to send a control packet with the P bit set (a la section 6.5.3)?
In other words, for a transition into UP, do you routinely send a control
packet with the P bit set?

The same thing seems to apply to transitions from UP.
bfd.DesiredMinTxInterval needs to be reset to one second.  Do you routinely
send a poll when exiting UP state?

About P/F operation - When you're polling in the UP state, it seems to me
that you want to timeout and go to FAILING if you don't receive an F bit
within the detection timeout.  However, in section 6.5.6, the detection
timer is restarted for each valid control packet, regardless of the setting
of the F bit.  Is this what you intend?  If so, does that imply an
additional, unmentioned, timer for poll response timeout?

When one side is active and the other passive:  Both initialize to the
FAILING state, the active side sends packets with H=0.  When the passive
side receives a packet, it can begin sending control packets of its own
(section 6.1), and moves to the DOWN state (section 6.5.6).  The natural
thing is for the passive side to set H=1 (after all, it started transmitting
because it heard the active side).  But the active side will only leave
FAILING if H=0 (section 6.5.6), and therefore the session won't come UP.
You seem to be in the same situation when both sides are active and one
side's initial packet is lost.  Have I missed something?

Tom Phelan




From exim@www1.ietf.org  Wed Oct  1 13:14:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24150
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 13:14:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4kY8-0007DB-Am
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 13:14:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91HE4aD027715
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 13:14:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4kY8-0007Cw-6S
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:14:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24131
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 13:13:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4kY6-0002NL-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 13:14:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4kY6-0002NI-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 13:14:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4kY5-0007CK-NB; Wed, 01 Oct 2003 13:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4kXz-0007Bg-JI
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 13:13:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24117
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 13:13:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4kXx-0002Mz-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 13:13:53 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4kXw-0002MM-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 13:13:53 -0400
Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h91HDMj08686;
	Wed, 1 Oct 2003 10:13:22 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Date: Wed, 1 Oct 2003 10:13:01 -0700
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: BFD questions
From: Dave Katz <dkatz@juniper.net>
To: Bill Tarvin <tarvin@juniper.net>, rahul@juniper.net, rtg-bfd@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <83077629-F432-11D7-94AA-000A95AF2316@juniper.net>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


> On Wednesday, Oct 1, 2003, at 07:57 US/Pacific, Phelan, Tom wrote:
>
>> Hi Dave,
>>
>> I have some questions about BFD:
>>
>> When you aren't in the UP state, bfd.DesiredMinTxInterval MUST be at 
>> least
>> one second.  To get sub-second failure detections, then, you need to 
>> change
>> bfd.DesiredMinTxInterval when you enter the UP state.  Does that 
>> change mean
>> you need to send a control packet with the P bit set (a la section 
>> 6.5.3)?
>> In other words, for a transition into UP, do you routinely send a 
>> control
>> packet with the P bit set?
>
> Yes.
>
>>
>> The same thing seems to apply to transitions from UP.
>> bfd.DesiredMinTxInterval needs to be reset to one second.  Do you 
>> routinely
>> send a poll when exiting UP state?
>
> Hm, good question.  As the spec reads now, the transmit rate will 
> never slow down if the neighbor simply goes away, since it will never 
> receive a packet with the Final bit.  This should be gated by the 
> session being in Up state, since the whole point of the exercise is to 
> not drop an active session when the parameters are changing (but if 
> it's already down it doesn't matter.)
>
>>
>> About P/F operation - When you're polling in the UP state, it seems 
>> to me
>> that you want to timeout and go to FAILING if you don't receive an F 
>> bit
>> within the detection timeout.  However, in section 6.5.6, the 
>> detection
>> timer is restarted for each valid control packet, regardless of the 
>> setting
>> of the F bit.  Is this what you intend?  If so, does that imply an
>> additional, unmentioned, timer for poll response timeout?
>
> This would mean that the implementation is badly broken, since the 
> other side MUST eventually reply with F.  The problem with timing it 
> out is that you don't know how long to wait--it may take many packets 
> if the interval is small and the round-trip time is high.  (I've 
> already got a couple of places that say "must be greater than the RTT" 
> and don't want to add any more, since it's arbitrarily difficult to 
> determine.)  It also adds more complexity to the spec, which I'm 
> trying to avoid.  In general, it is impossible to diagnose all ways in 
> which an implementation can be broken.
>
>>
>> When one side is active and the other passive:  Both initialize to the
>> FAILING state, the active side sends packets with H=0.  When the 
>> passive
>> side receives a packet, it can begin sending control packets of its 
>> own
>> (section 6.1), and moves to the DOWN state (section 6.5.6).  The 
>> natural
>> thing is for the passive side to set H=1 (after all, it started 
>> transmitting
>> because it heard the active side).  But the active side will only 
>> leave
>> FAILING if H=0 (section 6.5.6), and therefore the session won't come 
>> UP.
>> You seem to be in the same situation when both sides are active and 
>> one
>> side's initial packet is lost.  Have I missed something?
>
> The missing link is the fact that the detection timer starts to run as 
> soon as you enter Init state.  If the first packet is lost, eventually 
> the guy in Init state will time out and fall back to Failing and 
> things will work.
>
>
> Thanks for the excellent feedback--I've gotten very little thusfar.
>
> --Dave
>
>





From exim@www1.ietf.org  Wed Oct  1 13:44:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25225
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 13:44:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4l18-0000KD-6c
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 13:44:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Hi2ic001246
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 13:44:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4l17-0000K1-Ui
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:44:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25211
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 13:43:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4l15-0002ew-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 13:43:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4l15-0002et-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 13:43:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4l16-0000JY-ND; Wed, 01 Oct 2003 13:44:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4l09-0000EG-6g
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 13:43:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25174
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 13:42:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4l06-0002e5-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 13:42:58 -0400
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4l06-0002ds-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 13:42:58 -0400
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h91HgSIJ000938
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 13:42:28 -0400 (EDT)
Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com
 (Content Technologies SMTPRS 4.3.10) with ESMTP id <T65044b5bb00a80205d418@sonusms1.sonusnet.com>;
 Wed, 1 Oct 2003 13:42:24 -0400
Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id <RF5N4PZP>; Wed, 1 Oct 2003 13:42:24 -0400
Message-ID: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E447A@sonusmail01.sonusnet.com>
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "'Dave Katz'" <dkatz@juniper.net>
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>,
        "Sastry, Ravi"
	 <rsastry@sonusnet.com>
Subject: RE: BFD questions
Date: Wed, 1 Oct 2003 13:42:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>

Hi Dave,

See inline ...

Tom P.

> -----Original Message-----
> From: Dave Katz [mailto:dkatz@juniper.net]
> Sent: Wednesday, October 01, 2003 1:06 PM
> To: Phelan, Tom
> Cc: Dave Katz
> Subject: Re: BFD questions
> 
> 
> 
> On Wednesday, Oct 1, 2003, at 07:57 US/Pacific, Phelan, Tom wrote:
> 
> > Hi Dave,
> >
> > I have some questions about BFD:
> >
> > When you aren't in the UP state, bfd.DesiredMinTxInterval 
> MUST be at 
> > least
> > one second.  To get sub-second failure detections, then, 
> you need to 
> > change
> > bfd.DesiredMinTxInterval when you enter the UP state.  Does that 
> > change mean
> > you need to send a control packet with the P bit set (a la section 
> > 6.5.3)?
> > In other words, for a transition into UP, do you routinely send a 
> > control
> > packet with the P bit set?
> 
> Yes.
> 
> >
> > The same thing seems to apply to transitions from UP.
> > bfd.DesiredMinTxInterval needs to be reset to one second.  Do you 
> > routinely
> > send a poll when exiting UP state?
> 
> Hm, good question.  As the spec reads now, the transmit rate 
> will never 
> slow down if the neighbor simply goes away, since it will 
> never receive 
> a packet with the Final bit.  This should be gated by the 
> session being 
> in Up state, since the whole point of the exercise is to not drop an 
> active session when the parameters are changing (but if it's already 
> down it doesn't matter.)
> 
> >
> > About P/F operation - When you're polling in the UP state, 
> it seems to 
> > me
> > that you want to timeout and go to FAILING if you don't 
> receive an F 
> > bit
> > within the detection timeout.  However, in section 6.5.6, 
> the detection
> > timer is restarted for each valid control packet, regardless of the 
> > setting
> > of the F bit.  Is this what you intend?  If so, does that imply an
> > additional, unmentioned, timer for poll response timeout?
> 
> This would mean that the implementation is badly broken, since the 
> other side MUST eventually reply with F.  The problem with timing it 
> out is that you don't know how long to wait--it may take many packets 
> if the interval is small and the round-trip time is high.  (I've 
> already got a couple of places that say "must be greater than 
> the RTT" 
> and don't want to add any more, since it's arbitrarily difficult to 
> determine.)  It also adds more complexity to the spec, which 
> I'm trying 
> to avoid.  In general, it is impossible to diagnose all ways in which 
> an implementation can be broken.

What I get from this is, you shouldn't exit the Up state just because you
haven't received an F bit, but have continued to receive otherwise valid
control packets.  In other words, all receiving an F bit does is stop you
from continuing to send P bits.  Never receiving an F bit has no real effect
on the session.  I think this is what the spec says, I just didn't consider
the RTT problem.

What I also get from this and the above statement is that you should only
start polling during the Up state - it's the only time you have a reasonable
chance of getting an F bit response.  Polling in other states is probably
fruitless.

> > When one side is active and the other passive:  Both 
> initialize to the
> > FAILING state, the active side sends packets with H=0.  When the 
> > passive
> > side receives a packet, it can begin sending control 
> packets of its own
> > (section 6.1), and moves to the DOWN state (section 6.5.6).  The 
> > natural
> > thing is for the passive side to set H=1 (after all, it started 
> > transmitting
> > because it heard the active side).  But the active side 
> will only leave
> > FAILING if H=0 (section 6.5.6), and therefore the session 
> won't come 
> > UP.
> > You seem to be in the same situation when both sides are 
> active and one
> > side's initial packet is lost.  Have I missed something?
> 
> The missing link is the fact that the detection timer starts 
> to run as 
> soon as you enter Init state.  If the first packet is lost, 
> eventually 
> the guy in Init state will time out and fall back to Failing 
> and things 
> will work.

I think I see what I missed.  You can't send H=1 because of a packet
received in the Failing state.  The normal process with two active ends
coming up more-or-less together is:

Side one starts, enters Failing, sends H=0.
Side two isn't up yet, so packet is lost.
Side two starts, enters Failing, sends H=0.
Side one receives, enters Down, sends H=0 even though is does hear other
side, because packet received in Failing.
Side two receives, enters Down, sends H=0 as above.
Side one receives, enters Init, sends H=1.
Side two receives, enters Up, sends H=1.
Side one receives, enters Up.

The missing piece for me was the rule "You can't send H=1 because of a
packet received in Failing state".  That might need to be spelled out to
avoid other mistakes :-).

> 
> 
> Thanks for the excellent feedback--I've gotten very little thusfar.
> 
> --Dave
> 




From exim@www1.ietf.org  Wed Oct  1 13:57:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25613
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 13:57:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lDh-0000zn-QI
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 13:57:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Hv16u003821
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 13:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lDh-0000zY-M1
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:57:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25604
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 13:56:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lDf-0002mw-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 13:56:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lDf-0002mt-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 13:56:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lDg-0000zC-Qw; Wed, 01 Oct 2003 13:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lDN-0000z0-Pv
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 13:56:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25585
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 13:56:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lDL-0002ma-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 13:56:39 -0400
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lDL-0002mQ-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 13:56:39 -0400
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h91Hu9IJ001855
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 13:56:09 -0400 (EDT)
Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com
 (Content Technologies SMTPRS 4.3.10) with ESMTP id <T650457e2c40a80205d418@sonusms1.sonusnet.com>;
 Wed, 1 Oct 2003 13:56:05 -0400
Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id <RF5N4P8Z>; Wed, 1 Oct 2003 13:56:05 -0400
Message-ID: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E447B@sonusmail01.sonusnet.com>
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "Dave Katz (E-mail)" <dkatz@juniper.net>
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
Subject: Re: BFD questions
Date: Wed, 1 Oct 2003 13:56:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38845.486ADDF0"
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C38845.486ADDF0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Dave,
 
Oh, I see where the "don't set H=0 for a packet received in Failing" rule
is.  In section 6.5.6, the bfd.SessionState case statement does say that, in
effect.
 
Tom P.

------_=_NextPart_001_01C38845.486ADDF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=624105417-01102003><FONT face=Arial size=2>Hi 
Dave,</FONT></SPAN></DIV>
<DIV><SPAN class=624105417-01102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=624105417-01102003><FONT face=Arial size=2>Oh, I see where the 
"don't set H=0 for a packet received in Failing" rule is.&nbsp; In section 
6.5.6, the bfd.SessionState case statement does say that, in 
effect.</FONT></SPAN></DIV>
<DIV><SPAN class=624105417-01102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=624105417-01102003><FONT face=Arial size=2>Tom 
P.</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C38845.486ADDF0--




From exim@www1.ietf.org  Wed Oct  1 14:14:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26190
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 14:14:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUE-0001in-DC
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 14:14:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91IE6Fc006611
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 14:14:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUD-0001iD-R0
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 14:14:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26166
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 14:13:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lUA-0002zR-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 14:14:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lUA-0002zL-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 14:14:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUA-0001h6-Uo; Wed, 01 Oct 2003 14:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lTw-0001gA-Uz
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 14:13:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26145
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 14:13:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lTu-0002yy-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 14:13:46 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lTt-0002yK-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 14:13:45 -0400
Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h91IDFj14482;
	Wed, 1 Oct 2003 11:13:15 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Date: Wed, 1 Oct 2003 11:13:15 -0700
Subject: Re: BFD questions
Content-Type: multipart/alternative; boundary=Apple-Mail-4-825449515
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
To: "Phelan, Tom" <tphelan@sonusnet.com>
From: Dave Katz <dkatz@juniper.net>
In-Reply-To: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E447B@sonusmail01.sonusnet.com>
Message-Id: <ED1ABA21-F43A-11D7-94AA-000A95AF2316@juniper.net>
X-Mailer: Apple Mail (2.552)
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>


--Apple-Mail-4-825449515
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

That's the one...

--Dave

On Wednesday, Oct 1, 2003, at 10:56 US/Pacific, Phelan, Tom wrote:

> Hi Dave,
> =A0
> Oh, I see where the "don't set H=3D0 for a packet received in Failing"=20=

> rule is.=A0 In section 6.5.6, the bfd.SessionState case statement does=20=

> say that, in effect.
> =A0
> Tom P.

--Apple-Mail-4-825449515
Content-Type: text/enriched;
	charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

That's the one...


--Dave


On Wednesday, Oct 1, 2003, at 10:56 US/Pacific, Phelan, Tom wrote:


<excerpt><fontfamily><param>Arial</param><smaller>Hi =
Dave,</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Oh, I see where the "don't
set H=3D0 for a packet received in Failing" rule is.=A0 In section =
6.5.6,
the bfd.SessionState case statement does say that, in =
effect.</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Tom P.</smaller></fontfamily>

</excerpt>=

--Apple-Mail-4-825449515--





From exim@www1.ietf.org  Wed Oct  1 14:14:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26205
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 14:14:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUI-0001l0-VW
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 14:14:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91IEAnK006748
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 14:14:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUI-0001kl-PS
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 14:14:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26165
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 14:13:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lUA-0002zO-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 14:14:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lUA-0002zJ-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 14:14:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lU9-0001gZ-GA; Wed, 01 Oct 2003 14:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lTV-0001dR-6a
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 14:13:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26118
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 14:13:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lTS-0002yN-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 14:13:18 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lTR-0002xw-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 14:13:18 -0400
Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h91IClj14435;
	Wed, 1 Oct 2003 11:12:47 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Date: Wed, 1 Oct 2003 11:12:47 -0700
Subject: Re: BFD questions
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>,
        "Sastry, Ravi" <rsastry@sonusnet.com>
To: "Phelan, Tom" <tphelan@sonusnet.com>
From: Dave Katz <dkatz@juniper.net>
In-Reply-To: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E447A@sonusmail01.sonusnet.com>
Message-Id: <DC72DFEC-F43A-11D7-94AA-000A95AF2316@juniper.net>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, Oct 1, 2003, at 10:42 US/Pacific, Phelan, Tom wrote:

>> This would mean that the implementation is badly broken, since the
>> other side MUST eventually reply with F.  The problem with timing it
>> out is that you don't know how long to wait--it may take many packets
>> if the interval is small and the round-trip time is high.  (I've
>> already got a couple of places that say "must be greater than
>> the RTT"
>> and don't want to add any more, since it's arbitrarily difficult to
>> determine.)  It also adds more complexity to the spec, which
>> I'm trying
>> to avoid.  In general, it is impossible to diagnose all ways in which
>> an implementation can be broken.
>
> What I get from this is, you shouldn't exit the Up state just because 
> you
> haven't received an F bit, but have continued to receive otherwise 
> valid
> control packets.  In other words, all receiving an F bit does is stop 
> you
> from continuing to send P bits.  Never receiving an F bit has no real 
> effect
> on the session.  I think this is what the spec says, I just didn't 
> consider
> the RTT problem.

Receiving the F bit also allows you to actually change the timing 
parameters to the ones you're advertising;  in the mean time you 
advertise the new interval but continue to actually use the old one.

>
> What I also get from this and the above statement is that you should 
> only
> start polling during the Up state - it's the only time you have a 
> reasonable
> chance of getting an F bit response.  Polling in other states is 
> probably
> fruitless.

Yep, I think that's going to be the change.  I need to think a bit more.

>> The missing link is the fact that the detection timer starts
>> to run as
>> soon as you enter Init state.  If the first packet is lost,
>> eventually
>> the guy in Init state will time out and fall back to Failing
>> and things
>> will work.
>
> I think I see what I missed.  You can't send H=1 because of a packet
> received in the Failing state.  The normal process with two active ends
> coming up more-or-less together is:
>
> Side one starts, enters Failing, sends H=0.
> Side two isn't up yet, so packet is lost.
> Side two starts, enters Failing, sends H=0.
> Side one receives, enters Down, sends H=0 even though is does hear 
> other
> side, because packet received in Failing.
> Side two receives, enters Down, sends H=0 as above.
> Side one receives, enters Init, sends H=1.
> Side two receives, enters Up, sends H=1.
> Side one receives, enters Up.
>
> The missing piece for me was the rule "You can't send H=1 because of a
> packet received in Failing state".  That might need to be spelled out 
> to
> avoid other mistakes :-).

That's pretty much it.  The spec says to set bfd.RemoteHeard to 1 when 
you receive a control packet in Down state (causing subsequent packets 
to go out with H=1) and since you cannot be in down state without 
receiving an H=0 packet in Failing state, this is effectively the case.

I think the spec is unambiguous, if not totally obvious.  I could add 
more nonnormative descriptive text in 6.1 if you think it really 
necessary.

--Dave





From exim@www1.ietf.org  Wed Oct  1 15:29:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00777
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 1 Oct 2003 15:29:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mf0-0005Bo-83
	for rtg-bfd-archive@odin.ietf.org; Wed, 01 Oct 2003 15:29:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91JTI2m019942
	for rtg-bfd-archive@odin.ietf.org; Wed, 1 Oct 2003 15:29:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mf0-0005BZ-1D
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 15:29:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00746
	for <rtg-bfd-web-archive@ietf.org>; Wed, 1 Oct 2003 15:29:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4mey-00046C-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 15:29:16 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4mey-000469-00
	for rtg-bfd-web-archive@ietf.org; Wed, 01 Oct 2003 15:29:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mej-0005Ag-A3; Wed, 01 Oct 2003 15:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4me2-00055C-H5
	for rtg-bfd@optimus.ietf.org; Wed, 01 Oct 2003 15:28:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00638
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 15:28:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4me0-00044l-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 15:28:16 -0400
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4me0-00044B-00
	for rtg-bfd@ietf.org; Wed, 01 Oct 2003 15:28:16 -0400
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h91JRkIJ007607
	for <rtg-bfd@ietf.org>; Wed, 1 Oct 2003 15:27:46 -0400 (EDT)
Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com
 (Content Technologies SMTPRS 4.3.10) with ESMTP id <T6504abc4630a80205d418@sonusms1.sonusnet.com>;
 Wed, 1 Oct 2003 15:27:42 -0400
Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id <RF5N4QSV>; Wed, 1 Oct 2003 15:27:42 -0400
Message-ID: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E447D@sonusmail01.sonusnet.com>
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "'Dave Katz'" <dkatz@juniper.net>, "Phelan, Tom" <tphelan@sonusnet.com>
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>,
        "Sastry, Ravi"
	 <rsastry@sonusnet.com>
Subject: RE: BFD questions
Date: Wed, 1 Oct 2003 15:27:41 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>

Hi Dave,

> Receiving the F bit also allows you to actually change the timing 
> parameters to the ones you're advertising;  in the mean time you 
> advertise the new interval but continue to actually use the old one.

Oh.  Thanks for the clarification.

As new questions come up, I'll ask them :-).

Tom P.




From exim@www1.ietf.org  Wed Oct  8 09:21:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13826
	for <rtg-bfd-archive@odin.ietf.org>; Wed, 8 Oct 2003 09:21:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7EFT-0005hs-Oa
	for rtg-bfd-archive@odin.ietf.org; Wed, 08 Oct 2003 09:21:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98DL3XG021936
	for rtg-bfd-archive@odin.ietf.org; Wed, 8 Oct 2003 09:21:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7EFT-0005hj-KC
	for rtg-bfd-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 09:21:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13794
	for <rtg-bfd-web-archive@ietf.org>; Wed, 8 Oct 2003 09:20:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7EFS-0004ql-00
	for rtg-bfd-web-archive@ietf.org; Wed, 08 Oct 2003 09:21:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7EFR-0004qh-00
	for rtg-bfd-web-archive@ietf.org; Wed, 08 Oct 2003 09:21:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7EFR-0005hP-Ot; Wed, 08 Oct 2003 09:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7EFI-0005gg-3f
	for rtg-bfd@optimus.ietf.org; Wed, 08 Oct 2003 09:20:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13789
	for <rtg-bfd@ietf.org>; Wed, 8 Oct 2003 09:20:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7EFG-0004qY-00
	for rtg-bfd@ietf.org; Wed, 08 Oct 2003 09:20:50 -0400
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7EFF-0004qQ-00
	for rtg-bfd@ietf.org; Wed, 08 Oct 2003 09:20:49 -0400
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h98DKJIJ013458
	for <rtg-bfd@ietf.org>; Wed, 8 Oct 2003 09:20:19 -0400 (EDT)
Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com
 (Content Technologies SMTPRS 4.3.10) with ESMTP id <T652767de6d0a80205d420@sonusms1.sonusnet.com>;
 Wed, 8 Oct 2003 09:20:15 -0400
Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id <RF5NV3VN>; Wed, 8 Oct 2003 09:20:15 -0400
Message-ID: <CAC8ED3E4E27EE4BBCF7030CC74A267D011E449A@sonusmail01.sonusnet.com>
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "Dave Katz (E-mail)" <dkatz@juniper.net>
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>,
        "Sastry, Ravi"
	 <rsastry@sonusnet.com>
Subject: BFD implementation
Date: Wed, 8 Oct 2003 09:20:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38D9E.E5853F50"
Sender: rtg-bfd-admin@ietf.org
Errors-To: rtg-bfd-admin@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Id: RTG Area: Bidirectional Forwarding Detection DT <rtg-bfd.ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C38D9E.E5853F50
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Dave,
 
I've created a Linux process-level implementation of BFD.  At this point, it
implements all of the protocol features except for echo packets, but has
basically no user API (just command line options).  While it isn't useful in
a real application, it should be quite suitable for interoperability
testing.  If you can find a way to test it against your implementation I'd
appreciate it.
 
You can get source code and usage info at http://www.phelan-4.com/bfd
<http://www.phelan-4.com/bfd> .  Let me know of anything you need.
 
Tom P.

------_=_NextPart_001_01C38D9E.E5853F50
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1264" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=103531313-08102003><FONT face=Arial size=2>Hi 
Dave,</FONT></SPAN></DIV>
<DIV><SPAN class=103531313-08102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=103531313-08102003><FONT face=Arial size=2>I've created a Linux 
process-level implementation of BFD.&nbsp; At this point, it implements all of 
the protocol features except for echo packets, but has basically no user API 
(just command line options).&nbsp; While it isn't useful in a real application, 
it should be quite&nbsp;suitable for interoperability testing.&nbsp; If you can 
find a way to test it against your implementation I'd appreciate 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=103531313-08102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=103531313-08102003><FONT face=Arial size=2>You can get source 
code and usage info at <A 
href="http://www.phelan-4.com/bfd">http://www.phelan-4.com/bfd</A>.&nbsp; Let me 
know of anything you need.</FONT></SPAN></DIV>
<DIV><SPAN class=103531313-08102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=103531313-08102003><FONT face=Arial size=2>Tom 
P.</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C38D9E.E5853F50--