Subject: LDP MIB Indexing

From: Rob Schmitt <[email-masked]>
Date: Wed, 08 Mar 2000 11:11:34 -0800

>With regards to draft-ietf-mpls-ldp-mib-05, specifically the INDEX sets of
various tables.  The tables in question are shown here; my comment
relates to the inclusion of the index object 'mplsLdpPeerLdpId'.  I
show the table, followed by my comments about that table.
  @
          { mplsLdpEntityPeerTable }
           INDEX    { mplsLdpEntityLdpId,
                         mplsLdpEntityIndex,
                         mplsLdpPeerLdpId         }

  Are there _any_  scenarios anticipated where, having specified
  both 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex',
  where a further qualifier would be required to differentiate
  a row in this table?  The third index object is redundant, inconvenient
  for implementation, has previously been so recognized by the authors,
  and there have been no arguments put forward as to why it should be
  reintroduced  into the MIB.   There are really two choices for crafting
  an INDEX for this table
                 1) { mplsLdpEntityLdpId, mplsLdpEntityIndex }  or
                 2) { mplsLdpPeerLdpId }.
We should pick one of the above two options, not a union of the two.

  @
           { mplsLdpSessionTable }
           INDEX   { mplsLdpEntityLdpId,
                         mplsLdpEntityIndex,
                         mplsLdpPeerLdpId       }

The index objects 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex'
together and alone serve to identity sessions (and potential
sessions in other tables).  'mplsLdpPeerLdpId' is extraneous as an index.

  @
          { mplsLdpHelloAdjacencyTable }
           INDEX    { mplsLdpEntityLdpId,
                         mplsLdpEntityIndex,
                         mplsLdpPeerLdpId,
                         mplsLdpHelloAdjacencyIndex }

In this table 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex' serve to
uniquely select a session that supports {n} adjacencies.  The {n-th} 
instance is
resolved by 'mplsLdpHelloAdjacencyIndex.  But again, the interjection of
'mplsLdpPeerLdpId' is redundant, difficult for implementation, and
  does not add any benefit.

  @
          { mplsLdpAtmSessionTable }
           INDEX   { mplsLdpEntityLdpId,
                         mplsLdpEntityIndex,
                         mplsLdpPeerLdpId,
                         mplsLdpSessionAtmLabelRangeLowerBoundVpi,
                         mplsLdpSessionAtmLabelRangeLowerBoundVci        }

Since we are dealing here with the labels in the domain
of an Entity, what is the benefit of interjecting 'mplsLdpPeerLdpId' here
as an index.  This is going to be problematic for any implementor of this MIB.

  @
          { mplsLdpFrameRelaySessionTable }
           INDEX   { mplsLdpEntityLdpId,
                         mplsLdpEntityIndex,
                         mplsLdpPeerLdpId,
                         mplsLdpFrSessionMinDlci         }

Same comment as for AtmSessionTable: mplsLdpPeerLdpId is extraneous.

@
          { mplsLdpSessionPeerAddressTable }
           INDEX   { mplsLdpEntityLdpId,
                         mplsLdpEntityIndex,
                         mplsLdpPeerLdpId,
                         mplsLdpSessionPeerAddressIndex       }

Same comment as for mplsLdpHelloAdjacencyTable :
mplsLdpPeerLdpId is extraneous.

MORE DISCUSSION
--------------------------------
  In recent discussions, there was a hypothetical situation
  described whereby one might want to instantiate multiple Entities
  having the same LdpId.  From the perspective of a remote entity, the
  multiple instances would be differentiated with another index called
  mplsLdpPeerIndex.  If the
  above inclusions of 'mplsLdpPeerLdpId' are intended to address that
  scenario, they have failed to do so. It had been conjectured that one
  might want to assign differing Label Distribution methods to the
  same Entity, (a Peer when viewed  from a remote Entity).  This
  could only be done for platform-wide label spaces, where the norm
  would be to assign downstream-unsolicited for _all_ instances of the
  Entity.  In case of conflict arising during discovery, the
  LDP spec states that downstream-unsolicited 'wins' in the negotiation.
  So specifying this functionality in the MIB imputes to the LDP engine
  itself a burden of support that is non-trivial and hypothetical in the
  extreme.  While not precluded by the LDP Specification, this
  functionality is implicitly _not_ included, and therefore should not
  be wired into the MIB.

MORE
----------
 From day one of this MIB design, the term 'Peer' has meant 'remote entity'.
Prefixing this with 'Entity' to make 'EntityPeer' is, in my humble opinion, an
obfuscation of the term.  A Peer is a remote Entity, whether there is
a session with it, a potential session, or even a failed session with it.
It is still a 'Peer'.

>  :)
>  /rs
>
>  +---------------------------------------+------------------------------+
>              |           |                 |         Robert Schmitt
>              |           |                 |       [email-masked] (w)
>             |||         |||                 |         Chelmsford, MA
>            |||||       |||||                 |          978-244-3076
>        ..:|||||||:...:|||||||:..              |
>        C i s c o  S y s t e m s  |
>  +----------------------------------+-----------------------------------+

---

From: Joan Cucchiara <[email-masked]>
Date: Wed, 8 Mar 2000 12:30:24 -0500

> -----Original Message-----
> From: Rob Schmitt [mailto:[email-masked]]
> Sent: Wednesday, March 08, 2000 2:12 PM
> To: [email-masked]
> Subject: LDP MIB Indexing
> 
> 
> 
> 
>   a row in this table?  The third index object is redundant, 

Robert,

I would implore you to refer to version 01 of the MIB which
is available from Noritoshi Demizu's page 
http://infonet.aist-nara.ac.jp/member/nori-d/mlr/

This version has what you are suggesting in this email.

Then, I would like you to take a look at the archives from
July 1999 where several companies requested an additional
index in the Entity table (i.e. mplsLdpEntityIndex).

Then, if you would be so kind as to review the Oslo meeting
minutes, specifically where Bob Thomas (cisco) raised the issue
also (i.e that one-to-one mapping is probably not sufficient
for indexing), and Jim Luciani agreed that it should be fixed
(which we have in subsequent versions of the LDP MIB).

Perhaps I am missing something from this long email, but 
as far as I can tell, this issue has already been addressed 
in the version 01 MIB and in subsequent emails and Oslo meeting
minutes.

Having said this, I agree with you that not all implementations
need mplsLdpEntityIndex, BUT the working group wanted 
this additional index, because some implementations  
obviously do need it.   

Adding indexes and objects because some implementations
need them is not uncommon in Standard MIBs.  This has been
my experience with the IETF Standard MIBs and with MIBs in
other standards bodies as well. 

   -Joan
  
> inconvenient