At 5:52 PM -0500 11/17/00, Alex Conta wrote:
>Since the IPv6 flow label work started, two major efforts in IETF made
>significant progress on related topics: Diffserv and MPLS.
Alex,
Diffserv is in no way related to the Flow Label. IPv6 has the Traffic
Class field for diffserv-style QoS. The Flow Label was intended to
serve intserv-style QoS.
>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.
Intserv-style QoS, and the aggregation of intserv flows, is not an
extension of the diffserv aggregation (do you mean reclassification?)
model. If you want to do diffserv-style aggregation/reclassification,
go ahead and use the IPv6 Traffic Class field, which is intended for
that purpose.
>The argument boils down to **forcing "read-only" onto flow labels does
>not pay**.
We arranged for the Flow Label to be excluded from the AH authentication
function, precisely so it could safely be modified en-route, i.e., far
from "forcing" it to be read only, we have gone out of our way to make it mutable. We
patiently await a spec that says exactly how to use
re-writable flow labels *including* how to allocate flow labels for
multicast flows crossing multi-access links. It is the messiness and
fragility of solutions to that latter problem that led to the initial
end-to-end, instead of hop-by-hop, design of the Flow Label.
> 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.
MPLS was not designed to address the same problems, across the same range
of link types, as the Flow Label. (Granted, MPLS's purposes have kept
changing over time, but it's still true today.) If you all you want is
MPLS for IPv6, go ahead and use MPLS under IPv6. It works just fine
(or rather, as well as it does for IPv4).
>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.
No, my arguments for tunneling do not derive from the constraints of
the Flow Label design, and would be the same whether the Flow Label
were end-to-end or hop-by-hop.
The end-to-end Flow Label design derived from the observed problems
with doing label allocation for multi-access links. (Most of the
complexity of the ST protocol, which has hop-by-hop, layer-3 flow
labels/tags/VCIs, arose from trying to deal with that scenario.)
The end-to-end design avoids those problems, at the cost of a somewhat
more expensive look-up. Fortunately, router designers have gotten
better with sophisticated look-up algorithms, so we no longer have
to stick with small-integer indexing to get highest-speed forwarding
(MPLS's original raison d'etre).
>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.
They are on the table for discussion, and have been for years. That's
why it's in an appendix of the spec.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
