[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: Sunday, October 28, 2001 6:17 PM
> To: Tim Jenkins
> Cc: byfraser@cisco.com; tytso@mit.edu; bbruins@cisco.com;
> ipsec@lists.tislabs.com; leot@cisco.com
> Subject: 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?
Yes, I'm objecting that it's not based on the other drafts
because the intent of those drafts was to be the MIBs
produced by the working group to monitor the stuff that
came out of the working group.
Since they are not application specific, and in their raw
form may not be what most implementors want, it is expected
that they will be used as the building blocks for application
specific MIBs. That is why I submitted the tunnel monitoring
MIB: as an example of how the base MIBs could be used as
the building block of an application specific MIB.
The status is that they have had minimal changes for the last
three revisions, and are ready for last call. We get next to
no comments on them now. (But we do know people are reading
them, since we get private questions on them.)
Why should you base yours on them? Well, if they become the
standard MIBs for IPsec, then you'll likely have to implement
them anyway, so it would make your application level MIB much
smaller and easier to implement.
>
> 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.
See what happen again?
>
> 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.
>
Agreed it does.
When I first started the MIBs, I proposed one that looked very
similar to yours, in fact, it was similar to the tunnel MIB
I submitted with alot of the IPsec stuff as well.
This version was very forcefully rejected by the working group
at the meeting in Orlando because it was application specific,
and did not separate the components out. That is why there exists
the series you see today that honours the separation of the IPsec
components as they exist today.
Perhaps the working group has changed its mind. If it hasn't,
then I don't see how the Flow monitoring MIB can be advanced as
it is since it duplicates much of what is already done in the
collection of base MIBs.
> 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
>
Follow-Ups: