The MPLS WG Archive
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index][Thread Index][Author Index][Subject Index]
Question on tunnel Interface (w.r.t TE MIB)
-
From: "Adrian Farrel" <afarrel@movaz.com>
-
Date: Tue, 30 Oct 2001 10:17:08 -0500
-
Cc: "'mpls@uu.net'" <mpls@UU.NET>
-
X-OriginalArrivalTime: 30 Oct 2001 15:17:09.0573 (UTC) FILETIME=[F18CB750:01C16155]
Guys,
Before banging on the TE-MIB much more, apply
yourselves to Tom's question...
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
----- Original Message -----
Sent: Tuesday, October 30, 2001 10:07
AM
Subject: RE: Question on tunnel Interface
(w.r.t TE MIB)
Please scroll to the end...
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)
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.
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.
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.
Okay,
so what is the problem then? 8)
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
------------------------------------------------------------------------ Mathematics
is the supreme nostalgia of our time.
|