Subject: RE: Additional comments on the LSR MIB

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 05 Apr 2000 16:17:26 -0400

Hi,

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

         The labelstack table is optional in the LSR MIB. It
is not specified in the conformance statement.

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

         Fixed.

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

         The tSpec table is not mandatory in the LSR MIB.

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

         We patterned this after how it is implemented in the
AToM MIB. In that MIB it is widely accepted that this value
may or may not reflect that actual value, but just the
configured value. Furthermore, if you wish to incorporate
more sophisticated TSpec functionality, we have agreed in
an earlier thread to provide a RowPointer such that you may
point this to an external TSpec which may suit your
implementation's needs more closely.

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

         It really depends on the implementation. Those objects
were designed to allow the maximum amount of flexibility
for the implementation. For example, one implementation may
allow different in/out segment bw configurations and will mark
traffic in-coming on higher-bw in-segments before forwarding
to lower-bw out-segments. On the other hand, some implementations
may choose to drop those packets and not forward them at all.
This is why we do not want to be more specify here.

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

         I changed the description to the following:

         "Write access is not required.  A value of other(0) should be
supported because there may be cases where the agent may not know about
or support any of the other address types."

         --Tom

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