"Perry E. Metzger" wrote:
>
> Brian E Carpenter <[EMAIL PROTECTED]> writes:
> > Let's either clarify them, as in the one para summary that Tony Hain
> > sent a few days ago, or simply write the field off as reserved, in which
> > case IPv6 will have no advantage of IPv4 for QOS purposes.
>
> I
Margaret,
First, I agree - the normative text needed is very short (Tony's
paragraph) and the current draft can be confusing (I can say that
since I was a co-author of the previous version:).
Second- both intserv and diffserv already document their use of
the flow label. For intserv it's in RFC
Perry, the traffic class is mutable at ISP boundaries.
If the flow label is also mutable, it adds no value
and becomes wasted bits.
Brian
"Perry E. Metzger" wrote:
>
> Michael Thomas <[EMAIL PROTECTED]> writes:
> > If you don't believe in signaled QoS, you don't
> > believe in any use of a fl
Scott Bradner wrote:
>
> Perry sez:
> > My personal taste is that we rename the field "Reserved -- must be
> > zero" so that people quit coming up with proposals just because, as
> > one person at Salt Lake City put it, "it is embarrassing that we have a
> > flow label field but nothing uses it s
Michael Thomas wrote:
...
> > 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::
>
Couldn't have said it better :-)
Of course there is no silicon that
"Perry E. Metzger" wrote:
>
> Michael Thomas <[EMAIL PROTECTED]> writes:
> > > Yes, I have substantial doubts on this. First of all, people already
> > > have silicon that does this astonishingly fast.
> >
> >Define "astonishingly";
>
> Ran Atkinson says Extreme's implementation (among oth
Margaret Wasserman wrote:
...
> IPv6 is already deployed in a large number of systems, and if
> things go well, it will be deployed (and used!) in an even
> larger number of systems within the next two years. We need
> to stop making experimental changes, finish up our existing
> specs and get IP
On Sun, 23 Dec 2001, Brian E Carpenter wrote:
> > IMO, this is the wrong approach. Security precautions should be discussed
> > and handled all the way through the specification (as with Shipworm), and
> > in security considerations, a summary and remainder threats discussed.
> > Remainder threat
I'll re-post a point below in this separate thread, so it won't get lost
in the noise.
There was not discussion back a few months ago, but perhaps there are more
opinions now. Should compatible addresses be killed from addrarch (-07:
2.5.5), written in some more generic fashion or what?
--
P
Sometimes, not always. See RFC 2983.
Brian
"Perry E. Metzger" wrote:
>
> "James Kempf" <[EMAIL PROTECTED]> writes:
> > The most compelling application I've seen is
> > for QoS classification when the packet
> > is encrypted. Most of the other applications
> > people have cited can probably b
The diffserv field is mutable. The argument for an immutable
field applies to both intserv and diffserv. It's actually more compelling
than just the encryption case, for diffserv: it allows us to carry
semantics that are not conveyed by the port #s and protocol type.
Brian
Scott Bradner wrote
Scott Bradner wrote:
>
> > The traffic field gives the classification. The flow label
> > could serve as a proxy for the port number and
> > protocol type,
>
> the whole point of class-based QoS is to not have to deal at the
> port and protocol level
That's what I was getting at by saying that
James Kempf wrote:
>
> Scott,
>
> > > The traffic field gives the classification. The flow label
> > > could serve as a proxy for the port number and
> > > protocol type,
> >
> > the whole point of class-based QoS is to not have to deal at the
> > port and protocol level
> >
>
> Good point, tha
Michael Thomas wrote:
...
>Yes, and it almost always means "let's ignore
>admission control" too.
The diffserv architecture is very explicit that each domain
needs admission control (except maybe for the default class).
>...Just to make things
>clear, are you thinking of RFC 299
"Perry E. Metzger" wrote:
...
> >I have witnessed firsthand hardware engineers on high end
> >platforms react somewhere between disbelief and outright
> >hostility at the prospect of chasing down header chains at line
> >rate.
>
> Given the fact that IPv6 headers have to be proces
On Wed, 26 Dec 2001, Francis Dupont wrote:
> I have written a draft about IPv6 ingress filtering (with home address
> option considerations). It is not finished (some editing is needed) but
> I have put it for early access on (sorry for the long line):
>
> ftp://ftp.ipv6.rennes.enst-bretagne.fr/p
Indeed. But we also know that the cost of bandwidth is dropping
faster than Moore's law, so building hardware to keep up with
line speed is actually a little harder every day. That argues
for extreme simplicity.
Brian
Subrata Goswami wrote:
>
> Well, the need to reduce silicon real estate
Robert Elz wrote:
>
> Date:Wed, 26 Dec 2001 13:57:08 -0500 (EST)
> From:Scott Bradner <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | the whole point of class-based QoS is to not have to deal at the
> | port and protocol level
>
> But the informatio
Scott,
Scott Bradner wrote:
>
> I've been watching the discussion over the IPv6 flow label for a while
> and (like Perry) have yet to see anything I woukd call a real reason
> to be doing anything with it - specifically I've seen no vendors say what
> specific use they would put a FL to.
I have
"Perry E. Metzger" wrote:
...
> Repeating my earlier request:
>
> I'm an old fashioned kind of engineer. I'd like to see some folks from
> router vendors give us precise information about the *exact* use
> they'll put the flow label information to,
Here are the precise d
"Perry E. Metzger" wrote:
>
> Keith Moore <[EMAIL PROTECTED]> writes:
> > > Windows XP and such
> > > aren't going to be obeying any of this, so the routers have to look at
> > > the contents of the packets anyway.
> >
> > Shall we forever constrain IPv6 to support only what is now supported by
>
Brian sez:
> Disagree. The QOS usages are clear and well-defined. The others are all
> pretty dumb.
I disagree on both parts of this
Brian thinks the "other" uses for the flow label are dumb, I happen to agree
but the people who made the proposals did not think they were dumb - I
do not claim
Scott Bradner wrote:
>
> Brian sez:
> > Disagree. The QOS usages are clear and well-defined. The others are all
> > pretty dumb.
>
> I disagree on both parts of this
>
> Brian thinks the "other" uses for the flow label are dumb, I happen to agree
> but the people who made the proposals did not
> Nobody said they are. The issue is getting something minimal and
> unambiguous into the IPv6 spec before it's too late.
if you want "something minimal" why should it imply anyting about QoS?
Tony's words talk about "packets requiring special handling" - I see
no reason to think that any rout
Brian E Carpenter <[EMAIL PROTECTED]> writes:
> > and quantitative
> > information about how much better it will be for them to
> > have the flow
> > label than not to have it.
>
> Nobody is going to publish that sort of competitive data. As noted earlier,
> this
Both of the following example actually only tells you
how to set them, not how to use them and both are
optional.
Given the fact that there are only 20 bits in the flow
label, then globally only 4K flows can be defined - is that
enough ?
Subrata
-Original Message-
From: [EMAIL PROTECTED
Are there any IPv6 router implementations that currently
modify the flow label field in transit?
If not, I could live with the minimal change that Scott
has proposed below (in the nature of a "bug fix" to
RFC 2460).
Scott Bradner wrote:
>The 20-bit Flow Label field in the IPv6 header MAY b
"Perry E. Metzger" wrote:
>
> Brian E Carpenter <[EMAIL PROTECTED]> writes:
> > > and quantitative
> > > information about how much better it will be for them to
> > > have the flow
> > > label than not to have it.
> >
> > Nobody is going to publish that sort of
Subrata Goswami wrote:
>
> Both of the following example actually only tells you
> how to set them, not how to use them and both are
> optional.
No, they tell you how to use them. A flow_spec is how intserv
identifies flows; a classifier is how diffserv classifies
packets. Yes they are both opti
Taking Scott's suggestion, here's another try:
I'd like to propose the following as the
complete and total replacement of Section 6 of RFC 2460.
The 20-bit Flow Label field in the IPv6 header MAY be set by a
source to uniquely label sets of packets. Nodes that do not support
the Flow
Brian E Carpenter <[EMAIL PROTECTED]> writes:
> > We can already classify ESP traffic. The SPI for a particular host to
> > host connection is externally visible likely unique for a given
> > flow in most applications. (The VPN case is a bit different but the
> > VPN case is, we hope, not the bul
Actually, I would take out the word "uniquely". I am
not sure that we want to confine possible QoS solutions
to "uniquely" labeling anything.
Margaret
At 10:43 AM 12/27/01 , Brian E Carpenter wrote:
>Taking Scott's suggestion, here's another try:
>
>I'd like to propose the following as the
>c
Brian E Carpenter <[EMAIL PROTECTED]> writes:
> Scott Bradner wrote:
> > > The traffic field gives the classification. The flow label
> > > could serve as a proxy for the port number and
> > > protocol type,
> >
> > the whole point of class-based QoS is to not have to deal at the
> > port and pr
> No, because it's mutable. We need sonmeting that *isn't* mutable
> and *does* have semantics for classification.
see previous note - I do not see a reason to think that an immutable
field will actually be useful for QoS in teh real world
Scott
--
There is this myth going around that you can't distinguish ESP traffic
by any external means, but that of course can't be true or you
couldn't figure out which keys to use to decrypt the traffic. The SPI
distinguishes the use of a particular keyset, and our usual dogma in
the IPSEC world is that
As the flow bits have not been defined well, not used much,
not deployed and QoS is all ready handled by both Diffserv and
Intsev why not assign a different meaning to these bits
which can have implications beyond silicon.
One suggestion - rather then assigning flow semantics to
the 20 bits,
Hello,
RFC 2373 states that:
"The unspecified address must not be used as the destination address
of IPv6 packets or in IPv6 Routing Headers."
However it seems that certain stacks are using this address in a different
way.
When '::' is the destination address:
- some use the first available in
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
- Original Message -
From: "Brian E Carpenter" <[EMAIL PROTECTED]>
To: "Scott Bradner" <[EMAIL PROTECTED]>
> >
> > Scott
> >
> > (ps - for a data point in the mutability camp, Cisco IP phones are designed
> > with two Ethernet jacks, one to connect to the wall jack - the desktop
> > mac
works for me
---
>From [EMAIL PROTECTED] Thu Dec 27 10:45:19 2001
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to
[EMAIL PROTECTED] using -f
Date: Thu, 27 Dec 2001 16:43:48 +0100
From: Brian E Carpenter <[EMAIL PROTECTED]>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Wi
Margaret,
Given there seems to be so much contention around Tony's proposal,
I agree that Scott's minimal definition along with removal
of Appendix A is a viable alternative.
jak
- Original Message -
From: "Margaret Wasserman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sen
agree
---
>From [EMAIL PROTECTED] Thu Dec 27 11:11:09 2001
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to
[EMAIL PROTECTED] using -f
X-Sender: [EMAIL PROTECTED]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Thu, 27 Dec 2001 11:08:43 -0500
To: Brian E Carpent
Agree.
jak
- Original Message -
From: "Brian E Carpenter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 27, 2001 7:43 AM
Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]
> Taking Scott's suggestion, here's another try:
>
> I'd like to pro
> That IETF standardized usage of the flow label prior to actually
> defining its semantics precisely seems kind of curious in any event.
it's commonly called 'second system syndrome' which often produces a
lot of ill defined and not demonstrably necessary 'features'
randy
Lilian,
>
> RFC 2373 states that:
> "The unspecified address must not be used as the destination address
> of IPv6 packets or in IPv6 Routing Headers."
>
> However it seems that certain stacks are using this address in a different
> way.
>
> When '::' is the destination address:
> - some
45 matches
Mail list logo
