Subject: RE: Packet capture problem statement

From: Dan Romascanu <[email-masked]>
Date: Wed, 27 Jun 2001 14:16:01 +0200

Hi,
 
> Maybe, you should mention, that (and why!) current RMON does not meet
> the requirements of the applications you mention above. Or better, to
> what degree these requirements are matched and what gap would 
> be filled
> by pcap.
> 

The main limitation of the current RMON solution for port copy, as defined
in RFC 2613 is the fact that it is limited to operations between interfaces
that belong to the same device. The problem statement presented by Carter
describes a network-wide type of operation, and also includes extended
mechanism for filtering and privacy that do not exist in the RMON solution.

> Another drawback of port copy you shuld mention here is the 
> potentially
> huge amount of data sent to the collector, particuarly if you want to
> report on more than one port. Selective packet capturing can help, if
> only a part of all port traffic is of interest.
> 

Indeed combination of filter and port copy capabilities, or sampling
techniques have been used for selective packet capturing. However no
standard framework succeeded to catch them into one agreed mechanism, and
they were still limited to one device borders. The work proposed by Carter
can possibly provide this missing standard framework for network-wide
capabilities.

Regards,

Dan

---

From: "Carter Bullard" <[email-masked]>
Date: Wed, 27 Jun 2001 09:03:57 -0400

Hey Juergen,
   Now I understand.  I was trying to use RFC-2613 to
reiterate that RMON had problems and that vendors were
implementing their own technology to get around RMON's
shortcoming.  Since RFC-2613 was created by RMONMIB, I
was hoping they would remember that problems exist ;o)

   I'll add a phrase that RMONMIB also doesn't meet
the requirements, but I'll not explain why.  I want
this to be short and to the point, to get interest and
to highlight the problem.  I don't want to introduce
debatable issues that could simply confuse the discussion.

Definitely thanks for the comments!!!!

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2001 4:52 AM
> To: Carter Bullard; [email-masked]
> Cc: [email-masked]; 'Georg Carle'; 'Tanja Zseby'; 
> 'Sebastian Zander'; 'Marcelo Pias'
> Subject: RE: Packet capture problem statement
> 
> 
> Hi Carter,
> 
> Seems like I did not phrase well. Please see my comment below.
> 
> 
> -- Carter Bullard <[email-masked]> wrote:
> 
>  [snip]
> >> >
> >> > Packet capture is a fundamental mechanism in Internet network 
> >> > management and is used in support of a wide range of network 
> >> > operational tasks, such as fault detection, protocol analysis, 
> >> > performance analysis, and security assessment.  The IETF
> >> has specified
> >> > technology for packet capture in STD-59, Remote Network 
> Monitoring 
> >> > Management Information Base (RMON MIB) and RFC-1761, Snoop
> >> Version 2
> >> > Packet Capture File Format.  Working groups, such as 
> RMON and IPPM, 
> >> > continue to describe various aspects of packet capture
> >> technology in
> >> > RFC-2021, "Remote Network Monitoring Management Information Base 
> >> > Version 2 using SMIv2", RFC-2330, "Framework for IP Performance 
> >> > Metrics", and RFC-2613, "Remote Network Monitoring MIB
> >> Extensions for
> >> > Switched Networks Version 1.0".
> >>
> >> what degree these requirements are matched and what gap would be 
> >> filled by pcap.
> >
> > The RFC's mentioned are just examples of IETF standards track 
> > documents that specifically describe some property of packet
> > capture.   The purpose is to demonstrate that the IETF is
> > invested in defining packet capture technology.  I could include a 
> > brief list of RFC's that are dependant on packets for their 
> function, 
> > including RTFM, of course!! But I did want it to be brief.
> >
> > I've been asked to simply present the problem statement, and not 
> > necessarily present a solution, so I'll not mention pcap 
> except for a 
> > "draft is available" statement at the end.
> 
> My point is that when proposing something on the RMON list,
> we should state, that and why current RMON does not cover 
> this already, particularly that current RMON does not meet 
> the requirements of the applications you mentioned.
> 
> Best wishes,
> 
>     Juergen
> 
> 
>

---

From: "jason dinkleman" <[email-masked]>
Date: Wed, 27 Jun 2001 16:24:20 -0400

Please get me off this list.  I don't know what you are talking about.  This is the second time I have asked to be off this list.

From: Juergen Quittek

To: [email-masked], [email-masked]

CC: [email-masked], "'Georg Carle'" , "'Tanja Zseby'" , "'Sebastian Zander'" , "'Marcelo Pias'"

Date: Wed, 27 Jun 2001 10:52:13 +0200

Hi Carter,

-- Carter Bullard wrote:

[snip]

>> > Packet Capture File Format. Working groups, such as RMON and

>>IPPM,

>>Maybe, you should mention, that (and why!) current RMON does

>>not meet the requirements of the applications you mention

>>above. Or better, to what degree these requirements are

>>matched and what gap would be filled by pcap.

>invested in defining packet capture technology. I could

>include a brief list of RFC's that are dependant on

>packets for their function, including RTFM, of course!!

>But I did want it to be brief.

>I've been asked to simply present the problem statement, and

>not necessarily present a solution, so I'll not mention pcap

>except for a "draft is available" statement at the end.

we should state, that and why current RMON does not cover this

already, particularly that current RMON does not meet the

requirements of the applications you mentioned.

Best wishes,

Juergen

Get your FREE download of MSN Explorer at http://explorer.msn.com