Subject: [mpls] Early MIB Dr. review of draft-ietf-mpls-p2mp-te-mib-03.txt

From: "Joan Cucchiara" <[email-masked]>
Date: Fri, 6 Apr 2007 12:14:28 -0400

Adrian, Seisho and Tom,

Here is an early review of draft-ietf-mpls-p2mp-te-mib-03.txt.
There were 2  major concerns that denoted by **  below.

Probably worth some discussion on those.

Thanks,
   Joan

smicngPRO gives the following warnings:
-------------------------------------------

W: f(MPLS-TE-P2MP-STD-MIB), (930,4)
Name of item "mplsTeP2mpTunnelBranchPerfEntry"
must start with uppercase letter
Item name changed to "MplsTeP2mpTunnelBranchPerfEntry"

W: f(MPLS-TE-P2MP-STD-MIB), (300,4)
Item "mplsTeP2mpTunnelSubGroupOriginType" is not contained in
any group defined in the current module

W: f(MPLS-TE-P2MP-STD-MIB), (317,4)
Item "mplsTeP2mpTunnelSubGroupOrigin" is not contained in
any group defined in the current module

W: f(MPLS-TE-P2MP-STD-MIB), (346,4)
Item "mplsTeP2mpTunnelSubGroupID" is not contained in
any group defined in the current module

SMILINT gives the following:
-------------------------------
Line   Severity   Problem
300 4 warning: node `mplsTeP2mpTunnelSubGroupOriginType'
must be contained in at least one conformance group

317 4 warning: node `mplsTeP2mpTunnelSubGroupOrigin'
must be contained in at least one conformance group

346 4 warning: node `mplsTeP2mpTunnelSubGroupID'
must be contained in at least one conformance group

891 2 unknown type `MplsTeP2mpTunnelBranchPerfEntry'

902 6 info: previous definition of `mplsTeP2mpTunnelBranchPerfEntry'

930 2 redefinition of identifier `mplsTeP2mpTunnelBranchPerfEntry'
        1 syntax error, unexpected COLON_COLON_EQUAL, expecting OBJECT

938 5 warning: flushing recent incorrect declaration,
see previous error(s)

Comments in order of draft
--------------------------

*)Abstract

   In particular, it describes managed objects for point-to-multipoint
   Multiprotocol Label Switching-based traffic engineering.

NIT, but to be consistent with rfc3812 could this be changed
to:

   In particular, it describes managed objects for point-to-multipoint 
(P2MP)
   Multiprotocol Label Switching (MPLS) based traffic engineering (TE).

*) 4. Outline

With regard to the following section:
   "The setup of P2MP tunnels can be achieved as:
   - management actions only, by using [RFC3813]
   - control plane actions under the direction of a management process
     by using [RFC3812] and the MIB module defined in this document
   - control plane actions under the direction of some other management
     process, monitored using [RFC3812] and the MIB module defined in
     this document."

I am not clear what you are trying to say in the above.

How is P2MP acheived with rfc3813?
What is meant by "management actions", and "control plane actions"?

The following statement:
        "The subsequent section provides an explanation and
   example of how the P2MP MPLS-TE MIB module can be used for the
   processes listed above in combination with the MPLS-TE MIB module
   defined in [RFC3812]."

refers to "processes listed above", what is meant by this?

*) Are there any objects which apply only to GMPLS?

**) 4.2 Use of MPLS-TE-STD-MIB

I am checking with MIB Doctors on this, but currently believe
that what is being described in this section constitutes
semantic changes (maybe not every object described here, but
many of them).  Semantic changes in MIBs require a respin of
the MIB, meaning that you need to update rfc3812, so the rewrite
of the DESCRIPTION clauses for objects which live in rfc3812
would need to be updated in rfc3812 (not in this document).

*)   4.7. Relationships Between MIB Tables

The following statement would benefit from using the symbols in
the diagram.

  "An arrow in the figure shows that the MIB table pointed from contains
   a reference to the MIB table pointed to."

**) 6.1. Example Use of the LSR MIB Module

Even if the LSR MIB is able to be used to configure P2MP,
SHOULD it be used?
What is the benefit of doing so?
Are networks really doing this?

My concern is that it is far easier to document one way of configuring a 
feature
and supporting this way through the standards process than to put forth
a secondary way to configure.  So unless there is truly a compelling reason,
why do this?

If you want to proceed with the LSR MIB being used for p2mp,
then you need to show an example of how to
configure this.  Order of the configuration seems
critical, and that needs to be explained.

MIB MODULE
-----------------

*) General comment:  The REFERENCE clauses are helpful, but
would also be good to be more specific and denote relevant sections
in addition to the specification.

*) General comment:  InetAddressType and InetAddress need
to be re-examined.  These should be specified in the
Conformance section, not in the objects.

*)   mplsTeP2mpTunnelTotalMaxHops OBJECT-TYPE

So does this object specify all hops on all the branches?
It needs to be the same or larger than mplsTunnelMaxHops,
right?

*) mplsTeP2mpTunnelIsP2MP

If the row exists in this table, doesn't that mean that
the tunnel is p2mp?

In other words, is it really possible for this object to
be false(2)?

*) mplsTeP2mpTunnelSubGroupOriginType and
   mplsTeP2mpTunnelSubGroupOrigin
      SYNTAX        InetAddress (SIZE (1..16))

These should be limited in the conformance section
rather than here.  Also, the InetAddress may have a length
zero if the Type is unknown(0), so the following
needs to be restated:
            "At an ingress LSR this object is not used because there is
            no received Path message. mplsTeP2mpTunnelSubGroupOriginType
            should return unknown(0), and this object should return the
            value 0x00, or should be absent."

*)
   mplsTeP2mpTunnelDestTable OBJECT-TYPE
   mplsTeP2mpTunnelDestEntry OBJECT-TYPE

Contain the same paragraph:

            Entries in this table share some index fields with the
            mplsTeP2mpTunnelTable and the mplsTunnelTable in
            MPLS-TE-STD-MIB. Entries in this table have no meaning
            unless there is a corresponding entry in
            mplsTeP2mpTunnelTable (which, itself, depends on a
            corresponding entry in mplsTunnelTable) and that entry has
            mpl2P2mpTunnelIsP2mp set to true(1)."

It could probably be removed from the table's DESCRIPTION clause.

*)    mplsTeP2mpTunnelSubGroupIDNext OBJECT-TYPE

Where is the IndexInteger for this object?

*)    mplsTeP2mpTunnelDestSubGroupID OBJECT-TYPE
This should have SYNTAX of IndexInteger.

*)    mplsTeP2mpTunnelBranchPerfBranch OBJECT-TYPE

            the tunnel. If MPLS-LSR-STD-MIB is implemented, this object
            should contain a row pointer to the out-segment for this
            branch. Under all circumstances, this object should contain

What is meant by row pointer?

*)    mplsTeP2mpTunnelNotificationEnable OBJECT-TYPE

Can RFC3413 be used instead?

*)   With regard to the notifications, will there be a
huge amount of notifications generated when a tunnel goes
down branches?

Should there be some words of caution to this effect?

*) Conformance

This section needs work, but you probably know this already :)
Missing a read-only compliance
and also need to specify details of InetAddressType and InetAddress
in this section.

*) Why is RFC4461 in the informative section?  Would think this should
be in the Normative.

*) References
NIT: RFC4461, need a space.

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 16 Apr 2007 20:59:33 -0400

Hello,

Just wanted to update with the feedback from the
MIB Dr. about section "4.2 Use of MPLS-TE-STD-MIB".

There was concern that using the same Objects with updates from
MPLS-TE-STD-MIB would result in a backwards compatibility
issue.  (If the situation came about that there were devices that supported
the original version of the MPLS-TE-STD-MIB and a newer version, then
the interpretation of these objects might be confused.
The suggestion was to create new objects in this MIB.
Also, it would be necessary to include in the conformance section
of the MIB what objects from MPLS-TE-STD-MIB need to
be supported.  Please disregard what is written below for
**4.2 Use of MPLS-TE-STD-MIB and consider this suggestion.

Thanks,
  Joan

----- Original Message ----- 
From: "Joan Cucchiara" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Loa Andersson" 
<[email-masked]>; "Joan Cucchiara" <[email-masked]>; <[email-masked]>
Sent: Friday, April 06, 2007 12:14 PM
Subject: Early MIB Dr. review of draft-ietf-mpls-p2mp-te-mib-03.txt