From owner-rtfm@auckland.ac.nz Fri Jun 1 10:45:35 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09062
for ; Fri, 1 Jun 2001 10:45:31 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA23685;
Sat, 2 Jun 2001 01:35:47 +1200 (NZST)
Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA23679
for ; Sat, 2 Jun 2001 01:35:44 +1200 (NZST)
Received: from kshah-w2k.cisco.com (dhcp-64-102-78-109.cisco.com [64.102.78.109])
by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02645;
Fri, 1 Jun 2001 09:33:59 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010601093207.017b66f8@rooster.cisco.com>
X-Sender: kshah@rooster.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 01 Jun 2001 09:33:39 -0400
To: "Carter Bullard" ,
"'Simon Leinen'"
From: Kamlesh Shah
Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for
IPFX WG]
Cc: "'Dave Plonka'" , ,
In-Reply-To: <38E99DA2CEFA7248B5828BBF99344D8608C29B@ptah.newyork.qosien
t.com>
References: <4.3.2.7.2.20010530213154.01e5cb10@rooster.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Carter,
Good point. It is this "little bit of attention to the flow key and data" in the context of MPLS is what we were talking about.
But you present a good way to look at it, and deal with it along with the list of other flow types.
Regards.
At 10:59 PM 5/30/2001 -0400, Carter Bullard wrote:
>Gentle People,
> If you have a flexible flow key descriptor that is separate
>from the flow attributes that are reported in a flow data record
>(FDR), reporting on MPLS flows, or DSbyte flows, IPv6 flow_id
>flows, Layer 2 flows, ifIndex flows, VP flows, AS-AS
>flows, RTP based streaming media flows, ESP tunnel flows or
>traditional 5-tuple flows, whether they are uni-directional
>or bi-directional is really a very simple matter.
>
> The trick is to work within the limits of relational algebra.
>With a little bit of attention paid to flow key and flow
>attribute concepts, the FDR can be well structured such that it can
>handle all the semantics that the TE WG has discussed, as well
>as the semantics that are supported by all the current flow based
>technology.
>
>Just a thought,
>
>Carter
>
>Carter Bullard
>QoSient, LLC
>300 E. 56th Street, Suite 18K
>New York, New York 10022
>
>carter@qosient.com
>Phone +1 212 588-9133
>Fax +1 212 588-9134
>http://qosient.com
>
>
>-----Original Message-----
>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
>Behalf Of Kamlesh Shah
>Sent: Wednesday, May 30, 2001 10:22 PM
>To: Simon Leinen
>Cc: Dave Plonka; ipfx@net.doit.wisc.edu; rtfm@auckland.ac.nz
>Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for
>IPFX WG]
>
>
>Simon,
>
>You have raised some very valid/good points to consider. Please see in
>line.
>
>At 11:28 PM 5/30/2001 +0200, Simon Leinen wrote:
>>>>>>> "ks" == Kamlesh Shah writes:
>>> One of the things that differentiates MPLS from other examples you
>>> have below (such as vlan ids) is that it is an end-to-end thing in
>>> many ISP networks today.
>>
>>Actually this may not be such a good example, because ATM is also
>>something that is an end-to-end thing (customer-to-customer service) in
>
>>several otherwise IP networks today, including the one I help operate.
>
>I need to better explain my thought. I was thinking that since we are
>trying to do "IP Flow Export", the focus needs to be able to capture IP
>flows information end-to-end. This is somewhat different than IP packets
>that traverse an ATM cloud, which is similar in category to flows which
>traverse a FR cloud, where IP is mapped into layer 2 technology to
>traverse the cloud and really the only Layer 3 relationship exist
>between the edge devices.
>
>In case of MPLS, even though it is layer 2 and a half technology, the
>layer 3 relationship is carried thought out the cloud and is often
>transformed (read copied) from out of the cloud to in the cloud, gfor
>instance TTL and TOS bits. Hence the comment about considering MPLS as
>an aspect.
>
>
>>> If we do not account for MPLS, then we run the risk of ignoring a
>>> large portion of networks that will benefit.
>>
>>Sure, but since we won't make everybody happy anyway, we should try to
>>make our task as clearly defined as possible. And adding MPLS to the
>>picture just makes it a whole lot fuzzier to me.
>
>That is a matter of consensus, and I have no problem with this line of
>reasoning if generally speaking we want to keep it that way as a group.
>
>>There's a lot of experience with flow export mechanisms for IPv4 (such
>>as LFAP and NetFlow), so I think we have a good basis for building a
>>standard on that - which doesn't mean we're guaranteed to succeed.
>>Extension to IPv6 is natural and shouldn't provide much contention, so
>>it makes sense to include that from the beginning.
>
>Agree, IPV6 is much easier extension to consider as well as the fact
>that we all have a lot more experience with Flow export in the context
>of plane old IPv4 networks.
>
>
>>But extending the flow concept to "MPLS traffic flows" looks hairier to
>
>>me (different domain), and we certainly cannot build on a comparable
>>amount of operational experience with it.
>>
>>So as a practical matter (to keep our task tractable), I'd suggest to
>>remove it from the list of initial goals in the charter. Or at least
>>move it to a "for extra points^H^H^H^H^H^H^H^H^H^H^H^Hfurther study"
>>section. But personally I'd prefer to delegate responsibility for this
>
>>to the MPLS group.
>
>Please note, I am tuned into a lot of MPLS work in Cisco, and have some
>exposure to MPLS work out side of Cisco as well. I do NOT think there is
>*ANY* work going on to capture the flows or to define MPLS flows from
>the point of view of doing something similar to what we do with NetFlow
>export for instance.
>
>I would suggest to consider this for discussion here with some valid
>reasoning behind our actions besides the fact that we do not feel fully
>comfortable to handle this aspect or to keep it simple. At best, I can
>suggest to keep it as an item of discussion some what later in the
>process rather than dropping it altogether.
>
>>> The problem in covering MPLS as just another link layer technology is
>
>>> that we will loose capturing the information that is needed to
>>> complete end-to-end flow definition/capture as part of the charter.
>>
>>> Where as IETF has several RFCs and work in progress documents
>>> covering various aspects of MPLS networks, I do not know of any
>>> single one of them covering something similar to NetFlow (of Cisco).
>>
>>Maybe a NetFlow-like mechanism isn't really necessary for MPLS
>>networks, because MPLS has its own "natural" ways of grouping traffic
>>into aggregates, and defines mechanisms to count traffic in those
>>aggregates that are more convenient to use than the flow-export schemes
>
>>that are the topic of this group.
>
>I would go with this line of reasoning if MPLS was somewhat of a
>proprietary thing. Where as MPLS does have a concept of FECs (Forwarding
>Equivalence Class), to group traffic into "classes", this is still a
>layer 3 thing, and as such if we ignore this completely, we ignore a
>very crucial part of (at least some) SP networks. When you report a flow
>export from such a network, how do we treat the IP traffic flows
>behavior ?? How does an SP who is trying to charge for an IP flow
>account this part of his network ? So, I think we need to think thru
>this.
>
>At the very least, we should make a statement about things like this and
>Layer 2 VPNs to untangle this later in the process if that is what most
>folks here think, and I would be willing to table this for now.
>
>>--
>>Simon Leinen simon@babar.switch.ch
>>SWITCH http://www.switch.ch/misc/leinen/
>>
>> Computers hate being anthropomorphized.
>
>((((((((((((())))))))))))
>Kamlesh Shah CCIE # 2803
>Technical Marketing Engineer - MPLS, ISBU
>
>
>--
>Help mailto:majordomo@net.doit.wisc.edu and say "help" in message
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe
>ipfx" in message body
>Archive http://ipfx.doit.wisc.edu/list/ipfx/archive/
((((((((((((())))))))))))
Kamlesh Shah CCIE # 2803
Technical Marketing Engineer - MPLS, ISBU
From owner-rtfm@auckland.ac.nz Fri Jun 1 12:01:11 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10717
for ; Fri, 1 Jun 2001 12:01:09 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA27683;
Sat, 2 Jun 2001 02:49:56 +1200 (NZST)
Received: from ptah.newyork.qosient.com (adsl-162-83-198-57.nyc.adsl.bellatlantic.net [162.83.198.57])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA27675
for ; Sat, 2 Jun 2001 02:49:54 +1200 (NZST)
Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG]
Date: Fri, 1 Jun 2001 10:49:48 -0400
Message-ID: <38E99DA2CEFA7248B5828BBF99344D8608C29F@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Thread-Topic: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG]
Thread-Index: AcDqqhiX9i6f2RYGRu+4tdfvhKiGyw==
From: "Carter Bullard"
To: "Kamlesh Shah" , "Carter Bullard" ,
"Simon Leinen"
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Cc: "Dave Plonka" , ,
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10717
Hey Kamlesh,
I'm not sure that I see any particularly complex issue with
regard to MPLS flow/tag reporting. There don't seem to be
any unique issues that MPLS presents that don't have to be addressed
to support, say, extending the 5-tuple flow model to include the
ifIndex as a key to the flow, or to report the ifIndex as an
attribute of the traditional 5-tuple flow.
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
-----Original Message-----
From: Kamlesh Shah [mailto:kshah@cisco.com]
Sent: Friday, June 01, 2001 9:34 AM
To: Carter Bullard; 'Simon Leinen'
Cc: 'Dave Plonka'; ipfx@net.doit.wisc.edu; rtfm@auckland.ac.nz
Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for
IPFX WG]
Carter,
Good point. It is this "little bit of attention to the flow key and
data" in the context of MPLS is what we were talking about.
But you present a good way to look at it, and deal with it along with
the list of other flow types.
Regards.
At 10:59 PM 5/30/2001 -0400, Carter Bullard wrote:
>Gentle People,
> If you have a flexible flow key descriptor that is separate from the
>flow attributes that are reported in a flow data record (FDR),
>reporting on MPLS flows, or DSbyte flows, IPv6 flow_id flows, Layer 2
>flows, ifIndex flows, VP flows, AS-AS flows, RTP based streaming media
>flows, ESP tunnel flows or traditional 5-tuple flows, whether they are
>uni-directional or bi-directional is really a very simple matter.
>
> The trick is to work within the limits of relational algebra. With a
>little bit of attention paid to flow key and flow attribute concepts,
>the FDR can be well structured such that it can handle all the
>semantics that the TE WG has discussed, as well as the semantics that
>are supported by all the current flow based technology.
>
>Just a thought,
>
>Carter
>
>Carter Bullard
>QoSient, LLC
>300 E. 56th Street, Suite 18K
>New York, New York 10022
>
>carter@qosient.com
>Phone +1 212 588-9133
>Fax +1 212 588-9134
>http://qosient.com
>
From owner-rtfm@auckland.ac.nz Fri Jun 1 12:05:13 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10810
for ; Fri, 1 Jun 2001 12:05:11 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA27794;
Sat, 2 Jun 2001 02:51:03 +1200 (NZST)
Received: from smtp5ve.mailsrvcs.net (smtp5vepub.gte.net [206.46.170.26])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA27789
for ; Sat, 2 Jun 2001 02:51:02 +1200 (NZST)
Received: from sphynx (adsl-162-83-198-57.nyc.adsl.bellatlantic.net [162.83.198.57])
by smtp5ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id OAA11671290;
Fri, 1 Jun 2001 14:55:06 GMT
From: "Carter Bullard"
To: "'Kamlesh Shah'" , "Carter Bullard" ,
"'Simon Leinen'"
Cc: "'Dave Plonka'" , ,
Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG]
Date: Fri, 1 Jun 2001 10:49:44 -0400
Message-ID: <38E99DA2CEFA7248B5828BBF99344D8608C29F@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <4.3.2.7.2.20010601093207.017b66f8@rooster.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hey Kamlesh,
I'm not sure that I see any particularly complex issue with
regard to MPLS flow/tag reporting. There don't seem to be
any unique issues that MPLS presents that don't have to be addressed
to support, say, extending the 5-tuple flow model to include the
ifIndex as a key to the flow, or to report the ifIndex as an
attribute of the traditional 5-tuple flow.
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
-----Original Message-----
From: Kamlesh Shah [mailto:kshah@cisco.com]
Sent: Friday, June 01, 2001 9:34 AM
To: Carter Bullard; 'Simon Leinen'
Cc: 'Dave Plonka'; ipfx@net.doit.wisc.edu; rtfm@auckland.ac.nz
Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for
IPFX WG]
Carter,
Good point. It is this "little bit of attention to the flow key and
data" in the context of MPLS is what we were talking about.
But you present a good way to look at it, and deal with it along with
the list of other flow types.
Regards.
At 10:59 PM 5/30/2001 -0400, Carter Bullard wrote:
>Gentle People,
> If you have a flexible flow key descriptor that is separate from the
>flow attributes that are reported in a flow data record (FDR),
>reporting on MPLS flows, or DSbyte flows, IPv6 flow_id flows, Layer 2
>flows, ifIndex flows, VP flows, AS-AS flows, RTP based streaming media
>flows, ESP tunnel flows or traditional 5-tuple flows, whether they are
>uni-directional or bi-directional is really a very simple matter.
>
> The trick is to work within the limits of relational algebra. With a
>little bit of attention paid to flow key and flow attribute concepts,
>the FDR can be well structured such that it can handle all the
>semantics that the TE WG has discussed, as well as the semantics that
>are supported by all the current flow based technology.
>
>Just a thought,
>
>Carter
>
>Carter Bullard
>QoSient, LLC
>300 E. 56th Street, Suite 18K
>New York, New York 10022
>
>carter@qosient.com
>Phone +1 212 588-9133
>Fax +1 212 588-9134
>http://qosient.com
>
From owner-rtfm@auckland.ac.nz Wed Jun 20 11:48:07 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11682
for ; Wed, 20 Jun 2001 11:48:05 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA25489;
Thu, 21 Jun 2001 02:08:43 +1200 (NZST)
Received: from smtp4ve.mailsrvcs.net (smtp4vepub.gte.net [206.46.170.25])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA25483;
Thu, 21 Jun 2001 02:08:40 +1200 (NZST)
Received: from sphynx (adsl-162-83-194-24.nyc.adsl.bellatlantic.net [162.83.194.24])
by smtp4ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id OAA43753980;
Wed, 20 Jun 2001 14:07:30 GMT
Reply-To:
From: "Carter Bullard"
To:
Cc: "'Juergen Quittek'" , ,
"'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: Packet capture problem statement
Date: Wed, 20 Jun 2001 10:07:30 -0400
Organization: QoSient, LLC
Message-ID: <38E99DA2CEFA7248B5828BBF99344D8608C2F9@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <485855574.992623300@[192.168.102.178]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Gentle people,
In following up on the packet capture issues that were identified
at the RTFM2 BOF, the Management and Operations Area Directors have
suggested that we send a problem description and explanation to
the RMONMIB mailing list to see if there is consensus on the problem
and if RMONMIB is the right working group to consider the effort.
I have put together an initial draft problem statement, and I
would really like to get your input/comments. Since this is a
formal step in trying to get the IETF to address issues in packet
capture, I hope that we can put together a good statement and
explanation. If you have any comments, suggestions, opinions,
reactions, attitudes, flames, whatever, please do respond .
Thanks for the attention,
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
------- Insert Rmonmib Problem Statement.txt -------
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".
RFC-2613 identified 5 fundamental barriers that make packet monitoring
in modern networks difficult and noted that, "In order to overcome the
limitations of the existing standards, new monitoring mechanisms have
been implemented by vendors of switching equipment. All these
monitoring strategies are currently proprietary in nature". The
principal monitoring strategy referred to by RFC-2613 is "port copy",
which has been implemented by many switch and router vendors. While
RFC-2613 extended the RMON MIB standard definition of data source
objects to include "port copy" as a data source for RMON and SMON data,
RFC-2631 did not qualify these extended RMON and SMON data sources as
suitable for a particular task.
Packet analysis applications are being extended and new ones are being
proposed in several IETF working groups that cannot rely on "port copy"
mechanisms as a definitive source of packet data. Packet analysis
applications, such as Real Time Flow Monitors, Intrusion Detection
Devices and IPPM Framework based performance meters have difficultly
using "port copy" facilities, in part because the "port copy" mechanism
does not convey enough information regarding the source, disposition,
loss characteristics, order and time of replicated packets. As a
simple example, many "port copy" operating modes can result in multiple
copies of the same packet being delivered to an application, without
any means to detect that the packet is a duplicate. In these
conditions, port copy derived data will generate erroneous values in
applications such as RMON MIB.
In addition to the technical issues that limit port copy as a
definitive source of packet data for analytic functions, port copy
style mechanisms pose a significant threat to individual privacy. This
is because port copy mechanisms can only copy entire datagrams to
another interface. Without any mechanisms for minimizing user data
exposure or for limiting access to the resulting packet data, simple
port copy strategies introduce new significant threats to privacy.
As RFC-2613 indicated, vendors are implementing port copy schemes to
overcome limitations of the existing standards. We would like to
propose that the Remote Monitoring Working Group consider as a work
item, the specification of a packet copy facility that can act as a
definitive source of packet data for network analytic applications.
From owner-rtfm@auckland.ac.nz Fri Jun 22 10:17:25 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22495
for ; Fri, 22 Jun 2001 10:17:22 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA29175;
Sat, 23 Jun 2001 00:33:39 +1200 (NZST)
Received: from smtp7ve.mailsrvcs.net (smtp7vepub.gte.net [206.46.170.28])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA29169;
Sat, 23 Jun 2001 00:33:36 +1200 (NZST)
Received: from sphynx (adsl-162-83-194-24.nyc.adsl.bellatlantic.net [162.83.194.24])
by smtp7ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id MAA35494637;
Fri, 22 Jun 2001 12:32:25 GMT
Reply-To:
From: "Carter Bullard"
To:
Cc: "'Juergen Quittek'" , ,
"'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Date: Fri, 22 Jun 2001 08:32:21 -0400
Organization: QoSient, LLC
Message-ID: <38E99DA2CEFA7248B5828BBF99344D8608C315@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <38E99DA2CEFA7248B5828BBF99344D8608C2F9@ptah.newyork.qosient.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Gentle people,
Because there is little discussion regarding this,
I would like to assume that this is a reasonable start
for the process. Again if there are any comments,
opinions, reactions, either good or bad, please do send
them, as I would like to put this problem statement to
the RMONMIB mailing list today (Friday) or Monday.
Thanks for your attention!!!
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: Carter Bullard [mailto:carter@qosient.com]
> Sent: Wednesday, June 20, 2001 10:08 AM
> To: 'rtfm@auckland.ac.nz'
> Cc: 'Juergen Quittek'; 'n.brownlee@auckland.ac.nz'; 'Georg
> Carle'; 'Tanja Zseby'; 'Sebastian Zander'; 'Marcelo Pias'
> Subject: Packet capture problem statement
>
>
> Gentle people,
> In following up on the packet capture issues that were
> identified at the RTFM2 BOF, the Management and Operations
> Area Directors have suggested that we send a problem
> description and explanation to the RMONMIB mailing list to
> see if there is consensus on the problem and if RMONMIB is
> the right working group to consider the effort.
>
> I have put together an initial draft problem statement, and I
> would really like to get your input/comments. Since this is
> a formal step in trying to get the IETF to address issues in
> packet capture, I hope that we can put together a good
> statement and explanation. If you have any comments,
> suggestions, opinions, reactions, attitudes, flames,
> whatever, please do respond .
>
> Thanks for the attention,
>
> Carter
>
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York 10022
>
> carter@qosient.com
> Phone +1 212 588-9133
> Fax +1 212 588-9134
> http://qosient.com
>
> ------- Insert Rmonmib Problem Statement.txt -------
>
>
> 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".
>
> RFC-2613 identified 5 fundamental barriers that make packet
> monitoring
> in modern networks difficult and noted that, "In order to
> overcome the
> limitations of the existing standards, new monitoring mechanisms have
> been implemented by vendors of switching equipment. All these
> monitoring strategies are currently proprietary in nature". The
> principal monitoring strategy referred to by RFC-2613 is "port copy",
> which has been implemented by many switch and router vendors. While
> RFC-2613 extended the RMON MIB standard definition of data source
> objects to include "port copy" as a data source for RMON and
> SMON data,
> RFC-2631 did not qualify these extended RMON and SMON data sources as
> suitable for a particular task.
>
> Packet analysis applications are being extended and new ones
> are being
> proposed in several IETF working groups that cannot rely on
> "port copy"
> mechanisms as a definitive source of packet data. Packet analysis
> applications, such as Real Time Flow Monitors, Intrusion Detection
> Devices and IPPM Framework based performance meters have difficultly
> using "port copy" facilities, in part because the "port copy"
> mechanism
> does not convey enough information regarding the source, disposition,
> loss characteristics, order and time of replicated packets. As a
> simple example, many "port copy" operating modes can result
> in multiple
> copies of the same packet being delivered to an application, without
> any means to detect that the packet is a duplicate. In these
> conditions, port copy derived data will generate erroneous values in
> applications such as RMON MIB.
>
> In addition to the technical issues that limit port copy as a
> definitive source of packet data for analytic functions, port copy
> style mechanisms pose a significant threat to individual
> privacy. This
> is because port copy mechanisms can only copy entire datagrams to
> another interface. Without any mechanisms for minimizing user data
> exposure or for limiting access to the resulting packet data, simple
> port copy strategies introduce new significant threats to privacy.
>
> As RFC-2613 indicated, vendors are implementing port copy schemes to
> overcome limitations of the existing standards. We would like to
> propose that the Remote Monitoring Working Group consider as a work
> item, the specification of a packet copy facility that can act as a
> definitive source of packet data for network analytic applications.
>
>
>
From owner-rtfm@auckland.ac.nz Tue Jun 26 09:44:43 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05281
for ; Tue, 26 Jun 2001 09:44:41 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA00289;
Tue, 26 Jun 2001 23:39:31 +1200 (NZST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id XAA00280;
Tue, 26 Jun 2001 23:39:27 +1200 (NZST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f5QBdXb29400;
Tue, 26 Jun 2001 13:39:34 +0200 (CEST)
Received: from [192.168.102.178] (belem.heidelberg.ccrle.nec.de [192.168.102.178])
by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA28284;
Tue, 26 Jun 2001 13:35:45 +0200
Date: Tue, 26 Jun 2001 13:36:48 +0200
From: Juergen Quittek
To: carter@qosient.com, rtfm@auckland.ac.nz
cc: n.brownlee@auckland.ac.nz, "'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: Re: Packet capture problem statement
Message-ID: <1425163534.993562608@[192.168.102.178]>
In-Reply-To: <38E99DA2CEFA7248B5828BBF99344D8608C2F9@ptah.newyork.qosient.com>
X-Mailer: Mulberry/2.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hi Carter,
I think your text expresses the idea very well. I just have three
minor comments which you will find inline.
Juergen
--On Mittwoch, 20. Juni 2001 10:07 -0400 Carter Bullard wrote:
> Gentle people,
> In following up on the packet capture issues that were identified
> at the RTFM2 BOF, the Management and Operations Area Directors have
> suggested that we send a problem description and explanation to
> the RMONMIB mailing list to see if there is consensus on the problem
> and if RMONMIB is the right working group to consider the effort.
>
> I have put together an initial draft problem statement, and I
> would really like to get your input/comments. Since this is a
> formal step in trying to get the IETF to address issues in packet
> capture, I hope that we can put together a good statement and
> explanation. If you have any comments, suggestions, opinions,
> reactions, attitudes, flames, whatever, please do respond .
>
> Thanks for the attention,
>
> Carter
>
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York 10022
>
> carter@qosient.com
> Phone +1 212 588-9133
> Fax +1 212 588-9134
> http://qosient.com
>
> ------- Insert Rmonmib Problem Statement.txt -------
>
>
> 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".
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.
> RFC-2613 identified 5 fundamental barriers that make packet monitoring
> in modern networks difficult and noted that, "In order to overcome the
> limitations of the existing standards, new monitoring mechanisms have
> been implemented by vendors of switching equipment. All these
> monitoring strategies are currently proprietary in nature". The
> principal monitoring strategy referred to by RFC-2613 is "port copy",
> which has been implemented by many switch and router vendors. While
> RFC-2613 extended the RMON MIB standard definition of data source
> objects to include "port copy" as a data source for RMON and SMON data,
> RFC-2631 did not qualify these extended RMON and SMON data sources as
> suitable for a particular task.
>
> Packet analysis applications are being extended and new ones are being
> proposed in several IETF working groups that cannot rely on "port copy"
> mechanisms as a definitive source of packet data. Packet analysis
> applications, such as Real Time Flow Monitors, Intrusion Detection
> Devices and IPPM Framework based performance meters have difficultly
> using "port copy" facilities, in part because the "port copy" mechanism
> does not convey enough information regarding the source, disposition,
> loss characteristics, order and time of replicated packets. As a
> simple example, many "port copy" operating modes can result in multiple
> copies of the same packet being delivered to an application, without
> any means to detect that the packet is a duplicate. In these
> conditions, port copy derived data will generate erroneous values in
> applications such as RMON MIB.
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.
> In addition to the technical issues that limit port copy as a
> definitive source of packet data for analytic functions, port copy
> style mechanisms pose a significant threat to individual privacy. This
> is because port copy mechanisms can only copy entire datagrams to
> another interface. Without any mechanisms for minimizing user data
> exposure or for limiting access to the resulting packet data, simple
> port copy strategies introduce new significant threats to privacy.
I would mention here that there still remains a threat to privacy
that should be considered thoroughly.
> As RFC-2613 indicated, vendors are implementing port copy schemes to
> overcome limitations of the existing standards. We would like to
> propose that the Remote Monitoring Working Group consider as a work
> item, the specification of a packet copy facility that can act as a
> definitive source of packet data for network analytic applications.
>
>
>
From owner-rtfm@auckland.ac.nz Tue Jun 26 09:51:13 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06192
for ; Tue, 26 Jun 2001 09:51:11 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA04566;
Wed, 27 Jun 2001 00:21:43 +1200 (NZST)
Received: from virus-out.office-mail.co.uk (postfix@virus-out.office-mail.co.uk [217.15.160.67])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA04190;
Wed, 27 Jun 2001 00:17:10 +1200 (NZST)
Received: from mailsweeper2.office-mail.co.uk (mailsweeper2.office-mail.co.uk [217.15.160.65])
by virus-out.office-mail.co.uk (Postfix) with ESMTP
id C6E425D72; Mon, 25 Jun 2001 17:04:21 +0100 (BST)
Received: from virus-in.office-mail.co.uk (virus-in.office-mail.co.uk) by mailsweeper2.office-mail.co.uk
(Content Technologies SMTPRS 4.1.5) with ESMTP id ;
Mon, 25 Jun 2001 18:46:04 +0100
Received: from ntserver.office-mail.co.uk (ghostmailaddress.office-mail.co.uk [217.15.160.49])
by virus-in.office-mail.co.uk (Postfix) with ESMTP
id 15C5E36B8; Mon, 25 Jun 2001 17:01:51 +0100 (BST)
Received: by NTSERVER with Internet Mail Service (5.5.2650.21)
id ; Mon, 25 Jun 2001 17:00:31 +0100
Message-ID: <8B12F6A1231DD411A70600A0CC68AFC50D384E@NTSERVER>
From: Sean Kelly
To: netramet@auckland.ac.nz
Cc: rtfm@auckland.ac.nz
Subject: Monitoring and reporting network usage - dropped packets
Date: Mon, 25 Jun 2001 17:00:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Hi all,
Thanks again to all those who sent advice and comments regarding my
last post. They are greatly appreciated :)
Something that was questioned in the last conversation was whether
any packets were being dropped. Some people (Peter Van Epp was at least one
of them) mentioned that 'tcpdump' may report dropping packets when the
kernel will not.
After letting 'tcpdump' run for just over a minute I get:
36510 packets received by filter
35519 packets dropped by kernel
so does this mean that I'm losing about 97% of packets? I ran 'tcpdump' at
the same time my monitoring software was running - does this influence the
dropping of packets?
Thanks in advance,
--
Sean Kelly
*************************************************************
This email message has been scanned by MIMEsweeper for the
presence of computer viruses by www.viruscleaningcentre.co.uk
Hosted by the North East Datacentre www.ne-datacentre.co.uk
*************************************************************
From owner-rtfm@auckland.ac.nz Tue Jun 26 17:07:43 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18320
for ; Tue, 26 Jun 2001 17:07:41 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA23417;
Wed, 27 Jun 2001 07:54:40 +1200 (NZST)
Received: from smtp5ve.mailsrvcs.net (smtp5vepub.gte.net [206.46.170.26])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA23408;
Wed, 27 Jun 2001 07:54:37 +1200 (NZST)
Received: from sphynx (adsl-162-83-194-24.nyc.adsl.bellatlantic.net [162.83.194.24])
by smtp5ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id TAA21012129;
Tue, 26 Jun 2001 19:53:27 GMT
Reply-To:
From: "Carter Bullard"
To: "'Juergen Quittek'" ,
Cc: , "'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Date: Tue, 26 Jun 2001 15:53:27 -0400
Organization: QoSient, LLC
Message-ID: <38E99DA2CEFA7248B5828BBF99344D8608C325@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <1425163534.993562608@[192.168.102.178]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hey Juergen,
Thanks for the comments. Just a few responses for
clarification. I'll incorporate your suggestions in
the draft.
Thanks again!!!
Carter
> -----Original Message-----
[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".
>
> 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 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.
[snip]
>
> > In addition to the technical issues that limit port copy as a
> > definitive source of packet data for analytic functions, port copy
> > style mechanisms pose a significant threat to individual privacy.
> > This is because port copy mechanisms can only copy entire
> datagrams to
> > another interface. Without any mechanisms for minimizing user data
> > exposure or for limiting access to the resulting packet
> data, simple
> > port copy strategies introduce new significant threats to privacy.
>
> I would mention here that there still remains a threat to
> privacy that should be considered thoroughly.
>
How about adding?
port copy strategies introduce new significant threats to privacy,
that need to be addressed.
From owner-rtfm@auckland.ac.nz Wed Jun 27 06:26:33 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02205
for ; Wed, 27 Jun 2001 06:26:32 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA05945;
Wed, 27 Jun 2001 20:54:53 +1200 (NZST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA05934;
Wed, 27 Jun 2001 20:54:49 +1200 (NZST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f5R8sqb39079;
Wed, 27 Jun 2001 10:54:52 +0200 (CEST)
Received: from [192.168.102.178] (belem.heidelberg.ccrle.nec.de [192.168.102.178])
by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA02725;
Wed, 27 Jun 2001 10:50:56 +0200
Date: Wed, 27 Jun 2001 10:52:13 +0200
From: Juergen Quittek
To: carter@qosient.com, rtfm@auckland.ac.nz
cc: n.brownlee@auckland.ac.nz, "'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Message-ID: <1501687884.993639133@[192.168.102.178]>
In-Reply-To: <38E99DA2CEFA7248B5828BBF99344D8608C325@ptah.newyork.qosient.com>
X-Mailer: Mulberry/2.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hi Carter,
Seems like I did not phrase well. Please see my comment below.
-- Carter Bullard 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".
>>
>> 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 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 owner-rtfm@auckland.ac.nz Wed Jun 27 08:48:13 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02279
for ; Wed, 27 Jun 2001 08:48:11 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA14595;
Wed, 27 Jun 2001 23:17:15 +1200 (NZST)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id XAA14590;
Wed, 27 Jun 2001 23:17:13 +1200 (NZST)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RBGTs01971;
Wed, 27 Jun 2001 07:16:29 -0400 (EDT)
Received: from warp.lannet.com (h149-49-50-36.avaya.com [149.49.50.36])
by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RBGLN01945;
Wed, 27 Jun 2001 07:16:21 -0400 (EDT)
Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52])
by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id OAA28035;
Wed, 27 Jun 2001 14:26:00 +0300 (IDT)
Received: by ITC-EML2 with Internet Mail Service (5.5.2650.21)
id ; Wed, 27 Jun 2001 14:16:03 +0200
Message-ID: <15F58915DF84D311AC7D0090279AA6144467CA@ITC-EML2>
From: Dan Romascanu
To: "'Juergen Quittek'" , carter@qosient.com,
rtfm@auckland.ac.nz
Cc: n.brownlee@auckland.ac.nz, "'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'"
,
"'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Date: Wed, 27 Jun 2001 14:16:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
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 owner-rtfm@auckland.ac.nz Wed Jun 27 10:41:05 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03326
for ; Wed, 27 Jun 2001 10:41:04 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA20577;
Thu, 28 Jun 2001 01:04:03 +1200 (NZST)
Received: from ptah.newyork.qosient.com (adsl-162-83-194-24.nyc.adsl.bellatlantic.net [162.83.194.24])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA20565;
Thu, 28 Jun 2001 01:04:00 +1200 (NZST)
Subject: RE: Packet capture problem statement
Date: Wed, 27 Jun 2001 09:03:57 -0400
Message-ID: <38E99DA2CEFA7248B5828BBF99344D86082729@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Thread-Topic: Packet capture problem statement
Thread-Index: AcD/CZ4OQwG68e1aSceYVFjx/WxZrA==
From: "Carter Bullard"
To: "Juergen Quittek" ,
"Carter Bullard" ,
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Cc: , "Georg Carle" ,
"Tanja Zseby" ,
"Sebastian Zander" ,
"Marcelo Pias"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03326
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
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> Sent: Wednesday, June 27, 2001 4:52 AM
> To: Carter Bullard; rtfm@auckland.ac.nz
> Cc: n.brownlee@auckland.ac.nz; '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 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".
> >>
> >> 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 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 owner-rtfm@auckland.ac.nz Wed Jun 27 10:53:19 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11629
for ; Wed, 27 Jun 2001 10:53:17 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA20625;
Thu, 28 Jun 2001 01:05:05 +1200 (NZST)
Received: from smtp4ve.mailsrvcs.net (smtp4vepub.gte.net [206.46.170.25])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA20620;
Thu, 28 Jun 2001 01:05:03 +1200 (NZST)
Received: from sphynx (adsl-162-83-194-24.nyc.adsl.bellatlantic.net [162.83.194.24])
by smtp4ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id NAA47607701;
Wed, 27 Jun 2001 13:03:55 GMT
Reply-To:
From: "Carter Bullard"
To: "'Juergen Quittek'" ,
"Carter Bullard" ,
Cc: , "'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Date: Wed, 27 Jun 2001 09:03:53 -0400
Organization: QoSient, LLC
Message-ID: <38E99DA2CEFA7248B5828BBF99344D86082729@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <1501687884.993639133@[192.168.102.178]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
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
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> Sent: Wednesday, June 27, 2001 4:52 AM
> To: Carter Bullard; rtfm@auckland.ac.nz
> Cc: n.brownlee@auckland.ac.nz; '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 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".
> >>
> >> 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 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 owner-rtfm@auckland.ac.nz Wed Jun 27 17:59:02 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09433
for ; Wed, 27 Jun 2001 17:59:00 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA08555;
Thu, 28 Jun 2001 08:24:53 +1200 (NZST)
Received: from hotmail.com (law2-f34.hotmail.com [216.32.181.34])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA08537;
Thu, 28 Jun 2001 08:24:50 +1200 (NZST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Wed, 27 Jun 2001 13:24:20 -0700
Received: from 24.8.90.2 by lw2fd.hotmail.msn.com with HTTP; Wed, 27 Jun 2001 20:24:20 GMT
X-Originating-IP: [24.8.90.2]
From: "jason dinkleman"
To: quittek@ccrle.nec.de, carter@qosient.com, rtfm@auckland.ac.nz
Cc: n.brownlee@auckland.ac.nz, carle@fokus.gmd.de, zseby@fokus.gmd.de,
zander@fokus.gmd.de, M.Pias@cs.ucl.ac.uk
Subject: RE: Packet capture problem statement
Date: Wed, 27 Jun 2001 16:24:20 -0400
Mime-Version: 1.0
Content-Type: text/html
Message-ID:
X-OriginalArrivalTime: 27 Jun 2001 20:24:20.0751 (UTC) FILETIME=[25C089F0:01C0FF47]
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
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: carter@qosient.com, rtfm@auckland.ac.nz
CC: n.brownlee@auckland.ac.nz, "'Georg Carle'" , "'Tanja Zseby'" , "'Sebastian Zander'" , "'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Date: Wed, 27 Jun 2001 10:52:13 +0200
Hi Carter,
Seems like I did not phrase well. Please see my comment below.
-- Carter Bullard 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".
>>
>>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 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
Get your FREE download of MSN Explorer at http://explorer.msn.com
From owner-rtfm@auckland.ac.nz Wed Jun 27 22:32:14 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16719
for ; Wed, 27 Jun 2001 22:32:12 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA03967;
Thu, 28 Jun 2001 05:09:31 +1200 (NZST)
Received: from smtp6ve.mailsrvcs.net (smtp6vepub.gte.net [206.46.170.27])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA03962;
Thu, 28 Jun 2001 05:09:29 +1200 (NZST)
Received: from sphynx (adsl-162-83-194-24.nyc.adsl.bellatlantic.net [162.83.194.24])
by smtp6ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id RAA36731552;
Wed, 27 Jun 2001 17:08:21 GMT
Reply-To:
From: "Carter Bullard"
To: "'Juergen Quittek'" ,
Cc: , "'Georg Carle'" ,
"'Tanja Zseby'" ,
"'Sebastian Zander'" ,
"'Marcelo Pias'"
Subject: RE: Packet capture problem statement
Date: Wed, 27 Jun 2001 13:08:20 -0400
Organization: QoSient, LLC
Message-ID: <38E99DA2CEFA7248B5828BBF99344D86082734@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <1501687884.993639133@[192.168.102.178]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit
Gentle people,
I will not be able to send the problem statement to
RMONMIB until Monday, as my plane is leaving soon, and
I still have a change or two to make.
I will be sending it out on Monday, so if you have
comments, still. Please do send them this way before
the end of the week.
Thanks!!!!
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter@qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
From owner-rtfm@auckland.ac.nz Thu Jun 28 21:58:57 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00049
for ; Thu, 28 Jun 2001 21:58:56 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA20552;
Fri, 29 Jun 2001 07:14:51 +1200 (NZST)
Received: from babar.switch.ch (babar.switch.ch [130.59.4.2])
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA20546
for ; Fri, 29 Jun 2001 07:14:49 +1200 (NZST)
Received: (from leinen@localhost)
by babar.switch.ch (8.10.2+Sun/8.10.2) id f5SJEA403310;
Thu, 28 Jun 2001 21:14:10 +0200 (MEST)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: plonka@doit.wisc.edu
Cc: rtfm@auckland.ac.nz
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next Move")
References:
<20010423112822.A22844@doit.wisc.edu>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen
In-Reply-To: <20010423112822.A22844@doit.wisc.edu>
Date: 28 Jun 2001 21:14:10 +0200
Message-ID:
Lines: 18
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
[sorry for the late followup]
>>>>> "dp" == Dave Plonka writes:
> On Sun, Apr 15, 2001 at 01:26:29AM -0700, Nevil Brownlee wrote:
>> Collection of TCP or UDP microflows that
> What prior work defines "microflows"? (For the moment I'm presuming
> for TCP that that would be a fragment of a stream.)
I first heard about it in the context of diffserv, and RFC 2474
(Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers) includes a short and sweet definition:
Microflow: a single instance of an application-to-application flow
of packets which is identified by source address, destination
address, protocol id, and source port, destination port (where
applicable).
--
Simon.
From owner-rtfm@auckland.ac.nz Fri Jun 29 01:55:16 2001
Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16331
for ; Fri, 29 Jun 2001 01:55:14 -0400 (EDT)
Received: (from majordom@localhost)
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA20079;
Fri, 29 Jun 2001 12:18:46 +1200 (NZST)
Received: from sgi04-e.std.com (sgi04-e.std.com [199.172.62.134] (may be forged))
by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA20073
for ; Fri, 29 Jun 2001 12:18:44 +1200 (NZST)
Received: from world.std.com (world-f.std.com [199.172.62.5])
by sgi04-e.std.com (8.9.3/8.9.3) with ESMTP id UAA8553720;
Thu, 28 Jun 2001 20:18:44 -0400 (EDT)
Received: from localhost (brunner@localhost)
by world.std.com (8.9.3/8.9.3) with SMTP id UAA11533;
Thu, 28 Jun 2001 20:18:29 -0400 (EDT)
Message-Id: <200106290018.UAA11533@world.std.com>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: Simon Leinen
cc: plonka@doit.wisc.edu, rtfm@auckland.ac.nz, brunner@world.std.com
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next Move")
In-reply-to: Your message of "28 Jun 2001 21:14:10 EDT."
Date: Thu, 28 Jun 2001 20:18:27 -0400
From: Eric Brunner
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
[ditto]
> [sorry for the late followup]
> >>>>> "dp" == Dave Plonka writes:
> > On Sun, Apr 15, 2001 at 01:26:29AM -0700, Nevil Brownlee wrote:
> >> Collection of TCP or UDP microflows that
>
> > What prior work defines "microflows"? (For the moment I'm presuming
> > for TCP that that would be a fragment of a stream.)
>
> I first heard about it in the context of diffserv, and RFC 2474
> (Definition of the Differentiated Services Field (DS Field) in the
> IPv4 and IPv6 Headers) includes a short and sweet definition:
>
> Microflow: a single instance of an application-to-application flow
> of packets which is identified by source address, destination
> address, protocol id, and source port, destination port (where
> applicable).
This definition includes the http state management mechanism (cookies), a
point I brought up at the IRTF AAAArch meeting in Pittsburg, semi-privately.
Eric