Since the IPv6 flow label work started, two major efforts in IETF made
significant progress on related topics: Diffserv and MPLS.
As an extension of the Diffserv aggregation model, the flow label SHOULD
be re-writable. If you think about extending your argument to Diffserv,
then Diffserv aggregated flows should be always tunneled.
Similarly to Diffserv, allowing re-write does not always mean that the
flow label is going to be re-written, so the current specification, or
usage would be in fact a subset.
The argument boils down to **forcing "read-only" onto flow labels does
not pay**. On the contrary.
I think that the MPLS work is a significant progress on the concept, and
mechanisms of labeling flows, and as you know [(-:], I think IPv6
should borrow from it, rather than going against, or going on a path
that was started before the MPLS effort, but so far didn't go far enough
to be sufficiently significant.
Some of the weight, or basis, or the hidden reason, of your tunneling
argument comes, I think, from the fact that as of now, a flow label
defines uniquely a flow, only when associated with the source address.
Because of the need of the 20 + 128 bits for flow identification, just
re-writing the flow label would not do it: you need a new source address
as well for the flow identification.
But this (148 bits for uniquely identifying a flow), as well as
re-writing, local, or global significance, unicity, etc... are all
things that should be on the table for discussion.
Aggregation implies that some elements of the flows being subject to
aggregation are similar: QoS requirements, destination, etc... Your are
right, tunneling is indeed the most general, and most comprehensive
mechanism. But tunneling means changing all parameters. Is the cost
always justified, or
even when changing one parameter would be sufficient?
In my opinion, the cost is not justified, in particular if a "flow
label' of 20 bits, can define alone, uniquely, a traffic flow to the
forwarding process. Rewriting only the flow label for aggregation,
while leaving the rest of the packet's header's fields intact allows,
like in DIffserv, applying criteria of classification to those fields,
and the rest of the packet, similar to those applied to the original
packet, that is, do not require changing, or additional classifications
rules. Please note, and do not ignore the fact that, storing, deleting,
updating and disseminating classification rules is in fact at least if
not more expensive than similar operations done with forwarding table
information.
Alex
S/MIME Cryptographic Signature
