Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-p2mp-te-mib@ietf.org to (None)
2010-03-26
09 (System) State Changes to Dead from AD is watching by system
2010-03-26
09 (System) Document has expired
2010-03-25
09 Ross Callon State Changes to AD is watching from IESG Evaluation::Revised ID Needed by Ross Callon
2009-05-24
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom.
2009-05-07
09 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-05-07
09 Jari Arkko
[Ballot comment]
This specification was far more readable than most other MIBs, because
you included extensive discussion about the structure of the MIB and
examples. …
[Ballot comment]
This specification was far more readable than most other MIBs, because
you included extensive discussion about the structure of the MIB and
examples. Good work!
2009-05-07
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-05-06
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-05-06
09 Tim Polk
[Ballot discuss]
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 …
[Ballot discuss]
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?
2009-05-06
09 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-05-06
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-05-06
09 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-05-06
09 Dan Romascanu
[Ballot comment]
1. Adding optional UNITS clauses to the definition of the objects with Counter32 and Counter64 SYNTAX would be useful.

2. The root is …
[Ballot comment]
1. Adding optional UNITS clauses to the definition of the objects with Counter32 and Counter64 SYNTAX would be useful.

2. The root is this module is not under mib-2 as RECOMMENDED by RFC4181(Guidelines for Authors and Reviewers of MIB Documents), Section 3.5.2. Although the MPLS Working Group decided to root its MIB modules under mplsStdMIB before RFC 4181 was issued, the MIB Doctors recommendation is to revisit this decision for MIB modules published in documents that came after RFC 4181. If this change is made you need to IMPORT mib-2 from SNMPv2-SMI (and remove mplsStdMIB).
2009-05-06
09 Dan Romascanu
[Ballot discuss]
Some of the issues in this DISCUSS have been raised in the past by MIB Doctor Joan Cucchiara who performed an early MIB …
[Ballot discuss]
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).
2009-05-06
09 Dan Romascanu
[Ballot comment]
1. Addng optional UNITS clauses to the definition of the objects with Counter32 and Counter64 SYNTAX would be useful.

2. The root is …
[Ballot comment]
1. Addng optional UNITS clauses to the definition of the objects with Counter32 and Counter64 SYNTAX would be useful.

2. The root is this module is not under mib-2 as RECOMMENDED by RFC4181(Guidelines for Authors and Reviewers of MIB Documents), Section 3.5.2. Although the MPLS Working Group decided to root its MIB modules under mplsStdMIB before RFC 4181 was issued, the MIB Doctors recommendation is to revisit this decision for MIB modules published in documents that came after RFC 4181. If this change is made you need to IMPORT mib-2 from SNMPv2-SMI (and remove mplsStdMIB).
2009-05-06
09 Dan Romascanu
[Ballot discuss]
Some of the issues in this DISCUSS have been raised in the past by MIB Doctor Joan Cucchiara who performed an early MIB …
[Ballot discuss]
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. RFC 4461 seems to have been at the origin of the definition of many of the objects in this MIB module. It also is the first reference for the MIB module. However, this is an Informational RFC and the reference is Informational. It looks like the appropriate way to deal with it would have been to define RFC 4461 as a Normative Reference and excitly mention the downref in the IETF Last Call.

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).
2009-05-05
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-05-05
09 Dan Romascanu [Ballot comment]
1. Addng optional UNITS clauses to the definition of the objects with Counter32 and Counter64 SYNTAX would be useful.
2009-05-05
09 Dan Romascanu
[Ballot discuss]
This is a preliminary DISCUSS, which I may update later. Some of the issues in this DISCUSS have been raised in the past …
[Ballot discuss]
This is a preliminary DISCUSS, which I may update later. 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. Not all her comments and recommendations seem however to have been accepted and included in the subsequent versions of the document.

I appreciate the clarity of the writing of this document. I believe that users will approeciate 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. RFC 4461 seems to have been at the origin of the definition of many of the objects in this MIB module. It also is the first reference for the MIB module. However, this is an Informational RFC and the reference is Informational. It looks like the appropriate way to deal with it would have been to define RFC 4461 as a Normative Reference and excitly mention the downref in the IETF Last Call.

3. 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.

4. The root is this module is not under mib-2 as required by RFC4181(Guidelines for Authors and Reviewers of MIB Documents), Section 3.5.2.
If this change is made you need to IMPORT mib-2 from SNMPv2-SMI (and remove mplsStdMIB).

5. 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.

6. 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).
2009-05-05
09 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-05-04
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-05-04
09 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica
2009-05-01
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-04-20
09 Adrian Farrel [Ballot Position Update] New position, Recuse, has been recorded by Adrian Farrel
2009-04-20
09 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2009-04-20
09 Ross Callon Ballot has been issued by Ross Callon
2009-04-20
09 Ross Callon Created "Approve" ballot
2009-04-20
09 Ross Callon Telechat date was changed to 2009-05-07 from  by Ross Callon
2009-04-20
09 Ross Callon Telechat date was changed to 2009-05-07 from  by Ross Callon
2009-04-20
09 Ross Callon Placed on agenda for telechat - 2009-05-07 by Ross Callon
2009-04-20
09 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2009-04-17
09 (System) New version available: draft-ietf-mpls-p2mp-te-mib-09.txt
2009-04-17
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-04-14
09 Amanda Baber
IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "mib-2.transmission.mplsStdMIB" registry at
http://www.iana.org/assignments/smi-numbers

Decimal Name References
------- ----- ---------- …
IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "mib-2.transmission.mplsStdMIB" registry at
http://www.iana.org/assignments/smi-numbers

Decimal Name References
------- ----- ----------
[tbd] MPLS-TE-P2MP-STD-MIB [RFC-mpls-p2mp-te-mib-08]
2009-04-03
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2009-04-03
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2009-04-03
09 Amy Vezza Last call sent
2009-04-03
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-04-02
09 Ross Callon Last Call was requested by Ross Callon
2009-04-02
09 (System) Ballot writeup text was added
2009-04-02
09 (System) Last call text was added
2009-04-02
09 (System) Ballot approval text was added
2009-04-02
09 Ross Callon State Changes to Last Call Requested from AD Evaluation::AD Followup by Ross Callon
2009-03-08
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-03-08
08 (System) New version available: draft-ietf-mpls-p2mp-te-mib-08.txt
2009-03-02
09 Ross Callon State Changes to AD Evaluation::Revised ID Needed from Publication Requested::Revised ID Needed by Ross Callon
2008-08-14
09 Ross Callon State Changes to Publication Requested::Revised ID Needed from Publication Requested::External Party by Ross Callon
2008-08-07
09 Ross Callon State Changes to Publication Requested::External Party from Publication Requested by Ross Callon
2008-05-30
09 Cindy Morgan
Document: draft-ietf-mpls-p2mp-te-mib-07.txt
Intended status : Standards Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd …
Document: draft-ietf-mpls-p2mp-te-mib-07.txt
Intended status : Standards Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Loa Andersson is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

This document has been reviewed by the MPLS working group.

The document had a thorough "early" MIB Doctor review from Joan
Cucchiara. Joan is a MIB Doctor with considerable MPLS experience. Her
review led to many small updates to the document.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.
No IPR disclosures filed.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

There were no problems with consensus for this document. However,
working group last call was very quiet. This led to the last call being
extended until sufficient reviewers had commented.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

A simple IANA section is present requesting a new OID and pointing to
the suggested place in the tree.

Tags are used to show the RFC Editor where to update the document.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

MIB definitions checked as far as possible.
smilint checking used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.

RFC 3209 defines the RSVP-TE signaling protocol for use in MPLS-TE
networks.

RFC 3812 defines a MIB module to manage and control the operations
of that protocol and the network nodes that implement it,
while RFC 3813 defines a MIB module to model the behavior of an MPLS
Label Switching Router.

RFC 4802 extends the MPLS-TE MIB module for use in GMPLS (RFC 3473)
networks, and RFC 4803 extends the MPLS LSR MIB module for use in
GMPLS networks.

RFC 4461 sets out requirements for extending RSVP-TE to establish point-
to-multipoint (P2MP) Label Switched Paths (LSPs) in MPLS-TE networks.
RFC 4875 defines extensions to RSVP-TE to establish P2MP LSPs in MPLS-TE
networks.

This document defines a portion of the Management Information Base for
use with network management protocols in the Internet community. In
particular, it describes managed objects for P2MP MPLS-based traffic
engineering. The MIB module defined in this document is applicable to
P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC
3812
. It is equally applicable to P2MP Generalized MPLS (GMPLS) in
association with the GMPLS TE MIB module defined in RFC 4802.


>        Working Group Summary
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

Nothing of note.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

This MIB module has not been implemented.

Several key reviewers work at companies where implementation of such a
MIB module is on the roadmap, but where there is no pressing urgency for
implementation.  As such, their reviews have concentrated on whether the
module would be implementable within their existing code structure.
Their reviews led to some changes to the MIB module.

Further key reviewers and authors work at service providers interested
in using a MIB module in their MPLS-TE networks when P2MP is deployed.
They have verified that the MIB module appears to be correctly
structured for ease of use.

"Early" MIB Doctor review was provided by Joan Cucchiara when the I-D
was stable, but several revisions before working group last call. The
review led to an email discussion on the MPLS WG mailing list and
resulted in a number of updates to the document. it is believed that all
issues raised by the MIB Doctor were satisfactorily addressed.
2008-05-30
09 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-04-30
07 (System) New version available: draft-ietf-mpls-p2mp-te-mib-07.txt
2008-02-14
06 (System) New version available: draft-ietf-mpls-p2mp-te-mib-06.txt
2007-09-24
05 (System) New version available: draft-ietf-mpls-p2mp-te-mib-05.txt
2007-07-09
04 (System) New version available: draft-ietf-mpls-p2mp-te-mib-04.txt
2007-02-26
03 (System) New version available: draft-ietf-mpls-p2mp-te-mib-03.txt
2007-02-07
02 (System) New version available: draft-ietf-mpls-p2mp-te-mib-02.txt
2006-11-29
01 (System) New version available: draft-ietf-mpls-p2mp-te-mib-01.txt
2006-09-24
00 (System) New version available: draft-ietf-mpls-p2mp-te-mib-00.txt