Brian,
Comments embedded.
> I have discussed the flow label with product designers. They are
ignoring
> it because the words in RFC 2460 are fuzzy. Yet the IESG has approved
> two standards track documents (RFC 2205 and the diffserv MIB) with
> specific uses for the flow label in support of the IETF's two QOS
> solutions.
>
> We've inadvertently set up a situation where no vendor is going
> to speak up.
>
I don't claim to speak for DoCoMo (not a vendor
but a service provider anyway), but I do feel there is value in
precisely
defining the flow label. That IETF standardized usage of the flow label
prior
to actually defining its semantics precisely seems kind of
curious in any event. The alternatives seem to be either define
the semantics consistent with the already standardized usage or
not. Since the fact that there are standards on the
usage seems to indicate that at some point the WGs
involved and the IESG felt that there was some value
in having the semantics be other than "reserved",
it would seem to me to be worthwhile to continue
in that vein, unless there is some major argument
for shifting direction. I've been peripherially following
the flow label discussion since Jochem's original
email, but I've not yet seen any major argument
for shifting direction, though there have been
some good points brought up about deficiencies
in the current proposal for defining the flow label.
> >
> > I find it hard to see why so much time is being spent on this other
> > than the fear that idle bits are the devil's playground - i.e. the
> > fear of unassigned bits in the header -
>
> A number of us believe that the above fuzziness and inconsistency
> needs to be resolved, one way or the other.
>
Agreed.
> > I'd rather wait until
> > we are real sure that 1/ there is one or more use(s) for the FL that
> > consensus can be reached on,
>
> As noted, we've already standardised two...
>
> > 2/ have some understanding on what the FL
> > characteristics are for those uses
>
> afaik this is the case: locally unique, immutable, and (for intserv)
> IANA-assigned as per RFC 3140.
>
> >
> > Over the last few years I have seen suggestions ranging from the
original
> > idea of ofloading router forwarding engines (hard to justify in an
era
> > of ASIC-based and network processor-based forwarders, to an ID for
the
> > owner of the content of a packet, to QoS lables (which are hard to
> > diferentiate from difserv code points in teh real world), to billing
> > information. None of these have presented a compelling reason to
think
> > that we understand any FL use well enough to define anything now.
>
> Disagree. The QOS usages are clear and well-defined. The others are
all
> pretty dumb.
>
I have not looked at 2205 or the diffsrv MIB, but if the IANA
standardized
values you mentioned are independent of protocol and port number, then
this would be one way to mitigate the point Scott brought up about
the transited network being able to deduce the character of the
traffic even if the packet was encrypted, which I view as a potential
flaw in using the flow label for classifying encrypted traffic. As one
of your previous
postings indicated, getting agreement on values for the traffic
class field would probably be harder, but perhaps under the
pressure of necessity (if the flow field were defined as reserved)
it might evolve.
I hope we can achieve concensus for the current proposal,
and favor it, but if we cannot, then I believe we should
define the flow label as reserved, and reissue the two
specifications that assign usages of the flow label.
jak
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
