Subject: LSR MIB last call comments

From: "Cucchiara, Joan" <[email-masked]>
Date: Mon, 8 May 2000 21:50:48 -0400

Tom, Arun and Cheenu,

The first part of these comments are regarding
changes to the MplsObjectOwner which were made.

The second part of these comments are based on 
comments made during the prior last call.
I was under the impression that we had reached some
agreement but did not see the updates in the latest
version of the MIB.

The third part are comments which are editorial in
nature.

   -Joan

First Part
===========

* MplsObjectOwner TC,

 'crldp' should definitely be added -- it appeared in early
         versions of the MIB, so must have been mistakenly removed.

 'unknown' appears here, it would seem that the agent
           would always know where the data to create a row
           originated from, so am wondering why this was added.  

  I still don't understand why other possibilities
  here such as config file, cli, web-interface, etc. were not
  added for completeness sake.  If there is a reason
  to omit these from the TC then that would be important
  to understand.  What is the reason for singling out
  this particular subset?

Second Part:
===========
* mplsInterfaceTotalBuffer and mplsInterfaceAvailableBuffer

  was expecting that more description for these objects
  would be given (what these values mean with regard to
  an mpls interface).  

  Even a reference would be helpful because the framework
  documents talks about buffering as related to merge issues
  so if this is what is meant, that is not clear from the
  description.

* mplsInterfacePerfEntry AUGMENTS the 
  mplsInterfaceConfEntry.  More description was
  supposed to be given as to counting for
  Interfaces which participate in both the
  perInterface and perPlatform situation.

  For example, you could count these things
  twice (for the situation of the 0 index,
  and for a perInteface non-zero ifIndex), or
  you could count things once and only increment
  one of the row's counters. 

* mplsInSegment Table has no "IndexNext" object and
  one was supposed to be added.

* individual trap/enable objects still appear glumped
  together at the end of the MIB, these were supposed
  to be distributed closer to their relevant objects.

* MIB heirarchy -- there was supposed to be some 
  reorganization so that things would be grouped under
  branches instead of everything appearing under mpslLsrObjects.

Third Part (editorial)
======================

* Section 7.

   "The objects described in Sections 7.3-7.8,
   when considered together, are equivalent to the tables described
   in the MPLS architecture document [MPLSArch], that is, the
   Incoming Label Map (ILM) and the Next Hop Label Forwarding Entry
   (NHLFE) tables."  

   there aren't any ILM or NHLFE tables, so this appears to be
   an outdated reference.

*  mplsLsrMIB MODULE-IDENTITY
   DESCRIPTION
       "This MIB contains managed object definitions for the
        Multiprotocol Label Switching (MPLS) Router as
        defined in: Rosen, E., Viswanathan, A., and R.
        Callon, Multiprotocol Label Switching Architecture,
        Internet Draft <draft-ietf-mpls-arch-06.txt>,
        February 2000."

   * the date of the draft-ietf-mpls-arch-06.txt is
     August 1999.

* Revision History is not in reverse chronological order and it
  should be.

------------------

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 11 May 2000 17:28:46 -0400

Hi Joan,

>First Part

         We thought that the 'ldp' option would cover it. We will
add 'cdldp' as requested as long as there are no objections.

>            originated from, so am wondering why this was added.

         This option was chosen to present the agent with a
reasonable default value, as well as a choice if it did not
want to support this value.

>   added for completeness sake.

         The enumerations have always included 5 catagories:
management (snmp), the signaling protocols (ldp/rsvp),
provisioning (cops), unknown (a reasonable default or a choice
for agents which do not support this object) and other. We think
that the choices that you suggest fall under the "management"
category.

>Second Part:

         These objects are remnants from previous versions
of the MIB. We propose to remove these. If there is no
objection, these will be removed.

>   one of the row's counters.

mplsInterfaceInLabelsUsed OBJECT-TYPE
    SYNTAX        Gauge32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "This value indicates the specific number of labels
         that are in use at this point in time on this
         interface in the incoming direction. If the interface
           participates in the perPlatform label space only,
          then this instance of this object MUST be identical
          with the object instance with index 0. If the interface
          participates in the perInterface label space, then this
          instance of this object MUST only represent the number of
          per-interface labels that are in use at this point in
          time on this interface. "
    ::= { mplsInterfacePerfEntry 1 }

mplsInterfaceFailedLabelLookup OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "This value indicates the number of labeled packets
         that have been received on this interface and were
         discarded because there were no matching entries
         found for them in mplsInSegmentTable. This value always
           MUST count on a per-interface basis regardless of which
         label space the interface participates in."
    ::= { mplsInterfacePerfEntry 4 }

mplsInterfaceOutLabelsUsed OBJECT-TYPE
    SYNTAX        Gauge32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Indicates the number of top-most labels in the
         outgoing label stacks that are in use at this point
         in time on this interface. This value always
           MUST count on a per-interface basis regardless of
          which label space the interface participates in."
    ::= { mplsInterfacePerfEntry 5 }

mplsInterfaceOutFragments OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "This variable indicates the number of outgoing MPLS
         packets that required fragmentation before
         transmission on this interface. This value always
           MUST count on a per-interface basis regardless of which
         label space the interface participates in."
::= { mplsInterfacePerfEntry 8 }

>   one was supposed to be added.

         We removed this object (based on comments from the list)
because it did not make sense in the context of this table.

>   to be distributed closer to their relevant objects.

         We chose to locate these objects close to the
objects which they affected.

>   branches instead of everything appearing under mpslLsrObjects.

         We have followed the hierarchy used in other existing
standard RFC MIBs (1604, 2515, 2496, ...).

>Third Part (editorial)

         We specifically stated that objects _equivalent_ to the
ILM or NHLFE tables exist in this MIB. The section numbers
will be updated to 7.4-7.8.

>    * the date of the draft-ietf-mpls-arch-06.txt is

         We will fix this.

>* Revision History is not in reverse chronological order and it

         Yes, this will be fixed.

         --Tom

---

From: Cheenu Srinivasan <[email-masked]>
Date: Tue, 9 May 2000 14:31:12 -0400

>          There are actually two different ifTypes, one an
> LSP and one for a tunnel interface, both of which have

Tom made a typo - the two ifTypes are one for the MPLS layer (166)
and one for those MPLS tunnels that are to be represented as
interfaces (150).

Cheenu

> different and distinct ifType numbers (166, 150). We will
> add some descriptive text in the next version of the TE MIB
> to illustrate more clearly the fact that a tunnel may or may
> not be an interface.
> 
>          --Tom
> 
> 
> >My doubt is the interface type being "mpls" and "mplsTunnel" 
> different?
> >if so can this be explained.
> >
> >If these are same then the values in the two MIBs are to be synced.
> >
> >thanks in advance
> >with best regards
> >mani
>