Subject: RE: Additional Index for TE-MIB: mplsTunnelTable

From: "Friedeborn, William" <[email-masked]>
Date: Mon, 12 Jun 2000 11:30:34 -0400

What I am puzzeled about is the existence of the Tunnel objects on the
intermediate nodes that you are modeling. From section 2. in the
draft-ietf-mpls-te-mib-03.txt
 
 An explicitly routed LSP (ERLSP) is referred to as an
   MPLS tunnel.  It consists of one in-segment and/or one
   out-segment at the ingress/egress LSRs, each segment
   being associated with one MPLS interface.  These are
   also referred to as tunnel segments.  Additionally, at
   an intermediate LSR, we model a connection as
   consisting of one or more in-segments and/or one or
   more out-segments.  The binding or interconnection
   between in-segments and out-segments in performed
   using a cross-connect. These objects are defined in
   the MPLS Label Switch Router MIB [LSRMIB].
 
I took this to mean that the Tunnel objects can be brought into existence by
either an SNMP request or by a signaling entity at the ingress/egress nodes.
In the case of an SNMP request, the creation of the tunnel (MPLS_TE_MIB)
objects in the head end node would be the trigger that caused the creation
of the LSR-MIB objects in the head end, and kick off the protocols to signal
the lsp to the other nodes (assuming the SignalingProto object is LDP or
RSVP). In the intermediate nodes, the LSR-MIB objects are created till the
egress node is reached, at which point the Tunnel objects are created here
(as this is the egress end). (Actually, the sig proto reaches egress node,
Tunnel objects/LSR-MIB created and intermediate nodes filled in on return
trip). In the case where it is a signaling entity that is creating the
Tunnel objects, I could see that the ingress/egress node knows that the LSP
is an Originating/Terminating LSP and could create the Tunnel objects.
 
What is it in the signaling protocol (RSVP or LDP) that would tell the
intermediate node that the LSP being created should have objects other than
LSR-MIB objects created?
 
Thanks,
Bill
[Friedeborn, William]  -----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Friday, June 09, 2000 12:34 PM
To: Friedeborn, William
Cc: arun Viswanathan; cheenu Srinivasan
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable

At 12:24 PM 6/9/00 -0400, Friedeborn, William wrote:

Sorry for the long interval between the posting and this question. But, in
"draft-ietf-mpls-te-mib-03.txt"
 
7. Example of Tunnel Setup
 
   This section contains an example of which MIB objects
   should be modified if one would like to create
   loosely routed, unidirectional traffic engineered
   tunnel, which spans two hops of a simple network.
   Note that these objects should be created on the
   "head-end" LSR.
 
States that this is created on the head end LSR, how are the objects
propagated to the intermediate nodes in your scenario?

        Via the signaling protocol.

        --Tom

Thanks,
Bill 

-----Original Message----- 

From: Thomas D. Nadeau [ mailto:[email-masked] <mailto:[email-masked]>
] 

Sent: Friday, June 02, 2000 2:39 PM 

To: [email-masked] 

Cc: Cheenu Srinivasan; arun Viswanathan 

Subject: Additional Index for TE-MIB: mplsTunnelTable

    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: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Jun 2000 14:17:57 -0400

Hi,

>I took this to mean that the Tunnel objects can be brought into existence 
>by either an SNMP request or by a signaling entity at the ingress/egress 
>nodes. In the case of an SNMP request, the creation of the tunnel 
>(MPLS_TE_MIB) objects in the head end node would be the trigger that 
>caused the creation of the LSR-MIB objects in the head end, and kick off 
>the protocols to signal the lsp to the other nodes (assuming the 
>SignalingProto object is LDP or RSVP). In the intermediate nodes, the 
>LSR-MIB objects are created till the egress node is reached, at which 
>point the Tunnel objects are created here (as this is the egress end). 
>(Actually, the sig proto reaches egress node, Tunnel objects/LSR-MIB 
>created and intermediate nodes filled in on return trip). In the case 
>where it is a signaling entity that is creating the Tunnel objects, I 
>could see that the ingress/egress node knows that the LSP is an 
>Originating/Terminating LSP and could create the Tunnel objects.

         Yes, your understanding of the MIB seems correct. Initially the intent
of the TE MIB was for its information to be available at the ingress and
egress. However, some implementations may choose to make intermediate
tunnel hop information available at midpoints along the tunnel's path. There
is nothing in the standards which precludes this. However, since this is
an optional behavior, we did not make it mandatory in the MIB.

>intermediate node that the LSP being created should have objects other 
>than LSR-MIB objects created?

         I think that this is an implementation issue. For example, if
one's device supports RSVP, then one may obtain this information
at intermediate nodes by capturing the recorded route.

         --Tom