The MPLS WG Archive

[abhay <abhay@multitech.co.in>]

Hi,

  There are two sides of the coin here.Walking through the T.E MIB requires Chang's indexing idea

  But to have a LSP Management with the T.E MIB we can have the original order of indices as mentioned

  by the authors.One way to achieve this is  by actually having Ingress Based Pointers to the original

  Tunnel Table Entries in the  MIB.In this way,we can get the specified management functionality and also

  satisfy the indices rules in the MIB.

  Moreover,the RSVP / CR-LDP Signaling protocols have a small difference,the difference being the

  tunnel instance.So,if one is having both CR-LDP and RSVP operating in a disjoint manner ,we may not

  consider how we have the Tunnel head configuration.

  As I understand that Cisco's implementation has a source address NULL or zero to identify tunnel

  head configurations.

  Hope this helps.

  Happy MIB Walking..

  Regards,

  Abhay

"Thomas D. Nadeau" wrote:

         Hi,

         I think that if you think about the
indexes a little differently as we have done in
our implementation, you will find that they are
quite suitable in the order in which they are
specified. If you assign the tunnel index,
ingress and egress lsr ids according to the way
they normally should be, and each signaled LSP for
the tunnel uses a non-0 index, then use the convention
that the 0th instance is the tunnel head, you
will be able to sort the tunnel heads and the
signaled LSPs nicely. Doing this will produce a
MIB walk similar to:

         tunnelEntry.10.0.*.*  (tunnel head interface)
         tunnelEntry.10.1.*.*  (signaled LSP)
         tunnelEntry.10.2.*.*  (pre-signaled backup LSP)
         etc...

         Then, to find the LSPs that originate at
a specific LSR, you can just search for the 0th instances,
since heads will only exist on the LSR where the tunnel
originates. From that you will also know that any LSP
signaled for that head will also originate at that
LSR. You can alternatively use the mplsTunnelRole
object and test if it is head/non-head to determine
origin, since midpoint LSPs will not show up with
a role of "head".

         --Tom

>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.