[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: 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.
That was then. This is now.
>
> 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.
>
Too low level to be useful. Why would one want to implement
"unuseful" MIBs in order implement useful 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.)
>
So why can't one find these revisions?? Where can one get
a copy of these revised drafts? Since one cannot find them,
how would/could one implement 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.
>
Big IF here. Which does not need comment.
> >
> > 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.
So why are you objecting so strongly? That was then, this is now.
>
> 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.
I beleive it has.
>
> > 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: