Re: Detection time in demand mode
Dave Katz <dkatz@juniper.net> Sun, 20 March 2005 19:12 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10523; Sun, 20 Mar 2005 14:12:02 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD5v9-0006O8-FP; Sun, 20 Mar 2005 14:17:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD5op-0000Ea-LL; Sun, 20 Mar 2005 14:10:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD5on-0000ES-2L for rtg-bfd@megatron.ietf.org; Sun, 20 Mar 2005 14:10:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10412 for <rtg-bfd@ietf.org>; Sun, 20 Mar 2005 14:10:31 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD5th-0006MX-Hh for rtg-bfd@ietf.org; Sun, 20 Mar 2005 14:15:37 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2KJAHBm060009; Sun, 20 Mar 2005 11:10:18 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2KJACe75431; Sun, 20 Mar 2005 11:10:12 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <13616729.1111320742672.JavaMail.postfix@mx66.mail.sohu.com>
References: <13616729.1111320742672.JavaMail.postfix@mx66.mail.sohu.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <e8dc092bceeb9d88336d2f074c36631a@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Sun, 20 Mar 2005 12:13:50 -0700
To: roggie-bfd@sohu.com
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: Re: Detection time in demand mode
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
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>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
On Mar 20, 2005, at 5:12 AM, roggie-bfd@sohu.com wrote: > > Dave, > In section 6.7.4 , it said : > In Demand mode, the Detection Time calculated in the local system is > equal to bfd.DetectMult, multiplied by the agreed transmit interval > (the greater of bfd.RequiredMinRxInterval and the last received > Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due > to jitter) the number of packets that have to be missed in a row to > declare the session to be down. > From the above sentence , i get the flowing conclosion , for example > : > A------------------B > DM=3 DM=1 > MTI=100ms MTI=10ms > MRI=20ms MRI=200ms > if A sends a poll sequence , the transmit interval is > 200ms[max(100ms,200ms)] , > the detection time is 60ms[3*max(20ms,10ms)] , is it correct?? No, and thank you for catching this, I somehow managed to goof the language completely. The casual text is right--the agreed transmit interval is 200 ms, so the detection time would be 600 ms. I'll fix this ASAP; I can't believe that none of us noticed this in two years as it's pretty fundamental! Here's the proper language: In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval of the local system (the greater of bfd.DesiredMinTxInterval and the last received Required Min RX Interval.) bfd.DetectMult is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down. > > another question : in the spec , it always said "If Demand mode is > not active" , > i wants to ask is it the flowing meaning if one side set to demand > mode and > the other side dose not set , the side setted to demand mode also > MUST send > period control packet ? i am not sure ! From the spec: 6.5. Demand Mode Demand mode is negotiated by virtue of both systems setting the Demand (D) bit in its BFD Control packets. Both systems must request Demand mode for it to become active. If this is not clear, please let me know. --Dave
- Detection time in demand mode roggie-bfd
- Re: Detection time in demand mode Dave Katz