Subject: Re: Few questions related to MPLS-TE-MIB: tunnels vs tunnelInstances

From: Thomas Nadeau <[email-masked]>
Date: Fri, 19 Oct 2001 15:22:47 -0400

Hi Sanjaya,

>         Hi! I have few comments/questions related to the MPLS-TE-MIB.
>         Your help will be appreciated.
>
>         Q1. mplsTunnelTable represents two kind of concepts:Tunnel &
>         TunnelInstance.
>
>         It may make sense, to keep some of the attributes associated
>         with a tunnelInstance same, if they belong to the same tunnel.

         Yes. This is precisely why the tunnel instance can be used
to group together tunnel heads and their signaled instances. In cases
where an attribute does not make sense for an instance, it is noted
in the description of that object, and does have a known value like 0
indicating this state.

>         Is my assumption correct ? Is so, should there be two tables
>         : mplsTunnelTable & mplsTunneInstanceTable ?

         No. We chose to keep them in the same table in an effort to
keep things simple. Some implementations choose to make instance
0 the tunnel head/if, and the other instance entries the signaled instances
of the tunnel. Midpoints would not show instance 0, since the tunnel interface
does not exist there.

>         Q2. Specifically, what is the scope (tunnel or tunnelInstance)
>         of the following attribute ?
>
>                 a) mplsTunnelName - Should this be same for all tunnel
>                 instances, within a tunnel ?

         This is just the name of the tunnel. It is possible to name
the instances slightly differently so that you can distinguish them
that way, but the indexing does this explicitly too.

>                 b)mplsTunnelIfIndex - Do we have one ifIndex per
>                 tunnel or one ifIndex per tunnelInstance ?

         One ifIndex per tunnel head, but due to the nature of the MIB,
it is certainly possible to assign different ones to each instance. However,
in all of the implementations that I know of that use an ifIndex for a tunnel
head, the tunnel instances represent signaled (pre-signaled backups, make-
before-break, or actively) LSPs that run over an MPLS interface.

>                 [Does it make sense to create one ifIndex per
>                 tunnelInstance ???]
>
>         Q3. tunnelInstancePriority is valid ONLY within the context of
>         a tunnel.

         Yup.

>         Does this mean that two tunnelInstances that belong to two
>         _different_ tunnels (different tunnelIndex) should not be used
>         for load sharing even if the -IngressLSRId , EgressLSRId &
>         tunnelInstancePriority are same?

         I think that you can load share across two different
tunnels this way. In fact, I know that you can. Perhaps we
should just remove the sentence that mentions load-sharing, as it
seems confusing? The MIB does not specify how load-sharing takes
place other than  if two instances share the same priority and are active 
at the
same time (operStatus = up), it seems to make sense that they are being used
for load sharing. This makes sense too across tunnel heads, but also
make sense that the highest priority instances that are active be used
for load-sharing too. This is difficult to expose in the MPLS TE MIB, so I
don't think that load-sharing relationships per se should be represented in
there. The FTN MIB is really where you specify how load sharing is taking
place since it is really a FTN relationship you are trying to expose.

>         * It may be helpful to add a little more text to the draft,
>indicating  when should the user create a new tunnelInstance, instead
>of new tunnel.

         Certainly.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.