The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] LDP MIB, version 9 outstanding issue
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.
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.
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.
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'.
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.
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.
Thanks for your time in going through these comments.
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 }"
|
|