The MPLS WG Archive

[Arun Viswanathan <arun@force10networks.com>]

Joan,

> * mplsLabelStackIndexNext is an Unsigned32 and
>   the mplsLabelStackIndex is Integer32.  One of
>   these should be changed.

Done.

> 
> * mplsLabelStackIndex should have MAX-ACCESS of 
>   not-accessible.

Will do based on your previous comment.

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

> 
> * mplsTSpecIndexNext should start at zero.

See description of mplsTSpecIndexNext. 

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

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

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

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