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

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.