[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of ID: IPsec Flow Monitoring MIB
Tim Jenkins wrote:
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Friday, October 26, 2001 2:23 PM
> > To: Theodore Tso
> > Cc: Tim Jenkins; bbruins@cisco.com; bret_harrison@tivoli.com; Barbara
> > Fraser; cmadson@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com;
> > pcn@cisco.com
> > Subject: Re: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> > Hi -
> >
> > From: Theodore Tso <tytso@mit.edu>
> > Date: On Fri, 26 Oct 2001 14:23:03 -0400
> >
> > >Which leads us to the next question... assuming that there
> > >is only one attempt to implement the I-D's, what is the
> > >working group's feeling about advancing the documents?
> >
> >
> > I have looked through the IKE and IPsec monitoring MIBs
> > and I am a bit confused about the purpose of these "low level" MIBs.
> > Why were these defined and what problem are they meant to solve?
> > MIBs that dish out bits of the protocol merely because the bits
> > happen to be there, serve very little purpose (let's call
> > such MIBs "protocol MIBs").
>
> As I mentioned elsewhere, they are not application specifc because
> that is what the working group wanted, as was made clear in Orlando
> (yes, that long ago).
Right, but the need was there and in took awhile for it to
become clear.
>
> The split as is allows parts of them to be used if you use IPsec SAs
> with manual keying or some other key exchange protocol. It allows
> you to use the ISAKMP portion if you build a different key exchange
> protocol on top of ISAKMP.
The split makes no sense in current implementations. One cannot
do one without the other.
>
> This is what the working group wanted and I believe we have provided.
>
> Further, I believe, and I said this when the Flow monitoring MIB
> was first presented, that any application level MIB should use these
> base MIBs, rather than forcing a second presentation of the same
> information in another way.
We could should keep them independent and let the implementor choose.
>
> >
> > Why would an administrator use them instead of the command
> > line interface (I am not sure there is a device out there
> > that supports SNMP protocol but not management through
> > telnet)?
> >
> > One answer to my last question could be the following:
> > Monitoring and troubleshooting are done in the context of
> > an application of IPsec (such as VPNs). Hence, if a problem
> > with the application is traced down to the underlying protocol
> > (IPsec), the ensuing troubleshooting would require the nuts and bolts
> > of the protocol. Hence, I'd argue that without a MIB that provides
> > abstractions on top of the protocol view (an "application MIB"),
> > the protocol MIB serves little purpose.
> >
> > Its precisely for this reason that we (Tivoli Inc and Cisco)
> > drafted the IPsec Flow Monitoring MIB and proposed it to
> > IETF in Fall 1999. We were looking to building monitoring
> > and troubleshooting applications for IPsec-based VPNs. The MIBs
> > available in the WG at that time were too low level and hence
> > unsuitable for our purposes. The result of our work was a MIB
> > that provides both the views: it provides the abstractions of
> > IKE and IPsec Flows ("tunnels"), provides low level SA view of the
> > IPsec flows and correlates between the two views. I contend that
> > out proposal "IPsec Flow Monitoring MIB" can be stand alone
> > or can make use of some components defined by Jenkins et al.
> >
>
> Again, there is no doubt an application specific is valuable or
> needed. This is not an either-or case. My view is simply this:
> any application level MIB of IPsec should use the component MIBs,
> rather than re-defining the components. The flow monitoring MIB
> is an application level MIB, and it should define the application,
> not the components.
>
> > Finally, I'd like to hear comments from vendors (ISPs, VPN SPs, etc)
> > who are going to make use of these MIBs to provide VPN SLAs and other
> > goodies: please contrast the IPsec Monitoring MIB and the
> > "IPsec Flow Monitor MIB". Your comments from the trenches would be
> > invaluable to us in improving our proposal.
> >
> > There has not been any discussion on these MIBs, leave alone
> > a debate contrasting the two approaches (the Jenkins drafts and
> > the IPsec Flow Monitoring MIB, proposed by us).
> >
> > Hence, how can it be appropriate to take these drafts to the
> > final call?
>
> Because the components MIBs define the components as defined
> by the working group.
This is an unacceptable answer as new issue have arose.
>
> >
> > Rk
> > x77309
> >
> > ---
> > S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
> >
References: