Steve,
Thank you for the elaborate clarifications.
The dialog is certainly helping in dissipating confusion. The process is
asymptotic though, on some of the points we are parallel rather than
intersecting. For instance, my reference to diffserv was
relative to aggregation. Your reference to 'intserv', I think is not.
Intserv's "teething" problem was scalability, and "aggregation" was the
solution proposed. But, to be short, all I am saying, is that in terms
of the "mechanics" of aggregation, the solutions should not be
inconsistent, or disjoint. In other words, tunneling should be optional,
not mandatory. I feel relieved by your reminding that AH ignores the
flow label, to allow the rewriting en-route, which is an important
premise.
As I followed closely the design of the IPv6 flow label, I am in
complete agreement with you, that the
reasoning, motivations, and choices made, were optimal several years
ago, when this design took place.
However -- and please excuse me if I repeat myself - circumstances
changed since, if not in the complexity of the problem(s), in the
availability of solutions, that is, architectures and protocols,
which can be entirely, or partially, adopted, or IPv6 can be made easier
to work with.
You are absolutely right that the MPLS work had an emphasis on ATM,
nevertheless, support for other relevant links, such as Frame Relay,
PPP, and LANs was provided since day one, and generic encapsulation (PPP
and LANs) is a basic building block for MPLS forwarding. As I recall
vividly the discussions in the SIPP WG, and later in the IPng WG on the
role and placing of the flow label within the IPv6 header, to facilitate
fast forwarding, and/or filtering, I would argue that the set of
problems that MPLS and IPv6 flow label attempt to resolve, are not, or
do not have to be disjoint. In fact, since MPLS provides a simple
mechanism for destination based, QoS, multicast, etc... forwarding, and
traffic engineering, one could argue that the set of problems that it
resolves is a superset.
You are right that the emphasis "dans la raison d'etre" of MPLS has
changed, because the research improved drastically the availability of
solutions for IPv4 longest prefix match fast (or wire speed) forwarding.
But if you believe, or imply, that just because of that, the IPv6-ers
should no longer worry, and should no-longer search for mechanisms that
would enrich IPv6 forwarding with simpler and cheaper solutions, or
simplify or improve the existent mechanisms, then I should raise a flag
of warning !!!
If you look to "L-C tries", or "binary search on levels", or
"controlled prefix expansion", to mention a few, their complexity is so
much higher than the simple, fixed size label based forwarding, that in
fairness. one can only put their AVAILABILITY ON A PAR, BUT NOT THEIR
COST. Adding the need for additional engines for QoS, and multicasting,
is not making these solutions any cheaper.
1Gps, and soon 10Gps will be the norm. At 10Gps, within 51 nano-seconds
per packet time constraint,
the length of the IPv6 address -- which is a given, and not argued here
-- makes, unfortunately, the applicability of some of the IPv4 wire
speed longest prefix match forwarding solutions, both in terms of
lookup, and updating forwarding tables, quite problematic, thus reducing
the number of choices, and making the task of forwarding engines
designers not easier.
Warning flag down,
Alex
Steve Deering wrote:
>
> 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
S/MIME Cryptographic Signature
