Jarno,
I completely agree!
Intserv would work fine with ANY other mechanism for selecting flow
label values. It does not have to be PRN.
Intserv seems to work fine with FILTER_SPEC C-type 1, and 2, i.e. based
on "port numbers", which are not PRN.
Furthermore, work on classification mechanisms
Pekka Savola wrote:
>
> On Fri, 17 Aug 2001, Alex Conta wrote:
> > The Diffserv QoS engines in the access routers do a policing
> > (classification&metering&dropping) that trims the high level QoS traffic
> > -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So,
> > a user, a
Brian wrote:
> The distinction made in the proposal by the MSB is between a
> pseudo-random
> value as defined in RFC 2460 Appendix A (for intserv) and a
> non-random value
> (for diffserv). But they are both e2e values, unlike the
> DSCP. This should
> be documented.
>
But who need any of
itojun,
Jun-ichiro itojun Hagino wrote:
>
> >>then why you pushed those non-IANA values in the presentation?
> >>this is the source of confusion.
> >You refer to the last 2 slides of the 14 slide presentation, each WITH
> >BIG TITLES:
> >OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, pr
Pekka Savola wrote:
>
> On Fri, 17 Aug 2001, Alex Conta wrote:
> > The Diffserv QoS engines in the access routers do a policing
> > (classification&metering&dropping) that trims the high level QoS traffic
> > -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So,
> > a user, at
>>then why you pushed those non-IANA values in the presentation?
>>this is the source of confusion.
>You refer to the last 2 slides of the 14 slide presentation, each WITH
>BIG TITLES:
>OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of the
>draft.
>Your message titl
On Fri, 17 Aug 2001, Alex Conta wrote:
> The Diffserv QoS engines in the access routers do a policing
> (classification&metering&dropping) that trims the high level QoS traffic
> -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So,
> a user, at the most, uses up all that was co
Jun-ichiro itojun Hagino wrote:
>
>then why you pushed those non-IANA values in the presentation?
>this is the source of confusion.
You refer to the last 2 slides of the 14 slide presentation, each WITH
BIG TITLES:
OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of
>As Brian already rightfully said, perhaps not with the same words, the
>draft promotes the flow label format in the main text, which is the IANA
>based value format. As Brian, I believe more in the IANA format. The
>flow label formats in the Appendix are presented as possible choices,
>each with
Indeed, there is a need for at least one packet of a high QoS level
before one could steal the value of the flow label and use it for a
non-authorized flow
(it is mostly, if not always, known which ports are high QoS level and
which not).
However, once the pseudo-random number is cached, or sto
itojun,
As Brian already rightfully said, perhaps not with the same words, the
draft promotes the flow label format in the main text, which is the IANA
based value format. As Brian, I believe more in the IANA format. The
flow label formats in the Appendix are presented as possible choices,
each w
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > Michael Thomas wrote:
> > >
> > > Brian E Carpenter writes:
> > > > Excellent summary. We originally chose a 6 bit diffserv field partly because
> > > > it was available in both IPv4 and IPv6, and partly because it allows for
> > >
Brian E Carpenter writes:
> Michael Thomas wrote:
> >
> > Brian E Carpenter writes:
> > > Excellent summary. We originally chose a 6 bit diffserv field partly because
> > > it was available in both IPv4 and IPv6, and partly because it allows for
> > > very efficient classification in *co
Jun-ichiro itojun Hagino wrote:
>
> >> I heard the presentation differently. in IETF51 presentation Alex
> >> Conta made the following proposals, at least:
> >> - putting PHB value
> >> not trustworthy.
> >The PHB is as trustworthy as anything else, includ
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > Excellent summary. We originally chose a 6 bit diffserv field partly because
> > it was available in both IPv4 and IPv6, and partly because it allows for
> > very efficient classification in *core* routers, with the more demanding
> > mu
On Wed, 15 Aug 2001, Alex Conta wrote:
> >Jun-ichiro itojun Hagino wrote:
> >
> > >The traffic class field is not enough. If you have to re-classify traffic at
> > >an administrative boundary, then by definition at that point the traffic class
> > >field is inadequate; you need more information. T
>> I heard the presentation differently. in IETF51 presentation Alex
>> Conta made the following proposals, at least:
>> - putting PHB value
>> not trustworthy.
>The PHB is as trustworthy as anything else, including the pseudo-random
>value. If a user can s
Brian E Carpenter writes:
> Excellent summary. We originally chose a 6 bit diffserv field partly because
> it was available in both IPv4 and IPv6, and partly because it allows for
> very efficient classification in *core* routers, with the more demanding
> multi-field classification being left
See comment at the end.
Steve Blake wrote:
>
> Brian Carpenter wrote:
>
> > > Therefore it is pointless adding any semantics to the field, because
> > > even if there, they can't (won't) be used.
> >
> > But there's a recursion here. If you choose to believe port and protocol
> > numbers, then
Brian Carpenter wrote:
> > Therefore it is pointless adding any semantics to the field, because
> > even if there, they can't (won't) be used.
>
> But there's a recursion here. If you choose to believe port and protocol
> numbers, then all cheaters have to do is encapsulate their low priority
>
Steve,
Steve Blake wrote:
>
> Brian Carpenter wrote:
>
> > The traffic class field is not enough. If you have to re-classify traffic at
> > an administrative boundary, then by definition at that point the traffic class
> > field is inadequate; you need more information. The advantage that IPv6
Itojun,
You seem to ignore that both RFC 1883, and RFC 2460 themselves state
that the flow label definition has limitations. Since 1994-95, and 97-98
when those documents were written/reviewed, a lot more progress has been
made relative to QOS and labeling traffic, in terms of architecture,
speci
Robert Elz wrote:
>
> Date:Wed, 15 Aug 2001 08:43:04 -0500
> From:Brian E Carpenter <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> This is way outside my area, but ...
>
> | Well yes, but when the packet has an ESP header you are in trouble. The idea
>
Steve Blake wrote:
>
> Brian Carpenter wrote:
>
> > The traffic class field is not enough. If you have to re-classify traffic at
> > an administrative boundary, then by definition at that point the traffic class
> > field is inadequate; you need more information. The advantage that IPv6 has
> >
Date:Wed, 15 Aug 2001 08:43:04 -0500
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
This is way outside my area, but ...
| Well yes, but when the packet has an ESP header you are in trouble. The idea
| of adding some semantics in the f
I didn't hear the presentation since I was sick. But yes, the draft
analyses all those ideas and rejects them - the surviving proposal
is to use the PHB ID. I will comment on that in response to Steve's
message.
The pseudorandom case works for intserv and is irrelevant to diffserv.
Brian
Jun
> If I am reclassifying traffic at an administrative boundary then by
> definition I don't care about or trust the "QoS information" in the
> packet as anything more than a hint which I am free to ignore (depending
> on the TCS I have with the upstream network). When crossing security
> boundari
>The traffic class field is not enough. If you have to re-classify traffic at
>an administrative boundary, then by definition at that point the traffic class
>field is inadequate; you need more information. The advantage that IPv6 has
>is that even when the header is partly hidden by IPSEC, the
Brian Carpenter wrote:
> The traffic class field is not enough. If you have to re-classify traffic at
> an administrative boundary, then by definition at that point the traffic class
> field is inadequate; you need more information. The advantage that IPv6 has
> is that even when the header is p
> Subject: Re: draft-conta-ipv6-flow-label-02.txt
> Date: Fri, 10 Aug 2001 18:33:54 +0900
> From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> > with many of the diffserv-oriented encoding, there are possibilities
> > for routers to get tricked by originati
30 matches
Mail list logo
