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

["Adrian Farrel" <adrian@olddog.co.uk>]

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

A few responses in the snipped email below.

Cheers,
Adrian


> > >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."
>
> 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).

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.

> 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?

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.

> > >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).
>
> 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?

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?

> > >23)   gmplsOutSegmentEntry  OBJECT-TYPE
> > >Same comments as with gmplsInSegmentEntry
> >
> > Nack
> > Same answer
>
> Think you mean ack here?

Oops, yes.

> > >Section 8.  GMPLS-LABEL-STD-MIB
> > >===================================
>
> > >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".
>
> Yes, please.
>
> > Note, we should change this to say "MIB modules"
> >
>
> good.
>
> > 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.
> >
>
> It would be nice if you could add the above 2 paragraphs to the
> DESCRIPTION.

OK, will do.

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

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

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

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?

> > > 35)   gmplsLabelIndex OBJECT-TYPE
> > >       SYNTAX        Unsigned32 (0..4294967295)
>
> > >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.
>
> 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.

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.

> > >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?
> >
>
> Please refer to Bert's comments on this.

Agreed.

> > >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.
>
> Please refer to Bert's comments on this.

Tom says he understands this, and will fix it.