The MPLS WG Archive

[Joan Cucchiara <JCucchiara@Brixnet.com>]

Hi Tom, Arun and Cheenu,

I have read over most of the LSR MIB as you requested 
and as you probably expect, have some comments and questions.  

-Joan


Editorial
---------

* needs a table of contents

* would be nice to have a revisions section to
  track changes between versions, since this 
  has already been done on the email list, adding
  it to the document should be trivial.

* It seems that many tables in this MIB were gleaned
  from the ATM MIB, specifically the mplsInterfaceConfTable
  and the Cross Connect Tables.  Could you add a
  reference to the ATM MIB in the Reference Section?



General MIB Comments
--------------------

*  InterfaceIndex: understanding which InterfaceIndex
   is being used is sometimes unclear.  Since
   this MIB handles all MPLS protocols,
   the use of which InterfaceIndex and its
   corresponding ifType and thus an indication of
   where it would appear in the ifStackTable should 
   be clear, especially because many objects such
   as InPacket, InDiscards, AdminStatus, OperStatus, etc
   seem to me to potentially overlap with what is
   in the ifTable and ifXTable for ifType mpls.
   More description upfront would help with this.

* StorageType objects need to be added throughout
  various tables.



FRONT SECTION
-------------

* Sections 8.0 'Application of the Interface Group to MPLS'
  and 8.1 'Suport of the MPLS Layer by ifTable'

  "...Thus, the MPLS layer interface is represented as an entry in 
   the ifTable.  This entry is concerned with the MPLS layer
   as a whole, and not with individual LSPs/tunnels which are 
   managed via the MPLS-specific managed objects specified in this
   memo and in [TEMIB]."  

   I am confused by these statements.  There is as of yet, no
   concept of an MPLS Layer other than as outlined in the 
   architecture specification which talks about a shim layer.

   Is this the mpls shim layer (i.e. the layer where label
   stacking takes place) or something else?

MIB
---
* Revision history is incorrect.  The 
  initial revision in June 1999.

* ifIndex is not a textual convention

* Last Updated clause is incorrect.  The last
  update should match the latest revision date
  and these do not match.

* MplsLsrIANAAddrFamily needs to be removed.
  The AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB
  should be imported.  See RFC2677 or LDP MIB.

* MplsLabel needs to be updated to reflect the FRF decision
  to drop 17-bit DLCI support.  Also, missing REFERENCE for
  'MPLS using LDP and ATM VC Switching', draft-ietf-mpls-atm-02.txt.
   (the LDP MIB has updated this and it would be good if we
   could agree on a single definition for this TC.)

* IpV6Address -- ref.  draft-ops-endpoint-mib-07.txt
  Could you use similar IPv6 TCs as defined
  in the draft-ops-endpoint-mib-07.txt MIB?  
  e.g. InetAddressIPv6 OCTET STRING (SIZE(16|20))

*  In the MplsInterfaceConfTable a zero index for 
   mplsInterfaceConfIndex indicates that this entry
   represents a global label space.  There can also
   be only one entry in the table which 
   contains a zero value for this index, correct? 

*  Does the 'mplsInterfaceIsLocalLabelSpace' indicate
   per interface label space only? 

   I am confused why you need this object, it would
   seem that if the value of mplsInterfaceConfIndex is
   non-zero then this means that it is a per Interface
   label space, and that the 'mplsInterfaceIsGlobalLabelSpace'
   would indicate if it is participating in a global Label Space
   also.

   Could a REFERENCE clause labels which are considered
   both per interface and per platform be added to the
   LocalLabelSpace Object?

*  Not sure that I understand the use of the MIN and MAX 
   IN/OUT labels.  How does this relate to LDP which uses
   an ATM-type interface (and thus has a bunch of label ranges)?
 
   Are these MIN/MAX values a proper superset of label ranges
   on a per interface label space?

*  Total and Available Buffer.  What is it that is supposed
   to be learned from these values? 


* mplsInterfaceAdminStatus and mplsInterfaceOperStatus
  why are these necessary?  It seems like ifAdminStatus
  and ifOperStatus should be used for this.


*  mplsInterfacePerfEntry is said to Augment the 
   mplsInterfaceConfEntry, what happens for the
   situation when 'mplsInterfaceConfIndex' is zero?
   
   How are the values in this table counted when a label
   participates in both the global and local label spaces?

   Also, it seems that some of these overlap with
   ifTable (specifically, mplsInterfaceInPackets, 
   mplsInterfaceInDiscards, mplsInterfaceOutPackets,
   mplsInterfaceOutDiscards), maybe I am missing something
   here, but on an mplsInterface, I would assume that the
   ifTable and ifXTable would be counting Octets and Packets
   which are in essence MPLS Octets and Packets.

   Could you add in the description something
   which would differentiate these from the ifTable and 
   ifXTable at the mpls layer?   

   (Aside:  because the front section of the document 
    includes how to interpret the ifTable and ifXTable
    objects, I am under the assumption that these things
    are being counted in those tables and not here....)

* mplsInSegmentTable has no "IndexNext" object.
  Could one be added?

* mplsInSegmentIfIndex  type in Sequence doesn't match
  Object's type.

  Also this should be not-accessible.  Currently, it is
  read-create.  What is the ifType of this index?  
  Is this the same as the index used in the mplsInterfaceConfEntry
  for the label related to this entry?

  Could more description be added to this index?

* mplsInSegmentAddrFamily needs to use the
  IANA-ADDRESS-FAMILY-NUMBER-MIB's AddressFamilyNumbers TC.
  Reference is incorrect on this also.

* mplsInSegmentXCIndex description is incorrect.  A value
  of zero could certainly indicates a valid cross connect.
  The XC table does model XCs even for terminating InSegments
  and Originating OutSegments.

  The syntax clause should be changed in either this
  table or in the XC table since the syntax should be
  the same in both places.

* mplsInSegmentTSpecIndex -- this object needs to be made
  optional for LDP.

* mplsInSegmentOwner -- could this be removed from the
  table.  

  These object are of little value in my opinion because
  who really cares how the row got created?

  Also, if you have snmp and policyAgent, then you should
  add cli, config file, web, etc....

  Just seems to be a big rat hole in my opinion.

* mplsOutSegmentIndexNext object range should start at 0 (zero).

* mplsOutSegmentEntry is incorrect and should say 'outgoing'
  in place of incoming which I think someone else mentioned
  already.

  Also REF clause should be updated

* mplsOutSegmentIfIndex should be not-accessible

* mplsOutSegmentPushTopLabel's description is 
  somewhat misleading with regard to the current
  version of LDP.  In the case of LDP using ATM, the
  idea of a label popping does not apply.  So it's
  misleading to say, it does not support pop-and-go.
  It does not support label popping at all.

  Could you rephrase this section to specifically
  call out that for Version 1 of LDP using ATM or FR this should
  be set to true and Reference Section 5. of the LDP Spec?

* mplsOutSegmentTopLabel
 
  Could this object be changed to contain the value of
  the top label on egress?  I think it would be
  much more interesting to point to the egress label
  especially since the prior object (mplsOutSegmentPushTopLabel)
  tells whether or not this was pushed.

* mplsOutSegmentNextHopIpAddrType should use similar
  TC's as defined in draft-ops-endpoint-mib-07.txt

  Also, I have a question on this description:  What is
  meant by the outgoing interface being point-to-point in
  the case of LDP using ATM?

* mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr
  these should be combined, and should also use the relevant
  TC in draft-ops-endpoint-mib-07.txt

* mplsXCIndexNext object's range should start at 0.

* INDEX clause and description of the entry:

  The description redefines what a values of zero means
  for the mplsInSegmentIfIndex and mplsInSegmentLabel;
  in the mplsInSegmentTable they mean one thing, 
  and yet, they mean something  else in the XC table.  

  Could this be clarified?  

* mplsXCIndex should be not-accessible

* mplsXCCOS, should this object be made optional for
  LDP? 

* mplsXCIsPersistent should have SYNTAX of StorageType

* mplsXCOwner same comment as before, big rat hole, could
  we get rid of this object?

*  What do the AdminStatus and OperStatus objects mean when
   the LSP is terminating or Originating for this entry?

--