Re: draft-ietf-bfd-base-03.txt comments

Dave Katz <dkatz@juniper.net> Wed, 17 August 2005 18:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Sr0-0007nY-Lk; Wed, 17 Aug 2005 14:41:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Sqz-0007nT-Ir for rtg-bfd@megatron.ietf.org; Wed, 17 Aug 2005 14:41:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16695 for <rtg-bfd@ietf.org>; Wed, 17 Aug 2005 14:41:32 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5TQZ-00084G-J0 for rtg-bfd@ietf.org; Wed, 17 Aug 2005 15:18:20 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7HIfM951351; Wed, 17 Aug 2005 11:41:22 -0700 (PDT) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7HIfBG65451; Wed, 17 Aug 2005 11:41:11 -0700 (PDT) (envelope-from dkatz@juniper.net)
In-Reply-To: <4303778F.1080304@redback.com>
References: <4303778F.1080304@redback.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <A3ECA8A9-8183-4200-9F8E-5D7C13F717FA@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Wed, 17 Aug 2005 11:41:08 -0700
To: Chezhian Renganathan <chezhian@redback.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: Re: draft-ietf-bfd-base-03.txt comments
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

On Aug 17, 2005, at 10:44 AM, Chezhian Renganathan wrote:

> Hello,
>
> Section 6.7.4 -
> Unless I am missing something, it seems to me that the statement in  
> braces
> "roughly speaking, due to jitter"
> should be applicable in the context of Detection Time rather than  
> DetectMult.
> The DetectMult is just number of packets and there is no variance  
> there with
> jitter.

The text in the document is correct.  DetectMult is used to calculate  
time, not count packets, so given the application of jitter, the  
number of packets missed is approximate (if DetectMult were 10, for  
example, the actual number of packets missed before detection might  
be as high as 13 if 25% jitter is applied and the timing is right.)

>
> Also, was there any thinking along the lines of making the "Reg Min  
> Echo RX
> Interval" field optional, keeping with the spirit of this function,  
> being optional
> with either modes. This field could potentially be set to all zeros  
> for the entire
> length of a session unless changed if the end systems support this  
> function.

Not sure exactly what you're saying here.  To actually leave out the  
field and shorten the packet four bytes?  I'm not sure what would be  
gained by this.  The processing cost would be higher (Is the field  
there?  What is the value?) and the difference in packet size  
negligible.

As it stands now, the field can be set to zero if the sender does not  
wish or is not able to support the echo function.

Perhaps I don't understand the question.

--Dave

>
> thanks,
> chez
>
>
>