[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: DT's review of draft-ietf-tewg-mib-06.txt
Hi Dave,
Thanks for your review of the TE MIB.
> -----Original Message-----
> From: Dave Thaler
> Sent: Saturday, September 13, 2003 12:32 PM
> To: Tewg (E-mail)
> Cc: 'Wijnen, Bert (Bert)'
> Subject: DT's review of draft-ietf-tewg-mib-06.txt
>
> I've completed a review of draft-ietf-tewg-mib-06.txt at Bert's request,
> concentrating on the relationships with the Interfaces MIB and the
> IP Tunnel MIB, and have found what I feel are significant issues with
> this draft.
>
> Redundancy with IF-MIB:
>
> The MIB has no text on the relationship with the IF-MIB, and does not
> explain why teTunnelIndex is not an InterfaceIndex. Indeed, it actually
> requires that the teTunnelIndex fit into the InterfaceIndex numbering
> space (without saying why). There appears to be sufficient justification
> here to say that TE tunnels appear in the interfaces table in the IF-MIB,
> just like any other kind of tunnel. Certainly there is no justification
> to the contrary I could find.
There is no relation with the IF-MIB, hence no text on that. TE
Tunnels are abstract constructs for Traffic Engineering, not
interfaces. For example, TE Tunnels are usually unidirectional. If
you give me a list of criteria for what constitutes an interface, I
can try to say how TE tunnels differ.
The reason for teTunnelIndex should not overlap with interface indices
is an artifact of RFC 3477 using the same index object for interfaces
and TE tunnels, instead of defining a new object. This was for
convenience, and so I put this in the TE MIB (sans explanation, which
I will be happy to add).
Given this, I would suggest that TE Tunnels be objects in and of
themselves, rather than artificially make them interfaces, and hence
the following doesn't apply.
> Hence the following objects can be removed:
>
> teTunnelIndex - redundant with ifIndex
>
> teTunnelName - redundant with ifAlias
>
> teTunnelStatus - redundant with ifOperStatus
>
> teTunnelDiscontinuityTimer - redundant with ifCounterDiscontinuityTime
>
> teTunnelOctets - redundant with ifHCOutOctets
>
> teTunnelPackets - redundant with ifHCOut{Ucast,Multicast,Broadcast}Pkts
>
> teTunnelLPOctets - redundant with ifOut{Ucast,Multicast,Broadcast}Pkts
>
> teTunnelUp - redundant with linkUp
>
> teTunnelDown - redundant with linkDown
> Relationship to IPv4 Tunnel MIB:
TE Tunnels are tunnels, hence have a closer relation with IP tunnels
than with interfaces. But I would not call them IP tunnels -- they
just aren't _IP_ tunnels. They are any kind of tunnels that could be
used for traffic engineering, such as ATM VCs, or MPLS LSPs.
> This MIB has no text on the relationship with the IPv4 Tunnel MIB, and
> does not explain why it does not extend that MIB.
It would have helped to have this review *much* earlier. There didn't
appear to be a need to explain why the TE MIB didn't extend the IPv4
tunnel MIB. I can certainly add the outcome of this discussion in
some condensed form as an explanation, if deemed necessary.
> There was email on
> this topic which is not reflected in the document, which is that
> the tunnels are not necessarily IPv4. However, we know we need a
> corresponding IPv6 Tunnel MIB (or perhaps a generic IP Tunnel MIB)
> anyway. Given that, it is unclear whether there is sufficient
> justification (certainly none in the draft) to not extend it/them.
I might suggest that if there is a need for a generic tunnel MIB, it
start with this.
> The argument to extend it/them is twofold:
> a) you are consistent with other tunnel management schemes, rather than
> confusing people with multiple conflicting schemes, and
> b) that you get a number of things for free, specifically:
> tunnelIfHopLimit, tunnelIfSecurity, tunnelConfigEncapsMethod,
> tunnelIfTOS, and the ability to look up a tunnel index by its
> endpoints.
A TE tunnel need not be an IP tunnel of any kind -- not IPv4, not
IPv6, not GRE, not L2TP. The encapsulation need not be IP (although
it could); typically, the encaps is ATM or MPLS. One important
property of TE tunnels is that they can be explicitly routed (or
source routed), which is rather awkward for IP tunnels.
> teTunnelRowStatus - redundant with tunnelConfigStatus
>
> teNextTunnelIndex - redundant with tunnelConfigIfIndex
>
> The real issue is how to handle the teTunnelSourceAddressType
> and teTunnelDestinationAddressType. So before we can deal with that
> issue, we need several questions answered.
> 1) Is it legal for the two types to be different? (If not, the latter
> object should be removed).
It is indeed legal.
> 2) Are all values legal? E.g. what does it mean to have a source address
> type of "asnumber"? From a mailing list search, I see that
> Juergen asked the same question two years ago at
> http://ops.ietf.org/lists/te-wg/te-wg.2001/msg00231.html
> and did not get any answer that I could find. I will agree with
> Brian's and Juergen's comments in that thread. If the values are
> legal, the MIB should either say how that value is used, or else
> reference another document that does.
A TE tunnel has a definite source and destination, but the source and
destination may be specified more liberally. For example, a tunnel
may be needed from AS 1 to AS 10 for the purpose of engineering
traffic from AS 1 to AS 10. In that case, it makes more sense to
state the source address as AS 1 rather than the particular router
where the tunnel happens to start so that tunnel route computation
knows that any router in AS 1 is a valid starting point.
It might make more sense to update the description of the Hop Address
Type to say more clearly why the different types are needed, than to
do it just in this MIB.
> Other General comments:
>
> teTunnel{Age,TimeUp,PrimaryTimeUp} - TimeTicks wraps in around 16
> months.
> Once you have an Age > 16 months then the values appear to be
> useless.
> Whether this is a problem is up to the WG, but the DESCRIPTION
> should
> point this point, since the equations given are invalid in this
> case.
Good point. I will update the description.
> teTunnelAge, teTunnelTimeUp, teTunnelTransitions, teLastTransition -
> these all appear to be non-TEWG specific, and even non-tunnel specific,
> and should ideally be done in a separate table that can be used for
> any interface type.
Does this apply even if tunnels are not interfaces?
Kireeti.