[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: review of draft-ietf-ccamp-lsr-mib-08.txt
Hi Adrian,
Thank you for your quick response.
Few comments inline.
thanks, Joan
----- Original Message -----
From: Adrian Farrel <adrian@olddog.co.uk>
To: <jcucchiara@mindspring.com>; Thomas D. Nadeau <tnadeau@cisco.com>;
<ccamp@ops.ietf.org>
Cc: Wijnen, Bert (Bert) <bwijnen@lucent.com>; <jcucchiara@mindspring.com>
Sent: Wednesday, September 28, 2005 9:16 AM
Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt
> 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.
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.
>
> > 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.
>
okay.
> > > >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?
>
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.
> > > >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.
Thank you.
>
> > > >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).
>
Thank you.
> > > >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.
Opps, sorry. I misread your response. I'm fine with the original
description.
> 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.
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.
>
> > > >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.
>
>
>
>