[MIB-DOCTORS] MIB Dr. Review of draft-ietf-mpls-mldp-mib-04

Joan Cucchiara <jcucchiara.ietf@gmail.com> Mon, 06 August 2018 15:15 UTC

Return-Path: <jcucchiara.ietf@gmail.com>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DAB5B129C6B; Mon, 6 Aug 2018 08:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id miM-ODwkgCPw; Mon, 6 Aug 2018 08:15:50 -0700 (PDT)
Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA986128BAC; Mon, 6 Aug 2018 08:15:49 -0700 (PDT)
Received: by mail-oi0-x244.google.com with SMTP id y207-v6so22752066oie.13; Mon, 06 Aug 2018 08:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wK02MtbtZfIdJVd2zFxP3jvGKx+78mngQt5Snruuu4c=; b=Du8W22x9sUClKKlffUWzg2yONKV2Ipnkgk5furZqfqOF3CIgMp77EGHPsoFxJg+rfB KGw3UmD3oMS6/5CrwWfz7CR5dFAZ6sbgld4Fj77Rmnk8pbwXFj+Upnl/9mJUc6xB+nvx DQXpT2roc3hozQsi/D5l39ZG9Ry/3JS3fESOy7HXUEbtVXYtExedjHGxgvO89GL/LQ9O zJFhxz2iFqSA4r4zhNWsDBrdK/iuHMsBfcvq1sD1Slfc4VLKM66WhAoywQc5Z5MPcsDD mmDoG6M2bTfv/pRNAKOSsvN0KS/q8MoQK5rKTdcLg2BJQNBu7bE51ClvvXkfSJ0CRQrl WoGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wK02MtbtZfIdJVd2zFxP3jvGKx+78mngQt5Snruuu4c=; b=qrxXPHDPF0rlr+qAWqjntAlo8s3hGyjwQoTuTqIq7jCwudmCB8mCkV6DRNTFYpKQMI StSbhSQoZFHVPwe/xymaEfZwxNR9Lks3Gc7/+CsAqTA5pOqOVjiPsNg66vZf2E5mONZ9 N4AeH8k+r/+cLwXhc7+MSgscXuBsoS1nE36ZfpdL8IXhlRDuBtnGPfPCO9lGXTHK94tD VgWm+cb5Nig5MtmSLDVdogWWyp/yTtxh9jlFWxVOG97fMeQLd/sm/mwwi8X8jHbsyZlJ 4/rccn/DKyRiR5nBdEhSvtHozIP52IJCaXPqmzfUmtTc2iD6R28u7caJgRkpPNm0UB4G ikCQ==
X-Gm-Message-State: AOUpUlGQd6UZ+gGmS0Pm8UvarPUTk49ov46Tnc8ayrBLDx8GbGHM2oy9 XO1JzNO3r8Iv9M6K2436yTHXYT/LOC7cJgCbQdtMuo7v
X-Google-Smtp-Source: AAOMgpcDRS54vc9zt7Y2W0cf2QtikJyWv2olKxkzpOeForBkNG5HEiec6GhnhxqzPPRkEmObChvkuGRSITCu1dV65uk=
X-Received: by 2002:aca:ce85:: with SMTP id e127-v6mr15877700oig.169.1533568549159; Mon, 06 Aug 2018 08:15:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:bd10:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 08:15:48 -0700 (PDT)
From: Joan Cucchiara <jcucchiara.ietf@gmail.com>
Date: Mon, 6 Aug 2018 11:15:48 -0400
Message-ID: <CANSkkOmTD7F3ioxuccKUMq5tVUZh-MwvaDLyL0=59NTPiy2J9Q@mail.gmail.com>
To: mpls@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-mldp-mib@ietf.org
Cc: mib-doctors@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009c87280572c5c065"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/FenmPDOX27Ss-vIQGX8hIyQm58k>
Subject: [MIB-DOCTORS] MIB Dr. Review of draft-ietf-mpls-mldp-mib-04
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 15:15:52 -0000

Kishore and authors,

Thank you for the update.   The draft is in good shape.   The use of
AUGMENTS helped immensely in understanding the relationship between tables.

Below are my comments.  Please let me know if you have any



Comments for mpls-mldp-mib-04.txt


1.  Please fix these compiler warnings.

W: f(MPLS-MLDP-STD-MIB.my), (1133,9) Duplicate item "mplsMldpP2mpCapable"
in object-group "mplsMldpScalarsGroup" OBJECTS list

W: f(MPLS-MLDP-STD-MIB.my), (1142,9) Duplicate item "mplsMldProtLsrCapable"
in object-group "mplsMldpScalarsGroup" OBJECTS list

W: f(MPLS-MLDP-STD-MIB.my), (1157,11) Duplicate item
"mplsMldpSessionStatsNumFecsSent" in object-group "mplsMldpObjectsGroup"

2) Please use the suggested OID layout in RFC4181, Appendix D.  These
guidelines specify the following OID Layout for MIBs:



         +-- xxxNotifications(0)

         +-- xxxObjects(1)

         +-- xxxConformance(2)


             +-- xxxCompliances(1)

             +-- xxxGroups(2)

Below is the OID layout for this draft:

   -- notifications

   mplsMldpNotifications OBJECT IDENTIFIER ::= { mplsMldpStdMIB 0 }

   -- tables, scalars

   mplsMldpScalars       OBJECT IDENTIFIER ::= { mplsMldpStdMIB 1 }

   mplsMldpObjects       OBJECT IDENTIFIER ::= { mplsMldpStdMIB 2 }

mplsMldpConformance   OBJECT IDENTIFIER ::= { mplsMldpStdMIB 3 }

mplsMldpGroups        OBJECT IDENTIFIER ::= { mplsMldpConformance 1 }

mplsMldpCompliances   OBJECT IDENTIFIER ::= { mplsMldpConformance 2 }

3)  Section 10.2   You mention the mplsXCTable in this section but I don’t
see it in the MIB itself.  Is it being used in the MIB?

4) Section 10.3  Relationship to the LDP MIB

Should explain the relationship to the LDP MIB's  PeerTable and
SessionTable in this Section.

5) mplsLdpPeerCapability

Why is this a BITS value?   For example, could p2mp(1) and mp2mp(2)

both be set?

Under what circumstances would the value of this object be none(0)?  If the
value is none(0), can other BITS be set?

Please clarify.

5).  mplsMldpFecTable -- A few concerns about this table:

* mplsMldpFecRootAddrType --

IANA's Address Family Numbers registry is specified, so why is this being
limited to IPv4 and IPv6 only?

* mplsMldpFecType and mplsMldpFecOpaqueType

These 2 types are maintained by  IANA.  I believe a separate MIB Module
containing TEXTUAL-CONVENTIONs for these objects

should be added in the IANA considerations section .   (For an example,
please see  the IANA-GMPLS-TC-MIB

which is contained in RFC4802.)

If there are other Managed Objects which are also associated with
registries being maintained by IANA, then these should also be included.

(Once done, then the Future Considerations Section will no longer be

6) mplsMldpFecBranchStatsTable

This table is confusing wrt the indexing.

Could this be made a "sparse augments" to the mplsMldpFecTable?

(An example of sparse augments is the MplsLdpSessionPeerAddrTable in the


I think mplsMldpFecIndex could be used directly?  Then another index

which has the same value as the mplsOutSegmentIndex?   I am wondering

though if the Outsegment truly needs to be an index.

Will there always be a corresponding

entry in the MplsOutSegmentTable?  (Is it possible that there are multiple
downstream LDP sessions which map to the same OutSegment?)

Could mplsOutSegmentPerfDiscontinuityTime be used for the counters?

Why would the following object not have a valid value?

Does this imply also that the counters are not valid if the LDPIdentifier
is not valid?

   mplsMLdpFecBranchPeerLdpId          OBJECT-TYPE

      SYNTAX        MplsLdpIdentifier


           "This object identifies an outgoing branch peer LDP ID for this

           mLDP LSP. Its value is unique within the context of the mLDP LSP.

           On Egress node, this value could be as there will no

           downstream LDP session."

7) mplsMldpFecUpStreamSessTable

What does the mplsMldpFecUpstreamSessFecIndex represent?

Please clarify.   Could mplsMldpFecIndex be used directly?

Similar comments as above wrt mplsMldpFecUpstreamSessInSegIndex.

Does this truly have to be an index?  Could there be more than one upstream
mLDP sessions that maps to an InSegment?

Can the mplsInSegmentPerfDiscontinuityTime object be used, instead of the
one in this table?

8)  Is mplsMldpInterfaceIndex an ifIndex?

Please clarify.

9). Security Considerations

Please take out the mention of configuration in the first sentence:
for the configuration of certain objects..."

--- end of comments ----