Subject: LSR MIB last call

From: Vijay Srinivasan <[email-masked]>
Date: Tue, 21 Mar 2000 08:00:35 -0800

The authors of the LSR MIB have requested that we progress the document to
WG last call.  I would like to commence the last call, ending in two weeks
(due to the IETF in between).  Joan's comments to the list will be
considered as part of the last call.

- Vijay

-----Original Message-----
From: Joan Cucchiara [mailto:[email-masked]]
Sent: Tuesday, March 21, 2000 6:38 AM
To: [email-masked]'; [email-masked]';
[email-masked]'
Cc: [email-masked]'
Subject: LSR MIB comments and questions

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: "Abes, Andi" <[email-masked]>
Date: Tue, 21 Mar 2000 11:49:51 -0500

I think this has been mentioned before, 
but what support, if any is there for configuring and
representing Diff Serv capable LSP's ?
 
The only mention I found is the XCCos, which 
doesn't seem to be enough.
 
I would expect the MIB to be capable of the following:
- Connect an InSegment to (eventually) an Output Segment
  based both on Input IF, input Label and incoming EXP (COS) bits
 
  Preferably the inSegment would select the XC based on label, and then
  the XC would select a specific output segment based on EXP.
  ( this is meant to allow conversion between incoming E-LSP's to outgoing
   L-LSP's as would be needed in an LSR with both Ethernet and LC-ATM
interfaces
   for example)
 
- Allow a mapping between incoming EXP to outgoing EXP, not just a global
  replacement (as is provided by XCCos). This could be accomplished together
with
  the previous point by indexing the XC table with EXP as well. For LSP's
created by LDP, 
  a single value of 0 could be used.
 
- For output segments, specify their type (E/L-LSP's), and PHBID of the OA
carried over them.

This is my understanding of some of the requirements for supporting Diff
Serv LSP's.
The Diff Serv over MPLS authors could have better/greater/finer comments to
add to 
this.
Have they been consulted on the issue ? I remeber Adrian mentioning this
before 
 
Andi.

 

-----Original Message-----
From: Vijay Srinivasan [mailto:[email-masked]]
Sent: Tuesday, March 21, 2000 11:01 AM
To: 'Joan Cucchiara'; [email-masked]'; [email-masked]';
[email-masked]'
Cc: [email-masked]'
Subject: LSR MIB last call

- Vijay 

-----Original Message----- 
From: Joan Cucchiara [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, March 21, 2000 6:38 AM 
To: [email-masked]'; [email-masked]'; 
[email-masked]' 
Cc: [email-masked]' 
Subject: LSR MIB comments and questions 

Hi Tom, Arun and Cheenu, 

-Joan 

Editorial 
--------- 

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

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

MIB 
--- 

  

   

* mplsOutSegmentTopLabel 

  Could this be clarified?  

--

---

From: "Abes, Andi" <[email-masked]>
Date: Tue, 21 Mar 2000 12:47:23 -0500

Opps...

I didn't notice Adrian's mail, and the response from Tom.

In any case, if Diff Serv is to be added later, can we 
rid of the XCCos, which is not enough for Diff Serv support 
and might generate (or has already done so) confusion ?

Andi.

> From: Abes, Andi [mailto:[email-masked]]
> Sent: Tuesday, March 21, 2000 11:50 AM
> To: Vijay Srinivasan; [email-masked]
> Subject: RE: LSR MIB last call
> 
>

---

From: Joan Cucchiara <[email-masked]>
Date: Wed, 22 Mar 2000 09:47:18 -0500

> Sent: Tuesday, March 21, 2000 12:47 PM

I would be in favor of taking this object out of the LSR
MIB also for the reasons stated above

It would also be my preference to remove the TSpec table and
put this into the TE MIB for the similar reasons.  The LSR MIB,
should be able to support ALL MPLS protocols, and the TSpec
table is not relevant to LDP.  Certainly, it would be easy enough
to Augment/extend tables in the LSR MIB in the TE MIB (or any other
MIB), so there is really no need to have objects in the LSR MIB 
which are not supported all of the MPLS protocols.   It would
be "cleaner" to have related functionality in the same MIBs, instead
of having chunks in the LSR MIB and chunks in another MIB.  

   -Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Mar 2000 11:53:24 -0500

Hi,

>MIB also for the reasons stated above

         It seems that there is a consensus building here
to remove this object from the table. At this point three
different folks have requested that it be removed. Unless
we hear otherwise from other list members, we will remove
this object in the next update.

>of having chunks in the LSR MIB and chunks in another MIB.

         The purpose of the Tspec tables in the TE and the LSR
MIBs are different. In the LSR MIB, the Tspec indicates
the actual resource allocation for the LSP/LSPs in question.
In the TE MIB, the Tspec indicates the desired Tspec for
the tunnel. For these reasons, we feel that both tables
are necessary.

         --Tom