Subject: LSR MIB comments and questions

From: Joan Cucchiara <[email-masked]>
Date: Tue, 21 Mar 2000 09:38:01 -0500

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?

--

---

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

Arun,

(bunch of stuff deleted...)

> We meant it to be this way, that is, 0 is not a valid
> XC index. 0 is used to indicate that the XC entries
> have exhausted.

Currently, mplsInSegmentXCIndex has:

SYNTAX  Integer32(1..2147483647)
DESCRIPTION  
   "The index into mplsXCTable is used to identify which
   cross-connect entry this segment is part of.  Note
   that a value of zero indicates that it is not being
   referred to by any cross-connect entry."
DEFVAL {0}

Could this object be made a RowPointer? 

> Is already optional. A value of zero to indicate best effort.
> See description.

Why is it necessary for an LDP only implementation to
support this?

> If you don't want to identify yourself, you can choose the
> 'other' option ;-)
> 
> It is there because folks asked for it. It provides
> tracking for usage information, for troubleshooting,
> and erroneous deletion by somebody how did not create
> it in the first place.

Are you planning on specifying in the enum the
other possibilities (cli, config file, web, etc...)?

Also, why is policyAgent one of the choices, this is 
a MIB and it was my understanding that policyAgent's used
PIBs.  PolicyAgents can't support RowStatus, so I believe
that choice should be removed.

> No. 0 is bad index; is used to identify terminating connections
> in the cross-connect.

The description for this object says:
"If the number of unassigned entries is exhausted, 
this object will take on the value of 0...."

But the SYNTAX starts at 1, I believe that the SYNTAX should
start at 0.

> Evils of cut-and-paste.
> Will be removed and description adjusted.
> 
> > 
> Hmmm..I guess so.
> A label swapping is modelled as a pop followed by a push.
> See mplsInSegmentNPop. The description also talks about
> the ATM case.
> 
> > 
> I don't think we need to specially qualify LDP for this. This
> is common to any protocol on ATM.

I think that if you expect that people support this MIB
for LDP then you should be more accomodating.  I'm only
asking for a clarifying description and reference to be
added.

> Hmm..I guess I don't understand the comment. 
> It already is what you are asking it to be.

Sorry, my mistake.  I think the name confused me,
would you consider a name change to mplsOutSegmentLabel?

I know that we discussed this before and the reason
that you gave was that the MIB had been this way since
Feb 1999, but I am still confused as to why you
believe the indexing of this table to be better
than 
(mplsOutSegmentIfIndex, mplsOutSegmentLabel)

Also, this would imply a change to the XC table
as being (mplsInSegmentIfIndex, mplsInSegmentLabel, mplsOutSegmentIfIndex
and mplsOutSegmentLabel).

Something to keep in mind is that the above is more in
line with what is already being done in the internal XC tables,
so forcing another indexing on top of that is somewhat inefficient
for implementations to support.  

Could text be added as to why the present indexing is thought to be
more efficient?

> Done.
> That is, 'none' is not a valid choice for any multi-access network.
> 
> > 
> Yes.
> It is alright the way it is. 0 is reserved to indicate
> "no more cross-connect entries available".

I agree but the SYNTAX clause starts at 1 and should
start at 0. 

> Yes, they are different tables.
> Index zero is valid only for the InSegemntTable.

They may be different tables but they are the same indices,
so they should be used the same everywhere they are referenced.
It is not acceptable to redefine what a value means just because
they are in different tables. 

> Okay.
> Will remove this object based on comments on ML.
> 
> > 
> Okay.
> No, see comments above.

see my comments above also :)

> Admin status is provided to control the cross-connect from
> passing data. Oper status may reflect the overall health of 
> the cross-connect, for example, if the outgoing interface is
> down, then the cross-connect oper status may reflect that.

But what do they mean in the case of a terminating or originating
LSP which is in the XC table?
If AdminStatus is down, what does this imply for a terminating LSP?
Could the description be clarified to call this out, because this
is something which could be interpretted differently by different
vendors and needs to be clarified.

Thanks, Joan

> -arun

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Wed, 29 Mar 2000 10:30:47 -0500

Tom,

> 
> >I also question why this extra variable is required to
> >convey the label space membership attributes.
> >
> >If  mplsInterfaceConfIndex is zero, then it uneqivocally
> >has the attributes 'in global label space' and 'not in
> >local label space'.
> >
> >If mplsInterfaceConfIndex is non-zero, that it uneqivocally
> >has the attribute 'in local label space' and the 'in
> >global label space' variable arbitrates that (optional)
> >attribute.
> 
>          Yes, but there are cases in ATM where an interface needs
> to be part of both label spaces. This is why we have
> provided two separate variables here.

The combination of the index and ONE of these
objects would (I think) allow all combinations.  For example,

mplsInterfaceConfIndex
SYNTAX   InterfaceIndexOrZero
DESCRIPTION
   "...A non-zero index for an entry indicates the ifIndex for
    the corresponding interface entry in (of) the MPLS-layer in
    the ifTable.  Note that the global label space may apply to
    several interfaces, and therefore the configuration of
    the global label space interface parameters will
    apply to all of the interfaces that are participating in
    the global label space."

It has been stated that there will be at most 1 occurance
of mplsInterfaceConfIndex == 0 in this table.

Which means that the entry represents the perPlatform Label Space.

Further, a non-zero value represents the ifIndex (with ifType of
mpls(166)) represents a perInterface Label Space for that
"mpls interface".

Additionally, there are two objects:

mplsInterfaceIsGlobalLabelSpace
SYNTAX  TruthValue
DESCRIPTION
   "This value indicates whether or not this interface
   participates in the global label space."

and 

mplsInterfaceIsLocalLabelSpace
SYNTAX  TruthValue
DESCRIPTION
   "This value indicates whether or not this interface
   uses in the local or per-interface label space."

As far as I can tell the object 'mplsInterfaceIsLocalLabelSpace'
is redundant with a non-zero value of 'mplsInterfaceConfIndex'.

Here are the possible combinations

GlobalLabelSpace:

   mplsInterfaceConfIndex == 0
   mplsInterfaceIsGlobalLabelSpace == TRUE

Combo (GlobalLabelSpace and LocalLabelSpace)

   mplsInterfaceConfIndex == non-zero, ifIndex value
   mplsInterfaceIsGlobalLabelSpace == TRUE

LocalLabelSpace

   mplsInterfaceConfIndex == non-zero, ifIndex value
   mplsInterfaceIsGlobalLabelSpace == FALSE

NOT Possible

   mplsInterfaceConfIndex == 0
   mplsInterfaceIsGlobalLabelSpace == FALSE.

Are the above all that are necessary?   If not,
could the other possibilities be given?

Here are suggestions for what they are worth.

*  Replace the term GlobalLabelSpace with PerPlatformLabelSpace
   throughout the MIB.

*  Replace the term LocalLabelSpace with PerInterfaceLabelSpace
   throughout the MIB.

*  Remove the object mplsInterfaceIsLocalLabelSpace

*  Reword the description for the object mplsInterfaceIsGlobalLabelSpace as:

mplsInterfacePerPlatformLabelSpaceAlso  OBJECT-TYPE
SYNTAX  TruthValue
MAX-ACCESS  read-only
STATUS   current
DESCRIPTION
   "If the value of the 'mplsInterfaceConfIndex is non-zero, and
   the value of this object is 'true' then the interface represented
   by this entry also participates in the PerPlatform Label Space as
   described in Section 3.14 of the MPLS Architecture.

   If the value of the 'mplsInterfaceConfIndex is zero, then this entry
   indicates is for the PerPlatform Label Space and 
   the value of this object must be 'true'."

-Joan

>          --Tom