The MPLS WG Archive

[Adrian Farrel <AF@datcon.co.uk>]

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