[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: draft-ietf-tewg-mib-07.txt
Can some other MIB doctors look into this and maybe we
can have a discussion as to what we want to do.
Dave Thanler,
can you summarize what your main issue is?
I think (but am not 100% sure) you want the authors to consider
- would this MIB be better modeled as an extension to IF-MIB
- would this MIB be better modeled as an extension to the tunnel-mib
- or can this MIB module be kept as is with some clarifications.
I believe your email below (and some other exhanges with Mireeti et al)
we to try and get a better background to try and make up our mind.
These MPLS and TWEG MIB modules have been pestering us for a long time.
Unless we see a REAL BIG issue or FATAL FLAW I would prefer to get
them over with. And they have been targeting PS.
If we (you) feel that a new tunne-mib can better address all the issues,
tren we can still do so (better quick than slow) and later evaluate the
two approaches and get a better discussion. I did see you posted a new
ID for the tunnel MIB... so it seems we have started at least something.
Thanks,
Bert
-----Original Message-----
From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
Sent: dinsdag 14 oktober 2003 23:32
To: kireeti@juniper.net; Wijnen, Bert (Bert)
Subject: RE: draft-ietf-tewg-mib-07.txt
Review of draft-07...
Section 3.5:
> TE Tunnels are more often than not unidirectional
This point is not really relevant, as this is no different
from other tunnels. See for example RFC 2893 section 3.8 which says
> Automatic tunnels and unidirectional configured tunnels are
> considered to be unidirectional.
Next...
> they may comprise one or more concrete instantiations (Paths),
> any or all of which may be active (carrying traffic)
This point is not really relevant, as this is no different
from other tunnels. See for example RFC 1990 on multilink PPP.
> they need not have definite
> start and end points (a TE Tunnel source may be specified as strictly
> as an IPv4 host address, or as loosely as an Autonomous System number
> (which means it can start on any router in that AS), and similarly
> for TE Tunnel destinations)
I didn't follow this, so am unsure as to whether this is relevant
or not. (The fact that I didn't follow it means it isn't clear
enough in any case.)
Are you talking about determining what traffic should and should
not be routed across the tunnel? If so, this is not an endpoint,
just a traffic classification used in the forwarding lookup.
What is relevant as far as the IP Tunnel MIB goes is what is used
for encapsulation. You can't encapsulate in an IP header with an
AS number as the source address. If you encapsulate in an IP header
(and possibly other intermediate headers like MPLS or whatever else)
then you have a source address in the IP header. What is that
source address? (Below you partly answer this by saying you may
not encapsulate in an IP header, but my question remains for the
case where you do.)
> Finally, one doesn't often run routing adjacencies over TE Tunnels.
Not sure why routing adjacencies are relevant. Just because no
routing protocol is configured on an interfaces doesn't mean
it isn't an interface.
> All of these properties make it hard to
> consider TE Tunnels as a derived class of an interface.
See above. Most of the facts above appear to me to be irrelevant.
Next paragraph:
> a TE Tunnel (as mentioned above) is often unidirectional
No different than many other types of tunnels which are
represented by the tunnel MIB. Hence irrelevant.
> a TE Tunnel may have a nebulous source and
> destination;
I think this is the critical point. If you can clearly
explain this and make it the main point you'll be better off.
As yet, I don't understand it.
> an important aspect of TE Tunnels is that they have
> constraints that determines the actual path they take
This is no different from other types of tunnels that
extend the IP tunnel MIB, hence I again argue this
is irrelevant. E.g. if you have a source routed IP-in-IP
tunnel, this works fine with the IP Tunnel MIB.
You just have an extension MIB which has the source
route table in it.
> and perhaps
> most significantly, a TE Tunnel need not be encapsulated as IP; in
> fact, a common instantiation of a TE Tunnel is an MPLS LSP, and
> another instantiation is an ATM Virtual Circuit.
This is the other critical point. If the tunnel is not over IP,
then it is true that extending the IP Tunnel MIB is not sufficient.
However, one should not preclude having TE tunnels that do go
over IP show up in tables in the IP Tunnel MIB. (And to be clear
I'm not saying you are precluding it now.)
> The above captures the reasons that the TE Tunnel MIB module is a new
> MIB module rather than an extension of the Interface MIB module or
> the IP tunnel MIB module.
While I think one or two of the tunnel MIB points will be fine,
I'd remove the rest. I don't think there's a valid case made by
the current text in this section against the Interface MIB though.
In the DESCRIPTION clause of teTunnelIndex you have a different
argument on this point:
The reason that TE Tunnel indices should not overlap
with interface indices is because RFC 3477 defines
the LSP_TUNNEL_INTERFACE_ID object which has an
index that could either be an interface index or an
MPLS LSP index. Since MPLS LSPs are a common
instantiation of a TE Tunnel, it is vital that one
be able to distinguish between an interface and a
TE Tunnel based on the index value.
Here the argument is that a previous RFC apparently already
allowed for the discrepancy and you're trying to reflect
that in the MIB. This is the strongest case (possibly the
only valid one) yet, but it is not mentioned in section 3.5
at all.
However, I'm struggling to find where in RFC 2477 this
statement is made. What I've found so far is:
> the tail-end LSR MUST allocate an identifier to that Forwarding
> Adjacency (just like for any other unnumbered link).
The use of "other" implies that the Forwarding Adjancency is
treated the same as normal unnumbered links (which have interface
indices). In other words, my reading is that the number
allocated is in fact an interface index.
Hence I don't yet see the appeal to RFC 2477 as valid either.
Finally, the text added regarding TimeTicks wrapping:
> Note that since TimeTicks wrap in about 16
> months, this value will be useless unless the
> management station is careful to factor this in.
You need to say how the management station can "factor it in".
If there's no known way, then you're essentially saying these
required objects are useless.
-Dave
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: dinsdag 14 oktober 2003 8:50
> To: Jim Boyle; Edward Kern
> Cc: Wijnen, Bert; Kireeti Kompella
> Subject: draft-ietf-tewg-mib-07.txt
>
> Hi,
>
> Just posted draft-ietf-tewg-mib-07.txt, incorporating Dave Thaler's
> comments. New section 3.5, plus some changes to DESCRIPTION clauses.
>
> Kireeti.