Perry E. Metzger writes:
> > Indeed,
> > it's seems to be all of the hangwringing over
> > the obvious definition for these bits that
> > has managed to shoot IPv6 in the foot, re
> > fast flow clasification.
>
> There isn't a flow label in IPv4 and it seems
> to be well deployed.
Uh, make up your mind. Flow classification for
QoS is not well deployed. If your entire
point is that signaled QoS is a load of hooey,
state that so we can all save time.
> > But I'm not sure what you're asking for.
> > Do you really have any doubt that forming
> > the flow key from fixed postions in the
> > IP6 header is going to not kick butt on
> > chasing down header chains with a half
> > dozen different rules dependent on protocol
> > value to hopefully find a 5 tuple?
>
> Yes, I have substantial doubts on this. First of all, people already
> have silicon that does this astonishingly fast.
Define "astonishingly"; I don't know of anything
that does IP6 vaguely approaching "astonishingly"
except in slideware. IP6 adds the concept of
header chaining which, though possible in IP4,
is not common, and the cross product with QoS
is even less supported (if at all). This is a
substantial source of heartburn for ASIC
designers, and is problematic for CAM based
designs -- which are astonishingly fast --
where every bit is precious.
> Second of all, they
> don't yet have silicon that will do anything with the "flow label" and
> it will be years before they could have deployed hardware like
> that.
::snort::
What is absolutely for certain is that each
new protocol and/or tunnel combination will be
years away each time somebody decides that that
combination is vital to existence as we know it.
> Third, they'd have to chase down the header chains anyway,
> because stuff like XP isn't going away. (In other words, we've
> deployed, it is too late.)
As if XP is the only thing that will require
elevated QoS. In fact, I expect that if signaled
QoS is deployed at all, it will be for voip, etc,
widgets. Somebody sitting at a PC already has
low expectations.
> Fourth, I have yet to see any real
> explanation of what this is going to do for people in
> practice. Repeating my earlier request:
Then you're hearing what you want to hear.
> When I hear folks at Juniper mumbling that they already have their
> hardware v6 support out in the field in their existing router line,
> and I hear folks from Extreme mumbling that they have their packet
> classifiers built (and they're hardly the only ones),
Astonishingly fast, no doubt. Look, you can make
just about anything go "astonishingly fast" with
enough NRE + RE. The question is whether we should
keep the IETF QoS full employment act fully funded
by ignoring the layer violation. It seems that you're
saying that it's a done deal therefore ignore it.
What you're not fessing up to is that the reality
is that NAT's have *really* won and that IP6's
future is still very much uncertain. So, IMO, we
either continue with this possible fantasy that
we can engineer a clean new version of IP, or we
chuck it all and give in to the least common
denominator of hacks upon hacks upon hacks. There
are lots of other things in this class too; my
favorite bit of suspended disbelief is renumbering.
> and I look at
> the fact that there are a whole lot of v6 enabled systems already out
> there in the field that aren't going away, I feel like I have to start
> asking hard questions.
"Whole lot"? Please. And adding a flow label
to the kernel is *hardly* rocket science.
> If we're going to start mandating people do something new at this late
> stage of the game, we'd better have a good engineering rationale for
> it, along with good measurements to back up that rationale.
Nobody's "mandating" anything any more than
"mandating" DSCP marking. If you don't want
elevated QoS, you are completely at liberty
to ignore all of this nonsense.
Mike
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
