Comments on draft-ietf-bfd-mib-02.txt

Dave Katz <dkatz@juniper.net> Fri, 05 August 2005 16:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15S8-0006HV-1N; Fri, 05 Aug 2005 12:53:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15S6-0006HQ-7B for rtg-bfd@megatron.ietf.org; Fri, 05 Aug 2005 12:53:46 -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 MAA20141 for <rtg-bfd@ietf.org>; Fri, 5 Aug 2005 12:53:43 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E15zD-0004RL-3t for rtg-bfd@ietf.org; Fri, 05 Aug 2005 13:28:00 -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 j75GrZ981655 for <rtg-bfd@ietf.org>; Fri, 5 Aug 2005 09:53:35 -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 j75GrUG54236 for <rtg-bfd@ietf.org>; Fri, 5 Aug 2005 09:53:30 -0700 (PDT) (envelope-from dkatz@juniper.net)
Mime-Version: 1.0 (Apple Message framework v733)
Content-Transfer-Encoding: 7bit
Message-Id: <27F4588E-E478-4A94-95EB-0624FC065657@juniper.net>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
To: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
From: Dave Katz <dkatz@juniper.net>
Date: Fri, 05 Aug 2005 09:53:29 -0700
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Subject: Comments on draft-ietf-bfd-mib-02.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

MIBs make my head spin, but I noticed a few things based on comments  
from Sankar.  These comments may be wildly off the mark, as I don't  
really grok MIBs (an arcane art to be sure), but not knowing what I  
was talking about has never stopped me in the past.


First, the document reference is incorrect; it refers to Version 0  
and the 02 base spec, but the 02 base spec was Version 1 of the  
protocol (and the current draft is 03, though that shouldn't have any  
effect on the MIB as far as I can tell.)

There is major confusion over the session state;  I'm guessing that  
earlier versions of the MIB had a locally defined session state  
variable, but when the session state became codified in the protocol  
the state values all changed.  There are numerous references of the  
form "up(1)" (and "up(2)" for that matter) for all session state  
values that are incorrect and in some cases contradictory.

The bfdSessUp and bfdSessDown notifications should presumably have  
parameters of type bfdSessIndex.  The comments under them I don't  
understand at all (and were the source of Sankar's concern.)  I'm  
guessing that the sentence "The included values of bfdSessDiag MUST  
both be set equal to this new state" is trying to say that all of the  
sessions indicated by the index range must both be in Up state (which  
has nothing to do with the diagnostic value), but I'm not sure what  
the point of that is (and if the session entries are subsequently  
grabbed from the MIB, there is a very good chance that the sessions  
will *not* be in the specified state, as the notification will be  
stale.)

In a related area, BfdDiag defines the diagnostic values, but  
bfdSessDiag is defined as an opaque 32 bit value.  Shouldn't the  
latter be defined in terms of the former?

The comment for bfdSessDiag is too restrictive, as the session  
diagnostic has gotten a bit more flexible as the base spec  
progressed.  The diagnostic is sometimes set in situations other than  
a transition away from Up state.

--Dave