Subject: RE: MPLS TE MIB - Doubts

From: "Friedeborn, William" <[email-masked]>
Date: Mon, 26 Jun 2000 11:32:59 -0400

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:[email-masked]]
Sent: Sunday, June 25, 2000 9:25 PM
To: Thomas D. Nadeau
Cc: 'arun Viswanathan'; 'cheenu Srinivasan'; [email-masked];
[email-masked]'
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:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: Paul Langille <[email-masked]>
Date: Thu, 29 Jun 2000 10:57:22 -0400

Hi William. In the following text I have a few 'answers'. Standard
disclaimer of course! (My answers may not be totally accurate. If this is the
case then I am sure that someone will speak up!)

"Friedeborn, William" wrote:

> created on.

I believe that this is correct.

> In my first cut at understanding the use of Tunnels, I could see

This is basically correct also. (You may need more than the LSP ID to uniquely
identify an LSP. See the following text.)

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

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

So what is the difference between an LSP and an LSP tunnel? If you look in
section 2.1 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt it has the following text:

"The ingress node of an LSP can use a variety of means to determine which
packets are assigned a
particular label.  Once a label is assigned to a set of packets, the label
effectively defines the "flow" through the LSP.  We refer to such an LSP as an
"LSP tunnel" because the traffic through it is opaque to intermediate nodes
along the label switched path."

I think the difference is related to the signaling. To me an LSP has a 'hop by
hop' feel to it (e.g. LDP). When signaling an LSP the FEC is passed along to
each node in the path. This gives the intermediate nodes a hint about the data
that will traverse the LSP. For LSP tunnels the FEC decision is made at the head
end of  the LSP tunnel. From a signaling perspective, the nodes along the (LSP
tunnel) path do not know anything about the data traversing the LSP tunnel. The
beauty (or the confusing part) of all this is that the label swap operation is
the same for both LSPs and LSP tunnels.
Does this help or did I make it worse?

    Paul

--
Paul Langille                e-mail: [email-masked]
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 29 Jun 2000 16:38:41 -0400

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

> > egress node creating LSR-MIB objects along the way (or on reverse trip)
> > (i.e. how would this index info be passed on the LSP creation via RSVP?).
>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.

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

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

>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

---

From: Paul Langille <[email-masked]>
Date: Thu, 29 Jun 2000 17:44:02 -0400

Hi Tom. I apologize. I did not mean to imply that these comments would be
incorporated into the MIB. I was just trying to shed some light on some commonly
used terms. I choose the term "LSP tunnel" over "tunnel" based on the text in
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.

    I must say I am surprised by your 'tunnel statement' below. I thought that the
TE MIB was based on RSVP and CR-LDP (explicitly routed) LSPs. I did not think of it
as a general tunnel MIB. Don't get me wrong, I don't mean to imply that this is a
bad thing. I did not realize the scope was this broad. I guess the first comment I
have is that the text at the front of the MIB needs to reflect this.

            Paul

"Thomas D. Nadeau" wrote:
<snip>