Re: I-D ACTION:draft-ietf-bfd-mib-01.txt

"Thomas D. Nadeau" <tnadeau@cisco.com> Mon, 11 July 2005 12:47 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrxhI-0000jF-CS; Mon, 11 Jul 2005 08:47:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrxhF-0000j1-3p for rtg-bfd@megatron.ietf.org; Mon, 11 Jul 2005 08:47:41 -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 IAA06881 for <rtg-bfd@ietf.org>; Mon, 11 Jul 2005 08:47:39 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dry9E-0005G9-EC for rtg-bfd@ietf.org; Mon, 11 Jul 2005 09:16:37 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2005 05:47:33 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.93,278,1115017200"; d="scan'208"; a="1257909:sNHT25049648"
Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j6BCjhk8005214; Mon, 11 Jul 2005 08:47:31 -0400 (EDT)
In-Reply-To: <9e31186f05071102464808a520@mail.gmail.com>
References: <42cea4f8.3c325c90.6f04.06b9SMTPIN_ADDED@mx.gmail.com> <9e31186f05071102464808a520@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <DD61905E-BE14-4E0C-82C8-DED5C06B8405@cisco.com>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Date: Mon, 11 Jul 2005 08:47:30 -0400
To: Carlos Garcia Braschi <cgbraschi@gmail.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: Re: I-D ACTION:draft-ietf-bfd-mib-01.txt
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 Jul 11, 2005, at 5:46 AM, Carlos Garcia Braschi wrote:

>> Date: Fri, 08 Jul 2005 10:50:02 -0400
>> From: Internet-Drafts@ietf.org
>> Subject: I-D ACTION:draft-ietf-bfd-mib-01.txt
>> To: i-d-announce@ietf.org
>> Cc: rtg-bfd@ietf.org
>> Message-ID: <E1DquB0-00029R-Eq@newodin.ietf.org>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>> This draft is a work item of the Bidirectional Forwarding  
>> Detection Working Group of the IETF.
>>
>>         Title           : Bidirectional Forwarding Detection  
>> Management Information Base
>>         Author(s)       : T. Nadeau, Z. Ali
>>         Filename        : draft-ietf-bfd-mib-01.txt
>>         Pages           : 24
>>         Date            : 2005-7-8
>>
>>
>
> Hi,
> I have two comments on this draft, probably quite trivial to correct:
> - The bfdSessDown notification is specified to be generated when the
> BFD session state changes to down or adminDown, making it a
> notification that the session has entered a down state.
>
> Since this does not exactly mean that there has been a disconnection
> detection, wouldn't it be better if it is only generated when
> transitioning to down or adminDown from the Up state?

     No, because we might want to notify also based on
sessions going down because they are really broken. I
think we want to handle BOTH cases.

> Transitions from init or adminDown to down or adminDown mean that the
> session has not been established since the last down state and
> transitions from down to
> adminDown are just an administrative change, that does not change the
> connectivity detection.
>
> - The draft mostly references BFD protocol version 0 and has 0 as a
> default version, but the syntax for the state follows version 1.
> Shouldn't it reference version 1 as the default BFD protocol?
> In the same line, the drafts referenced are the previous ward-katz
> drafts, instead of the ietf- ones.

     Will fix those.

     --Tom


>
> Regards,
> Carlos.
> --
> Telefonica Empresas
>