[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: DT's review of draft-ietf-tewg-mib-06.txt
Mmmmm...
I believe I have not yet seen the below review posted to TEWG mailing
list. Dave claims he has sent it to the WG list too... but he is
not a subscriber... so potentially it is still awaiting approval
(who is the mailing list admin by the way?)
In any event, it would be very good to have answers to the
issues raised by Dave.
Bert
> > -----Original Message-----
> > From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> > Sent: zaterdag 13 september 2003 21:35
> > To: kireeti@juniper.net
> > Cc: bwijnen@lucent.com
> > Subject: FW: DT's review of draft-ietf-tewg-mib-06.txt
> >
> >
> > Since I'm not on the WG mailing list, I'm not sure how long
> > it will take to get approved, so I'm also sending this
> > directly to you.
> >
> > -Dave
> >
> > -----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.
> >
> > 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:
> >
> > This MIB has no text on the relationship with the IPv4
> > Tunnel MIB, and
> > does not explain why it does not extend that MIB. 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.
> >
> > 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.
> >
> > 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).
> > 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.
> >
> >
> > 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.
> >
> > 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.
> >
> > -Dave
> >
> >
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > Sent: Thursday, September 04, 2003 2:53 AM
> > > To: Tewg (E-mail)
> > > Subject: FW: WG Last Call: draft-ietf-tewg-mib-05.txt
> > >
> > > FYI, I had copied Dave Thaler (author/editor for IP Tunnel
> > > MIB) on my questions regaringd overlap/conflict/relationships.
> > >
> > > I think it is good that the WG knows
> > >
> > > Thanks,
> > > Bert
> > >
> > > -----Original Message-----
> > > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > > Sent: donderdag 4 september 2003 1:56
> > > To: Dave Thaler
> > > Cc: Wijnen, Bert (Bert); Adrian Farrel
> > > Subject: RE: WG Last Call: draft-ietf-tewg-mib-05.txt
> > >
> > >
> > > Hi Dave,
> > >
> > > On Wed, 3 Sep 2003, Dave Thaler wrote:
> > >
> > > > I will review the MIB this week.
> > > > We know we need an IPv6 Tunnel MIB (this fact is even mentioned
> > > > in RFC 2667), or perhaps an Inet Tunnel MIB if we want only one.
> > >
> > > > Just from the below, it sounds like the te-link MIB should logically
> > > > extend the IP Tunnel MIB, just like the L2TP MIB does.
> > >
> > > There are two different MIBs here -- the TE Tunnel MIB (filename
> > > draft-ietf-tewg-mib-06.txt) and the te link MIB (filename
> > > draft-ietf-mpls-telink-mib-03.txt).
> > >
> > > > That is, it shouldn't define its own ifType or its own local or
> > > > remote address objects, and it's probably missing the other things
> > > > the IP Tunnel MIB has (which would be moot if it extended the MIB
> > > > like L2TP does).
> > >
> > > As I said, the local and remote address objects for TE Tunnels are
> > > quite different, and a TE tunnel is not necessarily an interface (or
> > > even an IP tunnel).
> > >
> > > But you might find that the TE Tunnel MIB performance stats are worth
> > > stealing for the Inet MIB.
> > >
> > > > Or I could be wrong... I'll know more once I go through it.
> > >
> > > Look forward to your comments.
> > >
> > > Kireeti.
> >
> >