Subject: [MIB-DOCTORS] MIB Doctor review of draft-ietf-mpls-fastreroute-mib-09.txt

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 28 Jul 2008 01:20:23 -0400

Tom, et al.,

A great deal of work went into this latest draft.  Thanks
for that!

The MIB compiler output is given, followed by Overall Comments
and then specific comments.

Thanks,
  Joan

---

SMICNGPRO MIB Compiler Output
=============================
MPLS-FRR-GENERAL-STD-MIB
W: f(MPLS-FRR-GENERAL-STD-MIB), (5,8) "Integer32" imported but not used
W: f(MPLS-FRR-GENERAL-STD-MIB), (6,8) "NOTIFICATION-TYPE" imported but not 
used
W: f(MPLS-FRR-GENERAL-STD-MIB), (9,8) "NOTIFICATION-GROUP" imported but not 
used
W: f(MPLS-FRR-GENERAL-STD-MIB), (11,8) "TruthValue" imported but not used
W: f(MPLS-FRR-GENERAL-STD-MIB), (13,8) "InterfaceIndex" imported but not 
used

MPLS-FRR-ONE2ONE-STD-MIB

E: f(MPLS-FRR-ONE2ONE-STD-MIB), (74,35) Leading sub-Id "mplsOne2OneFrrMIB" 
is not known in current module
E: f(MPLS-FRR-ONE2ONE-STD-MIB), (398,30) Item "mplsFrrScalarGroup" should be 
IMPORTed
E: f(MPLS-FRR-ONE2ONE-STD-MIB), (399,30) Item "mplsFrrTunnelARHopGroup" 
should be IMPORTed
E: f(MPLS-FRR-ONE2ONE-STD-MIB), (400,30) Item "mplsFrrConstraintsGroup" 
should be IMPORTed
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (5,19) "Unsigned32" imported but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,8) "NOTIFICATION-TYPE" imported but not 
used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,27) "Gauge32" imported but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (9,8) "NOTIFICATION-GROUP" imported but not 
used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,20) "RowStatus" imported but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,31) "StorageType" imported but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,8) "InterfaceIndex" imported but not 
used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,24) "InterfaceIndexOrZero" imported but 
not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (14,8) "ifGeneralInformationGroup" imported 
but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" 
imported but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,8) "mplsTunnelGroup" imported but not 
used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,25) "mplsTunnelScalarGroup" imported but 
not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,8) "mplsTunnelARHopListIndex" imported 
but not used
W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,34) "mplsTunnelARHopIndex" imported but 
not used

MPLS-FRR-FACILITY-STD-MIB
E: f(MPLS-FRR-FACILITY-STD-MIB), (497,30) Item "mplsFrrScalarGroup" should 
be IMPORTed
E: f(MPLS-FRR-FACILITY-STD-MIB), (498,30) Item "mplsFrrTunnelARHopGroup" 
should be IMPORTed
E: f(MPLS-FRR-FACILITY-STD-MIB), (499,30) Item "mplsFrrConstraintsGroup" 
should be IMPORTed
W: f(MPLS-FRR-FACILITY-STD-MIB), (11,20) "RowStatus" imported but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (11,31) "StorageType" imported but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (13,24) "InterfaceIndexOrZero" imported but 
not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (14,8) "ifGeneralInformationGroup" imported 
but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" 
imported but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (22,8) "MplsTunnelAffinity" imported but 
not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (24,8) "mplsTunnelGroup" imported but not 
used
W: f(MPLS-FRR-FACILITY-STD-MIB), (24,25) "mplsTunnelScalarGroup" imported 
but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (25,8) "mplsTunnelARHopListIndex" imported 
but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (25,34) "mplsTunnelARHopIndex" imported but 
not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (27,8) "InetAddressType" imported but not 
used
W: f(MPLS-FRR-FACILITY-STD-MIB), (27,25) "InetAddress" imported but not used
W: f(MPLS-FRR-FACILITY-STD-MIB), (526,5) OBJECT-GROUP 
"mplsFrrFacilityScalarGroup"
   is not used in a MODULE-COMPLIANCE in current module

SMILINT

  Validation report

    File: MPLS-FRR-GENERAL-STD-MIB
      Severity level requested: 6

Line  Severity  Problem
5  5 warning: identifier `Integer32' imported from module`SNMPv2-SMI' is 
never used
6  5 warning: identifier `NOTIFICATION-TYPE' imported from module 
`SNMPv2-SMI' is never used
9  5 warning: identifier `NOTIFICATION-GROUP' imported from module 
`SNMPv2-CONF' is never used
11  5 warning: identifier `TruthValue' imported from module `SNMPv2-TC' is 
never used
13  5 warning: identifier `InterfaceIndex' imported from module `IF-MIB' is 
never used

---

File: MPLS-FRR-FACILITY-STD-MIB
Severity level requested: 6

Line  Severity  Problem
11  5 warning: identifier `RowStatus' imported from module `SNMPv2-TC' is 
never used
11 5 warning: identifier `StorageType' imported from module `SNMPv2-TC' is 
never used
13 5 warning: identifier `InterfaceIndexOrZero' imported from module 
`IF-MIB' is never used
14 5 warning: identifier `ifGeneralInformationGroup' imported from module 
`IF-MIB' is never used
15 5 warning: identifier `ifCounterDiscontinuityGroup' imported from module 
`IF-MIB' is never used
22 5 warning: identifier `MplsTunnelAffinity' imported from module 
`MPLS-TC-STD-MIB' is never used
24 5 warning: identifier `mplsTunnelGroup' imported from module 
`MPLS-TE-STD-MIB' is never used
24 5 warning: identifier `mplsTunnelScalarGroup' imported from module 
`MPLS-TE-STD-MIB' is never used
25 5 warning: identifier `mplsTunnelARHopListIndex' imported from module 
`MPLS-TE-STD-MIB' is never used
25 5 warning: identifier `mplsTunnelARHopIndex' imported from module 
`MPLS-TE-STD-MIB' is never used
27 5 warning: identifier `InetAddressType' imported from module 
`INET-ADDRESS-MIB' is never used
27 5 warning: identifier `InetAddress' imported from module 
`INET-ADDRESS-MIB' is never used
526 5 warning: current group `mplsFrrFacilityScalarGroup' is not referenced 
in this module

--

File: MPLS-FRR-ONE2ONE-STD-MIB
Severity level requested: 6

Line Severity Problem
74    1       unknown object identifier label 'mplsOne2OneFrrMIB'

Overall COMMENTs
---------------

*) One general comment is that the key words from section 1.1
(MUST/MUST NOT/SHOULD, etc.) should be utilized.  I've made
some suggestions in a few places (see below in The "Specific Comments"
area wrt 4.1, 4.1.1, 4.2.1, 4.2) but I did NOT make suggestions for every
section, so please review the other sections.  Basically, you need to
give a clear understanding of which MIB Modules need to be deployed.

*) The first 3 or 4 comments on the MPLS-FRR-GENERAL-STD-MIB also apply to 
the
other 2 MIB Modules but these were not repeated.  Please update all 3 MIB 
Modules.

COMMENTS ON DOC (as they appear in the doc)
---------------------------------------------

*) TOC

Section 4., 4.1, 4.2, 4.3, 4.4 and 4.5
and possibly others are incorrect in the TOC.

4.1.1, 4.1.2, 4.2.1, 4.2.2, 4.3.1,
(maybe others) are missing from the TOC.

Please regenerate the TOC.

*) 4. Overview of MIB Module

s/Module/Modules

Please update the TOC for this new title.

*) 4.1.  MPLS-FRR-GENERAL-STD-MIB

Some verbage needs to be added to
specify if/when this MIB Module MUST/SHOULD
be implemented.

e.g. (this is just an example)
This MIB Module MUST be implemented if either fast
reroute method is supported.

*) 4.1.1  mplsFrrConstraintsTable

(Similar comment to above...need to specify using MUST/SHOULD language
if possible)

So, the last paragraph in this section:

      This table is used at the ingress node of the protected TE
      tunnel instance to configure backup LSP setup constraints.

should be updated (as an example)
      This table MUST (or SHOULD) be implemented at the ingress node of the 
protected TE
      tunnel instance to configure backup LSP setup contraints.

*) 4.2.1 mplsFrrTunnelARHopTable

First sentence need a comma, after "availability",

Last paragraph (similar comment as above, need to use language MUST/SHOULD)

(as an example):
This table MUST be supported when the Record Route Object (RRO) is supported
by the implementation.

*) 4.2 MPLS-FRR-ONE2ONE-STD-MIB

* Please add something like:

  This MIB Module MUST be supported when the one-to-one backup method is 
used.

*) 4.2.1 and 4.2.2

*) I'm a little unclear as to the relationship between these tables
(PLR, Detour and the mplsTunnelTable).

For every protected LSP these could be N-1 detours, and each detour is
a tunnel and thus, there is an entry in the mplsTunnelTable.

Could you explain how one entry in the PLR table (which represents the
protected LSP) could be related to
more than one entry in the Detour table and further, how can I lookup
the Detour in the mplsTunnelTable?

Please give a concrete example using actual values for the indices
(similar to what was done in rfc3812 section 9).  It would be good
if you could do this with one protected LSP and more than one detour.

*) 4.3

*) 4.3.1  mplsFrrFacilityDBTable

*) 5. Handling IPv6 Tunnels

*) Please update the names of the objects to match the current
names in the MIB Modules.

*) 6  MPLS-FRR-GENERAL-STD-MIB

*) LAST-UPDATED and REVISION

s/May/June

*) Please remove the REVISION/DESCRIPTION clauses
except for the latest version of the MIB.  The REVISION
clause is typically used for RFC revisions (not draft
revisions).

*) DESCRIPTION:
...This MIB module is part of RFC 4327;
see the RFC itself for full legal notices.

needs to be changed to something like

                This version of this MIB module is part of RFC xxxx;
                See the RFC itself for full legal notices.

-- RFC EDITOR: please replace xxxx with actual number
-- and remove this note.

*) Please see RFC4181 Appendices C and D.

prefixes need to be consistent, so either use "mplsFrrGeneral" or "mplsFrr"

Also, the OID layout is not as suggested in rfc418 (and also breaks with
the other MPLS which does follow the suggested OID layout.)

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

Currently,

mplsFrrNotifications ::= { mplsFrrGeneralMIB 0 }  <-- there aren't any 
notifications
                                                      so don't need to 
define this

mplsFrrObjects ::= { mplsFrrGeneralMIB 1}
mplsFrrGeneralObjects ::= { mplsFrrObjects 1}
mplsFrrConformance ::= { mplsFrrObjects 2}

*) mplsFrrProtectionMethod Scalar

Please add to the DESCRIPTION the error that would be returned if
unknown(1) were to be set (would think inconsistentValue error?)

For example:

The value of unknown(1) is read-only and cannot be set. If the
value of unknown(1) is set an inconsistentValue error MUST be
returned.

*) NEW for mplsFrrProtectedMethod
Please include in the DESCRIPTION clause what
error should be returned if the value of unknown(1) is
set.

*) mplsFrrSwitchover
Should this be a Gauge32?

DESCRIPTION is awkward.

Seems like you are trying to say the following:

The number of tunnel instances for either detour LSPs or bypass tunnels
for which this LSR is the ingress.

*) mplsFrrConstraintsTable

*) mplsFrrConstraintsEntry

s/however, in these cases,/however,/

*) mplsFrrConstraintsTunnelIndex

s/for which/which/

Don't understand the last part of the last sentence
"as must exist in the mplsTunnelTable". What is it that
must exist in the mplsTunnelTable?

*) mplsFrrConstraintsProtectionType

Could a reference be added for this?

*) mplsFrrConstraintsSetupPrio

Could a more specific section be given
to the REFERENCE?  The reason is that there
is also a SetupPriority in RFC4090 and
this draft discusses supporting rfc4090

*) mplsFrrConstraintsHoldingPrio

Same request as above, for a more specific section
in the REFERENCE?

*) NEW mplsFrrConstraintHopLimit
According to RFC4090 this looks to be a byte, so
why is there not a range on this?

Same question wrt Reference
is this 4090 section 4.1 ?

*) mplsFrrTunnelARHopProtectType

Where is path(0) described in rfc4090?

Would it be possible to rename link to bandwidth to
use the same terms as in 4090?

*) NIT: mplsFrrConstraintsGroup not in the order
they appear in the table.  This is a NIT.

6.1 MPLS-FRR-ONE2ONE-STD-MIB

Scalars need to be updated to reflect that they
are relevant to one-to-one reroute method.

*) mplsFrrOne2OneDetourMergedDetourInst

Please spell out Instance (to be consistent)

6.3 MPLS-FRR-FACILITY-STD-MIB

Scalars need to be updated to be relevant only
to the FRR Facility method.

Think that these scalars should be Gauge32, since
the number of interfaces will be changing.

*) mplsFrrActiveProtectedLSPs (should this be in
the MPLS-FRR-ONE2ONE-STD-MIB?

*) mplsFrrFacilityNotificationsEnabled.
Why is this object needed?

Please answer the question wrt RFC3413.

*) mplsFrrFacilityNotificationsMaxRate
Are there other objects which indicate
if events are being thrown away due to this
throttling?  (Would that be useful?)

NOT DONE.  Please answer the question.  I would
think such an object (or objects) would be useful
information if throttling is done.

*) mplsFrrFacilityDBTable

s/mplsFrrFacilityProtIfIdx/mplsFrrFacilityProtectedIfIndex/

*) mplsFrrFacilityDBNumProtectingTunnelOnIf
s/speficied/specified/

*) mplsFrrFacilityFinalTunnelRestored

Need to remove the verbage about if this is the Facility method
at the end of the DESCRIPTION.

*) 7. Security Considerations

s/in this MIB module./in these MIB modules.

*) 8 IANA Considerations

Need section 8.2 and 8.3 for the other 2 MIB Modules.

*) 10.1 Normative References

    [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC4090,
              May 2005.

and A. Atlas,

-- end--

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 28 Jul 2008 12:14:01 +0200

Joan,

Thank you for the review. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joan Cucchiara
> Sent: Monday, July 28, 2008 8:20 AM
> To: Thomas D. Nadeau; Agrahara S Kiran Koushik
> Cc: Swallow George; [email-masked]; MIB Doctors (E-mail); Loa Andersson
> Subject: [MIB-DOCTORS] MIB Doctor review 
> ofdraft-ietf-mpls-fastreroute-mib-09.txt
> 
> 
> Tom, et al.,
> 
> 
> A great deal of work went into this latest draft.  Thanks for that!
> 
> The MIB compiler output is given, followed by Overall 
> Comments and then specific comments.
> 
> Thanks,
>   Joan
> 
> ---
> 
> 
> W: f(MPLS-FRR-GENERAL-STD-MIB), (6,8) "NOTIFICATION-TYPE" 
> imported but not used
> W: f(MPLS-FRR-GENERAL-STD-MIB), (9,8) "NOTIFICATION-GROUP" 
> imported but not used
> W: f(MPLS-FRR-GENERAL-STD-MIB), (13,8) "InterfaceIndex" 
> imported but not used
> 
> 
> MPLS-FRR-ONE2ONE-STD-MIB
> 
> E: f(MPLS-FRR-ONE2ONE-STD-MIB), (398,30) Item 
> "mplsFrrScalarGroup" should be IMPORTed
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,8) "NOTIFICATION-TYPE" 
> imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (9,8) "NOTIFICATION-GROUP" 
> imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,8) "InterfaceIndex" 
> imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,24) 
> "InterfaceIndexOrZero" imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (14,8) 
> "ifGeneralInformationGroup" imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,8) "mplsTunnelGroup" 
> imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,25) 
> "mplsTunnelScalarGroup" imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,8) 
> "mplsTunnelARHopListIndex" imported but not used
> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,34) 
> "mplsTunnelARHopIndex" imported but not used
> 
> 
> 
> E: f(MPLS-FRR-FACILITY-STD-MIB), (497,30) Item 
> "mplsFrrScalarGroup" should be IMPORTed
> W: f(MPLS-FRR-FACILITY-STD-MIB), (13,24) 
> "InterfaceIndexOrZero" imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (14,8) 
> "ifGeneralInformationGroup" imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (22,8) "MplsTunnelAffinity" 
> imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (24,8) "mplsTunnelGroup" 
> imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (24,25) 
> "mplsTunnelScalarGroup" imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (25,8) 
> "mplsTunnelARHopListIndex" imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (25,34) 
> "mplsTunnelARHopIndex" imported but not used
> W: f(MPLS-FRR-FACILITY-STD-MIB), (27,8) "InetAddressType" 
> imported but not used
> 5  5 warning: identifier `Integer32' imported from 
> module`SNMPv2-SMI' is never used
> 6  5 warning: identifier `NOTIFICATION-TYPE' imported from 
> module `SNMPv2-SMI' is never used
> 9  5 warning: identifier `NOTIFICATION-GROUP' imported from 
> module `SNMPv2-CONF' is never used
> 11  5 warning: identifier `TruthValue' imported from module 
> `SNMPv2-TC' is never used
> 13  5 warning: identifier `InterfaceIndex' imported from 
> module `IF-MIB' is never used
> 
> ---
> 
> 11  5 warning: identifier `RowStatus' imported from module 
> `SNMPv2-TC' is never used
> 11 5 warning: identifier `StorageType' imported from module 
> `SNMPv2-TC' is never used
> 13 5 warning: identifier `InterfaceIndexOrZero' imported from 
> module `IF-MIB' is never used
> 14 5 warning: identifier `ifGeneralInformationGroup' imported 
> from module `IF-MIB' is never used
> 15 5 warning: identifier `ifCounterDiscontinuityGroup' 
> imported from module `IF-MIB' is never used
> 22 5 warning: identifier `MplsTunnelAffinity' imported from 
> module `MPLS-TC-STD-MIB' is never used
> 24 5 warning: identifier `mplsTunnelGroup' imported from 
> module `MPLS-TE-STD-MIB' is never used
> 24 5 warning: identifier `mplsTunnelScalarGroup' imported 
> from module `MPLS-TE-STD-MIB' is never used
> 25 5 warning: identifier `mplsTunnelARHopListIndex' imported 
> from module `MPLS-TE-STD-MIB' is never used
> 25 5 warning: identifier `mplsTunnelARHopIndex' imported from 
> module `MPLS-TE-STD-MIB' is never used
> 27 5 warning: identifier `InetAddressType' imported from 
> module `INET-ADDRESS-MIB' is never used
> 526 5 warning: current group `mplsFrrFacilityScalarGroup' is 
> not referenced in this module
> 
> --
> 
> area wrt 4.1, 4.1.1, 4.2.1, 4.2) but I did NOT make 
> suggestions for every section, so please review the other 
> sections.  Basically, you need to give a clear understanding 
> of which MIB Modules need to be deployed.
> 
> 
> *) The first 3 or 4 comments on the MPLS-FRR-GENERAL-STD-MIB 
> also apply to the other 2 MIB Modules but these were not 
> repeated.  Please update all 3 MIB Modules.
> 
> 
> 
> 
> specify if/when this MIB Module MUST/SHOULD be implemented.
> 
> This MIB Module MUST be implemented if either fast reroute 
> method is supported.
> 
> 
> 
> (Similar comment to above...need to specify using MUST/SHOULD 
> language if possible)
> 
>       This table MUST (or SHOULD) be implemented at the 
> ingress node of the protected TE
>                                                       so 
> don't need to

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 28 Jul 2008 08:49:28 -0400

Sorry foe the mix up compiling. We are working on a revision to fix  
these now.

Sent from my cracked/hacked/unlocked iPhone!