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
- Comments on draft-ietf-bfd-mib-02.txt Dave Katz
- Re: Comments on draft-ietf-bfd-mib-02.txt Thomas D. Nadeau
- Re: Comments on draft-ietf-bfd-mib-02.txt Tom Petch
- Re: Comments on draft-ietf-bfd-mib-02.txt Thomas D. Nadeau