Subject: Question on tunnel Interface (w.r.t TE MIB)

From: "Dominic-Savio, Patrick" <[email-masked]>
Date: Mon, 29 Oct 2001 11:46:15 -0500

Here is my question:
When you create a tunnel at the head-end, you can set the mplsTunnelIsIf
variable to TRUE and this specifies that an interface will be created over
the tunnel at the head-end. What is the procedure for identifying at the
tail-end that this tunnel is to be used as an interface (for the purpose of
receiving packets coming from the head-end)?.
Should a tail-end manual entry be made in the TE table ahead of time with
the mplsTunnelIsIf value set to TRUE?. If so, it does not seem like there is
a (documented) way to uniquely identify an incoming signalling message (for
tunnel termination) using the tail-end TE MIB specification. In other words
how do I match a user created tail-end configuration with (say) a RSVP
session that is terminating on this tail-end LSR.

Thanks

---------------------------------------------------------
Patrick Dominic-Savio            E-mail: [email-masked]

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 29 Oct 2001 12:05:04 -0500

Lets first be specific about which document
we are referring to. It sounds like you are referring to
the MPLS-TE-MIB. If you are, then read on, otherwise
skip my reply.

>the tunnel at the head-end.

         Not really. This means that the tunnel IS the ifIndex associated
with it.

>What is the procedure for identifying at the

         First, note that this functionality is optional in the MIB. Second,
this can be implemented only if your device creates an tunnel entry at
the egress. Note that this will be at the penultimate-hop, if that is
enabled.

>the mplsTunnelIsIf value set to TRUE?.

         Depends on your implementation. I suppose that you could manually
create such an entry, but I am not sure why. Some implementations represent
the tail of the tunnel the same way that other midpoints are represented 
(without
an ifIndex) except that the tunnelRole would be set to tail(3).

>If so, it does not seem like there is

         You should be able to figure this out given the RSVP-TE information
stored at the tail-end router. It should tell you that this RSVP-TE session
terminates at that LSR the same way that a mid-point LSR tells keeps
information about transit-sessions.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Dominic-Savio, Patrick" <[email-masked]>
Date: Mon, 29 Oct 2001 16:29:46 -0500

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Monday, October 29, 2001 12:05 PM
To: Dominic-Savio, Patrick
Cc: [email-masked]'
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)

Sorry I was not specific, but yes, I am referring to the MPLS-TE-MIB. 

Here is my question:

        First, note that this functionality is optional in the MIB.  
 
Even if it is optional, I think it should be clearly specified how the
feature is to be supported using the MIB table(s).
 
 Second,
the egress.  
Yes, of course.
 
 Note that this will be at the penultimate-hop, if that is 
enabled.
Why should it be at the penultimate-hop ?. RSVP signalling goes all the way
to the tail-end and the tail-end TE tunnel entry can be created there.
(Also, penultimate-hop popping is optional).

 
The reason to create this entry would be so that the user can set the
mplsTunnelIsIf value to TRUE. So it is clear based on the configuration that
this terminating tunnel will be a terminating point of an unidirectional
interface.

 
So you are saying that the terminating point of a tunnel interface is
identified on the terminating router based on the RSVP session information
for that tunnel?. But that is confusing if the user has to use the
mplsTunnelTable to configure interface capability on the head-end and use
some other table to configure the interface capability at the tail-end.
 
Let me give you an example, lets say you have router A and router B, with
some intermediate hops (that are of no consequence).
There is a tunnel (tunnel index 1) with  mplsTunnelIsIf set to TRUE
originating on Router A and terminating on Router B. Also mplsTunnelName for
tunnel 1 is "tunIntf1"
So you have an interface by the name of "tunIntf1" on Router A.
If you want to have an interface on Router B to receive packets sent from
Router A on tunIntf1, how do you set it up ? and where do you specify the
tunnel interface name on Router B?
 
Thanks

        --Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 29 Oct 2001 16:50:55 -0500

>Why should it be at the penultimate-hop ?. RSVP signalling goes all the 
>way to the tail-end and the tail-end TE tunnel entry can be created there. 

         I was thinking of the LSR MIB this morning at the same time.
You are right.
>>The reason to create this entry would be so that the user can set 
>>the  mplsTunnelIsIf value to TRUE. So it is clear based on the 
>>configuration that this terminating tunnel will be a terminating point of 
>>an unidirectional interface.
>identified on the
>terminating router based on the RSVP session information for that tunnel?.

         Most if not all MPLS implementations that I know of only require 
the operator
to configure the tunnel at the head end. If your implementation wishes to 
create an
interface for the tail end of the tunnel, it can do this based on the 
acceptance of
an RSVP-TE session at the tail point, or via manual configuration. However, 
making
this ifIndex consistent with the one at the head automatically is something 
that I think you
will have to do manually.
>But that is confusing if the user has to use the mplsTunnelTable to 
>configure interface
>capability on the head-end and use some other table to configure the 
>interface capability
>at the tail-end.

         How else would you propose getting that information to the tail? 
The only way I see
doing this is manually. I don't believe that there is a way of getting this 
information
to the tail using RSVP-TE, but I could be wrong.

         --Tom

>originating on Router A and terminating on Router B. Also mplsTunnelName 
>for tunnel 1 is "tunIntf1"

---

From: "Dominic-Savio, Patrick" <[email-masked]>
Date: Mon, 29 Oct 2001 17:41:54 -0500

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Monday, October 29, 2001 4:51 PM
To: Dominic-Savio, Patrick
Cc: [email-masked]'
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)

enabled. 

        Most if not all MPLS implementations that I know of only require the
operator
to configure the tunnel at the head end.  
 
But, if you want to treat a tunnel as a real interface (and assign IP
addresses etc. to it at both ends) you will have to have interface
configuration at both the head and tail ends. If you don't have a tail end
interface configuration the only reason to use tunnel interfaces is probably
to make the tunnel *look* like an interface on the head end router. This
however means that you are treating it as an interface on one side and
treating it as a simple terminating tunnel on the other side. This seems
anomalous.
 
 If your implementation wishes to create an
 
I think you misunderstood, the actual value of the ifIndex is of no
consequence, you just have to have a corresponding interface at the other
end. 

at the tail-end.

        How else would you propose getting that information to the tail? The
only way I see
doing this is manually. I don't believe that there is a way of getting this
information
to the tail using RSVP-TE, but I could be wrong. 
 
You don't have to get any additional information to the tail. For the
tail-end configuration if you have two additional variables to specify the
originating LSRid and originating tunnel index that should do it. With this
information you can directly associate a tail-end configuration with a
head-end configuration (which is already available at the tail-end through
RSVP-TE signalling).

Thanks.
 
        --Tom

Thanks 

        --Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 29 Oct 2001 19:11:28 -0500

>addresses etc. to it at both ends)

         I would categorize the use of a single interface as a "real" interface
configuration as well.

>you will have to have interface configuration at both the head and tail ends.

         That is possible using the existing MIB. I think that we have
violent agreement on this point.

>If you don't have a tail end interface configuration the only reason to 
>use tunnel interfaces is probably to make the tunnel *look* like an 
>interface on the head end router. This however means that you are treating 
>it as an interface on one side and treating it as a simple terminating 
>tunnel on the other side. This seems anomalous.

         I guess that you are entitled to your opinion. My customers
don't think that this approach is so anomalous.

>an RSVP-TE session at the tail point, or via manual configuration. 
>However, making
>this ifIndex consistent with the one at the head automatically is 
>something that I think you
>consequence,
>you just have to have a corresponding interface at the other end.

         Okay, so what is the problem then? 8)

         --Tom

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 30 Oct 2001 11:08:41 +0530

Hi,

It would be great from understanding point of view if it can be answered
more elaborately. 
the question still remains..whats wrong in having IfTable interface entry at
both ends, which can be provisioned from te-mib.
note that..it may not be done manually at tail-end.

Khuzema.

> ----------
> From: 	Thomas Nadeau[SMTP:[email-masked]]
> Sent: 	Tuesday, October 30, 2001 5:41 AM
> 	        Most if not all MPLS implementations that I know of only
> require the operator
> 	But, if you want to treat a tunnel as a real interface (and assign
> IP addresses etc. to it at both ends) 
> 
> 
> 	If you don't have a tail end interface configuration the only reason
> to use tunnel interfaces is probably to make the tunnel *look* like an
> 	interface for the tail end of the tunnel, it can do this based on
> the acceptance of

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 30 Oct 2001 08:34:19 -0500

>It would be great from understanding point of view if it can be answered

         I don't understand the question.

>both ends, which can be provisioned from mpls-te-mib.

         Nothing. I think that we all agree that this works.

>note that..it may not be done manually at tail-end.

         You want this to be done through signalling?

         --Tom

---

From: "Dominic-Savio, Patrick" <[email-masked]>
Date: Tue, 30 Oct 2001 10:42:26 -0500

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, October 30, 2001 10:17 AM
To: Dominic-Savio, Patrick; 'Thomas Nadeau'
Cc: [email-masked]'
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)

Guys,
 
Before banging on the TE-MIB much more, apply yourselves to Tom's
question... 
 
I wish my questions did not sound like I was "banging" the TE MIB!
Anyway, your two points below seem to pretty much sum up the scope of the
MIB and I may have erred in trying to use the MIB to accomplish more than
what it was designed for.
 
Thanks
 
How is this signaled?
 
The TE MIB can only handle two things...
 
- local configuration (e.g. head end ifIndex)
- protocol elements (i.e. things that will be signaled)
 
Note that the Unnumbered Interface signaling drafts add the concept of
signaling the Unnumbered Interface Id by which the tunnel is known if it is
represented as an unnumbered interface.  This is being added to the GMPLS
version of the TE MIB (due out any time soon).
 
I'm sure that just as soon as it is agreed how to signal the tail end
ifIndex for tunnels that appear as numbered interfaces, Tom will be happy to
add this to the TE MIB.
 
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
[email-masked] <mailto:[email-masked]> 

----- Original Message ----- 
From: Dominic-Savio, Patrick <mailto:[email-masked]>  
To: 'Thomas Nadeau' <mailto:[email-masked]>  
Cc: [email-masked]' <mailto:[email-masked]'>  
Sent: Tuesday, October 30, 2001 10:07 AM
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)

Please scroll to the end...

-----Original Message-----
From: Thomas Nadeau [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Monday, October 29, 2001 7:11 PM
To: Dominic-Savio, Patrick
Cc: [email-masked]' <mailto:[email-masked]'> 
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)

        I would categorize the use of a single interface as a "real"
interface
configuration as well.

you will have to have interface configuration at both the head and tail
ends. 

If you don't have a tail end interface configuration the only reason to use
tunnel interfaces is probably to make the tunnel *look* like an interface on
the head end router. This however means that you are treating it as an
interface on one side and treating it as a simple terminating tunnel on the
other side. This seems anomalous.   

 

The problem is that the TE MIB does not provide *complete* configuration
support for setting up of a "corresponding" tail-end tunnel interface. On
the head-end it provides all of the required configuration parameters (isIf,
name) and on the tail-end it provides some (isIf, name) but not all (you
would at least need the head-end tunnel index to be specified at the
tail-end).
Let me try the question again in case my earlier questions were not clear.
If I create a tunnel  interface on a head-end router and would like to
create a corresponding tail-end tunnel interface on the tail-end router, how
do I do this using the TE MIB. I would like to see a complete solution using
just the TE MIB (because it attempts to solve the problem on the head-end),
if this is not possible then what other MIB tables should I use and how?. I
can easily come up with some proprietary scheme to do this but I would like
to see some "standard" usage guidelines. Again, given that the TE MIB seems
to be taking on the responsibility of creating tunnel interfaces I would
like a "standard" way of doing it on the tail-end to be documented in the
mpls-te-mib specification.
 
Thanks

        --Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 30 Oct 2001 10:37:58 -0500

>support for setting up of a "corresponding" tail-end tunnel interface.

         What you don't find in there today is an example of how to do 
this, but it certainly
does allow for this type of configuration (see below).
>On the head-end it provides all of the required configuration parameters 
>(isIf, name) and on the tail-end it provides some (isIf, name) but not all 
>(you would at least need the head-end tunnel index to be specified at the 
>tail-end).
>create a corresponding tail-end tunnel interface on the tail-end router, 
>how do I do this using the TE MIB.

         Your implementation should keep some sort of RSVP-TE record at the
tail end of the router. Your MPLS-TE-MIB agent can then use this information
to create a tunnel entry for it. The agent can then assign an ifIndex to 
this entry.
The indexes will be the same as at the head end, so your NMS can
correlate them that way. You can optionally allow the operator to assign
the ifIndex. Note that the operator could also do this at the head as well.
>I would like to see a complete solution using just the TE MIB
>(because it attempts to solve the problem on the head-end),

         This is not the case. The MIB allows for the configuration of the 
head, midpoints
and tail -- wherever your implementation supports it.
>if this is not possible then what other MIB tables should I use and how?. 
>I can easily come up with some proprietary scheme to do this but I would 
>like to see some "standard" usage guidelines.

         Well, to be honest with you, your implementation and one other are 
the only
ones that I have heard use this scheme of two ifIndexes for a tunnel. All 
of the
others I know of (about 30 or so), create a single configuration record at 
the head
end where a corresponding tunnelEntry is created. Most also bound an 
ifIndex to the
tunnelEntry at that time. Some optionally create entries at midpoints and 
the tail, but
without ifIndexes at either of these places.
>  Again, given that the TE MIB seems to be taking on the responsibility of 
> creating tunnel interfaces

         For reference, the MPLS TE MIB does NOT require that an ifIndex be 
assigned
anywhere.  The MIB assumes that the agent (or operator) creates the tunnel 
interface(s)
where necessary; the MIB cannot create anything per se. If you do create an 
entry and have
a corresponding ifIndex, then the tunnelIsIfIndex is used to indicate this. 
If you want to
assign an ifIndex at the tail, they go for it, but remember to turn this 
bit on so that operators
and NMS systems know that a corresponding Interfaces MIB entry exists and
can be examined.
>I would like a "standard" way of doing it on the tail-end to be documented 
>in the mpls-te-mib specification.

         The MIB shows examples of how it is commonly used. If you would 
like an additional
example at this point, I think that you just volunteered to write something 
up. 8)

         --Tom