>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
Hi Brian,
> I think the WG needs to decide once and for all whether the
> flow label is
>a) a CATNIP or MPLS-like routing handle
> or b) a QOS hint for intserv only
> or c) a QOS hint for intserv and diffserv
> or d) a waste of bits
>
> We can get back to the details once we have a consensu
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
Brian,
At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote:
>I think the WG needs to decide once and for all whether the flow label is
>a) a CATNIP or MPLS-like routing handle
>or b) a QOS hint for intserv only
>or c) a QOS hint for intserv and diffserv
>or d) a waste of bits
I would like t
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
> > >
> On Thu, 16 Aug 2001 17:31:26 +0200 (CEST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo()
>> use this mapping, all applications that use those two functions are
>> affected, including ping, traceroute, ifconfig, netsta
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
> Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo()
> use this mapping, all applications that use those two functions are
> affected, including ping, traceroute, ifconfig, netstat, route,
> telnet, ssh, ftp,...
I'm confused.
When you ship a new release that supports a link id
On Thursday, 08/16/2001 at 03:40 ZE2, Erik Nordmark
<[EMAIL PROTECTED]> wrote:
> > So, the basic idea is as follows:
> >
> > - take 4+28 split.
> > - actual mapping from zone to the 28 bit part does not matter, but it
> > should not change while the node is running (as discussed in this
> > t
<[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
X-Mailer: Cue version 0.6 (010815-1037/onoe)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
> If B were the standard interoperable thing, but C would also be legal
> behavior (since it's a superset of B behavior)
> On Wed, 15 Aug 2001 12:11:12 -0700,
> "Dave Thaler" <[EMAIL PROTECTED]> said:
>> This should basically be the same idea as B. So I guess supporters
> of
>> B do not oppose to this (I hope not, actually).
>>
>> => no opposition! Where I can sign? (:-)
> Same for supporters of C. (B
> On Thu, 16 Aug 2001 15:40:25 +0200 (CEST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
> Seems like, to the extent that there are existing applications
> which use if_nametoindex() -> sin6_scope_id for link-local addresses,
> we need to also support the top 4 being zero as an alias for t
> - take 4+28 split.
> - actual mapping from zone to the 28 bit part does not matter, but it
> should not change while the node is running (as discussed in this
> thread)
> - introduce "aliases" for numeric zone IDs to improve readability in
> the textual representation. e.g. "link2" is an a
I think the WG needs to decide once and for all whether the flow label is
a) a CATNIP or MPLS-like routing handle
or b) a QOS hint for intserv only
or c) a QOS hint for intserv and diffserv
or d) a waste of bits
We can get back to the details once we have a consensus on this.
Brian
---
> So, the basic idea is as follows:
>
> - take 4+28 split.
> - actual mapping from zone to the 28 bit part does not matter, but it
> should not change while the node is running (as discussed in this
> thread)
> - introduce "aliases" for numeric zone IDs to improve readability in
> the text
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
19 matches
Mail list logo
