Subject: RE: Proposed Indexing Changes to draft-ietf-mpls-ldp-mib-03.txt

From: "Kullberg, Alan" <[email-masked]>
Date: Tue, 16 Nov 1999 16:05:11 -0500

Thomas,

I finally had a chance to analyze your suggested changes to the LDP MIB.
I believe that there are some faults in your proposed indexing changes.
The summary of your new indexing is as follows:

mplsLdpEntityEntry OBJECT-TYPE
INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex }
mplsLdpPeerEntry OBJECT-TYPE
INDEX { mplsLdpPeerLdpId }
mplsLdpSessionEntry OBJECT-TYPE
INDEX { mplsLdpPeerLdpId }
mplsLdpHelloAdjacencyEntry OBJECT-TYPE
INDEX { mplsLdpPeerLdpId, mplsLdpHelloAdjacencyIndex }

The indexing of the LDP Entity is fine.  The indexing of the other
3 break down under certain configurations of LSRs.

For instance, if LSR-A and LSR-B are connected via 2 interfaces,
an ethernet and a PPP.  Let's say both interfaces on LSR-A are using
platform wide label space, and both interfaces on LSR-B are using
interface specific label space.  Both LSRs are using separate IP
addresses for each of their interfaces.  LSR-A is sending the same
LdpId on each interface, while LSR-B is sending a different LdpId
on each interface.

When LSR-B receives Hellos from LSR-A, there can only be one Peer entry
created in the MIB because the indexing is by PeerLdpId.  But, the
information in the Peer entry is in conflict because
mplsLdpPeerInternetworkAddr is different for the 2 different Hellos
received.  In addition, this configuration results in 2 separate LDP
Sessions being created, but the MIB indexing doesn't support it.

Therefore, I think the MIB indexing is not sufficient.  I think that
the following will work better:

mplsLdpPeerEntry OBJECT-TYPE
INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId }

mplsLdpSessionEntry OBJECT-TYPE
INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId }

mplsLdpHelloAdjacencyEntry OBJECT-TYPE
INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId,
        mplsLdpHelloAdjacencyIndex }

Alan

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, November 08, 1999 4:27 PM
> To: [email-masked]
> Cc: [email-masked]; Joan Cucchiara; Hans Sjoestrand;
> [email-masked]
> Subject: Proposed Indexing Changes to draft-ietf-mpls-ldp-mib-03.txt
> 
> 
> Hello All,
> 
> Rob Schmitt and I have finally had a chance to compare notes and work 
> through the LDP MIB indexing issues he and I raised over the past few 
> weeks. This message is an attempt to capture the issues we 
> discovered and 
> our proposed solutions to these problems. I hope that these suggested 
> modifications reach the authors prior to the release of the next
> version of the MIB, but if not we appologize.
> 
> Let us begin with a brief overview of what we are trying to 
> accomplish. At 
> the heart of what we are proposing is simply to reduce the number of 
> indexes for the existing tables from in some cases 4 or 5 
> indexes, down to 
> a single index or possibly two. The reason for our meddling with the 
> current version of the MIB is simple  after implementing 
> version "draft 01" 
> of the MIB, we found that it was difficult enough to 
> implement the way it 
> was. In the subsequent versions to this MIB a significant 
> number of indexes 
> have been added to may of the tables. We think that the 
> majority of the 
> additional indexes on the tables are unnecessary and result in an 
> implementation which is very difficult at best, to implement 
> correctly.
> 
> To begin with a high level perspective of LDP MIB indexing, it may be 
> helpful to think of the MIB as containing three main groups: 
> ENTITY, PEER 
> and SESSION. Each of these groups has equal prominence as 
> vantage points to 
> view the total MIB object space. Revision 03 of the MIB has partially 
> completed a transition to this perspective, reference the Peer Group. 
> Whereas in Rev 1 the Peer identifiers had been contextualized 
> with the 
> local Entity identifier, in Rev 3, these objects are now 
> accessed directly 
> via the Peer's LDP identifier. This having been done, both 
> the Entity and 
> Peer groups now have direct references to their contained 
> objects. From the 
> point of view of ease of implementation, run-time efficiency, and 
> clarity/simplicity, it is highly recommended that the same 
> direct indexing 
> approach be taken for the third leg of this triad, the Session Group.
> 
> Note: mplsLdpEntityLdpId refers to LOCAL label spaces, not 
> REMOTE(peer).
> 
> ENTITY
> ======
> 
> The Entity, layer2 parameters and label ranges: leave as is, 
> the second 
> index, added in version 3, is useful for  differentiating 
> platform-wide 
> label spaces.
> 
> mplsLdpEntityEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex }
> 
> mplsLdpEntityAtmParmsEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex }
> 
> mplsLdpEntityConfAtmLabelRangeEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId,  mplsLdpEntityIndex }
> 
> mplsLdpEntityFrameRelayParmsEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex }
> 
> mplsLdpEntityConfFrLabelRangeEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex }
> 
> PEER
> ====
> Rev 01 had cast the PeerIndex in the context of a 'local' Entity:
> 
> INDEX { mplsLdpEntityID, mplsLdpPeerIndex }
> 
> Rev 03 has properly removed the local Entity 
> contextualization in favor of 
> mplsLdpPeerLdpId, a direct reference to a Peer. However, Rev 03 has 
> over-shot the mark by adding a second level of index : 
> mplsLdpPeerIndex.
> Once the mplsLdpPeerLdpId is specified, there is no further 
> differentiation 
> to be gained. The authors have already acknowledged this, so 
> the way to go 
> is to remove mplsLdpPeerIndex.
> 
> mplsLdpPeerEntry OBJECT-TYPE
> INDEX { mplsLdpPeerLdpId }
> 
> 
> SESSION
> =======
> Rev 01 had cast the indexes for Sessions as:
> 
> INDEX { mplsLdpEntityID, mplsLdpPeerIndex, mplsLdpSessionIndex}
> 
> Rev 03 added mplsLdpEntityIndex as a means to differentiate 
> for platform 
> wide entities, and further developed the second level of 
> context by adding 
> mplsLdpPeerLdpId. Given these three indices, the fourth index 
> introduced in 
> Rev 3, mplsLdpPeerIndex is redundant and has been so 
> recognized by the 
> authors. The main question to be raised here is why the final 
> differentiator for the session is so highly contextualized by 
> the Entity 
> and Peer indexes. It would be highly desirable to have a 
> direct index for 
> the sessions, which would be mplsLdpPeerLdpId. The 
> corresponding local 
> EntityLdpId should be included as a read-only object column 
> within the 
> group so accessed. This would present a completely 
> symmetrical lens on the 
> protocol engine by having each of the three main groups 
> directly indexable, 
> with the associated relationships among the three represented 
> as managable 
> objects
> within the respective groups.As presented in Rev 03 :
> 
> mplsLdpSessionEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId,  mplsLdpEntityIndex,  mplsLdpPeerLdpId, 
> mplsLdpPeerIndex, mplsLdpSessionIndex
> }
> 
> mplsLdpAtmSessionEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, 
> mplsLdpPeerIndex,
> mplsLdpSessionIndex
> }
> 
> mplsLdpFrameRelaySessionEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, 
> mplsLdpPeerIndex,  mplsLdpSessionIndex
> }
> 
> mplsLdpSessionPeerAddressEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, 
> mplsLdpPeerIndex,
> mplsLdpSessionIndex
> }
> 
> Replace the INDEX set with :
> 
> INDEX { mplsLdpPeerLdpId }
> 
> and add managable objects (columns) :
> 
> mplsLdpEntityLdpId
> 
> mplsLdpEntityIndex
> ==============================================================
> ================
> 
> 
> HELLO ADJACENCY
> ===============
> Rev 01 had properly defined the INDEX for this group to be:
> 
> INDEX { mplsLdpSessionIndex, mplsLdpHelloAdjacencyIndex }
> 
> This was a better choice, but was supplanted by the 
> contexualization thread 
> introduced in Rev 3, and described above:
> 
> mplsLdpHelloAdjacencyEntry OBJECT-TYPE
> INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, 
> mplsLdpPeerIndex,
> mplsLdpHelloAdjacencyIndex }
> 
> It is recommended that we revert to the Rev 01 specification. In 
> combination with our recommendations for Sessions, the index becomes:
> 
> INDEX { mplsLdpPeerLdpId, mplsLdpHelloAdjacencyIndex }
> ==============================================================
> ============== 
> =====
> 
> 
> LIB
> ===
> Leave as is:
> 
> mplsLdpLibEntry OBJECT-TYPE
> INDEX { mplsLdpLibLspId }
> ==============================================================
> ============== 
> =====
> 
> FEC
> ===
> We have no opinion about this at the present time, but 
> suspect that it 
> could be specified as
> INDEX { mplsLdpFecAddressIndex }, a unique number with mplsLdpFecType,
> AddressFamily, AddressLength and Address as manageable objects.
> 
> mplsLdpFecEntry OBJECT-TYPE
> INDEX { mplsLdpFecType, mplsLdpFecAddressFamily, 
> mplsLdpFecAddressLength,
> mplsLdpFecAddress }

---

From: Bob Thomas <[email-masked]>
Date: Wed, 17 Nov 1999 14:58:58 -0500

Hi Alan,

> LdpId on each interface, while LSR-B is sending a different LdpId

I'll leave the specific MIB design issues on this thread to others.
However, if this example is intended to show that the pair of LDP Ids:

    (Local LDP Id, Remote LDP Id)

is insufficient to uniquely identify an LDP session within an LSR,
I don't think it does.  I believe the pair of LDP Ids is sufficient
in all cases.  (I suppose this is an implicit call for counter examples).

Bob