Subject: Additional comments on the LSR MIB

From: "Cucchiara, Joan" <[email-masked]>
Date: Mon, 27 Mar 2000 19:00:58 -0500

Hi Tom, Arun and Cheenu,

A few more comments on the LSR MIB.

          -Joan

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

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

* The mplsLabelStackTable should be made optional for LDP LSPs
  which use ATM or FR.  Could this be added in
  the conformance section?

* mplsTSpecIndexNext should start at zero.

* mplsTSpecMeanRate -- what is the agent or mpls
  supposed to do with this value?  

  Is the mean rate for an LSP calculated over time?

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

* Is this table going to be made optional for LDP?

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

  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?

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

* In general, the MIB heirarchy could use some heirarchy :)
  Seems like everything is under 'mplsLsrObjects'.

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

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

      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.

---

From: Arun Viswanathan <[email-masked]>
Date: Mon, 27 Mar 2000 21:18:56 -0800

Joan,

>   the mplsLabelStackIndex is Integer32.  One of

Done.

> * mplsLabelStackIndex should have MAX-ACCESS of 

Will do based on your previous comment.

>   which use ATM or FR.  Could this be added in

It already supports non-stackable environments.

> * mplsTSpecIndexNext should start at zero.

See description of mplsTSpecIndexNext. 

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

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

>   "actual" objects which reflect what the true values

The implication of such things may be platform specific.
 
>   configurable, could you explain why it is needed

Multipoint-to-point LSPs.

>   you would expect the objects to be in the MIB.)

Will consider.

>   Seems like everything is under 'mplsLsrObjects'.

Will fix that.

>   removed from the Conformance section.

If this is the general approach in other MIBs, will do so.

> 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 above already have a MAX-ACCESS of read-only.

-arun

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Tue, 28 Mar 2000 10:27:33 -0500

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

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

> See my comments to your previous set of comments.

Which ones?

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

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

> 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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 28 Mar 2000 16:44:15 -0500

Hi,

>a LabelStack in these cases is misleading.  This

         Are you then advocating making it optional
in the conformance statement?

         With regard to some of your other questions
where you requested that additional text be added to
descriptions, could you please provide the text that
you feel would make the object clearer or better
defined so that we can just look over your
text and decide whether or not it can go in, or
perhaps just tweak the text a bit and then add it?
Otherwise we will change the text, re-publish the
document, and then have to field additional comments.

         I don't like being pedantic, but I am just
trying to get explicit opinions here so that we
can reach a quick and specific consensus on these
last remaining issues. I hope that you
understand. 8)

         --Tom