[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: