The MPLS WG Archive

["Cucchiara, Joan" <JCucchiara@Brixnet.com>]

> > 
> > * The mplsLabelStackTable should be made optional for LDP LSPs
> >   which use ATM or FR.  Could this be added in
> >   the conformance section?
> 
> It already supports non-stackable environments.

That is not really the issue, the issue is why does
LDP using ATM or FR need to support this table?

It is some amount of overhead and no help whatsoever
for this case.  Also, the concept of having to support
a LabelStack in these cases is misleading.  This
should be made optional.

> 
> > 
> > * mplsTSpecIndexNext should start at zero.
> 
> See description of mplsTSpecIndexNext. 

DESCRIPTION says:

"...The value 0 indicates that no unassigned entries
are available...."

The SYNTAX clause starts at 1 and it should start at 0.

> 
> > 
> > * mplsTSpecMeanRate -- what is the agent or mpls
> >   supposed to do with this value?  
> > 
> >   Is the mean rate for an LSP calculated over time?
> 
> No. This is one of the tuple for defining a token bucket.
> The agent has to ensure that the specified QoS requirement
> for the LSP is met.
> 
> > 
> > * mplsTSpecMaxRate and mplsTSpecMaxBurstSize:  are
> >   these objects related?  If so, could an explanation
> >   be given of how they are related?  Can the BurstSize
> >   exceed the MaxRate?  What does it mean if this happens?
> 
> See above comments.
> 
> > 
> > * Is this table going to be made optional for LDP?
> 
> See my comments to your previous set of comments.

Which ones?

> 
> > 
> > * Could we have a description of what happens when the
> >   InSegment TSpec values are lower than the OutSegment
> >   TSpec values?  (Seems like there should be some 
> >   co-operation between the objects, or at least some
> >   "actual" objects which reflect what the true values
> >   are.) 
> 
> The implication of such things may be platform specific.

I completely agree which is why I suggest adding "actual"
objects to see what the "real" values are.

Just because something is configured does not mean that
those are the actual rates/burst size.

>  
> > 
> >   Why does one need to specify the TSpec for the
> >   InSegment?  It would seem that the OutSegment is 
> >   relevant and that the InSegment is not really
> >   configurable, could you explain why it is needed
> >   for the InSegment?
> 
> Multipoint-to-point LSPs.

That still doesn't explain what it means to configure
values for an InSegment and how it relates to the OutSegment
which could have different (i.e. higher values).

Could an explanation be added for the situations where the
OutSegment is lower than the InSegment and vice versa?

> 
> > 
> > * Could the individual trap enable/disable objects be placed near
> >   their respective information?  (NOTE:  they are grouped
> >   differently in the conformance section which is more where
> >   you would expect the objects to be in the MIB.)
> 
> Will consider.
> 
> > 
> > * In general, the MIB heirarchy could use some heirarchy :)
> >   Seems like everything is under 'mplsLsrObjects'.
> 
> Will fix that.
> 
> > 
> > * In general, the Index objects which have MIN-ACCESS of read-only
> >   should be fixed in the mib to have not-accessible access and
> >   removed from the Conformance section.
> 
> If this is the general approach in other MIBs, will do so.
> 
> > 
> > * The conformance information for the following object
> >   is worrisome because it is not clear under which circumstances
> >   one would not support all the enums.
> > 
> >       OBJECT      mplsInSegmentAddrFamily
> >       SYNTAX      INTEGER { other(0) }
> >       MIN-ACCESS  read-only
> >       DESCRIPTION
> >           "Write access is not required.  A value of
> >            other(0) should be supported."
> > 
> > If the agent can't tell or doesn't know what the Address Family
> > is, then how are all the counters effected (specifically
> > packet and octet counters) that are related to this
> > InSegment on an MPLS Interface?  
> 
> Addr family if for the MPLS payload. Counters are for MPLS 'frames'.
> MPLS counters may go up independent of payload type.

The only time that other(0) would be valid is when the
value is not one of the other AddressFamily types.  The
way this Conformance Info is written leads me to believe
that "other" is being used to mean something different.

What does the value of "other" in this context mean?

Thanks, Joan



> 
> > 
> >       OBJECT mplsOutSegmentIndexNext
> >       MIN-ACCESS    read-only
> >       DESCRIPTION
> >           "Write access is not required."
> > 
> >       OBJECT mplsXCIndexNext
> >       MIN-ACCESS    read-only
> >       DESCRIPTION
> >           "Write access is not required."
> > 
> >       OBJECT mplsXCLabelStackIndexNext
> >       MIN-ACCESS    read-only
> >       DESCRIPTION
> >           "Write access is not required."
> > 
> > The above already have a MAX-ACCESS of read-only.
> > 
> > 
> 
> 
> -arun
>