Subject: RE: MPLS TE MIB - Doubts

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 19 Jun 2000 08:57:53 -0400

Hi,

         Replies embedded in black text below.

At 09:22 PM 5/18/00 +0100, Adrian Farrel wrote:
>Thanks Cheenu, Arun and Tom.
>Good stuff.  Some responses (which appear to be in green for those 
>following the thread in html)
>
>Adrian,
>
>Please see our comments to the questions you sent some time back about
>the TE MIB. (Your questions are in black.) - blue?
>
>3. LSPId explicit hop type
>    Is there any reason to prevent configuration of an explicit hop
>    of type LSPId?  I suggested some ASN.1 for this in an email to
>    Tom on 7th Jan.
>
>         If ldp is chosen to route the tunnel then we'll add this as
>         a choice for the hop type.
>
>I'm not quite sure what your answer means.  I think you're saying you'll 
>add the hop type but only allow it if the signaling protocol is flagged as 
>[CR-]LDP.  This would be great.

         If any of the signaling protocols can handle such an option,
then we will extend the MIB to handle this. At present, none of
the MPLS signaling protocols officially support this.

>6. MPLS Tunnel Resource Table
>    This table is a welcome addition.
>    I believe you need to be very careful because of the differences
>    between forward and reverse resource reservation.  For example,
>    for an RSVP tunnel, what is configured here must be the TSpec.
>    Clearly, sharing TSpecs is useful from a configuration point of
>    view, but says nothing about sharing of resources which is
>    determined elsewhere in the network.  Is it your intention that
>    this table is updated on the reverse path?
>
>         - tunnels are unidirectional; so the issue of bidirectional
>                 resource reservation does not arise
>It wasn't my intention to talk about bi-directional LSPs at this point 
>(although that is an interesting topic of conversation in this 
>regard).  When I talk about forward and reverse reservation I am simply 
>distinguishing between CR-LDP where the resources are reserved as the 
>Label_Request traverses the network, and RSVP where the resources are 
>(strictly speaking) only reserved when the Resv travels back.  Thus the 
>information in the MIB row is far more likely to reflect the true 
>reservation in CR-LDP than in RSVP unless the table is updated by the 
>protocol code on completion of LSP setup to reflect the flowspec.

         The ARHopTable is captures the actual reservation, and is
applicable to both signaling protocols.

>15. mplsTunnelXCIndex
>    It would be good to expand on the Description.  Explain that this
>    object is only writeable in conjunction with pre-existing entries
>    in the LSR MIB.  Say that in normal signaled operation this object
>    will be set by the LSR.  Explain the meaning of zero.
>
>         We'll see how to improve the description.
>How about...
>        "This variable represents an index into the
>         mplsXCTable. This table identifies the segments
>         that compose this tunnel, their characteristics,
>         and relationships to each other.
>         In the case where a signaling protocol is used
>         to set up the tunnel, this field is set by the
>         MPLS code to reflect the row in the mplsXCTable
>         that has been set up to describe the cross-
>         connect for this LSP and SHOULD NOT be changed.
>         In the case where the tunnel has been statically
>         configured by writing to the tables in the LSR
>         MIB, this field MUST be set to indicate the
>         correct entry in the mplsXCTable."

         We would prefer the following:

        "This variable represents an index into the
         mplsXCTable. This table identifies the segments
         that compose this tunnel, their characteristics,
         and relationships to each other.
         In the case where a signaling protocol is used
         to set up the tunnel, this field is to reflect
         the row in the mplsXCTable
         that has been set up to describe the cross-
         connect for this LSP and SHOULD NOT be changed.
         In the case where the tunnel has been statically
         configured by writing to the tables in the LSR
         MIB, this field MUST be set to indicate the
         correct entry in the mplsXCTable."

>mplsTunnelResourceInMaxRate etc.
>MplsBitRate is defined in the LSR MIB in 1,000 bits per second.
>The descriptions for these fields need updating.  Additionally,
>the UNITS tag is ood.
>
>         What do you mean by this sentence ("ood")?
>Sorry.  ood = out of date.
>In other words, all of the UNITS definitions say "bits per second" and 
>should say "1,000s of bits per second".

         We will fix this in the next draft.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 19 Jun 2000 08:56:59 -0400

Hi,

         Our responses are in blue.

>1) Local Cookie, Remote Cookie. - How do I get this value, Do I get this value
>by concatenating
>    a) Extended Tunnel Id and Tunnel ID field values in case of RSVP path 
> messages?
>    b) Ingress LSR Router ID and Local CRLS- Id in case of CRLDP Lbl Req 
> messages?

         By consensus of the WG mailing list, these objects are being removed
in the next version of the draft.

>2) What is the significant difference between the MIB objects 
>"mplsTunnelOwner"
>and "mplsTunnelSignallingProto"? and how are these fields to be used?
>
>   a) If the field "mplsTunnelOwner" is set to snmp(1) and the "mplsTunnel
>       SignallingProto" is set to "ldp" / "rsvp", does this mean once the row
>       status is made up, the tunnel must be established using CRLDP or
>       RSVP respectively?
>
>   b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" does it mean
>      that the tunnel is dynamically established using IGP (routing info)
>      information? If so will the "mplsTunnelSignallingProto" have value
>      "ldp" or "rsvp" respectively?

         If the tunnel is created my a management protocol operation and
is signaled, then the owner would be management, and the signaling protol
would be whatever signaling protocol was used. If the tunnel is manually
created, the owner would be set to management and the signaling protocol
would be set to none.

         --Tom

---

From: Adrian Farrel <[email-masked]>
Date: Fri, 23 Jun 2000 02:08:52 +0100

Tom, Thanks.

>>I'm not quite sure what your answer means.  I think you're
>>saying you'll add the hop type but only allow it if the 
>>signaling protocol is flagged as [CR-]LDP.  This would be
>>great.

>        Perhaps I was confused about this. Now that Arun and I 
>have discussed this, we now recall that we agreed to add this.
>Here is a description of the object type. We have also added the
>LSP ID to the hop entry as well.
>
>mplsTunnelHopAddrType OBJECT-TYPE
>SYNTAX        INTEGER {ipV4(1), 
>                       ipV6(2), 
>                       asNumber(3), 
>                       lspid(4) 
>                      }

Great.  Thanks, that's just what I wanted.  You'll also need to add another
object to express a hop of this type as I suggested in January, viz.

MplsTunnelHopEntry ::= SEQUENCE {
      mplsTunnelHopIndex              Integer32,
      mplsTunnelHopAddrType           INTEGER,
      mplsTunnelHopIpv4Addr           IpAddress,
      mplsTunnelHopIpv4PrefixLen      INTEGER,
      mplsTunnelHopIpv6Addr           Ipv6Address,
      mplsTunnelHopIpv6PrefixLen      INTEGER,
      mplsTunnelHopAsNumber           INTEGER,
      mplsTunnelHopLspId              INTEGER,
      mplsTunnelHopStrictOrLoose      INTEGER,
      mplsTunnelHopRowStatus          RowStatus
   }

mplsTunnelHopLspId OBJECT-TYPE
   SYNTAX        OCTET STRING (SIZE(6))
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If mplsTunnelHopAddrType is lspId(4), the LSPID
        over which to route this hop.  This is encoded as
        two bytes of Local LSPID followed by four bytes of
        Ingress LSR Router ID.
        This object is not significant otherwise and should
        return a value of 0."
   ::= { mplsTunnelHopEntry 8 }

>>>>6. MPLS Tunnel Resource Table 
[Lots of pruning!]

OK.  I think we now have the same understanding on most of this.
We have...
- mplsTunnelResourceTable is configured and not updated by 
  the protocol code
- mplsTrafficParamTable reflects the actual reservations made
- if two rows in the mplsTunnelTable reference the same row in
  the mplsTunnelResourceTable and the protocol is RSVP then
  the LSPs have the same TSpec
- if two rows in the mplsIn/OutSegmentTable reference the same
  row in the mplsTrafficParamTable then the segments share the 
  same reserved resources

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

---

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

Comments are inline.

>I have some doubts. Can you please clarify me.
>
>#mplsTunnelHopEntry  OBJECT-TYPE
>#SYNTAX        MplsTunnelHopEntry
>#MAX-ACCESS    not-accessible
>#STATUS        current
>#DESCRIPTION
>#"An entry in this table represents a tunnel hop.  An entry is created by a
>#network administrator for signaled ERLSP set up by an MPLS signaling
>#protocol."
>#INDEX { mplsTunnelHopListIndex, mplsTunnelHopIndex }
>#::= { mplsTunnelHopTable 1 }
>
>It has been proposed/suggested as above, the index definition for
>TunnelHopEntry in the forthcoming TE MIB.
>
>(Probably the MIB might be help understand better. Since it is in the
>draft stage and we use the indices in our discussion, I request you this 
>clarification.
>Sorry if I have missed some mails where you might have clarified, if so
>just please refer them).
>
>1) My understanding of the mplsTunnelHopListIndex, is that it is an index
>    to a list of ER Hops.
>    i.e. when the rows in the Tunnel Hop Table are to be created, I can
>    create rows with the following indices combination.
>    a) mplsTunnelHopListIndex = 1, mplsTunnelHopIndex  = 1
>    b) mplsTunnelHopListIndex = 1, mplsTunnelHopIndex  = 2
>    c) mplsTunnelHopListIndex = 1, mplsTunnelHopIndex  = 3
>    d) mplsTunnelHopListIndex = 2, mplsTunnelHopIndex  = 1
>    e) mplsTunnelHopListIndex = 2, mplsTunnelHopIndex  = 2
>    f) mplsTunnelHopListIndex = 2, mplsTunnelHopIndex  = 3
>
>   Now I have two ER Hop Lists which has 3 ER hops each.
>
>   Is my understanding correct?

         Yes, I believe that you are correct. However,
we have modified the tunnelEntry to contain an extra
object, which would be the primary index into the
mplsTunnelHopTable. This would obiate the need to
extend the indexing of the hop entries in the
same way in which the tunnelTable was extended recently.
This change has the added advantage of the tunnelHopTable
indexing being totally independent of how the tunnelTable
is indexed.

>2) If my above understanding is wrong, then the following questions
>    are not valid.
>
>    a) If I am right, then my questions are how are we associating the
>    ER Hops to the tunnels?

         We always have associated them.

>3) Though with the earlier MIB we were forced to configure the
>    ER Hop information again and again for different tunnels (when
>    a ER hop is shared by a set of tunnels, or otherwise set of
>    tunnels pass through the same ER Hop), It was straight forward
>    and easy to implement.  Clarifications will help me appreciate
>    the new hop table proposal.

         Exactly. If we use the indexing scheme described above,
it is very easy for multiple tunnels to point at the same set
of ERHops.

         --Tom