Hi Mark, > Are you generally trying to avoid it because it would appear to be an > implied IETF definition of a flow, rather than just the IPv6 > definition? Or is it to avoid having to start defining the a possibly > large set of flow definitions?
Actually, because I have enough email to deal with right now anyway :-) Your proposed definition looks reasonable, but the IPFIX people have a rather different definition: "A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties.... A flow is considered to be expired if no packet of this flow has been observed for a given timeout interval" [RFC3917] The crucial difference is the tiemout. In the observational world of IPFIX, a flow is deemed to end when there is a certain period of silence. So a stop-start flow meeting your definition might be broken up into multiple flows by IPFIX. That's where things get vague. Regards Brian On 2010-04-15 21:46, Mark Smith wrote: > Hi Brian, > > On Thu, 15 Apr 2010 10:13:04 +1200 > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> Hi Mark, >> >> On 2010-04-15 09:59, Mark Smith wrote: >>> Hi Brian and Sheng, >>> >>> On Wed, 14 Apr 2010 16:48:25 +1200 >>> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: >>> >>>> Hi, >>>> > > <snip> > >>> I suppose partly that comes down to what a 'flow' is. In some contexts, >>> it is definitely a transport layer connection. In others, e.g. an MPLS >>> network, I think it could be seen to be all packets that match a >>> Forwarding Equivalence Class. If it was possible to use a FEC to set >>> the flow label, once the packet has traversed the MPLS network, and the >>> MPLS labels are stripped off, the flow label that was set due to the >>> FEC would be preserved, which might be useful. Is there an opportunity >>> to make the definition of a flow a bit more general, and then for allow >>> for the choice of different packet classification methods to be used to >>> define a flow, based on context e.g. transport layer connection in some >>> contexts, MPLS FEC, QoS/Diff Serv classifiers etc. in others? >> And that's an even wider question. I'm inclined to duck it, or at >> least to assert that it's a much wider question than 6man can tackle. >> > > Are you generally trying to avoid it because it would appear to be an > implied IETF definition of a flow, rather than just the IPv6 > definition? Or is it to avoid having to start defining the a possibly > large set of flow definitions? > > I think that as the field is an IPv6 one, IPv6 can have a position on > what it considers a flow to be. > > I had a bit of a think about a more general definition of what a flow > is and came up with this: > > "a set of packets that have a common attribute, or common relationship > with another entity" > > with common attribute being things like field (single or multiple > ) values, optional fields (e.g. a set of extension headers), same > result of a hash of fields etc. > > A common relationship might be the same MPLS FEC, BGP NEXT_HOP, router > incoming interface, destination AS etc. > > Looking at the definitions of flows in the IPv6 RFC, and in RFC3697, I > think the above general definition would encompass those as well. > > If that was an acceptable general definition, then this draft could > also then define one specific instance of a flow definition, namely the > fields used to identify a transport layer connection, and state that > other instances of applicable flow definitions may be defined in other > RFCs, including non-IPv6 ones. > > > Regards, > Mark. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
