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

RE: Status of ID: IPsec Flow Monitoring MIB



Hi -

I hope I am addressing all your questions
and remarks in the following points:

1. NOT application-specific:

   We are not proposing an "application-specific MIB".
   This term is misleading and is biasing this
   discussion. (I am gong to delete the term VPN from
   the glossary of the MIB altogether).

   I would henceforth use the terms "bit level MIB" and
   "high level MIB" instead.


2. Judicious combination of two views needed:

   We are proposing a MIB that provides a high level
   abstraction of flows and correlations that is NOT
   specific to any application of IPsec.

    Simultaneously, we are also providing an SA level view
   in such a way that the NMS may implement correlation
   both ways (flows -> components nuts and bolts,
   nuts and bolts -> flows).

   Hence, we are seeking to judiciously combone
   both monitoring and troubleshooting requirements.


3. Why your MIBs are unacceptable:

   You have defined many layers of MIBs and now
   you want to base the abstractions we porpose
   on these layers.

   This makes the cost of SNMP-manageability unacceptably high.
   Vendors of small IPsec devices would clearly shy away
   from providing management support (heck, big vendors
   such as Cisco may partly shy away).

   Let's have a quick show of hands on how many vendors
   would implement layers of bit-level MIBs and then on top of
   that implement the abstractions defined by us, merely so
   as to provide SNMP manageability.


5. With regards to WG dictating MIB requirements:

   You appear to suggest that WG wants a token MIB to
   represent faithfully the protocol defined by them. I
   would like to hear from the WG chair on this. I would
   suggest that to WG make manageability its aim in defining
   these MIBs.

   Manageability is improved by abstracting details; if the WG
   wants a to define a MIB to reveal the bits of the protocol,
   they would make the task of managing the IPsec devices very
   difficult and management applications very complex. Such a
   MIB had better not be defined at all.


Thanks,

Rk
x77309

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

On Mon, 29 Oct 2001, 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.
>
> 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



References: