Re: [mpls] [MIB-DOCTORS] MIB Doctor review ofdraft-ietf-mpls-fastreroute-mib-09.txt

[Thomas Nadeau <[e-mail]>]

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

Sent from my cracked/hacked/unlocked iPhone!

On Jul 28, 2008, at 6:14 AM, "Romascanu, Dan (Dan)"  
<[e-mail]> wrote:

> Joan,
>
> Thank you for the review.
>
> Dan
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Joan Cucchiara
>> Sent: Monday, July 28, 2008 8:20 AM
>> To: Thomas D. Nadeau; Agrahara S Kiran Koushik
>> Cc: Swallow George; [e-mail]; 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
>>
>> ---
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>
>
_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls