The MPLS WG Archive

[dwilder@baynetworks.com (David Wilder)]

I'd like to know too what people are thinking is the difference between a
"tunnel", an "LSP tunnel" and an "LSP"?  I see the terms used interchangably
on this list by some but as different entities by others.

Dave

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