The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

> > A couple of points I am a little confused on in this thread about adding a
> > SourceID to the Tunnel indexing scheme.
> > 1. Tunnel Indexing - When I look at the current indexing scheme of
> > TunnelIndex, TunnelInstance, there is nothing here that would indicate that
> > this information should have any significance  other than to the node it is
> > created on.
>
>I believe that this is correct.

         It has been suggested that the tunnel indexes be the same
at each hop along the route of the tunnel. Doing so makes it
a whole lot easier for the management application to put the
pieces of the tunnel together. But note that the configuration
of the tunnel is only done at origination point of the tunnel
(i.e.: head). This is also why the tunnelIngressRouterId was
added to the indexing of the tunnelEntry.

> > In my first cut at understanding the use of Tunnels, I could see
> > that the ingress node could have the Tunnel objects defined via SNMP/cli.
> > The Tunnel instrumentation would pass the info down to the supporting
> > protocol statemachine (LDP or RSVP), the protocols would signal down to the
> > egress node creating LSR-MIB objects along the way (or on reverse trip)
> > the egress node is reached, where the LSR-MIB and Tunnel objects are
> > created. Since my understanding of the LDP and RSVP protocols is not that
> > detailed, I didn't see where the Tunnel indexing info fit in LDP or RSVP
> > (i.e. how would this index info be passed on the LSP creation via RSVP?).
> > seemed that the intent was to use the cross-connects on each node to
> > associate the Tunnel object using it. And the LSPID to track the 
> sequence of
> > cross-connects so that one could follow an LSP from node to node via the
> > LSPID.
>
>This is basically correct also. (You may need more than the LSP ID to 
>uniquely identify an LSP. See the following text.)

         Yes, this is true.

> > If the intent is that a tunnel definition should have more than just local
> > significance, shouldn't there be some tunnelID defined (like LSPID)? I can
> > see that adding a SourceID makes it possible to pass these locally defined
> > indices, but it seems odd to me that when you define a set of indices 
> on >one machine, that another machine should know about them.
>
>Have a look at draft-ietf-mpls-rsvp-lsp-tunnel-05.txt and focus on the session
>object and the sender template. The session object contains the  "IPv4 tunnel
>end point address", "Tunnel ID", and the "Extended Tunnel ID". If you make the
>Extended Tunnel ID equal to the tunnel ingress node's IP address then you have
>uniquely identified the two ends of the tunnel. The Tunnel ID is used to
>identify multiple tunnels between the same source and destination. (I believe
>this is what you are looking for.)
>If you now want to move traffic from one tunnel to another without disrupting
>service (aka "make-before-brake") you would keep the same session object and
>modify the LSP ID in the sender template. (This is explained much better in
>draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.)
>I think the use of the Source ID (and the Tunnel ID) will be clearer in 
>the next version of the MIB. (Right Tom?)

         Yes, this is correct.


> > 2. Multiple LSPs on a Tunnel - Looking at the LSR-MIB I see that the
> > cross-connect object has a XCIndex and three other indices. I assumed these
> > were set up to support MP-PT, and PT-MP by keeping the XCIndex and
> > OutSegmentIndex constant and varying the InSegmentIfIndex/label, the MP-PT
> > case is achieved, and similarly the PT-MP could be done. (Is it
> > possible/practical to have MP-MP?). In any case, it seemed that there could
> > be a situation where a Tunnel had a XCIndex that referenced  more that one
> > row in a XC table. I wasn't sure if the multiple rows in the XC table ment
> > multiple LSPs? Or just a MP-PT or PT-MP single LSP?

         First of all, the TE MIB model only supports point-to-point
TE tunnels. However, you are correct in pointing out that
a particular XCentry can facilitate multiple in and outSegments
in a MP-MP or PT-MP situation.

> > 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.
>
>First let's get rid of one of the terms. I think that a "tunnel" and an "LSP
>tunnel" in the context of the TE MIB are the same things. So throw out 
>"tunnel". It is too general.

         No LSP Tunnel. The use of "tunnel" in the TE MIB
refers to the specific parameters used to describe a
traffic engineered tunnel which may or may not result in
the formation of an LSP.

         --Tom