IP Flow Information Export (ipfix)

Carter Bullard | 3 Sep 2002 21:36

RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)

Gentle People,
   An unambiguous way of referring to the fragment most
likely to contain flow identifying information
is to refer to the "zero offset fragment".

   It is not correct to assume, however, that all the information
needed to track a standard 5-tuple flow is in the zero
offset fragment, as the algorithm allows fragmentation to
occur within the TCP header.  While there are RFC's that
suggest that this should not be allowed, some routers still
can fragment at the destination port field boundary.  I
believe that a paragraph that talks about fragmentation
should mention that some reassembly may be required.

Carter

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

+1 212 588-9133 Phone
+1 212 588-9134 Fax

> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo <at> mil.doit.wisc.edu] On Behalf Of 
> calato <at> riverstonenet.com
> Sent: Friday, August 30, 2002 10:14 AM

(Continue reading)

calato | 4 Sep 2002 16:21

[ipfix-req] Re: IPFIX Requirements Questions


I wanted to summarize where we are with the issues
I raised a while back. A few still need to be resolved.

calato <at> riverstonenet.com wrote:
> 
> As I work on the advocates document some questions
> have come to mind on the requirements document.
> 
> 4.3 Distinguishing flows using Transport Header Fields
> 
>         In the case of fragmented packets there are
>         no port numbers. Are we saying flow state information
>         MUST be maintained? In general, it is not clear from
>         the document what the requirements are for fragmented
>         packets.

	RESOLVED: State information MAY be kept for 
		  proper flow designation.

> 
> 4.4 MPLS Label
> 
>         In the case of dynamic LSP's the label is not useful.
>         Why require distinguishing flows based on label.
>         What can be done with that information?

	RESOLVED: We agreed to distinguish by label and to report label.

>

(Continue reading)

STEPHAN Emile FTRD/DAC/LAN | 13 Sep 2002 10:49

draft-stephan-ippm-spatial-metrics-00.txt

Hello,

An new I-D related to measurement is available online http://www.ietf.org/internet-drafts/draft-stephan-ippm-spatial-metrics-00.txt

Abstract:
	  The IETF IP Performance Metrics (IPPM) working group has standardized 
	  metrics for measuring end to end performance. Measurements system 
	  scope is often limited to administrative boundaries. This memo 
	  defines spatial metrics both for measuring end-to-end network 
	  performance using aggregation of sequence of network measures and for 
	  measuring the performance of segment of an IP path trajectory. It 
	  distinguishes clearly the decomposition of one end-to-end measure 
	  result in a sequence of per hop results from the aggregation of a 
	  sequence of per hop measure results in an end-to-end result. 

 
best regards.
Emile

Benoit Claise | 17 Sep 2002 17:16

Picon

[ipfix-req] IPFIX Requirement draft status

Dear all,

A lot of topics have been recently discussed on the mailing list. So 
many that the draft status is currently not too clear (even if we have 
some consensus on certain issues).
Let us consolidate all the feedback, insert all the changes into a new 
requirement draft and send it to the mailing list. This should be done 
by the middle of next week.

Regards, the editor team

--
Help        mailto:majordomo <at> net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo <at> net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

calato | 17 Sep 2002 17:45

Re: [ipfix-req] IPFIX Requirement draft status

Benoit Claise wrote:
> 
> Dear all,
> 
> A lot of topics have been recently discussed on the mailing list. So
> many that the draft status is currently not too clear (even if we have
> some consensus on certain issues).
> Let us consolidate all the feedback, insert all the changes into a new
> requirement draft and send it to the mailing list. This should be done
> by the middle of next week.

	I would like to get some resolution to the remaining
	open issues I raised first. I sent a summary message 
	to the list, but no responses to date.

	Paul

> 
> Regards, the editor team
> 
> --
> Help        mailto:majordomo <at> net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo <at> net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo <at> net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo <at> net.doit.wisc.edu and say
"unsubscribe ipfix" in message body

(Continue reading)

Ganesh Sadasivan | 26 Sep 2002 04:20

Picon

Re: [ipfix-req] Re: IPFIX Requirements Questions


calato <at> riverstonenet.com wrote:

> I wanted to summarize where we are with the issues
> I raised a while back. A few still need to be resolved.
>
> calato <at> riverstonenet.com wrote:
> >
> > As I work on the advocates document some questions
> > have come to mind on the requirements document.
> >
> > 4.3 Distinguishing flows using Transport Header Fields
> >
> >         In the case of fragmented packets there are
> >         no port numbers. Are we saying flow state information
> >         MUST be maintained? In general, it is not clear from
> >         the document what the requirements are for fragmented
> >         packets.
>
>         RESOLVED: State information MAY be kept for
>                   proper flow designation.
>
> >
> > 4.4 MPLS Label
> >
> >         In the case of dynamic LSP's the label is not useful.
> >         Why require distinguishing flows based on label.
> >         What can be done with that information?
>
>         RESOLVED: We agreed to distinguish by label and to report label.

(Continue reading)

calato | 26 Sep 2002 16:16

Re: [ipfix-req] Re: IPFIX Requirements Questions

Ganesh Sadasivan wrote:
> 
> calato <at> riverstonenet.com wrote:
> 
> > I wanted to summarize where we are with the issues
> > I raised a while back. A few still need to be resolved.
> >
> > calato <at> riverstonenet.com wrote:
> > >
> > > As I work on the advocates document some questions
> > > have come to mind on the requirements document.
> > >
> > > 4.3 Distinguishing flows using Transport Header Fields
> > >
> > >         In the case of fragmented packets there are
> > >         no port numbers. Are we saying flow state information
> > >         MUST be maintained? In general, it is not clear from
> > >         the document what the requirements are for fragmented
> > >         packets.
> >
> >         RESOLVED: State information MAY be kept for
> >                   proper flow designation.
> >
> > >
> > > 4.4 MPLS Label
> > >
> > >         In the case of dynamic LSP's the label is not useful.
> > >         Why require distinguishing flows based on label.
> > >         What can be done with that information?
> >

(Continue reading)

Ganesh Sadasivan | 26 Sep 2002 17:39

Picon

Re: [ipfix-req] Re: IPFIX Requirements Questions


calato <at> riverstonenet.com wrote:

> Ganesh Sadasivan wrote:
> >
> > calato <at> riverstonenet.com wrote:
> >
> > > I wanted to summarize where we are with the issues
> > > I raised a while back. A few still need to be resolved.
> > >
> > > calato <at> riverstonenet.com wrote:
> > > >
> > > > As I work on the advocates document some questions
> > > > have come to mind on the requirements document.
> > > >
> > > > 4.3 Distinguishing flows using Transport Header Fields
> > > >
> > > >         In the case of fragmented packets there are
> > > >         no port numbers. Are we saying flow state information
> > > >         MUST be maintained? In general, it is not clear from
> > > >         the document what the requirements are for fragmented
> > > >         packets.
> > >
> > >         RESOLVED: State information MAY be kept for
> > >                   proper flow designation.
> > >
> > > >
> > > > 4.4 MPLS Label
> > > >
> > > >         In the case of dynamic LSP's the label is not useful.

(Continue reading)

calato | 26 Sep 2002 18:14

Re: [ipfix-req] Re: IPFIX Requirements Questions

Ganesh Sadasivan wrote:
> 
> calato <at> riverstonenet.com wrote:
> 
> > Ganesh Sadasivan wrote:
> > >
> > > calato <at> riverstonenet.com wrote:
> > >
> > > > I wanted to summarize where we are with the issues
> > > > I raised a while back. A few still need to be resolved.
> > > >
> > > > calato <at> riverstonenet.com wrote:
> > > > >
> > > > > As I work on the advocates document some questions
> > > > > have come to mind on the requirements document.
> > > > >
> > > > > 4.3 Distinguishing flows using Transport Header Fields
> > > > >
> > > > >         In the case of fragmented packets there are
> > > > >         no port numbers. Are we saying flow state information
> > > > >         MUST be maintained? In general, it is not clear from
> > > > >         the document what the requirements are for fragmented
> > > > >         packets.
> > > >
> > > >         RESOLVED: State information MAY be kept for
> > > >                   proper flow designation.
> > > >
> > > > >
> > > > > 4.4 MPLS Label
> > > > >

(Continue reading)

Ganesh Sadasivan | 26 Sep 2002 20:54

Picon

Re: [ipfix-req] Re: IPFIX Requirements Questions


calato <at> riverstonenet.com wrote:

> Ganesh Sadasivan wrote:
> >
> > calato <at> riverstonenet.com wrote:
> >
> > > Ganesh Sadasivan wrote:
> > > >
> > > > calato <at> riverstonenet.com wrote:
> > > >
> > > > > I wanted to summarize where we are with the issues
> > > > > I raised a while back. A few still need to be resolved.
> > > > >
> > > > > calato <at> riverstonenet.com wrote:
> > > > > >
> > > > > > As I work on the advocates document some questions
> > > > > > have come to mind on the requirements document.
> > > > > >
> > > > > > 4.3 Distinguishing flows using Transport Header Fields
> > > > > >
> > > > > >         In the case of fragmented packets there are
> > > > > >         no port numbers. Are we saying flow state information
> > > > > >         MUST be maintained? In general, it is not clear from
> > > > > >         the document what the requirements are for fragmented
> > > > > >         packets.
> > > > >
> > > > >         RESOLVED: State information MAY be kept for
> > > > >                   proper flow designation.
> > > > >

(Continue reading)

Group

gmane.ietf.ipfix.

Advertisement

Search Archive

Page

1 | 2 | 3

Articles in period: 28

September 2002

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[IPFIX] Flow-state dependent packet selection techniques -- draft upda (18 Jun 2013)
[IPFIX] Changes to IPFIX Information Elements approved by IE Doctors (18 Jun 2013)
[IPFIX] Last Call: (Spec (14 Jun 2013)
[IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-08.txt (13 Jun 2013)
[IPFIX] Protocol Action: 'Flow Selection Techniques' to Proposed Stand (3 Jun 2013)
[IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-18.txt (30 May 2013)
[IPFIX] Compliance Statement (Pete Resnick's DISCUSS) (28 May 2013)
[IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-17.txt (24 May 2013)
[IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-07.txt (23 May 2013)
[IPFIX] Questions about compliance statement in IPFIX-selection-techni (22 May 2013)
[IPFIX] Fwd: initiatorOctets/initiatorPackets/responderOctets/responde (17 May 2013)
[IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPack (16 May 2013)
[IPFIX] Ted Lemon's No Objection on draft-ietf-ipfix-flow-selection-te (12 May 2013)
[IPFIX] Biggest Fake Conference in Computer Science (27 Apr 2013)
[IPFIX] R: R: Last Call Expired: (24 Apr 2013)
[IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-16.txt (21 Apr 2013)
[IPFIX] Last Call: (Spec (17 Apr 2013)
[IPFIX] Last Call: (Spec (17 Apr 2013)
[IPFIX] R: Last Call Expired: (15 Apr 2013)
[IPFIX] Data type change for observationPointId (11 Apr 2013)
[IPFIX] Last Call Expired: (10 Apr 2013)

10	June 2013
22	May 2013
32	April 2013
43	March 2013
41	February 2013
19	January 2013
54	December 2012
61	November 2012
75	October 2012
41	September 2012
43	August 2012
48	July 2012
42	June 2012
7	May 2012
39	April 2012
70	March 2012
63	February 2012
11	January 2012
15	December 2011
33	November 2011
42	October 2011
64	September 2011
68	August 2011
48	July 2011
26	June 2011
28	May 2011
36	April 2011
56	March 2011
16	February 2011
26	January 2011
25	December 2010
44	November 2010
73	October 2010
25	September 2010
20	August 2010
38	July 2010
11	June 2010
30	May 2010
20	April 2010
128	March 2010
37	February 2010
31	January 2010
22	December 2009
48	November 2009
55	October 2009
17	September 2009
24	August 2009
73	July 2009
87	June 2009
14	May 2009
33	April 2009
62	March 2009
38	February 2009
12	January 2009
1	December 2008
38	November 2008
22	October 2008
9	September 2008
18	August 2008
32	July 2008
29	June 2008
8	May 2008
15	April 2008
44	March 2008
29	February 2008
18	January 2008
7	December 2007
26	November 2007
20	October 2007
27	September 2007
36	August 2007
79	July 2007
23	June 2007
38	May 2007
12	April 2007
46	March 2007
21	February 2007
30	January 2007
84	December 2006
39	November 2006
111	October 2006
54	September 2006
7	August 2006
17	July 2006
41	June 2006
87	May 2006
72	April 2006
17	March 2006
1	January 2006
16	December 2005
1	September 2005
1	August 2005
3	July 2005
1	June 2005
33	May 2005
14	April 2005
59	March 2005
7	February 2005
3	December 2004
22	November 2004
18	October 2004
16	August 2004
13	July 2004
35	February 2004
94	January 2004
59	December 2003
152	November 2003
153	October 2003
10	September 2003
26	August 2003
32	July 2003
76	June 2003
143	May 2003
40	April 2003
17	March 2003
24	February 2003
34	January 2003
1	December 2002
96	November 2002
231	October 2002
20	September 2002
63	August 2002
27	July 2002
36	June 2002
23	May 2002
74	April 2002

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template