[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of ID: IPsec Flow Monitoring MIB
RedCreek has implemented the ipsec monitoring mib, and intends to
implement the IKE monitoring mibs. Once we reach agreement on a tunnel
mib, we may implement that as well.
Scott
Barbara Fraser wrote:
>
> All,
>
> We have 5 MIB documents that really need general attention from the working
> group. Postings to the list seem to indicate there isn't much active
> interest in these documents at the current time. So, Ted and I are issuing
> a call for interest to see how many folks are planning to implement some or
> all of these MIBs.
>
> Thanks
> Barb
>
> At 06:25 AM 10/10/2001, Tim Jenkins wrote:
> >All,
> >
> >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.
> >
> >Tim
> >
> > > -----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.
> > >
Follow-Ups:
References: