Good day, I am a Researcher in NTT MSC , Malaysia .
I am working on the implementation of QOS in IPv6 Network. Is RFC 1809 the
latest information regarding Flow Label in IPv6? What is the
latest development on the usage of the flow label in IPv6.
Thanks
Sean Lim
Researher
NTT
I couldn't attend last WG Meeting and from the Minutes
I didn't see an outcome of the flow label discussion.
Principally, I see similar options as Steve:
- complete standardization in either of the three
directions (mutable label, e-t-e-label or the combination
of both) that enab
Am I correct in saying that, at this point, the flow label is at most
a way for intermediate routers to avoid layer violations, since a flow
is immutable and is properly given as a tuple?
One must ask what kind of layer violations this is intended to
stop, and what the purpose of those layer
Perry E. Metzger writes:
>
> Am I correct in saying that, at this point, the flow label is at most
> a way for intermediate routers to avoid layer violations, since a flow
> is immutable and is properly given as a tuple?
Yes.
> One must ask what kind of layer vio
Just a quick question from an interested lurker: Are these hums of
acquiescence in response, specifically, to the idea that an originating
node may set the flow label to any value, and that nodes forwarding
packets will leave that value alone? -- George Mitchell
[Was "Re: Revised IPng Working Group Charter"]
Thinking about the discussion on what to do with the IPv6 flow label field,
I have couple of thoughts.
The discussion about the best working group for this work is somewhat
academic until there is a concrete proposal (i.e, an internet
We have an
idea of what to use it for.
I'm currently writing a draft about
"traffic engineering in ipv6" like I said to you Bob.
A draft proposal is finished quite soon and the
intention is to see if there is some interest to use the flowlabel for traffic
engineering and If you would like t
> Good day, I am a Researcher in NTT MSC , Malaysia . I am working on the =
> implementation of QOS in IPv6 Network. Is RFC 1809 the latest =
> information regarding Flow Label in IPv6? What is the latest =
> development on the usage of the flow label in IPv6. Thanks
Check the
> Having said that, does anyone maintain an archive of this mailing list
> that is threaded per-message? It would be useful to have such an
> archive to refer to specific messages, as in this case. Note that I am
> not asking that the current archive at
> ftp://playground.sun.com/pub/ipng/mail-arc
As Bob mentioned, we have set aside a chunk of time in the Minneapolis
agenda to discuss the various proposals for what to do with the IPv6
Flow Label field. This was a hot topic here on the list just before
the San Diego IETF, and then we ended up with an agenda that was too
full to allow in
he packets anyway. For many of the protocols we're
dealing with here (such as tunnels inside tunnels) it isn't clear
there is a clean way for the mechanisms to actually extract an
appropriate flow label under the new definition, and, most
importantly, as I noted earlier, you can't
If you don't believe in signaled QoS, you don't
believe in any use of a flow label qua flow label.
Fine; many people don't. For those people, you
have the DSCP and the luck of the draw. It's
infinitely mutable, etc, etc. Be happy because
there's nothing to be done he
Michael Thomas <[EMAIL PROTECTED]> writes:
> If you don't believe in signaled QoS, you don't
> believe in any use of a flow label qua flow label.
I thought we had a "traffic class" to permit "signaled QoS" for some
value of "signaled QoS&quo
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 find it hard to see why so mu
Perry E. Metzger writes:
>
> Michael Thomas <[EMAIL PROTECTED]> writes:
> > If you don't believe in signaled QoS, you don't
> > believe in any use of a flow label qua flow label.
>
> I thought we had a "traffic class" to permit "s
Michael Thomas <[EMAIL PROTECTED]> writes:
> Perry E. Metzger writes:
> >
> > Michael Thomas <[EMAIL PROTECTED]> writes:
> > > If you don't believe in signaled QoS, you don't
> > > believe in any use of a flow label qua flow label.
i guess the flow bits should officially be reserved.
subrata
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott Bradner
Sent: Monday, December 24, 2001 4:49 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Label
I've been watching the discu
y put it, "it is embarrassing that we have a
flow label field but nothing uses it so we should come up with a use"
(one of the most frightening things I've ever heard at an IETF meeting.)
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development,
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 so w
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
practice.
I want to see that clearly and distinctly explained well before we go
through the exercise.
I'm looking for statements from several router vendors that look much
like this:
"Big Router Company believes that it is important that we have the
flow label because by implementing it
>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 so we should come
"Perry E. Metzger" wrote:
...
> Yes, you need to go on. For the most part, I'm not sure this is going
> work out. As I note, we've already deployed. Windows XP and such
> aren't going to be obeying any of this,
We're designing for 2002 operating systems? I thought we were designing
for the next
Perry E. Metzger writes:
> I'm looking for statements from several router vendors that look much
> like this:
I don't speak for Cisco. I speak for myself.
Sorry.
Mike
IETF IPng Working Group Mailing L
Brian E Carpenter <[EMAIL PROTECTED]> writes:
> "Perry E. Metzger" wrote:
> ...
> > Yes, you need to go on. For the most part, I'm not sure this is going
> > work out. As I note, we've already deployed. Windows XP and such
> > aren't going to be obeying any of this,
>
> We're designing for 2002
yourself, can you describe your simulations of
hardware performance with and without the flow label?
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
r" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 24, 2001 4:49 PM
Subject: Re: Flow Label
>
> 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
"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 be handled
> by other means, as you point out.
Can't we do classification by expressin
> The most compelling application I've seen is
> for QoS classification when the packet
> is encrypted.
the difserv field is not encrypted so I am not compelled by this example
Scott
IETF IPng Working Group Mailing List
IPng Ho
gt; by other means, as you point out.
>
> Can't we do classification by expressing the traffic type in the
> "traffic" field in the encapsulating packet, however?
>
The traffic field gives the classification. The flow label
could serve as a proxy for the port number and
protocol t
Scott,
> the difserv field is not encrypted so I am not compelled by this
example
>
If by this you mean that the flow label is not covered
by AH then I agree that this is a weakness in the flow label proposal.
The end node cannot check that the flow label wasn't changed
in transit
> 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
Scott
> If by this you mean that the flow label is not covered
> by AH
nope - I mean that it is not encrypted thus it can be seen by the
routers
Scott
IETF IPng Working Group Mailing List
IPng Home Page:
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, thanx for the
> Perhaps there is some other way to solve the problem, like
> uniform agreement among service providers on
> diffserv code points
I expect that will happen over time
> some kind of authentication on the
> traffic classification field, so that the service
> provider could authenticate that it
- Original Message -
From: "James Kempf" <[EMAIL PROTECTED]>
>
> But this is perhaps the topic for another
> thread and maybe another working group...
>
Probably a topic for a different Galaxy and StarGate :-)
Jim Fleming
http://www.IPv8.info
IPv16One Better !!
-
> > If by this you mean that the flow label is not covered
> > by AH
>
> nope - I mean that it is not encrypted thus it can be seen by the
> routers
>
>
Ah, I think I see what you are getting at.
The transited network can see the source/destination address,
and t
> The transited network can see the source/destination address,
> and the flow label. Thus, if the flow label acts as a proxy
> for the protocol type and port number, the transited
> network can still obtain a certain amount of information
> on the packet contents.
do not equa
> 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
Microsoft?
Keith
I
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
> Microsoft?
No, but the further alo
> 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 so we should co
> No, but the further along the deployment curve you get, the more
> seriously you have to examine changes
the more seriously you have to examine *incompatible* changes.
> we kind of have to accept that a
> large chunk of the end nodes are going to run XP for the foreseeable
> fut
Scott Bradner writes:
> > 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
Yes,
>Yes, and it almost always means "let's ignore
>admission control" too.
yes, and that will be a real problem wherever the level of priority
traffic approaches the size of the links (which could easily happen
if video traffic gets prioritized)
Scott
---
I speak for myself.
> >
> >Sorry.
>
> Well, speaking for yourself, can you describe your simulations of
> hardware performance with and without the flow label?
I'm not especially interested in this game
because some hardware geek somewhere is
bound
>Sorry.
> >
> > Well, speaking for yourself, can you describe your simulations of
> > hardware performance with and without the flow label?
>
>I'm not especially interested in this game
>because some hardware geek somewhere is
>bound to
Well, the need to reduce silicon real estate is very noble
indeed. The price and density of silicon goes down by a factor
of 2 every 2 years so, and the flow-label legacy would probably
last beyond that. So the pertinent question to answer would be
how do we assign the bits in a way that they
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 information about the QoS desired has to come f
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
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
&
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 s
x27;t think you'll find it works very well for ESP traffic. That is, please
don't forget, why the flow label is a potential solution.
Brian
IETF IPng Working Group Mailing List
IPng Home Page: ht
; specs and get IPv6 ready for prime time.
And our existing specs contain a big hole: the sloppy text about
the flow label. That's why this discussion started
(see Jochen Metzler's message of November 15, 2000).
Brian
---
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 w
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
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
real estate is very noble
> indeed. The price and density of silicon goes down by a factor
> of 2 every 2 years so, and the flow-label legacy would probably
> last beyond that. So the pertinent question to answer would be
> how do we assign the bits in a way that they would still be
>
e mutable - when it reaches any random
> router it could contain any value at all - not in any way related to
> the value it had when the packet left the originator.
>
> So, in your model, from where does an arbitrary router discover the QoS
> request desired for this particular packe
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 t
"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 labe
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
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
> bu
- I see
no reason to think that any router will ever want to look at a FL
for any QoS related reason - there may be other reasons that routers
might want to look at FLs or there might be e2e reasons but I think it is
far too early to guess at uses
if you want "something minimal" this wo
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 o
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
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 IP
"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 t
hey are both optional - like many enhancements.
>
> Given the fact that there are only 20 bits in the flow
> label, then globally only 4K flows can be defined - is that
> enough ?
It's the 2uple {source address, flow label} or possibly the
3uple {source addr, destination addr, flow
VPN case is, we hope, not the bulk of traffic in the future.)
>
> Sorry, the SPI is no good for diffserv classification
> because it has no semantics.
Neither does the flow label. Both are just a number that can be used
to distinguish a bunch of traffic flowing between two hosts from
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-base
> 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
--
ECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Flow Label
> 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
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 su
>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 27, 2001 7:28 AM
Subject: Re: Flow Label
>
> 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
> 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 necess
Date:Thu, 27 Dec 2001 11:05:13 -0800
From:Randy Bush <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| it's commonly called 'second system syndrome' which often produces a
| lot of ill defined and not demonstrably necessary 'features'
That's what IPv6 has del
Perry E. Metzger writes:
> > Sorry, the SPI is no good for diffserv classification
> > because it has no semantics.
>
> Neither does the flow label. Both are just a number that can be used
> to distinguish a bunch of traffic flowing between two hosts from other
>
Michael Thomas <[EMAIL PROTECTED]> writes:
> Perry E. Metzger writes:
> > > Sorry, the SPI is no good for diffserv classification
> > > because it has no semantics.
> >
> > Neither does the flow label. Both are just a number that can be used
> &
e
good; linked lists are bad. Doable but bad is
still bad.
Also: you seem to be under the illusion that
QoS classifiers are set in stone. They are not.
I just took a quick look at SCTP: its ports
are not in the same place as TCP/UDP; hence,
hardware ch
Michael Thomas <[EMAIL PROTECTED]> writes:
> Perry E. Metzger writes:
> > Michael Thomas <[EMAIL PROTECTED]> writes:
> > >Bzzt. You're overloading semantics. SPI's enumerate
> > >the set of packets for which a given security policy
> > >applies. That may have exactly zero to do wi
expect that will change with the advent of
lots of IP phones going across VPN's, but
when that happens you want hard coupling of
QoS and Security even less: VPN concentrators
have finite memory/hardware for SA's. Since
there's no security benefit, you&
Scott Bradner writes:
> >Yes, and it almost always means "let's ignore
> >admission control" too.
>
> yes, and that will be a real problem wherever the level of priority
> traffic approaches the size of the links (which could easily happen
> if video traffic gets prioritized)
A
lt;[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sat, 29 Dec 2001 13:55:30 -0800 (PST)
To: Scott Bradner <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: F
> Scott Bradner writes:
>>>Yes, and it almost always means "let's ignore
>>>admission control" too.
>> yes, and that will be a real problem wherever the level of priority
>> traffic approaches the size of the links (which could easily happen
>> if video traffic gets prioritized)
> And??
>
[this also responds to Scott's comments, I think]
"Perry E. Metzger" wrote:
>
> Michael Thomas <[EMAIL PROTECTED]> writes:
> > Perry E. Metzger writes:
> > > > Sorry, the SPI is no good for diffserv classification
> > > > because it ha
ing the DSCP value and router configurations)
> may differ from ISP to ISP, but the flow label bits convey end to end
> semantics. This is more powerful than port numbers whose semantics are poor at
> best for QOS purposes, and it works when the port numbers are invisible.
this still begs
al traffic flow.
> > The implementation details (including the DSCP value and router configurations)
> > may differ from ISP to ISP, but the flow label bits convey end to end
> > semantics. This is more powerful than port numbers whose semantics are poor at
> > best for QOS purposes,
> why do folk think that ISPs half way around the world would find it useful
> to know what the sending computer wanted for QoS?
because the sending computer (application) knows the nature of the traffic?
Keith
IETF IPng Workin
>> why do folk think that ISPs half way around the world would find it
>> useful to know what the sending computer wanted for QoS?
> because the sending computer (application) knows the nature of the
> traffic?
no need to signal. we already know that they think their traffic is more
important th
umption
that we have any idea what to do with the static info
> If A is a customer of ISP X in some distant country, there might be (and
> I am only saying might be) an SLA in place that says "whenever you get
> a packet from or to A, with 1234 in its flow label, give it such a level
> > why do folk think that ISPs half way around the world would find it useful
> > to know what the sending computer wanted for QoS?
> because the sending computer (application) knows the nature of the traffic?
without a way for the remote ISP to get paid for treating the traffic in
some way oth
Scott Bradner writes:
> > > why do folk think that ISPs half way around the world would find it useful
> > > to know what the sending computer wanted for QoS?
>
> > because the sending computer (application) knows the nature of the traffic?
>
> without a way for the remote ISP to get paid
- Original Message -
From: "Scott Bradner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 8:20
raffic flow.
> > The implementation details (including the DSCP value and router configurations)
> > may differ from ISP to ISP, but the flow label bits convey end to end
> > semantics. This is more powerful than port numbers whose semantics are poor at
> > best for QOS pur
Scott Bradner writes:
>Are you claiming that RFC 3182 (nee 2752) is
>inadequate for interdomain?
>
> for telling someone who you are its fine but that does not even
> start to address teh operational issues of how an ISP would make use
> of the information
There is already an
Are you claiming that RFC 3182 (nee 2752) is
inadequate for interdomain?
for telling someone who you are its fine but that does not even
start to address teh operational issues of how an ISP would make use
of the information
Scott
--
all you're saying
here is that you don't believe in Intserv/RSVP.
I did not say that at all
I do not believe that there is currently any way to deal with the
*business* and *operational* issues of asking some remote ISP
to provide QoS service for you in any sort of scalable way
please d
1 - 100 of 837 matches
Mail list logo
