[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Status of ID: IPsec Flow Monitoring MIB
> -----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).
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.
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.
>
> 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.
>
> Rk
> x77309
>
> ---
> S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
>
Follow-Ups: