The MPLS WG Archive

[jcucchiara@mindspring.com]

Hi Ravi,

Thank you for the comments.  Please see responses inline.

At 02:23 PM 4/15/03 +0200, Ravi_MALHOTRA/BE/ALCATEL@UU.NET wrote:
>Hi Joan,
>
>We have discussed the proposal of Neil internally in our group and have
>the following comments.
>
>
>1. mplsLdpUpLspType : The value of originatingLsp(3) would be invalid in
>this case as an upstream label would never be at the head-end of an LSP.
>The same also applies to mplsLdpDownLspType where the value of
>terminatingLsp(2) would be invalid.

This TC has been reworded in the TC MIB.  So think the definition is
better now.

>
>2. mplsLdpUpLsrXCPointer : in case of point-to-multipoint connections,
>we can have the same upstream label connected to multiple downstream
>labels. In that case, this object would no longer be unique. 
>Suggestion - use mplsXCIndex i.s.o row-pointer; the other indices of the
>mplsXCTable can be derived from other objects in this table.

LDP does not support point-to-multipoint.  It is not a goal of the MIB
to support this, since the spec doesn't.  Having said that, consider
this suggestion.

>
>3. mplsLdpDownLiberal : This object is redundant and its value can
>instead be determined from the mplsLdpDownLsrOutSegmentPointer. If the
>label is liberally-retained and not-in-use, then it would not have an
>out-segment and correspondingly no entry in the mplsOutSegmentTable.
>Thus, if the value of mplsLdpDownLsrOutSegmentPointer is 0.0, then the
>label is liberally-retained.
>
>4. mplsLdpDownLsrXCPointer : in case of multipoint-to-point connections,
>we can have the same downstream label connected to multiple upstream
>labels. In that case, this object would no longer be unique.
>Suggestion - use mplsXCIndex i.s.o row-pointer.

Same comment as above for #2.

>
>5. How can we represent label-stacking in LDP via this MIB. The
>label-stacking could be either
>- LDP LSPs over RSVP-TE tunnels.
>- PWE-LDP (Martini) LSPs over core LDP/RSVP - LSPs.
>
>Suggestion - Each core LSP (LDP/RSVP) can be represented by an if-index
>in the IF-MIB. If we include the if-index in the above tables then we
>can find out whether the LSP goes via a physical-interface or a
>'tunnel-interface'.

I believe this was answered in email discussion between Tom and Riza.


>
>6. Whether mplsLdpLspIndex is really required ? - it may happen in
>non-merging MPLS networks that the downstream peer (the egress LSR)
>might send the same label (implicit/explicit-NULL) for the same FEC to
>the same peer for mutiple Label-Requests. However, from an operational
>point of view - all these entries would be the same and the LSR would
>indeed be 'merging'. As such, these entries would just be unneccessary
>duplicates conveying no extra information.
>Also, from a deployment point of view, MPLS networks where
>implicit/explicit-NULL labels (i.e. generic labels) are used, generally
>support merging. Only in case of legacy layer-2 networks like ATM/FR,
>merging may not be supported. In these cases, one can never have the
>duplicate label/FEC/Peer combination as it would force these LSRs to do
>merging.
>
>Suggestion: mplsLdpUpLabel & mplsLdpDownLabel are quite sufficient as
>indices for mplsLdpUpLabelTable & mplsLdpDownLabelTable i.s.o
>mplsLdpLspIndex.
>

As I mentioned, there will likely be revisions to the original tables
proposed by Neil.  This appears to be a simplification and 
so we will consider this.

>
>7. In our implementation of the LDP-LIB tables, we use
>mplsLdpLabelDirection as an additional index to determine whether the
>label/FEC has been advertised or received. 
>The addition of this object to the mplsLdpLspTable in LDP-MIB version 9,
>would solve the problem with the uniqueness of the indexing as pointed
>out by Neil. At the same time, we can avoid having multiple tables
>and/or a large number of indices in the MIB.
>

We will consider this also.  However, in my opinion, it is sometimes
better to use separate tables and have simpler indexing.  The number of
objects will remain the same even with 2 tables.


>
>Thanks for your time in going through these comments.

Thanks for the comments,
  -Joan


>
>
>Warm regards,
>Ravi 
>
>
>----------------------------------------------------
>Ravi Malhotra                          
>WX-25, Alcatel-Bell,                   
>Antwerpen-2016, Belgium.               
>                                       
>email: ravi.malhotra@alcatel.be           
>phone : +32-3240-9738                     
>----------------------------------------------------
>
>
>jcucchiara@mindspring.com wrote:
>> 
>> Hello Everyone,
>> 
>> From the Atlanta MPLS MIB meeting there was an outstanding issue
>> as described by the "MPLS MIB review meeting minutes" posted
>> to the mpls working group on Dec 03, 2002.  This issue
>> had to do with the change from version 8 of the MIB to
>> version 9.
>> 
>> Version 8 of the MIB had 3 Mapping tables, from an LDP LSP
>> to either an InSegment/OutSegment/XCSegment in the LSR-MIB.
>> 
>> Version 9 reduces this to 1 table and uses RowPointers.
>> 
>> The motivation for doing this was to reduce the number of
>> objects.  However, it turns out that this table is lacking
>> because the indexing will not be unique under certain
>> circumstances.  This was very well documented in email
>> by Neil Jerram on Nov 15, 2002 "RE: Questions on LDP MIB v9".
>> This is repeated here for your convenience:
>> 
>>   "Here is a concrete example of the problem.  LSR A and LSR B each
>>    distribute a label to each other, and by chance they use the same
>>    label value, 67.  So in LSR A's mplsLdpLspTable, the label that A
>>    distributed to B has index:
>> 
>>      mplsLdpEntityLdpId      AA AA AA AA 00 01
>>      mplsLdpEntityIndex      1
>>      mplsLdpPeerLdpId        BB BB BB BB 00 01
>>      mplsLdpLspIfIndex       1
>>      mplsLdpLspLabel         67
>> 
>>    The label that A received from B has index:
>> 
>>      mplsLdpEntityLdpId      AA AA AA AA 00 01
>>      mplsLdpEntityIndex      1
>>      mplsLdpPeerLdpId        BB BB BB BB 00 01
>>      mplsLdpLspIfIndex       1
>>      mplsLdpLspLabel         67
>> 
>>    Which is exactly the same.  So the mplsLdpLspTable can't hold
>>    represent both of these labels at once."
>> 
>> Please note, the next version of the MIB will
>> not have the mplsLdpLspTable.  Neil has proposed a solution
>> which is very detailed in that email (and repeated
>> at the end of this email).  I would like to incorporate his
>> these tables (or revised versions of these tables)
>> into the next version of the MIB.
>> 
>> Does anyone have any objections with this change?
>> 
>>    Thanks, Joan
>> 
>> Quoting from Neil's email dated Nov 15th to the mpls@uu.net:
>> 
>> "Key points of my proposal are as follows.
>> 
>> - The new tables are:
>> 
>>   - mplsLdpUpLabelTable, describing labels distributed to upstream peers
>> 
>>   - mplsLdpDownLabelTable, describing labels received from downstream
>>     peers, including liberally retained and null labels.
>> 
>> - Like the tables that they replace in LDP MIB v9, these tables use
>>   RowPointers to point to LIB information in the LSR MIB.  They don't
>>   unnecessarily duplicate any information that can be obtained from
>>   the LSR MIB.
>> 
>> - Advantages in comparison with LDB MIB v9 are that:
>> 
>>   - mplsLdpDownLabelTable can show both established and liberally
>>     retained labels, and has a flag to indicate which labels are which
>> 
>>   - mplsLdpDownLabelTable can show multiple label mappings received
>>     from the same peer, for the same FEC, and with the same label
>>     value (this is most relevant for implicit and explicit null
>>     labels, but can also occur in some networks with non-null label
>>     values)
>> 
>>   - mplsLdpUpLabelTable and mplsLdpDownLabelTable can show a
>>     distributed label and a received label that share the same
>>     session, FEC and label value.
>> 
>> - mplsLdpUpLabelTable has a RowPointer to an mplsLdpDownLabelTable
>>   entry that can be used to show how upstream and downstream mappings
>>   are connected.
>> 
>> The full ASN.1 and a note on indexing are appended below.  Thank you
>> very much for your time.
>> 
>>      Neil
>> 
>> Indexing
>> ========
>> 
>> The tables are indexed by (LDP session, FEC index, LSP index), where:
>> 
>> - LDP session is the usual (entity ldp id, entity index, peer ldp id)
>> - FEC index is a non-predictable index into the mplsFecTable
>> - LSP index is a non-predictable tie-breaker index for non-merging
>>   LSPs for the same FEC.
>> 
>> The key benefit of this indexing is that it permits the
>> representation, for non-merging FECs, of the labels established by
>> multiple Label Request - Label Mapping exchanges through an LSR, even
>> when the labels distributed for different Label Requests are the same
>> (usually implicit and explicit nulls).
>> 
>> ASN.1
>> =====
>> 
>>      --
>>      --  The MPLS LDP Upstream Label Table
>>      --
>> 
>>      mplsLdpUpLabelTable OBJECT-TYPE
>>          SYNTAX      SEQUENCE OF MplsLdpUpLabelEntry
>>          MAX-ACCESS  not-accessible
>>          STATUS      current
>>          DESCRIPTION
>>              "A table mapping LDP sessions and FECs to the upstream
>>              labels distributed for those sessions and FECs, and to
>>              the corresponding LIB entries in the LSR MIB."
>>          ::= { mplsLdpSessionObjects 6 }
>> 
>>      mplsLdpUpLabelEntry OBJECT-TYPE
>>          SYNTAX      MplsLdpUpLabelEntry
>>          MAX-ACCESS  not-accessible
>>          STATUS      current
>>          DESCRIPTION
>>              "An entry in this table represents a label that has been
>>              distributed upstream for a particular session and FEC
>>              combination.  It is indexed by the session's index triple
>>              (mplsLdpEntityLdpId, mplsLdpEntityIndex,
>>              mplsLdpPeerLdpId), the FEC index (mplsFecIndex) and an
>>              LSP index (mplsLdpLspIndex) that distinguishes between
>>              non-merging LSPs for the same FEC.
>> 
>>              The information contained in a row is read-only."
>>          INDEX       { mplsLdpEntityLdpId,
>>                        mplsLdpEntityIndex,
>>                        mplsLdpPeerLdpId,
>>                        mplsFecIndex,
>>                        mplsLdpLspIndex
>>                      }
>>          ::= { mplsLdpUpLabelTable 1 }
>> 
>>      MplsLdpUpLabelEntry ::= SEQUENCE {
>>          mplsLdpUpLabel                  MplsLabel,
>>          mplsLdpUpLabelType              MplsLdpLabelType,
>>          mplsLdpUpLspType                MplsLspType,
>>          mplsLdpUpDownLabelPointer       RowPointer,
>>          mplsLdpUpLsrInSegmentPointer    RowPointer,
>>          mplsLdpUpLsrXCPointer           RowPointer
>>      }
>> 
>>      mplsLdpLspIndex OBJECT-TYPE
>>          SYNTAX       Unsigned32
>>          MAX-ACCESS   not-accessible
>>          STATUS       current
>>          DESCRIPTION
>>              "A tie-breaker index that distinguishes between multiple
>>               non-merging LSPs for the same FEC.
>> 
>>               Where an LSR merges all LSPs for the same FEC, this
>>               field is not needed and should always be zero.
>> 
>>               Where an LSR does not merge LSPs for the same FEC, it is
>>               possible for the LSR to distribute (or receive) multiple
>>               label mappings for the same FEC to (or from) the same
>>               session, and for some of these labels to be equal (in
>>               particular where implicit and explicit null labels are
>>               in use).  In this case, the entries that describe the
>>               labels are distinguished from each other by using a
>>               different, non-zero value for this index field."
>>          ::= { mplsLdpUpLabelEntry 1 }
>> 
>>      mplsLdpUpLabel OBJECT-TYPE
>>          SYNTAX        MplsLabel
>>          MAX-ACCESS    not-accessible
>>          STATUS        current
>>          DESCRIPTION
>>              "The upstream label value."
>>          ::= { mplsLdpUpLabelEntry 2 }
>> 
>>      mplsLdpUpLabelType  OBJECT-TYPE
>>          SYNTAX        MplsLdpLabelType
>>          MAX-ACCESS    read-only
>>          STATUS        current
>>          DESCRIPTION
>>              "The Layer 2 upstream label type."
>>          ::= { mplsLdpUpLabelEntry 3 }
>> 
>>      mplsLdpUpLspType OBJECT-TYPE
>>          SYNTAX        MplsLspType
>>          MAX-ACCESS    read-only
>>          STATUS        current
>>          DESCRIPTION
>>              "The type of LSP connection for which this label is in
>>              use.  The possible values are:
>> 
>>                 unknown(1)         --  if the LSP is not known
>>                                        to be one of the following.
>> 
>>                terminatingLsp(2)   -- if the LSP terminates
>>                                       on the LSR, then this
>>                                       is an ingressing LSP
>>                                       which ends on the LSR,
>> 
>>                originatingLsp(3)   -- if the LSP originates
>>                                       from the LSR, then this
>>                                       is an egressing LSP which is
>>                                       the head-end of the LSP,
>> 
>>              crossConnectingLsp(4) -- if the LSP ingresses
>>                                       and egresses on the LSR,
>>                                       then it is cross-connecting
>>                                       on that LSR."
>>          ::= { mplsLdpUpLabelEntry 4 }
>> 
>>      mplsLdpUpDownLabelPointer OBJECT-TYPE
>>          SYNTAX      RowPointer
>>          MAX-ACCESS  read-only
>>          STATUS      current
>>          DESCRIPTION
>>              "If this label is cross-connected to a received LDP
>>              downstream label mapping, this RowPointer should point to
>>              the entry in the mplsLdpDownLabelTable that describes the
>>              downstream label.
>> 
>>              Otherwise this field's value is zeroDotzero."
>>          ::= { mplsLdpUpLabelEntry 5 }
>> 
>>      mplsLdpUpLsrInSegmentPointer OBJECT-TYPE
>>          SYNTAX      RowPointer
>>          MAX-ACCESS  read-only
>>          STATUS      current
>>          DESCRIPTION
>>              "If this label has a corresponding entry in the LSR MIB
>>              mplsInSegmentTable, this RowPointer should point to that
>>              entry.
>> 
>>              Otherwise this field's value is zeroDotzero."
>>          ::= { mplsLdpUpLabelEntry 6 }
>> 
>>      mplsLdpUpLsrXCPointer OBJECT-TYPE
>>          SYNTAX      RowPointer
>>          MAX-ACCESS  read-only
>>          STATUS      current
>>          DESCRIPTION
>>              "If this label is cross-connected to a received LDP
>>              downstream label mapping and there is an entry
>>              describing this cross-connect in the LSR MIB mplsXCTable,
>>              this RowPointer should point to that entry.
>> 
>>              Otherwise this field's value is zeroDotzero."
>>          ::= { mplsLdpUpLabelEntry 7 }
>> 
>>      --
>>      --  The MPLS LDP Downstream Label Table
>>      --
>> 
>>      mplsLdpDownLabelTable OBJECT-TYPE
>>          SYNTAX      SEQUENCE OF MplsLdpDownLabelEntry
>>          MAX-ACCESS  not-accessible
>>          STATUS      current
>>          DESCRIPTION
>>              "A table mapping LDP sessions and FECs to the downstream
>>              labels received for those sessions and FECs, and to the
>>              corresponding LIB entries in the LSR MIB."
>>          ::= { mplsLdpSessionObjects 6 }
>> 
>>      mplsLdpDownLabelEntry OBJECT-TYPE
>>          SYNTAX      MplsLdpDownLabelEntry
>>          MAX-ACCESS  not-accessible
>>          STATUS      current
>>          DESCRIPTION
>>              "An entry in this table represents a label that has been
>>              received from a downstream peer for a particular session
>>              and FEC combination.  It is indexed by the session's
>>              index triple (mplsLdpEntityLdpId, mplsLdpEntityIndex,
>>              mplsLdpPeerLdpId), the FEC index (mplsFecIndex) and an
>>              LSP index (mplsLdpLspIndex) that distinguishes between
>>              non-merging LSPs for the same FEC.
>> 
>>              The information contained in a row is read-only."
>>          INDEX       { mplsLdpEntityLdpId,
>>                        mplsLdpEntityIndex,
>>                        mplsLdpPeerLdpId,
>>                        mplsFecIndex,
>>                        mplsLdpLspIndex
>>                      }
>>          ::= { mplsLdpDownLabelTable 1 }
>> 
>>      MplsLdpDownLabelEntry ::= SEQUENCE {
>>          mplsLdpDownLabel                  MplsLabel,
>>          mplsLdpDownLabelType              MplsLdpLabelType,
>>          mplsLdpDownLspType                MplsLspType,
>>          mplsLdpDownLiberal                TruthValue,
>>          mplsLdpDownLsrOutSegmentPointer   RowPointer,
>>          mplsLdpDownLsrXCPointer           RowPointer
>>      }
>> 
>>      mplsLdpDownLabel OBJECT-TYPE
>>          SYNTAX        MplsLabel
>>          MAX-ACCESS    not-accessible
>>          STATUS        current
>>          DESCRIPTION
>>              "The downstream label value."
>>          ::= { mplsLdpDownLabelEntry 1 }
>> 
>>      mplsLdpDownLabelType  OBJECT-TYPE
>>          SYNTAX        MplsLdpLabelType
>>          MAX-ACCESS    read-only
>>          STATUS        current
>>          DESCRIPTION
>>              "The Layer 2 downstream label type."
>>          ::= { mplsLdpDownLabelEntry 2 }
>> 
>>      mplsLdpDownLspType OBJECT-TYPE
>>          SYNTAX        MplsLspType
>>          MAX-ACCESS    read-only
>>          STATUS        current
>>          DESCRIPTION
>>              "The type of LSP connection for which this label is in
>>              use.  The possible values are:
>> 
>>                 unknown(1)         --  if the LSP is not known
>>                                        to be one of the following.
>> 
>>                terminatingLsp(2)   -- if the LSP terminates
>>                                       on the LSR, then this
>>                                       is an ingressing LSP
>>                                       which ends on the LSR,
>> 
>>                originatingLsp(3)   -- if the LSP originates
>>                                       from the LSR, then this
>>                                       is an egressing LSP which is
>>                                       the head-end of the LSP,
>> 
>>              crossConnectingLsp(4) -- if the LSP ingresses
>>                                       and egresses on the LSR,
>>                                       then it is cross-connecting
>>                                       on that LSR."
>>          ::= { mplsLdpDownLabelEntry 3 }
>> 
>>      mplsLdpDownLiberal OBJECT-TYPE
>>          SYNTAX      TruthValue
>>          MAX-ACCESS  read-only
>>          STATUS      current
>>          DESCRIPTION
>>              "Whether this is a liberally retained downstream label."
>>          DEFVAL { false }
>>          ::= { mplsLdpDownLabelEntry 4 }
>> 
>>      mplsLdpDownLsrOutSegmentPointer OBJECT-TYPE
>>          SYNTAX      RowPointer
>>          MAX-ACCESS  read-only
>>          STATUS      current
>>          DESCRIPTION
>>              "If this label has a corresponding entry in the LSR MIB
>>              mplsOutSegmentTable, this RowPointer should point to that
>>              entry.
>> 
>>              Otherwise this field's value is zeroDotzero."
>>          ::= { mplsLdpDownLabelEntry 5 }
>> 
>>      mplsLdpDownLsrXCPointer OBJECT-TYPE
>>          SYNTAX      RowPointer
>>          MAX-ACCESS  read-only
>>          STATUS      current
>>          DESCRIPTION
>>              "If this label is cross-connected to a distributed LDP
>>              upstream label mapping and there is an entry describing
>>              this cross-connect in the LSR MIB mplsXCTable, this
>>              RowPointer should point to that entry.
>> 
>>              Otherwise this field's value is zeroDotzero."
>>          ::= { mplsLdpDownLabelEntry 6 }"
>