[CCAMP] OPS-DIR review of draft-ietf-ccamp-gmpls-ted-mib-14

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 14 October 2012 11:39 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 03EDE21F847D; Sun, 14 Oct 2012 04:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.842
X-Spam-Status: No, score=-102.842 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wBi3FbY71998; Sun, 14 Oct 2012 04:39:15 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com []) by ietfa.amsl.com (Postfix) with ESMTP id ABE3821F8455; Sun, 14 Oct 2012 04:39:14 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAISjelCHCzI1/2dsb2JhbABFv3GBCIIgAQEBAQIBEh4KOAwNARUVBgwMB1cBBAEaGoVugW4GoBmbdpE2YAOSO4k1iiyCb4Fh
X-IronPort-AV: E=Sophos;i="4.80,584,1344225600"; d="scan'208";a="31499991"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Oct 2012 07:31:29 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Oct 2012 07:16:54 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Oct 2012 13:39:11 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04082301A0@307622ANEX5.global.avaya.com>
Thread-Topic: OPS-DIR review of draft-ietf-ccamp-gmpls-ted-mib-14
Thread-Index: Ac2qAIeNeJPCVFZlQRa0gUyIbefUrQ==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <ccamp-chairs@tools.ietf.org>, <ccamp@ietf.org>, <ops-dir@ietf.org>
X-Mailman-Approved-At: Sun, 14 Oct 2012 07:28:30 -0700
Subject: [CCAMP] OPS-DIR review of draft-ietf-ccamp-gmpls-ted-mib-14
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Oct 2012 11:39:16 -0000


This is the OPS-DIR review of draft-ietf-ccamp-gmpls-ted-mib-14. 

OPS-DIR reviews use RFC 5706 as guidelines. See Appendix A for a
checklist of issues typically reviewed. Note that not all issues apply
to all documents. 

This document defines a MIB module. Note that this review is an OPS-DIR
review and not a MIB Doctor review. 

I believe that the document is useful from an operational and
manageability point of view, and is ready for approval. The issues
raised below if addressed can improved the quality of the document, but
none is blocking. As written the document seems to be more addressed to
implementers and less to users, expanding the example from the
perspective of the operator using this MIB module would be a good thing
(see comment #4) that would ease deployment. 

This MIB module exposes traffic engineering database (TED) topology
information for MPLS-TE and GMPLS. Most of the MIB objects are read-only
with the exception of the objects configuring the sending of


1. In Section 2: 

>  This MIB module should be used in conjunction with OSPFv2 MIB, OSPF 
   v3 MIB and ISIS MIB as well as other MIBs defined in [RFC3812], 
   [RFC3813], [RFC4802], [RFC4803] for the management of MPLS/GMPLS 
   based traffic engineering information.  

It would have been useful to develop this a section that explains the
relation of the TED-MIB with other MIB modules that model MPLS-TE and
GMPLS devices. Are all these MIB modules required on the same device at
the same time? Being more precise here would help implementers and
switch designers in planning the resources required to implement and run
this MIB module. 

2. Runing id-nits results in a number of warnings related to unused

  == Unused Reference: 'RFC2328' is defined on line 1552, but no
     reference was found in the text
     '[RFC2328] J. Moy, " OSPF version2 ", RFC2328, April 1998....'

  == Unused Reference: 'RFC4001' is defined on line 1566, but no
     reference was found in the text
     '[RFC4001]  M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,

  == Unused Reference: 'RFC4801' is defined on line 1579, but no
     reference was found in the text
     '[RFC4801] T. D. Nadeau and A. Farrel, Ed., "Definitions of Textual

  == Unused Reference: 'RFC5340' is defined on line 1587, but no
     reference was found in the text
     '[RFC5340] R. Coltun, D. Ferguson, J. Moy, A.Lindem " OSPF for

  == Unused Reference: 'RFC6340' is defined on line 1593, but no
     reference was found in the text
     '[RFC6340] R. Presuhn, "Textual Conventions for the Representation

  == Unused Reference: 'ISO10589' is defined on line 1596, but no
     reference was found in the text
     '[ISO10589] ISO 10589, "Intermediate system to Intermediate system

  == Unused Reference: 'RFC4220' is defined on line 1625, but no
     reference was found in the text
     '[RFC4220] M. Dubuc, T. D. Nadeau and J. Lang, " Traffic
Actually the references are used, but they appear in the DESCRIPTION or
REFERENCE clauses in the MIB module, and in a format (no brakets) that
makes them to pass undetected by id-nits. It would be useful to group at
lease the references that contain MIB modules in a short section prior
to the MIB module, so that implmenters and operators deploying the MIB
have an easy access to the documents that indicate what MIB modules need
to be compiled or loaded together with the TED-MIB. Add to these RFC4802
mentioned in the IMPORTS.  

3. The example provided in section 6 is ipv4 only. It would be useful to
add an ipv6 example. 

4. Expanding the example to detail what would be a typical or
recommended operational flow used by an operator when working with the
MIB module would have been useful. How is the MIB modules supposed to be
used. What an operator can do with this MIB module? Download the
topology? How often? Verify that the switch was properly configured and
debug problems in the network using the objects in the tedTable,
tedRemoteTable and tedSwCapTable? What is the functionality and how can
be used the tedSrlgTable? 

5. Notifications throttling is discussed and implemented and this is a
good thing. However, there is a potential issue here. The notifications
tedEntryCreated and tedENtryDeleted are supposed to be sent when an
entry was created or deleted in the TED table. However, the writeable
object that sets the notifications rate is set by default at 1
notification/minute, a value that many operators will leave as is. This
means that whenever more than one row is created or deleted in one
minute, just one notification will be sent. I think that an explicit
warning should be included about this situation, so that operators are
aware that in order to make sure that all changes were detected when a
notification was received, the whole table needs to be traversed. 

6. There is no indication or hints to the operators about using the
objects in this MIB module for faults management or alerting about the
status of the network. For example can the tedUnreservedBandwidth per
priority objects be used to detect problems in capacity or in