[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: review of draft-ietf-ccamp-lsr-mib-08.txt
Hi Adrian,
I have snipped parts where we are in agreement.
Please see inline comments.
thanks, Joan
----- Original Message -----
From: Adrian Farrel <adrian@olddog.co.uk>
To: <tnadeau@cisco.com>; <ccamp@ops.ietf.org>; <jcucchiara@mindspring.com>
Cc: <bwijnen@lucent.com>; <jcucchiara@mindspring.com>
Sent: Thursday, September 22, 2005 8:55 AM
Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt
> 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 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."
Good. Thanks.
> >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).
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?
>
> >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?
>
> We can add:
> This object is not valid if gmplsInterfaceSignalingCaps is
> set to crldpGmpls (2)
>
>
>
> >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.
okay.
>
> >23) gmplsOutSegmentEntry OBJECT-TYPE
> >Same comments as with gmplsInSegmentEntry
>
> Nack
> Same answer
Think you mean ack here?
>
> >24) gmplsOutSegmentDirection OBJECT-TYPE
> >Same comment as with gmplsInSegmentDirection
>
> Ack
>
> >27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE
> >
> >Same comment as with gmplsInSegmentExtraParamsPtr
>
> Nack
> Same answer
>
okay.
> >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
> >===================================
> >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.
> 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
>
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.
> >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.
>
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.
> >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.
Yes, it is fine to allow zero, I was just trying to understand when it
should be
zero (under what conditions)?
>
> >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.
>
> >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.
> >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.
> >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.
>