Subject: Re: Questions on LDP MIB v9

From: [email-masked]
Date: Sat, 02 Nov 2002 10:44:23 -0500

Hi Neil,

At 03:32 PM 10/30/02 -0000, Neil Jerram wrote: 

<excerpt><fontfamily><param>Arial</param><smaller>The latest LDP MIB
draft looks generally good, but I see three problems with the new
mplsLdpLspTable, which could be genuine, or could indicate
misunderstanding on my part -- so I would appreciate your thoughts on
them.  I also have one question.

</smaller></fontfamily>  

<fontfamily><param>Arial</param><smaller>1. It isn't possible to
represent an egress or transit LSP (A) at the same time as an ingress LSP
(B), if LSP A's incoming (interface, label) are the same as LSP B's
outgoing (interface, label), because the index in both cases is the same:
(i1, l1).  The old XCMapTable could represent both at the same time,
using indices (i1, l1, 0, 0) or (i1, l1, i2, l2) for LSP A and (0, 0, i1,
l1) for LSP B.

</smaller></fontfamily></excerpt><<<<<<<<

I agree that the XCMap Table was a little bit nicer

because it gave the Lib IN and LIB Out info as 

part of the index (which could possibly help in LIB lookups).  

However, this is also duplicated

information because it exists in the LSR-MIB's 

XCTable.  One of the primary concerns from the IESG

review was to reduce the number of objects in the LDP

MIB because it is such a huge MIB.  All 3 of the Mapping

tables were collapsed into this one table which simply

lists the LSPs (by IfIndex, Label) within each Session

(represented by mplsLdpEntityLdpId, mplsLdpEntityIndex,

and mplsLdpPeerLdpId).  The Mapping to the LSR MIB 

is done by using Row Pointers.  So, this increases the

burden on the agent to now retrieve the info from the

LSR MIB to get label in/out indices.

The mplsLdpLspType was added to give a hint as to the

type of LSP, terminating, originating or XC, so that the appropriate

RowPointer could be retrieved.

<excerpt>

<fontfamily><param>Arial</param><smaller>2. There is no mplsLdpLspType
value to indicate a liberally retained label.

</smaller></fontfamily></excerpt><<<<<<<<

This is a configurable option for the Entity,
mplsLdpEntityLabelRetentionMode.

So although it is true that it is not defined on a per Lsp basis, it

is defined for the session.

<excerpt>

<fontfamily><param>Arial</param><smaller>3. In the description
mplsLdpLspType, your uses of "ingress" and "egress" (as verbs describing
the LSP's relationship to the LSR) are exactly opposite to the
conventional usage (which describes a data packet's relationship to an
LSP).  This could be rather confusing!

</smaller></fontfamily>  

</excerpt><<<<<<<<

I agree!  Will be fixed in the TC MIB's description and LDP MIB's
description.

<excerpt>

<fontfamily><param>Arial</param><smaller>4. Do you expect implicit and
explicit null labels to appear in this table, and, if so, how?  The point
is that implicit and explicit null labels can be distributed multiple
times for different FECs in the same session, and it isn't clear in this
case how the MIB indexing will work.

</smaller></fontfamily>  

</excerpt><<<<<<<<

Good question.  Would the ifIndex be different in this case?  

The goal would be to have this table be able to list all LDP LSPs
uniquely

and then have pointers to their counter-parts in the 

LSR-MIB's InSegment/OutSegment/XC tables.

Thanks for your questions,

  -Joan

<excerpt>

<fontfamily><param>Arial</param><smaller>Best regards,

</smaller></fontfamily>    
<fontfamily><param>Arial</param><smaller>Neil

</smaller></fontfamily>  

<fontfamily><param>Arial</param><smaller>Neil Jerram

Network Protocols Group

Data Connection Ltd.

<<http://www.dataconnection.com>www.dataconnection.com

</smaller></fontfamily>  

</excerpt><<<<<<<<

---

From: Neil Jerram <[email-masked]>
Date: Fri, 15 Nov 2002 17:53:23 -0000

Joan,

Thanks for responding to my questions.  I'm afraid, though, that your
answers don't resolve the issues that I raised under numbers 1, 2 and
4, as follows.

1. Unless I misunderstood, your answer didn't address the specific
   indexing problem that I raised.

   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.

2. You noted the per-entity LabelRetentionMode field.  However, as you
   say, this is not a per-label or per-LSP flag.  Whether an LDP label
   is liberally retained or not is useful information for an
   administrator, and other well known interfaces provide this.  So I
   repeat my suggestion that we should add a field to the appropriate
   per-label or per-LSP table in the LDP MIB to indicate whether each
   downstream label is liberally retained.

4. You ask whether the ifIndex would be different for different
   mappings.  Unfortunately no, and that is the problem.

   The common scenario here is a non-merging LSR A that is the
   penultimate hop for an LSP.  As it is non-merging, it sends a Label
   Request to the egress LSR B for every upstream label that it
   distributes or receives a request for.  Because B knows that it is
   egress, it always sends back an implicit null Label Mapping.

   So LSR A and LSR B both have multiple Label Mappings, all on the
   same session and same interface (ifIndex), for the same FEC and
   with the same label value (3, implicit null).

   In LDP MIB up to v8, this is impossible to represent in both A's
   mplsLdpSessionOutLabelTable and B's mplsLdpSessionInLabelTable,
   because the (ifIndex, label) pairs for all labels are the same.

   In LDP MIB v9, it is impossible on B for the same reason: all the
   labels have the same session, ifIndex and label.  (It's actually OK
   on A, but in a rather bizarre way that I doubt you intended: the
   mplsLdpLspTable entries for the downstream labels on A can be
   indexed by the session, ifIndex and label for the _upstream labels_
   to which they are connected, which must be unique.)

Based on these real problems, and having studied the motivations
behind the revisions from v8 to v9, I'd like to propose replacing
mplsLdpLspTable and mplsLdpLspFecTable with 2 new tables that solve
the problems.

(If the goal was to minimize the changes with respect to v9, you could
also solve the problems by adding two new index fields to the
mplsLdpLspTable and mplsLdpLspFecTable: an upstream/downstream flag
and (for problem 1) and an arbitrary tie-breaker index (for problem
4).  Plus of course the new liberally retained field for problem 2.
However, I believe that the tables proposed below also present LDP's
label binding information more naturally than those in v9.)

I apologise that this proposal comes late in the lifetime of the LDP
MIB.  On the other hand, I couldn't find any substantial previous
discussion of these tables in the archive, so as far as I know this
isn't stepping on anyone else's toes.  (Please correct me if that's
wrong!)

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 }

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 02 November 2002 15:44
To: Neil Jerram; [email-masked]'; [email-masked];
[email-masked]
Cc: [email-masked]'
Subject: Re: Questions on LDP MIB v9

Hi Neil, 

At 03:32 PM 10/30/02 -0000, Neil Jerram wrote: 
The latest LDP MIB draft looks generally good, but I see three problems with
the new mplsLdpLspTable, which could be genuine, or could indicate
misunderstanding on my part -- so I would appreciate your thoughts on them.
I also have one question. 
1. It isn't possible to represent an egress or transit LSP (A) at the same
time as an ingress LSP (B), if LSP A's incoming (interface, label) are the
same as LSP B's outgoing (interface, label), because the index in both cases
is the same: (i1, l1). The old XCMapTable could represent both at the same
time, using indices (i1, l1, 0, 0) or (i1, l1, i2, l2) for LSP A and (0, 0,
i1, l1) for LSP B. 
<<<< 

2. There is no mplsLdpLspType value to indicate a liberally retained label. 
<<<< 

3. In the description mplsLdpLspType, your uses of "ingress" and "egress"
(as verbs describing the LSP's relationship to the LSR) are exactly opposite
to the conventional usage (which describes a data packet's relationship to
an LSP). This could be rather confusing! 
<<<< 

4. Do you expect implicit and explicit null labels to appear in this table,
and, if so, how? The point is that implicit and explicit null labels can be
distributed multiple times for different FECs in the same session, and it
isn't clear in this case how the MIB indexing will work. 
<<<< 

Good question. Would the ifIndex be different in this case? 
The goal would be to have this table be able to list all LDP LSPs uniquely 
and then have pointers to their counter-parts in the 
LSR-MIB's InSegment/OutSegment/XC tables. 

Best regards, 
Neil 
Neil Jerram 
Network Protocols Group 
Data Connection Ltd. 
<http://www.dataconnection.com>www.dataconnection.com 
<<<<