Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module
draft-ietf-mpls-p2mp-te-mib-09

Some of the issues in this DISCUSS have been raised in the past by MIB Doctor Joan Cucchiara who performed an early MIB Doctor review on the document. Although part of her comments and recommendations were accepted and included in the subsequent versions of the document, a few key ones have been left out.  

I appreciate the clarity of the writing of this document. I believe that users will also appreciate the detailed examples which make the document very useful and ease the understanding of a rather complex technical material. 

1. The MIB module does not compile clean. Although the majority of the issues are in the MODULE-COMPLIANCE clauses, these need to be fixed and clrified.

smicngPRO gives the following output:

E: f(MPLS-TE-P2MP-STD-MIB.my), (532,35) Subtype size/range is not compatible with base size/range
E: f(MPLS-TE-P2MP-STD-MIB.my), (449,16) Index item "mplsTeP2mpTunnelDestSrcSubGroupID" must be defined with syntax that includes a range
E: f(MPLS-TE-P2MP-STD-MIB.my), (1261,10) Item "mplsTeP2mpTunnelDestSrcSubGroupOriginType" in object-group "mplsTeP2mpGeneralGroup" has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1262,10) Item "mplsTeP2mpTunnelDestSrcSubGroupOrigin" in object-group "mplsTeP2mpGeneralGroup" has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1263,10) Item "mplsTeP2mpTunnelDestSrcSubGroupID" in object-group "mplsTeP2mpGeneralGroup" 
has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1264,10) Item "mplsTeP2mpTunnelDestSubGroupOriginType" in object-group "mplsTeP2mpGeneralGroup" has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1265,10) Item "mplsTeP2mpTunnelDestSubGroupOrigin" in object-group "mplsTeP2mpGeneralGroup" has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1266,10) Item "mplsTeP2mpTunnelDestSubGroupID" in object-group "mplsTeP2mpGeneralGroup" 
has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1267,10) Item "mplsTeP2mpTunnelDestDestinationType" in object-group "mplsTeP2mpGeneralGroup" has access of "not-accessible"
E: f(MPLS-TE-P2MP-STD-MIB.my), (1268,10) Item "mplsTeP2mpTunnelDestDestination" in object-group "mplsTeP2mpGeneralGroup" 
has access of "not-accessible"
W: f(MPLS-TE-P2MP-STD-MIB.my), (1205,19) MIN-ACCESS value identical to access specified for "mplsTeP2mpTunnelP2mpXcIndex"


smiLint gives:

Severity level requested: 6

Line  Severity  Problem
1250 3 node `mplsTeP2mpTunnelDestSrcSubGroupOriginType' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestSrcSubGroupOrigin' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestSrcSubGroupID' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestSubGroupOriginType' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestSubGroupOrigin' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestSubGroupID' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestDestinationType' is an invalid member of group `mplsTeP2mpGeneralGroup'
        3 node `mplsTeP2mpTunnelDestDestination' is an invalid member of group `mplsTeP2mpGeneralGroup'

2. Although the MIB module is in tight coupling with the MPLS-TE-STD-MIB defined in [RFC3812] and the MPLS-LSR-STD-MIB defined in [RFC3813] some tables being actually an extension of the tables in these two MIB modules, none of these are mentioned in the MODULE-COMPLIANCE. 

3. top-level OID structure is not as recommended by rfc4181.txt (Guidelines for Authors and Reviewers of MIB Documents), Appendix D: Suggested OID Layout

         xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)


The MPLS-TE-P2MP-STD-MIB has:

   mplsTeP2mpStdMIB
   |
   +-- mplsTeP2mpNotifications OBJECT IDENTIFIER ::= { mplsTeP2mpStdMIB 0 }
   +-- mplsTeP2mpScalers       OBJECT IDENTIFIER ::= { mplsTeP2mpStdMIB 1 }
   +-- mplsTeP2mpObjects       OBJECT IDENTIFIER ::= { mplsTeP2mpStdMIB 2 }
   +-- mplsTeP2mpConformance   OBJECT IDENTIFIER ::= { mplsTeP2mpStdMIB 3 }
       |
       +-- mplsTeP2mpGroups OBJECT IDENTIFIER ::= { mplsTeP2mpConformance
1 }
       +-- mplsTeP2mpCompliances OBJECT IDENTIFIER ::= { mplsTeP2mpConformance 2 }


Note also, Groups and Compliances are reversed.

4. One concern that discussed at length during the early review is Section 4.2 (and its subsection 4.2.1 and  particularly 4.2.2 regarding settable objects).

The protocol specification for the point-2-multipoint (P2MP) reuses some of the same fields in the point-2-point (P2P) protocol specification.
So in other words, a Session object which was designed for point-2-point
(P2P) now has some of the same fields reused for point-2-multipoint (P2MP). These fields take on different meanings when the protocol is P2MP.

The concern is that this "reuse" in the protocol specification is not practical for MIB objects.  The "reuse" for MIB objects, changes the semantics of the original objects in the MPLS-TE-STD-MIB (rfc3812) which is not allowed by the SMI rules. 

While the authors are very thorough in explanationing what is actually happening with these MIB objects, the MIB objects are in the MPLS-TE-STD-MIB (rfc3812) and the new DESCRIPTIONS appear in this draft (MPLS-TE-P2MP-STD-MIB). The MIB Doctors were consulted via the mib dr email list and a couple of MIB Doctors suggested that new MIB objects be added, as opposed to reusing existing MIB objects. This suggestion was communicated to the authors, but does not appear in this draft.

The description in 4.2.1 and 4.2.2 does not actually cover all possible combinations that may lead to problems. What happens if a 'new' management application deals with 'legacy' agents in the field? What is a 'new' script is run with a mix of 'new' and 'legacy' agents? 

Some of the reused objects are indexes which are used in tables in
rfc3812 (MPLS-TE-STD-MIB).

The MIB Doctor raised the concern that this MIB draft (MPLS-TE-P2MP-STD-MIB) seems to change the semantics of some objects in the MPLS-TE-STD-MIB (RFC3812).

The review of backward compatibility concerns for read operations in Section 4.2.1 determined that a legacy system would not be impacted by the values reported for mplsTunnelXCPointer (0.0),  mplsTunnelHopTableIndex (zero), or mplsTunnelPathInUse (zero).

However, the review of backward compatibility concerns for write operations in Section 4.2.2 notes that a legacy system successfully SET these values.  This was considered acceptable since the values would be ignored by the management agent.

However, this creates a new third state: legacy systems obtain non-zero but incorrect values for mplsTunnelXCPointer,  mplsTunnelHopTableIndex, or mplsTunnelPathInUse.  What are the consequences for this third possibility?