Subject: draft-ietf-mpls-te-mib-04 clarifications

From: Sowdambiga Karthikeyan <[email-masked]>
Date: Mon, 13 Nov 2000 14:19:02 -0500

Can somebody clarify the following :

1. How is the Tunnel Destination ip address specified in the mplsTunnelTable ? 
     In the example shown in the mib, the source (head-end router) is specified
as the first entry in the hop table and destination is specified as the last
entry in the hop table. Is this is how the destination is specified ? If so,
then we can't reuse the hop table entries for different tunnels as specified in
the mib I guess as different tunnels can have differnt destinations.
     If we can have a separate fields in mplsTunnelEntry specifying the Tunnel
Source and Destination, it will also be helpful in case where we don't want to
specify any explicit path and use the default routing. 

2. mplsTunnelHopTable :
	I guess this is indexed by mplsTunnelHopListIndex and mplsTunnelHopIndex and
can be reused by any number of tunnels. But the description text of
mplsTunnelHopTable specifies that "Each row in this table is indexed primarily
by the same index, mplsTunnelIndex, as the row of the corresponding tunnel in
mplsTunnelTable". 

3. mplsTunnelARHopTable :

	I guess this should be indexed by the mplsTunnelTable indices. (The description
text of mplsTunnelARTable says just mplsTunnelIndex and mplsTunnelInstance but
should also include mplsTunnelIngressLSRId I think). The text says this but
mplsTunnelHopEntry Index field says mplsTunnelARHopListIndex and
mplsTunnelARHopIndex.

Thanks,
Sowdambiga K

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 13 Nov 2000 14:36:52 -0500

>       Can somebody clarify the following :

         Let me give it a try. :P

>the mib I guess as different tunnels can have differnt destinations.

         Yes, that is true. We are doing two things to address this
in version -05 of the MIB. First, we are adding the tunnelDst
directly as part of the tunnelTable. Second, to address your
second concern, there is going to be an additional index added
to the tunnelHopTable. The main reason for doing this is to allow
multiple hop "path options" to be configured for each tunnel
instance. However, this will have the effect of allowing you
to reuse the hop entries if you so choose.

>specify any explicit path and use the default routing.

         The original intent was for you to specify the src/dst as
the first two hops in the hop table and this would result in
default routing behavior. However, we have added a few other things
to the MIB in version -05 to address things like enabling/disabling
CSPF computation on the tunnel, as well as what I described above.

>mplsTunnelHopEntry Index field says mplsTunnelARHopListIndex and

         If you look in the tunnelTable, you will see a variable
called mplsTunnelARHopTableIndex. This is the primary index
into the ARHopTable which is associated with this tunnel. The
secondary index in the ARHopTable is used to index to actual
hops associated with the signalled path. I think that this
indexing is adequate.

         --Tom

---

From: Sowdambiga Karthikeyan <[email-masked]>
Date: Mon, 13 Nov 2000 15:02:22 -0500

Thanks for the answers. Some more comments in-line ...

> CSPF computation on the tunnel, as well as what I described above.

	Can we have one more field in the mplsTunnelEntry, to turn on/off the record
route option (for eg. in case of RSVP, the RRO option can be turned on/off).
This can be interpreted as: if this is turned on, then the AR Hop Table may be
populated by the signalling protocol and if it is turned off, the table won't be
populated. 

	By the way, when can we expect version -05 ?

Thanks,
Sowdambiga K

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 13 Nov 2000 15:13:33 -0500

>populated by the signalling protocol and if it is turned off, the table 

         The ARTable should always contain the actual path being taken
by the tunnel unless it is unavailable, so your interpretation of
it not being populated if RRO is disabled is accurate. I can see
that it might be an interesting nob to turn off/on, but I would want
to hear from others before adding new stuff to the MIB at this point.

>         By the way, when can we expect version -05 ?

         As soon as Cheenu and Arun return from vacation and
we can all have a conference call. ;)  Seriously, it is
finished with only one minor issue that needs to be decided.
After that it will go out. Hopefully this will be within the
next day or so.

         --Tom

---

From: "Manikantan S" <[email-masked]>
Date: Tue, 14 Nov 2000 09:30:57 +0530

Hello Thomas,

#
#-----Original Message-----
#From: [email-masked] [mailto:[email-masked]]On Behalf Of Thomas D.
#Nadeau
#Sent: Tuesday, 14 November 2000 1:44 AM
#To: Sowdambiga Karthikeyan
#Cc: [email-masked]
#Subject: Re: draft-ietf-mpls-te-mib-04 clarifications
#
#>         Can we have one more field in the mplsTunnelEntry, to turn on/off
#> the record
#>route option (for eg. in case of RSVP, the RRO option can be turned
on/off).
#>This can be interpreted as: if this is turned on, then the AR Hop Table
may be
#>populated by the signalling protocol and if it is turned off, the table
#>won't be
#>populated.
#
#         The ARTable should always contain the actual path being taken
#by the tunnel unless it is unavailable, so your interpretation of
#it not being populated if RRO is disabled is accurate. I can see
#that it might be an interesting nob to turn off/on, but I would want
#to hear from others before adding new stuff to the MIB at this point.

We do have such a support to enable and disable RRO option added in our
enterprises MIB. It will be very helpful it is made part of the standard
MIB.

thanks and regards
mani

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 13 Nov 2000 23:16:38 -0500

Hi,

         I will add it as long as there are no objections
voiced within the next few days.

         Thanks for your input.

         --Tom