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