Carter Bullard | 3 Sep 21:36 2002

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 16:21 2002

[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 10:49 2002

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 17:16 2002
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 17:45 2002

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 04:20 2002
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 16:16 2002

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 17:39 2002
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 18:14 2002

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 20:54 2002
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)


Gmane