RE: draft-ietf-tewg-mib-07.txt

["Dave Thaler" <dthaler@windows.microsoft.com>]

Summary of main issues:

1) the endpoint model does not make sense (see Juergen's email)

2) the model of not extending IF-MIB doesn't yet make sense in 
   light of current understanding and the response by Venkata 
   Naidu.  Even Kireeti's response so far only strengthen the 
   case that the MIB in fact should already extend the IF-MIB.
   For example, assigning addresses to things other than
   interfaces would require corresponding updates to a number 
   of standards track RFCs (RFC 3513, 2011, 2096, etc.)
   This does not appear to be warranted if the TE MIB 
   does extend the IF-MIB.

3) there is current text about the ability to do operations
   between two TimeTicks objects (specifically take the 
   ratio a/b).  Since TimeTicks wraps in 16 months, after that
   point the objects are apparently useless.  Current DESCRIPTION
   clauses say the management station should "take this into 
   account", but doesn't say how this can be done, and it's not
   clear whether it can be done without adding another object.

4) text on why not extend the Tunnel MIB needs to be cleaned
   up.  This doesn't affect the actual MIB part, just the 
   introductory text.  Currently it contains several irrelevant
   items, and misses one of the two reasons that may make sense
   (if it's true, which I still have a question out on) which
   is currently only mentioned in a DESCRIPTION clause.

-Dave

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]
On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Thursday, October 16, 2003 5:11 AM
> To: Mreview (E-mail)
> Subject: 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.