The MPLS WG Archive

["Friedeborn, William" <wfriedeb@netplane.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. 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) till
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?). It
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.

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. 

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?

3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.

Hope someone can clarify the above,
Thanks,
Bill Friedeborn
 
-----Original Message-----
From: Adrian Farrel [mailto:AF@datcon.co.uk]
Sent: Sunday, June 25, 2000 9:25 PM
To: Thomas D. Nadeau
Cc: 'arun Viswanathan'; 'cheenu Srinivasan'; mpls@UU.NET;
'manis@future.futsoft.com'
Subject: RE: MPLS TE MIB - Doubts


>>At an intermediate node, the ARhop table reflects the actual 
>>routes taken by the LSPs.  Since two LSPs may have the same 
>>tunnel index and tunnel instance, it is necessary to 
>>differentiate the entries in the ARhop table by also using 
>>the sourceAddress.

>I think that you are looking at it a bit backwards. The LSPs do not
>have tunnel indexes; the tunnels point at LSPs via the cross-connects
>which they use. I don't see the case where a single instance of a
>tunnel will be using multiple LSPs.

Is there a difference in your mind between a "tunnel", an "LSP tunnel"
and an "LSP"?

I am not suggesting that "a single instance of a tunnel will be using 
multiple LSPs".  I am pointing out that two tunnels at an intermediate
node may have the same tunnel index and tunnel instance and be 
distinguishable only by the source address.  This is what you have 
noticed and used to extend the indexing of the mplsTunnelTable.

>>Now, at an intermediate node the hop table (i.e. not the ARhop table)
>>reflects the remaining part of the requested ER signaled by the
>>protocol.  Since two LSPs may have the same tunnel index and tunnel
>>instance and yet not have the same remaining ER, surely the hop table
>>also needs to be indexed by source address.

>No. At an intermediate node the HopTable should not reflect anything
>since there is no tunnel head configuration information stored there,
>just ARHop information from say the signalling protocol. Again, the 
>HopTable only contains the *configured* tunnel information, and the 
>ARHopTable contains the actual hop information. At intermediate nodes,
>the ARHopTable *may* contain the remainder of the path for that tunnel,
>and the tunnel table should also be able to identify which LSP (via 
>the XCIndex) it is using. This is something that I believe is very 
>useful for allowing network operators of very large networks containing
>dozens or hundreds of LSRs to visualize what is actually going on at 
>any LSR in their network.

Tom, I understand that you think it is useful to hold the TE MIB at 
intermediate nodes.  If that is the case, I think you should hold _all_
of the information available at the intermediate nodes and not arbitrarily
drop some.  In this case, the information to build the HopTable is
signaled by both RSVP and CR-LDP as the Explicit Route.  Further, the
information signaled as the ER is potentially significantly different
from the ARHopTable which records the actual route.

If the ARHopTable is useful to network managers at intermediate nodes,
the differences from the requested ER (i.e. the HopTable) must also be
very useful.  Consider that the HopTable specifies a loose hop but the 
ARHopTable shows the actual route taken.

>>I'm wondering whether this isn't all getting a bit messy?  It is
>>driven by the idea of maintaining the TE MIB at intermediate nodes
>>which is potentially interesting, but not within the original scope
>>of the TE MIB as I understood it.

>I think that it is potentially messy because we have not necessarily
>been clear in the draft about this since the idea of using the MIB at
>midpoints is a new one that I recently introduced. I apologize for 
>this. We are about to publish the next version of the TE MIB, and I 
>will make sure that this version contains some text explaining this
>topic.

I look forward to reading it.

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422