Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Sep 2005 13:55:02 +0100

Hi again Joan,

This is the response to your excellent review of the GMPLS LSR MIB module.

As before, I have indicated Ack or Nack for each point you raised.  Where
there is a Nack I have indicated either our reasoning or a proposed
alternate solution.

Feel free to snip in any response you send.

Once we have closure on a few remaining issues we will respin applying
David's
comments on the TE MIB here as well.

Cheers,
Adrian

>Section 1.1 Migration Strategy
>--------------------------------
>
>1) Does the following statement refer to the
>GMPLS LSR MIB module?
>
>  "The GMPLS Label MIB module may be referenced using a row pointer from
>   objects within the LSR MIB module."
>                     ^^^^
>As previously mentioned, using the entire MIB module name
>would be clearer.

Ack

>Section  4. Outline
>---------------------
>
>2)  Need to clarify the phrase "this MIB module" because
>there are 2 MIB modules in this document.
>
>
> "-  Enabling GMPLS on GMPLS capable interfaces using this MIB module."
>
>(which is referring to the GMPLS-LSR-STD-MIB module??)
>
>...
>
>  "-  Optionally setting up labels in the label table in this MIB module
>      if the textual convention MplsLabel is not capable of holding the
>      required label (for example, if the label requires more than 32
>      bits to encode it), or if the operator wishes to disambiguate
>      GMPLS label types."
>
>The phrase, "in this MIB module", needs to be clarified since there
>are 2 mib modules in this document.  Here, I think you are
>referring to the GMPLS-LABEL-STD-MIB, but prior to this you use
>a similar phrase and are referring the the GMPLS-LSR-STD-MIB.
>Please consistently specify the MIB modules by using their
>names.

Ack.

>3) Please move section, 4.1 MIB Modules to section 1.1, Migration
>Strategy.  There is much overlap in these 2 sections so please
>combine them.

Ack

>Section 4.1.2  Summary of GMPLS Label MIB Module
>-------------------------------------------------
>
>4)      "Generalized Labels can be of variable length and have distinct
>      bit-by-bit interpretations according to the use that is made of
>      them."
>
>Please change the above to:
>
>      "Generalized Labels can be of variable length and have distinct
>      bit-by-bit interpretations depending upon how they are defined
>      by the specific service provider."

Nack.
Nothing to do with the service provider.
Will change to:

      "Generalized Labels can be of variable length and have distinct
      bit-by-bit interpretations depending upon how they are defined
      for the specific technology in which they are used. For example,
      labels used for MPLS packet switching are different in length
      and content from labels used in TDM timeslot switching."

>5) Same section, 4.1.2  Summary of GMPLS Label MIB Module
>
>Please remove this last sentence:
>
>    These tables are described in the subsequent sections.

Ack.

>6) "This MIB module..."
>
>Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module

Ack

>7)  Please specifically call out which term you will be using in
>this document.  Beginning with the 3rd paragraph, there is much
>terminology, so please add some statement such as:
>
>"In this document, the terms 'forward' and 'reverse' will be used.

Ack

>Section 6. Example of LSP Setup
>-------------------------------
>
>8) First and second sentences:
>   "In this section we provide a brief example of using the MIB objects
>   described in sections 7 and 8 to set up an LSP. While this example is
>   not meant to illustrate every nuance of the MIB, it is intended as an
>   aid to understanding some of the key concepts..."
>
>The phrase, "every nuance of the MIB" should probably be
>"every nuance of the MIB modules"  since you are referring to both
>of the MIB modules (sections 7 and 8).

Ack

>9) Typo:  gmplsLableTable

Ack

>10) Typo:   accesible  (in several places)

Ack

>Section 7.  GMPLS-LSR-STD-MIB
>======================
>
>11) smicngpro gives the following:
>
>E: f(GMPLS-LSR-STD-MIB), (315,8) Item "ifGeneralInformationGroup" should
be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (316,8) Item "ifCounterDiscontinuityGroup"
should be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (322,8) Item "mplsInterfaceGroup" should be
IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (323,8) Item "mplsInSegmentGroup" should be
IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (324,8) Item "mplsOutSegmentGroup" should be
IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (325,8) Item "mplsXCGroup" should be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (326,8) Item "mplsPerfGroup" should be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (327,8) Item "mplsLsrNotificationGroup" should
be IMPORTed
>W: f(GMPLS-LSR-STD-MIB), (358,18) For "gmplsOutSegmentTTLDecrement",
syntax is identical
>E: f(GMPLS-LSR-STD-MIB), (378,8) Item "ifGeneralInformationGroup" should
be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (379,8) Item "ifCounterDiscontinuityGroup"
should be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (385,8) Item "mplsInterfaceGroup" should be
IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (386,8) Item "mplsInSegmentGroup" should be
IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (387,8) Item "mplsOutSegmentGroup" should be
IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (388,8) Item "mplsXCGroup" should be IMPORTed
>E: f(GMPLS-LSR-STD-MIB), (389,8) Item "mplsPerfGroup" should be IMPORTed
>W: f(GMPLS-LSR-STD-MIB), (404,14) For "gmplsInterfaceSignalingCaps",
syntax is identical
>W: f(GMPLS-LSR-STD-MIB), (415,18) For "gmplsInterfaceRsvpHelloPeriod",
syntax is identical
>W: f(GMPLS-LSR-STD-MIB), (431,18) For "gmplsInSegmentExtraParamsPtr",
syntax is identical
>W: f(GMPLS-LSR-STD-MIB), (447,18) For "gmplsOutSegmentTTLDecrement",
syntax is identical
>W: f(GMPLS-LSR-STD-MIB), (454,18) For "gmplsOutSegmentExtraParamsPtr",
syntax is identical
>
>
>Please correct the above.
>
>Also, please change the following 2 statements (which appear twice)
>to remove the SYNTAX, since this is redundant, unless there is
>a reason why you prefer to leave it.
>
>     OBJECT      gmplsInSegmentDirection
>     SYNTAX      GmplsSegmentDirection
>     MIN-ACCESS  read-only
>     DESCRIPTION
>       "Write access is not required. Only forward(1) needs to be
>        supported by implementations that only support unidirectional
>        LSPs."
>
>
>     OBJECT      gmplsOutSegmentDirection
>     SYNTAX      GmplsSegmentDirection
>     MIN-ACCESS  read-only
>     DESCRIPTION
>       "Write access is not required. Only forward(1) needs to be
>        supported by implementations that only support unidirectional
>        LSPs."
>
>Compiles cleanly with smilint.

Ack. (I wish smilint caught the other errors.)

>12) DESCRIPTION
>   Please change the first paragraph to (this comment applies to
>   the other MIB modules also.)
>
>             Copyright (C) The Internet Society (2005).  This version of
>             this MIB module is part of RFC XXX; see the RFC itself for
>             full legal notices.

Ack

>13) Change the following:
>
>     GmplsSegmentDirection
>       FROM GMPLS-TC-STD-MIB                             -- GMPLSTCMIB
>                      -- RFC-Editor please resolve the reference above
>
>TO:
>
>     GmplsSegmentDirection
>       FROM GMPLS-TC-STD-MIB                             -- RFCXXXX
>                      -- RFC-Editor please resolve the reference above
>                      -- and remove this note.

Ack

>14) Please remove:
>
>   -- Notifications
>   -- no notifications are currently defined.
>   gmplsLsrNotifications OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 0 }
>
>(You don't need to change any numbering, but no sense defining
>a number you don't need).

Ack

>15) Please remove comments such as (this request is made
>     for all MIB modules in all 3 documents):
>   -- Top level components of this MIB module.
>   -- Tables, Scalars
>   -- Conformance
>   -- GMPLS Interface Table.
>
>   -- End of gmplsInterfaceTable
>
>   -- In-segment table.
>
>etc.

Ack

>16)   gmplsInterfaceEntry OBJECT-TYPE
>
>       "A conceptual row in this table is created automatically by an
>        LSR for every interface capable of supporting GMPLS and which
>        is configured to do so."
>
>Please change first sentence:
>
>       "A conceptual row in this table is created automatically by an
>        LSR when the interface is capable of supporting GMPLS and is
>        correctly configured to do so."

Nack
Agree original is not perfect, but replacement says "the interface"
without
specifying which interface.

Will change to:

       "A conceptual row in this table is created automatically by an
        LSR for each interface that is both capable of supporting
        GMPLS and that is configured to support GMPLS."

>        ....
>
>Please change the first sentence of the last paragraph:
>
>       "The indexing is the same as that for mplsInterfaceTable."
>
>to:
>
>       "The indexing is the same as the mplsInterfaceTable."

Nack.

Will change to:

       "The indexes are the same as for the mplsInterfaceTable."

>17) object:    gmplsInterfaceSignalingCaps OBJECT-TYPE
>
>     SYNTAX  BITS {
>       unknown (0),
>       rsvpGmpls (1),
>       crldpGmpls (2), -- note the use of CR-LDP is deprecated
>       otherGmpls (3)
>     }
>
>
>What is otherGmpls(3)??

Nack

I'm embarrassed to say that there are other "GMPLS" signaling protocol
variants that have been developed outside the IETF. This was added in
response to a WG request.

>Also, this description is confusing.  How can unknown(0) and
>rsvpGmpls(1) be set simultaneously?

Ack
Will add:

    ...but if unknown(0) is set, no other bit may be set.

>Additionally, how can no bits be set?  If this is a GMPLS interface,
>then doesn't one of these bits HAVE to be set?

Ack

As it says...

        Setting no bits implies
        that GMPLS signaling cannot be performed on this interface and
        all LSPs must be manually provisioned or that this table entry
        is only present to supplement an entry in the mplsInterfaceTable
        by providing the information carried in other objects in this
        row.

This means that we should change gmplsInterfaceEntry to read:

       "A conceptual row in this table is created automatically by an
        LSR for each interface that is both capable of supporting
        GMPLS and that is configured to support GMPLS. Note that
        support of GMPLS is not limited to control plane signaling,
        but may include data-plane only function configured through
        SNMP SET commands performed on this MIB module.

        A conceptual row in this table may also be created via SNMP
        SET commands or automatically by the LSR to supplement a
        conceptual row in the mplsInterfaceTable where the interface
        is not capable of GMPLS but where the other objects carried
        in this row provide useful additional information for an
        MPLS interface."

>18)   gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
>       "Period, in milliseconds, between sending RSVP Hello messages on
>        this interface. A value of 0 indicates that no Hello messages
>        should be sent on this interface."
>
>This object is only valid if the gmplsInterfaceSignalingCaps
>object is set to rsvpGmpls.  Please update the description
>to reflect that.

Nack
It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB).

We can add:
       This object is not valid if gmplsInterfaceSignalingCaps is
       set to crldpGmpls (2)

>19)    gmplsInSegmentEntry  OBJECT-TYPE
>       "An entry in this table extends the representation of an incoming
>        segment represented by an entry in mplsInSegmentTable. An entry
>        can be created by a network administrator or an SNMP agent, or a
>        GMPLS signaling protocol.
>
>Please use the phrase:  "via SNMP SET commands to create an entry"
>in place of "SNMP agent".

Ack

>20) same entry, gmplsInSegmentEntry
>
>        Note that the storage type for this entry SHOULD be inherited
>        from the corresponding entry in the mplsInSegmentTable given by
>        the value of the mplsInSegmentStorageType object."
>
>Please change to:
>
>Note that the storage type for this entry is given by the value
>of mplsInSegmentStorageType in the corresponding entry of the
>mplsInSegmentTable.

Ack

>21)    gmplsInSegmentDirection OBJECT-TYPE
>
>Please use "corresponding" instead of "associated"

Ack

>22)    gmplsInSegmentExtraParamsPtr  OBJECT-TYPE
>     SYNTAX       RowPointer
>     MAX-ACCESS   read-create
>     STATUS       current
>     DESCRIPTION
>       "Some Tunnels will run over transports that can usefully support
>        technology-specific additional parameters (for example, SONET
>        resource usage). Such can be supplied from an external table and
>        referenced from here. A value of zeroDotzero in this attribute
>        indicates that there is no such additional information."
>     DEFVAL      { zeroDotZero }
>     ::= { gmplsInSegmentEntry 2 }
>
>What is meant by "external table"?  If this is an enterprise-specific
>table, then is it necessary to have this object in the MIB.  In other
>words, why is this MIB dictating that a row-pointer be used when
>an enterprise-specific MIB may which to simply use indices.
>
>I think this object is unnecessary, but maybe I don't understand
>something.

Nack

rowPointers are typically used when there may be a many-to-one mapping.
This is appropriate for traffic parameters because there may be a few
service
categories defined in a traffic parameters table, and multiple LSPs may
use
those parameters.

Compare with mplsInSegmentTrafficParamPtr in RFC3813.

Now, in this case no such traffic parameters table has been supplied. To
some extent
we are guilty of future-proofing. We are aware that such tables will need
to be
added for TDM (quite soon), for lambda (possibly), and for Ethernet
(almost certainly).

Although it would be possible to leave this out, we feel that the
necessary single-object
extension that would need to be created later would be messy.

>23)   gmplsOutSegmentEntry  OBJECT-TYPE
>Same comments as with gmplsInSegmentEntry

Nack
Same answer

>24)    gmplsOutSegmentDirection OBJECT-TYPE
>Same comment as with gmplsInSegmentDirection

Ack

>25)    gmplsOutSegmentTTLDecrement OBJECT-TYPE
>
>       "This object indicates the amount by which to decrement the TTL
>        of any payload packets forwarded on this segment if per-hop
>        decrementing is being done.
>
>Please change above to:
>
>This object indicates the amount to decrement the TTL...

Nack
If we want to be picky, even Webster doesn't recognise "decrement" as a
verb.
But this is a particularly useful verbization that is is common usage.

But I also believe in the use of prepositions. So no change.

>26)    same object's gmplsOutSegmentTTLDecrement OBJECT-TYPE
>
>        A value of zero indicates that no decrement should be made or
>        that per-hop decrementing is not in force.
>
>Please change:  in force to enforced.

Nack
Will change to "in use"

>27)    gmplsOutSegmentExtraParamsPtr  OBJECT-TYPE
>
>Same comment as with gmplsInSegmentExtraParamsPtr

Nack
Same answer

>28) Compliance Statements
>
>I believe that gmplsInSegmentExtraParamsPtr and
>gmplsOutSegmentExtraParamsPtr do not need to be
>supported, so these maybe should be optional.

Ack

>Section 8.  GMPLS-LABEL-STD-MIB
>===================================
>smicngPRO gives the following:
>
>E: f(GMPLS-LABEL-STD-MIB), (21,13) Module "MPLS-TC-STD-MIB" has already
been specified in IMPORTS clause

Ack

>E: f(GMPLS-LABEL-STD-MIB), (481,12) Group "gmplsLabelTableGroup" is both
a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB"

Ack

>Compiles cleanly with smilint.
>
>Also, disconnect in the numbering of the
>gmplsLabelTable:
>
>   |         \-v-1 gmplsLabelInterface, name "InterfaceIndexOrZero", na,
current
>   |           |-2 gmplsLabelIndex, Unsigned32(0..4294967295), na,
current
>   |           |-3 gmplsLabelSubindex, Unsigned32(0..4294967295), na,
current
>   |           |-4 gmplsLabelType, name "GmplsGeneralizedLabelTypes", rc,
current
>--->  5 is missing

Ack

>29)  DESCRIPTION
>   Please change the first paragraph to (this comment applies to
>   the other MIB modules also.)
>
>             Copyright (C) The Internet Society (2005).  This version of
>             this MIB module is part of RFC XXX; see the RFC itself for
>             full legal notices.

Ack

>30) Please remove these statements (don't need to change any numbers).
>
>   -- Notifications
>   -- no notifications are currently defined.
>   gmplsLabelNotifications  OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 }

Ack

>31)   gmplsLabelTable OBJECT-TYPE
>
>The last part of the last paragraph is awkward:
>
>        "... Labels in the tables in other MIBs are referred to using
>        row pointer into this table. The indexing of this table provides
>        for arbitrary indexing and also for concatenation of labels."
>
>Are you saying that other MIBs can use a row pointer to point to
>this table?  Why would they do that if they could just use the
>indices directly?   Also, I don't follow the comment about
>concatenation of labels.  Could you explain this?

Nack
Yes we are saying that other MIB modules can use a row pointer to
point to this table.
Yes they could use indices. This was the subject of a very lengthy
discussion between the co-authors, etc., but in the end we
observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr
(RFC3813) are rowPointers so we had better support being pointed to.

We could soften the language here by replacing "are" with "may".

Note, we should change this to say "MIB modules"

For an example of label concatenation see RFC3945 section 7.1. In essence,
a GMPLS label may be composite in order to identify a set of resources in
the data plane. Practial examples are timeslots and wavelength sets (which
are not contiguous like wavebands).

The indexing mechanism allows multiple entries in this table to be seen
as a sequence of labels that should be concatenated. Ordering is
potentially
very sensitive for concatenation.

I don't believe we need to add text or references for concatenated labels
since they are part of the architecture.

>32)    gmplsLabelEntry OBJECT-TYPE
>
>The last sentence of the DESCRIPTION, please remove
>the word "more" from the phrase "is more persistent."

Nack.
The Textual Convention gives us degrees. That is, 'readOnly' is more
durable than 'permanent' which is more durable than 'nonNolatile' which
is more durable than 'volatile'.
We need to convey that there is a ranked inheritance.
"Persistence" is acceptable in a comparative.

>I still don't understand how the subindex provides a way
>to concatenate the labels.  Could you give an example?

Nack
If you are asking for an example in the I-D, I don't think it is
necessary.

For your information, the composite label {{A}, {B}, {C}} might be
constructed
as...

gmplsLabelInterface = 1
gmplsLabelIndex     = 1
gmplsLabelSubindex  = 1
gmplsLabelFreeform  = A

gmplsLabelInterface = 1
gmplsLabelIndex     = 1
gmplsLabelSubindex  = 2
gmplsLabelFreeform  = B

gmplsLabelInterface = 1
gmplsLabelIndex     = 1
gmplsLabelSubindex  = 3
gmplsLabelFreeform  = C

>33) please switch RowStatus and StorageType (this will
>more closely match the other MPLS MIBs).

Ack

>34)    gmplsLabelInterface OBJECT-TYPE
>
>DESCRIPTION also needs to specify that zero may be
>used to indicate that the InterfaceIndex is not known
>or that an InterfaceIndex exists but it is not important
>wrt this implementation so zero is used.

Nack
The use of zero is very precisely specified at the moment.
The reasons for setting zero that you cite are:
- the InterfaceIndex is not known
  You cannot have a per-interface label space without knowing the
  interface to which it applies.
- InterfaceIndex exists but it is not important wrt this implementation
  That is exactly the case of the global label space, and is already
  stated.

>35)   gmplsLabelIndex OBJECT-TYPE
>     SYNTAX        Unsigned32 (0..4294967295)
>
>36a) I was expecting the SYNTAX to be IndexInteger due
>to the gmplsLabelIndexNext in the DESCRIPTION.
>Please explain why the use of zero is needed.  You
>explain the use of zero in the gmplsLabelInterface
>and gmplsLabelSubindex indices.

Nack

This is explained by the paragraph:

        Note that implementations that are representing 32 bit labels
        within this table MAY choose to align this index with the value
        of the label, but should be aware of the implications of
        sparsely populated tables.

We believe it would be inappropriate to use IndexInteger to have greater
meaning than just an index.

But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted
paragraph
must allow zero as well.

>36b)Please change the "may" to "should" in this statement:
>        A management application may read the gmplsLabelIndexNext
>        object to find a suitable value for this object."

Nack
Why "should" it do this? This is a convenience offered to it. It may use
any
mechanism it chooses including the one suggested in the quoted paragraph
above.

>37)    gmplsLabelType OBJECT-TYPE
>
>        of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is
>        present, but does not describe whether this is signaled using
>        MPLS or GMPLS.
>
>Is this 23 bit value correct?  Is this a FrameRelay DLCI label?

Ack
This is terrible text!
Yes. 23 bits is FrameRelay.
This text should be much more expansive allowing a 20 bit MPLS label, a 10
or
23 bit FR label, or a 28 bit ATM label. It should also refer to the
gmplsLabelMplsLabel object.

>38)   gmplsLabelRowStatus OBJECT-TYPE
>MUST explain which columns must be properly configured
>before the row can be made active (as per RFC2579)

Ack

>39) Please clarify in the DESCRIPTION of each of
>the following groups, if the group is optional
>or needs to be supported by such implementations:
>     GROUP gmplsLabelPacketGroup
>     DESCRIPTION
>       "This group extends gmplsLabelTableGroup for implementations that
>        support packet labels."
>
>     GROUP gmplsLabelPortWavelengthGroup
>     DESCRIPTION
>       "This group extends gmplsLabelTableGroup for implementations that
>        support port and wavelength labels."
>
>     GROUP gmplsLabelFreeformGroup
>     DESCRIPTION
>       "This group extends gmplsLabelTableGroup for implementations that
>        support freeform labels."
>
>     GROUP gmplsLabelSonetSdhGroup
>     DESCRIPTION
>       "This group extends gmplsLabelTableGroup for implementations that
>        support SONET or SDH labels."
>
>     GROUP gmplsLabelWavebandGroup
>     DESCRIPTION
>       "This group extends gmplsLabelTableGroup for implementations that
>        support Waveband labels."

Ack

>40)   gmplsLabelModuleROCompliance MODULE-COMPLIANCE
>
>Please change the name to: gmplsLabelModuleReadOnlyCompliance
>to be consistent with the other MPLS and GMPLS MIB modules.

Nack
I thought we tried to keep names down to 32 characters. I recall this
conversation before. Not mandatory, but desirable.

A choice between two desires?

>41) The ReadOnly compliance for gmplsLabelRowStatus
>does NOT have a MIN-ACCESS of read-only.  Is this
>intentional?

???
Not sure about this.
I thought the present of a WRITE-SYNTAX made some difference.

>42) Also, (related to the above)
>     OBJECT       gmplsLabelRowStatus
>     SYNTAX       RowStatus {
>       active(1),
>       notInService(2)
>     }
>
>     WRITE-SYNTAX RowStatus {
>       active(1),
>       notInService(2),
>       createAndGo(4),
>       destroy(6)
>     }
>     DESCRIPTION
>       "Support for notInService, createAndWait and notReady is not
>        required."
>
>The DESCRIPTION clause conflicts with the WRITE-SYNTAX.
>Please clarify the intentions for this ReadOnly compliance
>object.

Ack
There is an error here.

>Section 12.2 Informational References
>---------------------------------------
>
>43a) The title of this section should be
>Informative.

Ack/Nack

I am aware of the RFC Editor's preferences.
Unfortunately these references are only informative if you read an
understand them (and
even then not always :-), but they are informational even if you don't
read or
understand them.

>43b) Please move the following from
>Informative to Normative.
>
>   [RFC3471]         Berger, L. (Editor), "Generalized Multi-Protocol
>                     Label Switching (GMPLS) Signaling Functional
>                     Description", RFC 3471, January 2003.
>
>   [RFC3472]         Ashwood-Smith, P., Berger, L. (Editors),
>                     "Generalized MPLS Signaling - CR-LDP Extensions",
>                     RFC 3472, January 2003.
>
>   [RFC3473]         Berger, L. (Editor), "Generalized MPLS Signaling -
>                     RSVP-TE Extensions", RFC 3473 January 2003.
>
>   [GMPLSSonetSDH]   Mannie, E., Papadimitriou, D. (Editors),
>                     "Generalized Multi-Protocol Label Switching
>                     Extensions for SONET and SDH Control",
>                     draft-ietf-ccamp-gmpls-sonet-sdh, work in progress.

Ack.

>43c)  The above reference now appears to be RFC 3946.
>
>Please change the above (NOTE also the changes in the
>reference itself, more on the Reference format next):
>
>   [GMPLS-SONET]   Mannie, E. and D. Papadimitriou, "Generalized Multi-
>                   Protocol Label Switching (GMPLS) Extensions for
>                   Synchronous Optical Network (SONET) and Synchronous
>                   Digital Hierarchy (SDH) Control", RFC 3946, October
>                   2004.

Ack.
My how time flies.

>44) There are a number of references (as discovered by
>Bert) that aren't in the RFC expected format.
>Please review all the references in this document and
>the other GMPLS MIB docs.
>
>Here are some to change. One suggestion is to copy a reference
>(if possible) from an existing RFC.  Sometimes a date is missing
>and sometimes the authors/editors names do not appear as
>expected.  Also, titles need to appear exactly as on
>the RFC.  Please check the other GMPLS docs also.
>(NOTE: see also draft-rfc-editor-rfc2223bis-08.txt)

Ack

>Please change:
>   [RFC2026]         S. Bradner, "The Internet Standards Process --
>                     Revision 3", RFC 2026, October 1996.
>
>to:
>
>   [RFC2026]        Bradner, S., "The Internet Standards Process --
>                    Revision 3," BCP 9, RFC 2026, October 1996.
>
>Please change:
>
>   [RFC2863]         McCloghrie, K. and F. Kastenholtz, "The Interfaces
>                     Group MIB", RFC 2863, June 2000.
>
>to (author name misspelled):
>
>   [RFC2863]   McCloghrie, K. and F. Kastenholz,  "The Interfaces Group
>               MIB", RFC 2863, June 2000.
>
>Please change:
>
>   [RFC3032]         Rosen, E. et al, "MPLS Label Stack Encoding",
>                     RFC 3032, January 2001.
>
>to:
>
>   [RFC3032]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
>               Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
>               Encoding", RFC 3032, January 2001.
>
>
>Please change:
>
>   [RFC3212]         Jamoussi, B., Aboul-Magd, O., Andersson, L.,
>                     Ashwood-Smith, P., Hellstrand, F., Sundell, K.,
>                     Callon, R., Dantu, R., Wu, L., Doolan, P., Worster,
>                     T., Feldman, N., Fredette, A., Girish, M., Gray,
>                     E., Halpern, J., Heinanen, J., Kilty, T., Malis,
>                     A., and P. Vaananen, "Constraint-Based LSP Setup
>                     using LDP", RFC 3212, December 2001."
>
>to:
>
>   [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
>             Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
>             Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
>             Malis,  "Constraint-Based LSP Setup using LDP", RFC 3212,
>             January 2002.
>
>
>Please change:
>
>   [RFC3411]         Harrington, D., Presuhn, R., and B. Wijnen, "An
>                     Architecture for Describing Simple Network
>                     Management Protocol (SNMP) Management Frameworks",
>                     RFC 3411, December 2002.
>
>to:
>   [RFC3411]             Harrington, D., Presuhn, R., and B. Wijnen, "An
>                         Architecture for Describing Simple Network
>                         Management Protocol (SNMP) Management
>                         Frameworks", STD 62, RFC 3411, December 2002.
>
>Please change:
>
>   [RFC3413]         Levi, D., Meyer, P., Stewart, B., "SNMP
>                     Applications", RFC 3413, December 2002.
>to:
>   [RFC3413]   Levi, D., Meyers, P. and B. Stewart, "Simple Network
>               Management Protocol (SNMP) Applications", STD 62, RFC
>               3413, December 2002.
>
>
>Please change:
>   [RFC3443]         Agarwal, P. and Akyol, B., "Time To Live (TTL)
>                     Processing in Multi-Protocol Label Switching
>                     (MPLS) Networks", RFC 3443, January 2003.
>
>to:
>   [RFC3443]         Agarwal, P. and B. Akyol, "Time To Live (TTL)
>                     Processing in Multi-Protocol Label Switching
>                     (MPLS) Networks", RFC 3443, January 2003.
>
>
>Please change:
>   [RFC3471]         Berger, L. (Editor), "Generalized Multi-Protocol
>                     Label Switching (GMPLS) Signaling Functional
>                     Description", RFC 3471, January 2003.
>
>
>to:
>   [RFC3471]        Berger, L., Editor, "Generalized Multi-Protocol
>                    Label Switching (GMPLS) Signaling Functional
>                    Description", RFC 3471, January 2003.
>
>
>Please change:
>
>   [RFC3472]         Ashwood-Smith, P., Berger, L. (Editors),
>                     "Generalized MPLS Signaling - CR-LDP Extensions",
>                     RFC 3472, January 2003.
>
>to:
>   [RFC3472]         Ashwood-Smith, P. and L. Berger, Editors,
>                     "Generalized Multi-Protocol Label
>                     Switching (GMPLS) Signaling Constraint-based
>                     Routed Label Distribution Protocol (CR-LDP)
>                     Extensions", RFC 3472, January 2003.
>
>Please change:
>
>   [RFC3473]         Berger, L. (Editor), "Generalized MPLS Signaling -
>                     RSVP-TE Extensions", RFC 3473 January 2003.
>
>to:
>   [RFC3473]        Berger, L., Editor, "Generalized Multi-Protocol
>                    Label Switching (GMPLS) Signaling - Resource
>                    ReserVation Protocol-Traffic Engineering (RSVP-TE)
>                    Extensions", RFC 3473, January 2003.

Ack

---

From: <[email-masked]>
Date: Tue, 27 Sep 2005 23:14:11 -0400

Hi Adrian,

I have snipped parts where we are in agreement.
Please see inline comments.

  thanks, Joan

----- Original Message -----
From: Adrian Farrel <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 22, 2005 8:55 AM
Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt

>       and content from labels used in TDM timeslot switching."

Good.   Thanks.

>         in this row provide useful additional information for an

If I could ask you to put your chair hat on for a minute, what are the
co-authors doing to get feedback from the MPLS working group on
objects which may apply to MPLS?

Additionally, is this draft going to have a last call in the MPLS working
group?  (maybe this is a question for the ADs).

Also, it seems this object would be more appropriate in the
GMPLS-TE-STD-MIB.   Is there a reason for choosing the
GMPLS-LSR-STD-MIB for this object?

> It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB).

Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB?

I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB,
is that not the case?

> extension that would need to be created later would be messy.

okay.

> >Same comments as with gmplsInSegmentEntry

Think you mean ack here?

> >Same comment as with gmplsInSegmentExtraParamsPtr

okay.

> We could soften the language here by replacing "are" with "may".

Yes, please.

> Note, we should change this to say "MIB modules"

good.

> very sensitive for concatenation.

It would be nice if you could add the above 2 paragraphs to the DESCRIPTION.

> For your information, the composite label {{A}, {B}, {C}} might be

This is a good example and would, I think, be helpful someplace in the
document.  This is only a suggestion however, and not a blocking issue.

>   That is exactly the case of the global label space, and is already

I think you need to list all the reasons under which zero could be a valid
value for this index.  You have listed more above which are not
specified in the description.

> But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted

Yes, it is fine to allow zero, I was just trying to understand when it
should be
zero (under what conditions)?

> mechanism it chooses including the one suggested in the quoted paragraph

Without getting into a debate about tables and indexing, the
should is extremely appropriate.  Think of the case where you have a large
number
of  rows in this table, do you expect a user to try a bunch of numbers to
create a row
even if he/she has access to a CLI, it will  certainly be annoying to have
to page
through this table and get to an available number.

If a user consults the gmplsLabelIndexNext object then creating an entry
should be
easier than not getting the gmplsLabelIndexNext object.

> A choice between two desires?

Please refer to Bert's comments on this.

> I thought the present of a WRITE-SYNTAX made some difference.

Please refer to Bert's comments on this.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Sep 2005 14:16:28 +0100

Again, thanks Joan. I think we are converging quickly.

A few responses in the snipped email below.

Cheers,
Adrian

> Additionally, is this draft going to have a last call in the MPLS
> working group?  (maybe this is a question for the ADs).

We can certainly poll the MPLS WG to see:
a. if there are other attributes that need to be controlled and could be
   added to these modules
b. if there are any further review comments

Since the work form MPLS-TE is split between the MPLS and CCAMP working
groups, it is usually assumed that anyone with an interest in MPLS-TE is
following both working groups. Further, since GMPLS is a superset of
MPLS-TE we can assume that anything that is needed for MPLS-TE is needed
for GMPLS.

But I will send mail, not as a formal last call, but to see if we can
catch any more isues at this time.

> GMPLS-LSR-STD-MIB for this object?

The main reason is that this object desribes the capabilities of an LSR's
interface. Included in this is the possilibity that the LSR does not
support any signaling protocols on the interface but still supports LSPs
(a la PVC). This makes this an LSR-related thing.  Lastly, this object is
part of the gmplsInterfaceTable which is an extension of the
mplsInterfaceTable that appears in RFC3813, the MPLS-LSR-STD-MIB.

> I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB,

Exactly the point.
RFC3812 does not contain per-interface objects. These are in RFC3813 in
the MPLS-LSR-STD-MIB.

You are correct that this object is protocol dependent and would not be
used unless a TE protocol was in use (specifically RSVP-TE) unlike the
previous object. Thus, we could introduce a per-interface table within the
GMPLS-TE-STD-MIB to contain only this object, or we could leave it where
it is with all of the other per-interface objects. Had there been more
similar objects, I think we might have opted for this approach, but for
one object it did not seem worth it.

Do you feel strongly?

> > >Same comments as with gmplsInSegmentEntry

Oops, yes.

> > For an example of label concatenation see RFC3945 section 7.1. In
> > essence, a GMPLS label may be composite in order to identify a set
> > of resources in the data plane. Practial examples are timeslots
> > and wavelength sets (which are not contiguous like wavebands).
> >
> > The indexing mechanism allows multiple entries in this table to be
> > seen as a sequence of labels that should be concatenated. Ordering
> > is potentially very sensitive for concatenation.
> >
>

OK, will do.

> > constructed as...

OK. We'll look at how to include an example in the pre-amble text (not the
Description clasue).

> I think you need to list all the reasons under which zero could be a
> valid value for this index.  You have listed more above which are not

Erm, but of the two reasons given above I have refuted one, and the other
is specified in the descritpion.
I can't think of a meaningful way to change the existing text.
     DESCRIPTION
       "The interface on which this label is used. If the label has or
        could have applicability across the whole system, this object
        SHOULD be set to zero."
Perhaps we can re-order the words...
     DESCRIPTION
       "The interface on which this label is used. If this object is set
         to zero, the label has or could have applicability across the
         whole system and is not limited to a single interface."

Does that help?

> > Why "should" it do this? This is a convenience offered to it. It may
> > use any mechanism it chooses including the one suggested in the
> > quoted paragraph above.
>
> should is extremely appropriate.  Think of the case where you have a
> large number of rows in this table, do you expect a user to try a
> bunch of numbers to create a row even if he/she has access to a CLI,
> it will  certainly be annoying to have to page through this table
> and get to an available number.
>
> If a user consults the gmplsLabelIndexNext object then creating an
> entry should be easier than not getting the gmplsLabelIndexNext
> object.

And if the implementation is using correlation of gmplsLabelIndex
with the actual label ("Note that implementations that are
representing 32 bit labels within this table MAY choose to align
this index with the value of the label, but should be aware of the
implications of sparsely populated tables.") then the use of
gmplsLabelIndexNext would be completely inapproproriate because the
correct value (dependent on the label actually assigned in hardware)
comes from a different source.

The use of "should" would curtail (a.k.a. break :-) this function.

> Please refer to Bert's comments on this.

Agreed.

> Please refer to Bert's comments on this.

Tom says he understands this, and will fix it.

---

From: <[email-masked]>
Date: Thu, 29 Sep 2005 21:07:55 -0400

Hi Adrian,

Thank you for your quick response.
Few comments inline.

thanks, Joan

----- Original Message -----
From: Adrian Farrel <[email-masked]>
To: <[email-masked]>; Thomas D. Nadeau <[email-masked]>;
<[email-masked]>
Cc: Wijnen, Bert (Bert) <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 28, 2005 9:16 AM
Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt

> catch any more isues at this time.

Thank you.    I meant to suggest also sending email to the MPLS working
group
when these set of documents go to last call in the CCAMP working group.
Sorry if that was not clear.

okay.

> one object it did not seem worth it.

Okay to leave where it is.

Regarding MPLS objects in this and the GMPLS-TE-STD-MIB, I have
consulted other MIB Doctors and one suggestion was made which I would
like to relay, that is:  to create a separate object
group for these MPLS or MPLS TE objects in the Conformance Statements.

An object group for the above object would contain only the one object, and
the description would specify that this object applies to using MPLS
with RSVP-TE.

The benefits of doing this would be that someone reading the MIB module
would
quickly be able to isolate MPLS objects.    As you pointed out,
implementations
will probably migrate certain groups (objects)  before other groups, so this
would
probably help in making the decision of what object groups to implement
first, second, etc.

> > It would be nice if you could add the above 2 paragraphs to the

Thank you.

> OK. We'll look at how to include an example in the pre-amble text (not the

Thank you.

> is specified in the descritpion.

Opps, sorry.  I misread your response.  I'm fine with the original
description.

> The use of "should" would curtail (a.k.a. break :-) this function.

Okay, I understand this now, you are suggesting 2 different ways to
assign a value for this index.  I would expect that an operator would use
one or the other for the table (not both), right?  If so please modify the
DESCRIPTION
clause to make that clear, i.e. "The following paragraphs describe 2 methods
to assign a
value to this index,  only one of these methods should be used."

Please also add what the value of zero could represent for each method
of assigning indexes, i.e. if using the value of
the label as an index, than the value of zero, represents .....,...
If using the gmplsLabelIndexNext there should be no value of zero (correct?)
because
gmplsLabelIndexNext returns zero to indicate that the table cannot create a
row
at this time.

The use of "may" is fine.