Subject: mplsTunnelEntry index

From: Koling Chang <[email-masked]>
Date: Thu, 12 Jul 2001 17:07:49 -0400 (EDT)

Hi!

The latest MPLS TE-MIB (draft-ietf-mpls-te-mib-06.txt,
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt)
indicates that the index for the mplsTunnelTable are the following
four things:

 mplsTunnelIndex, 
 mplsTunnelInstance,
 mplsTunnelIngressLSRId, 
 mplsTunnelEgressLSRId.

Although this index set is sufficient to global-uniquely identify an
LSP, it is not very convenient to use when walking through the MIB table
using GetNext. Finding a list of LSPs originated at a specific LSR
requires going through the entire table and do index matches.

Since the tunnel index and instance are picked at the ingress, I suggest
to change the significance of the indexes to the following
order:

mplsTunnelIngressLSRId,
mplsTunnelIndex,
mplsTunnelInstance,
mplsTunnelEgressLSRId.

Koling Chang, Ph.D.
Principal Software Engineer
Axiowave Networks, Inc.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 14 Jul 2001 14:17:58 -0400

>Thanks for your response. First let me try to completely understand
>what you described:
>
>When you say tunnelEntry.10.0.*.*
>       Do you mean the following?
>         mplsTunnelIndex = 10
>         mplsTunnelInstance = 0
>         mplsTunnelIngressLSRId = *
>         mplsTunnelEgressLSRId = *
>
>If yes, please consider the case below:
>
>If operator is createing 10 LSPs on Node A towards Node B, with tunnel
>index 1 to 10, assuming these are what "mplsTunnelIndexNext" returns on
>Node A after each lsp creation. If your convention is followed that
>instances are not zero for non-head LSPs, then in Node B's
>mplsTunnelTable, we will see the following:
>
>tunnelEntry.1.1.A.B
>tunnelEntry.2.1.A.B
>...
>tunnelEntry.10.1.A.B
>
>If 11 tunnels are then be setup on Node B towards Node A,
>the table on Node B will look like this:
>
>tunnelEntry.1.0.B.A
>tunnelEntry.1.1.A.B
>tunnelEntry.2.0.B.A
>tunnelEntry.2.1.A.B
>...
>tunnelEntry.10.0.B.A
>tunnelEntry.10.1.A.B
>tunnelEntry.11.0.B.A

         This looks correct assuming that the same
primary tunnel index is used.

>On Node B, don't you need to walk through the entire 21 entries to collect
>all the tunnels that have heads on node B? If tunnel 1 to 10, originaled
>on Node B are deleted, then the table becomes:
>
>tunnelEntry.1.1.A.B
>tunnelEntry.2.1.A.B
>...
>tunnelEntry.10.1.A.B
>tunnelEntry.11.0.B.A <--
>
>Don't you need to walk through the entire table to
>find the first tunnel that is locally configured?

         Yes, and as I mentioned, you can quickly
note which are heads and which are not by using
the indexing convention I outlined. Remember, there
are many ways to skin a cat, and the indexing scheme
chosen was what agreed to early on is the one which
we are using today. I understand that there are
alternate methods for indexing this table, and
in some instances they might be arguably better,
but again the indexing scheme that exists is the
one that was agreed upon by the working group early
on and during the working group's last call.

>My point is, tunnelEntry.1.0.B.A and tunnelEntry.1.1.A.B may be totally
>irrelevant due to the fact that tunnelIndex is only significant to the
>head (source) end. Why do we put them together in the table?
>By the way, you implied that the TunnelInstance is "designated to"
>non-zero at the tail end. Do you mean that the same LSP have different
>index (mplsTunnelInstance) on head and tail nodes?

         The same LSP id cannot be used to identify
different tunnels, so the instance ID will be different.

>Is the
>mplsTunnelInstance value carried by signalling protocols at all?

         Yes. I believe that RSVP carries it directly.
CD-LDP has no notion of instance, so the convention I
outlined will need to be modified if you happen to be using
CR-LDP.

         --Tom