Subject: FW: DT's review of draft-ietf-tewg-mib-06.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Sep 2003 11:35:05 +0200

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:[email-masked]]
> > Sent: zaterdag 13 september 2003 21:35
> > To: [email-masked]
> > Cc: [email-masked]
> > 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:[email-masked]]
> > > 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:[email-masked]]
> > > 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.
> >
> >

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 29 Sep 2003 07:54:25 -0700 (PDT)

Hi Dave,

Thanks for your review of the TE MIB.

> I've completed a review of draft-ietf-tewg-mib-06.txt at Bert's request,
> IP Tunnel MIB, and have found what I feel are significant issues with
> this draft.
>
> Redundancy with IF-MIB:
>

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.

>  teTunnelDiscontinuityTimer - redundant with ifCounterDiscontinuityTime
>
>  teTunnelPackets - redundant with ifHCOut{Ucast,Multicast,Broadcast}Pkts
>
>  teTunnelLPOctets - redundant with ifOut{Ucast,Multicast,Broadcast}Pkts
>

> 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

I might suggest that if there is a need for a generic tunnel MIB, it
start with this.

>     tunnelIfTOS, and the ability to look up a tunnel index by its

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.

>  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

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.

>     point this point, since the equations given are invalid in this

Good point.  I will update the description.

>     and should ideally be done in a separate table that can be used for

Does this apply even if tunnels are not interfaces?

Kireeti.