The MPLS WG Archive

[Arun Viswanathan <arun@force10networks.com>]

Joan,
    Thanks for your extensive comments.

> * needs a table of contents

We will try to put this in.

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

No need for this, but when we issue the next rev based
on the last-call comments, we will send the diff to the ML.

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

We can perhaps refer to it saying this MIB achieves for MPLS
what ATOM MIB does for ATM (in some sense). Though LSR MIB
is broader in scope.

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

Will put descriptive text in the introduction section that
depicts the MPLS interface stacked over a well-known interface.

> 
> * StorageType objects need to be added throughout
>   various tables.

Okay.

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

The last sentence will be removed. We will also remove all references
to TEMIB. 'Layer' here means the MPLS interface layer in interface stack.
Adding general description (previous comment) will also add to clarity.

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

No, See above comments.

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

Will do.

> 
> * ifIndex is not a textual convention

Will do.

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

Okay.

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

We are fixing this already based on some other comments.

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

Will remove DLCI size 17 from description.

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

Will do.

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

Yes.

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

Interfaces that have interface specific label space may also
want to participate in global label space. The two objects,
[...]LabelSpace, together enable that.

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

Will do. Section 3.14 of Arch.

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

Yes.

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

This was added because of a few requests. I personally think
this is not very useful information. Perhaps having available
BW per priority level will be more useful.

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

Vestiges. Will throw them out.

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

I assume you meant to ask a interface participates in both
local and global label space. The counters are for basically
the actual interfaces and should count for both types of
labels (local as well as global). In addition, LSRs MAY
count for global labels separately.

Will add more text in the description to make this clear.

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

Vestiges. Will remove them.

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

See above comment.

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

I think we can add that.

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

We caught this with the SMIC compiler.

>   Is this the same as the index used in the mplsInterfaceConfEntry
>   for the label related to this entry?

Yes.

> 
>   Could more description be added to this index?

Okay.

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

Will do.

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

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.

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

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

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

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.

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

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

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

Evils of cut-and-paste.

> 
>   Also REF clause should be updated

Will be removed and description adjusted.

> 
> * mplsOutSegmentIfIndex should be not-accessible

Hmmm..I guess so.

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


A label swapping is modelled as a pop followed by a push.
See mplsInSegmentNPop. The description also talks about
the ATM case.

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

I don't think we need to specially qualify LDP for this. This
is common to any protocol on ATM.

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


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

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

Done.

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

That is, 'none' is not a valid choice for any multi-access network.

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

Yes.

> 
> * mplsXCIndexNext object's range should start at 0.

It is alright the way it is. 0 is reserved to indicate
"no more cross-connect entries available".

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

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

> 
> * mplsXCIndex should be not-accessible

Okay.

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

Will remove this object based on comments on ML.

> 
> * mplsXCIsPersistent should have SYNTAX of StorageType

Okay.

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

No, see comments above.

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

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.

-arun