Subject: ICMP support for labeled IP packet

From: Jason Chen <[email-masked]>
Date: Mon, 08 Nov 1999 10:18:15 -0800

Hi, All,

Is it a mandatory requirement to generate ICMP messages for
un-forwardable
labeled IP packet ?

Regards,
Jason

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 08 Nov 1999 16:27:23 -0500

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: Ron Bonica <[email-masked]>
Date: Mon, 08 Nov 1999 21:12:52 -0500

Jason,

The MPLS encapsulation draft sites situations in which it is desirable to 
generate ICMP messages, but does not dictate their generation as an
absolute requirement.

                                       Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jason
> Chen
> Sent: Monday, November 08, 1999 1:18 PM
> To: [email-masked]
> Cc: Jason Chen
> Subject: ICMP support for labeled IP packet
> 
> 
> Hi, All,
>