Subject: Additional Index for TE-MIB: mplsTunnelTable

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 02 Jun 2000 14:39:21 -0400

Hi,
I would like to modify the mplsTunnelEntry to include
a few more objects as well as indexes. I wanted to
bring these changes to the list for discussion before
adding them to the TE MIB due to the fact that they
constitute a significant change, and we did not want to
surprise anyone. This change comes from my implementation
experience with the current version of the MIB, so it is
grounded in an actual implementation.

I would like to add five additional values to the mplsTunnelTable
as well as augment the current indexes with two more indexes:

mplsTunnelSrcAddrType     INTEGER,
mplsTunnelSrcAddrIPv4   InetAddresIPv4,
mplsTunnelSrcAddrIPv6   InetAddresIPv6,
      Now let me explain why. When you want to examine the tunnel
      entry at a midpoint, it is possible for tunnelId/tunnelInstance
      collisions to occur because the mplsTunnelId + mplsTunnelInstance
      variables are not guaranteed to be unique within an MPLS domain.
      A simple example of this occurs when LSR A has tunnelId = 1,
      tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
      which utilize the same next hop, LSR C. If one examines the
      tunnel table at LSR C, it is impossible to distinguish both tunnels;
      hence, the third index. A fourth index is required because we need
      to support V6 addresses.

      An additional benefit of the added indexes is that one can now
      sort tunnelEntries based on src address, which is quite useful
      at mid-points and tunnel tails. For this same reason, it might be
      useful to add the tunnel destination address to the indexes of
      this table as well.

      --Tom

---

From: Paul Langille <[email-masked]>
Date: Mon, 05 Jun 2000 17:32:55 -0400

Hi Tom. I agree with you (and Mani) that you need the triplet <
Tunnel index, Tunnel Instance and Source address> to uniquely identify a
tunnel. Good catch.
    So now I am wondering, do you need the tunnel cookie (since it is
the source address and the tunnel index)? Could you also give some brief
examples as to how this would work with bi-directional tunnels. (I may
be a bit confused by the mplsTunnelDirection object.)

            Thanks
            Paul

--
Paul Langille                e-mail: [email-masked]
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 05 Jun 2000 17:35:25 -0400

Hi Paul,

> Tunnel index, Tunnel Instance and Source address> to uniquely identify a 

         Thanks.

>     So now I am wondering, do you need the tunnel cookie (since it is the 
> source address and the tunnel index)?

         I believe that we are going to eliminate the cookies from the MIB.
There was some discussion about this a while back.

>Could you also give some brief examples as to how this would work with
>bi-directional tunnels. (I may be a bit confused by the
>mplsTunnelDirection object.)

         Do you still need the example now that you know that the
cookie is deleted, or were you referring to the addition of the
srcAddr to the index?

         --Tom

---

From: Paul Langille <[email-masked]>
Date: Tue, 06 Jun 2000 08:38:08 -0400

Hi (again!) Tom,

> There was some discussion about this a while back.

Thanks. I don't recall the discussion. I will check the archives.

> cookie is deleted, or were you referring to the addition of the

It is not clear to me how to represent a bi-directional tunnel with the MIB.
Some of my confusion may come from the fact that I don't understand the
mplsTunnelDirection object. For example, what does it mean to have this object
set to "bi-directional"? Does it mean that this row refers to a bi-directional
tunnel? Does the TunnelDirection (in, out) have any significance at the tunnel
midpoint? What role does the cookie (or the lack of one!) play in
bi-directional tunnels?

So rather than answer these questions one at a time, it might be faster to
catch them all with an example. I assume that you have a solution in mind but
you currently don't have the cycles to put it in the MIB. Have you implemented
bi-directional tunnels?

        Thanks Paul

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Jun 2000 14:52:00 -0400

>It is not clear to me how to represent a bi-directional tunnel with the MIB.

         See my last email to Adrian.

         --Tom