[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Status of ID: IPsec Flow Monitoring MIB



Hi -

I do not understand your first objection below:
you are objecting to a draft because its not based
on another draft? What is the status of your draft?
Why should we base our proposal on it?

I looked through the textual conventions defined by you
and John Shriver <draft-ietf-ipsec-doi-tc-mib-05.txt>.
I find them comprehensive am willing to based our definitions
on them. That is the extent of layering I proposed below.

  > As a guide, I have submitted <draft-jenkins-ipsec-tun-mon-mib-00.txt>
  > as an illustration of how this can be done.

Unfortunately, this would make it expensive for an
vendors of small IPsec devices to implement the MIB
we propose, although it details very useful abstractions
and correlations. I'd hate to see that happen.

Like I said in my earlier mail, the IPsec Flow Monitor
MIB provides both the protocol view and an application view
and hence can be stand-alone.

Thanks,

Rk
x77309


  On Wed, 10 Oct 2001, Tim Jenkins wrote:


  > I have two main objections to this MIB document. They are:
  > 1) It doesn't use the base IPsec MIBs.
  > 2) It does things that are outside the scope of IPsec.

  > Below, there is agreement to using the base MIBs, so that
  > deals with my first objection. As a guide, I have submitted
  > <draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
  > of how this can be done.

  > As far as I can see, the second objection has not been
  > dealt with. While I believe that a number of these
  > additional features are things that are user requested
  > (such as IP address to domain name conversion; see objects
  > ikeTunLocalName and ikeTunRemoteName as examples), it is my
  > belief that they do not belong in an IPsec MIB. However,
  > there are few of these, so it is likely this objection can
  > be easily overcome.

>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Tuesday, October 09, 2001 6:14 PM
> > To: byfraser@cisco.com; tytso@mit.edu
> > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > Subject: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> >
> > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > IPsec monitoring applications designed to evaluate the
> > connectivity and performance and troubleshoot connectivity
> > failures. The MIB has evolved ever since based on comments
> > from early of VPN deployers. We would like to standardize
> > this MIB and want the WG chairs to advance the ID in the
> > standards track.
> >
> >
> > History:
> >   The MIB was first defined because the MIBs available during
> >   that time in the area were insufficient in providing the
> >   abstractions that are desirable to make IPsec manageable.
> >
> >   Tivoli Systems (a multi-vendor management company) refined
> >   the MIB with Cisco Systems to make it a multi-vendor/standard
> >   MIB for managing IPsec networks. After successful deployment in
> >   the field, it was revised and the revision was submitted to
> >   the WG early this year.
> >
> >   The MIB has since been adopted by a few VPN service providers,
> >   management vendors and users. Their comments were helpful in
> >   further refining the MIB definition.
> >
> >
> > Highlights of the MIB:
> >   Defining a MIB to merely export bits of the protocol serves no
> >   management purpose. We defined the MIB with the following features:
> >
> >     1. Build abstractions that may be used by the network
> > administrators
> >        to identify traffic flows in IPsec networks. This
> > would allow the
> >        correlation of the performance of the application traffic with
> >        that of the underlying IPsec networks.
> >     2. Help define SLAs to qualify the performance and failures.
> >     3. History and failure tables for trending and troubleshooting.
> >     4. SA tables to aid low level troubleshooting.
> >     5. Separation of IKE and IPsec groups to allow later
> > extensions for
> >        other keying protocols to be used with IPsec (such as KINK).
> >
> >     I'd very much like to hear comments on this from administrators
> >     or NMS developers who are facing the problem of monitoring
> >     and troubleshooting IPsec-based VPNs.
> >
> >
> > Coexistence with other MIB drafts:
> >   Our proposal may be regarded as being competing or complementary to
> >   the low level MIBs proposed by Jenkins et al. To that extent,
> >   we are willing to layer our MIB on top of the basic definitions
> >   provided by the Jenkins drafts.
> >
> >   In 1999, it was proposed that we use the ISAKMP and IPsec textual
> >   conventions proposed by Jenkins drafts. This is quite feasible
> >   since there is little difference between the TCs proposed by
> >   the two drafts.
> >
> >
> > Please advise us on what we need to do in order to advance this MIB
> > in the standards track.
> >
> > Thanks,
> >
> > Leo Temoshenko, Cisco Systems Inc.
> > Cheryl Madson, Cisco Systems Inc.
> > Chinna Pellacuru, Cisco Systems Inc.
> > Bret Harrison, Tivoli Systems Inc.
> > S Ramakrishnan, Cisco Systems Inc.

---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca



References: