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 --------------------------------------------------------------------
