May I offer an updated set of text which focuses on a consistent
use of the term FLOW and tries to issolate it from discussions of
state or the mechanisms to establish that:
>>>-
IPv6 Working Group J. Ra
- Original Message -
From: "Margaret Wasserman" <[EMAIL PROTECTED]>
To: "Brian E Carpenter" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 12:18 PM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
> Hi Brian,
>
> >If it is defined architecturally as a
Margaret Wasserman wrote:
> You have given one single example (the congestion discard
> case), where an ambiguous flow label might have some
> limited usefulness.
You asked for an example, and that was the one that came to mind without
any significant study.
> [Have you analyzed how this compare
Hi Hesham,
>=> Perhaps another way to look at this, is to
>come back to basics and say that the flow label
>is part of the IPv6 header, therefore it seems
>rational to let IPv6 WG define its use.
>I don't see anything wrong with this, no other
>fields in the IPv6 header are defined by other
>g
>...so why are we still talking
>about it?
Because I still haven't seen a compelling argument for why
we need additional rules regarding the flow label, beyond
those that are already included in RFC 2460.
You have given one single example (the congestion discard
case), where an ambiguous flow l
As a general point, I do not think that end-node applications care much
about what happens to flow labels in the network. They rather care of a
certain service from the network.
If a flow Setup and flow processing for a certain service is defined and
implemented to keep flow labels constant, the
Alex Conta wrote:
> Furthermore, the
> restriction has a detrimental effect on the subset of
> applications that
> could take advantage of a changing value.
I am sorry, but those applications should be using the DSCP which is
already mutable. If we allow the FL to be mutable, there will be no
app
Hesham Soliman wrote:
> => Perhaps another way to look at this, is to
> come back to basics and say that the flow label
> is part of the IPv6 header, therefore it seems
> rational to let IPv6 WG define its use.
> I don't see anything wrong with this, no other
> fields in the IPv6 header are define
Margaret Wasserman wrote:
> As far as I can tell, this makes it impossible to use the flow label
> as current defined (without some out-of-band flow management system
> to supply knowledge of flow lifetimes) to identify a single flow.
>
> What am I missing?
As I said earlier, you are focused on
Obviously I missed some mail here... In looking at draft-06, I am
concerned about src addr selection Rule 7. The sense of this is flipped
from what I remember, and it is done to accommodate the tiny number of
apps that do a consistency check of the reverse DNS pointer. Since those
apps are the one
At the IPv6 WG meeting (Thu AM) in Salt Lake City, I mentioned that the
DHCPv6 spec is about ready for WG last call. I've included a message below
that I sent to the DHC earlier today. I invite and encourage the IPv6 WG
to review and comment on draft-ietf-dhc-dhcpv6-22.txt in the [EMAIL PROT
Robert Elz writes:
> Date:Fri, 21 Dec 2001 08:56:26 -0800 (PST)
> From:Michael Thomas <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> |I sure see a difference. If my stack does that for me
> |I always have the option to cd /usr/src/linux/ne
Hi Brian,
>If it is defined architecturally as an immutable e2e value, there
>are immediate ways to use it in hardware that will work for any
>semantics we may later add to it.
Could you give an example?
From my understanding of the current draft, the information in the
packet (the flow label
> On Fri, 21 Dec 2001 18:25:07 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> > Are there TCP applications which use RFC 2292 style for accessing received
>> > extension headers?
>> > I thought we had concluded that no TCP applications existed that access
>> > the received stu
On Fri, 21 Dec 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
>I use such scenario in real life for my home office network (dynamic
>IPv4 on gateway).
>
>
>configured (a static prefix):
>homeoffice <-> tunnel.bieringer.de <-> 6bone
>
>+
>
If we had a flow label processing in the network without flow label
setup perhaps I would have agreed with you.
But if we accept that:
a. the flow label has no semantics
b. the flow label processing in the Network /depends directly on/is
controlled by/ the flowsetup in the Network dev
> > Are there TCP applications which use RFC 2292 style for accessing received
> > extension headers?
> > I thought we had concluded that no TCP applications existed that access
> > the received stuff (even tough telnet can set things like routing headers
> > for transmit).
>
> Okay, compatibili
- Original Message -
From: "Robert Elz" <[EMAIL PROTECTED]>
To: "Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 10:48 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
Date:Fri, 21 Dec 2001 08:56:26 -0800 (PST)
From:Michael Thomas <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
|I sure see a difference. If my stack does that for me
|I always have the option to cd /usr/src/linux/net/ipv6
|and make it stop doing
Robert Elz writes:
> | Alternatively another part of the stack may also choose to set it.
>
> Yes. But don't you see how similar this is to having a router set it?
> In either case, it won't (shouldn't) be altered if it has been explicitly
> set by the application, but assuming the exist
> However, what counts is "can be altered" - that happens
> only if things
> don't break when it is altered. If packets get rejected
> because it is
> being authenticated, and the alteration is detected -
> that's breaking,
> so anyone who tried to fiddle such a field would find
Date:Fri, 21 Dec 2001 17:18:24 +0100
From:"Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| So in this case, if you end up with an application that
| doesn't support the flow label or simply doesn't
| care, it might still be a good i
Margaret,
> > > Then, why not leave the specification of flow label
> semantics and
> > > rules to this same WG?
> >
> >Because the participants in those WGs have consistently proven they
> >don't understand the concept of an architecturally
> consistent immutable
> >field which
=> I agree with nealry everything you said except
for one point I'd like to clarify below.
> In general, Tony Hain's arguments are pretty persuasive to
> me ... but I
> am not sure that I would go as far as to prohibit all changes to the
> label - though the only ones I would allow a
So, let me get this right...
> > Then, why not leave the specification of flow label semantics and
> > rules to this same WG?
>
>Because the participants in those WGs have consistently proven they
>don't understand the concept of an architecturally consistent immutable
>field which the origin ca
In your previous mail you wrote:
There is value in a mechanism that the origin host can trust that a
remote router will see its intent. If you are strictly talking about
endpoint conversations, yes using an extension header is appropriate.
The point is that an application needs to co
In your previous mail you wrote:
I use such scenario in real life for my home office network (dynamic
IPv4 on gateway).
configured (a static prefix):
homeoffice <-> tunnel.bieringer.de <-> 6bone
+
6to4:
homeoffice <-> 6to4relay <-> 6bone
=> why do
I have just one last thing to say on the matter:
3041.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.s
Brian,
> > > > => Well, there is no requirement that the flow label is
> > > > globally unique. So this should work as long as you use
> > > > a unique value between 2 addresses.
> > > >
> > >
> > > However, it's only useful for a subset of cases,
> >
> > => I didn
Title: RE: draft-rajahalme-ipv6-flow-label-00.txt
IMO, you are absolutely right. To pin it down to one specific use would in effect limit its use (i.e. reduce extensibility of IPv6).
We should also learn from past on the mutability question in that if there is an economic incentive for funct
>=> It would be good if yu could point out
>a link perhaps to help me understand the reasons.
>
> => there are tons of mails in the archive of this list about that.
=> OK thanks.
>
> >If we want to make it
> >more sophisticated then we can add another
Just a reminder, people claim that 80% of all IP-based equipment
is never connected directly to "THE Internet"whatever THE is...
Jim Fleming
http://www.RepliGate.net
- Original Message -
From: "Francis Dupont" <[EMAIL PROTECTED]>
To: "Michael Thomas" <[EMAIL PROTECTED]>
Cc: <[EMAIL
In your previous mail you wrote:
So here's the end-game for the flow label
allowing for dumb hosts/smart routers: MIDCOM.
Can we just say no?
=> right fight, wrong forum...
[EMAIL PROTECTED]
IETF IPng
In your previous mail you wrote:
I'm afraid this brings us back to the slippery slope
of edge-remarkers and the layer violation of routers
wanting to look at L4+ headers, and the inherent
difficulty/impossibility.
=> I agree I don't like this but this is a fact.
BTW if
In your previous mail you wrote:
I think the group is converging on modifing that text to:
Hosts or routers
=> Nodes ?
that do not support the functions of the Flow Label
field are required to set the field to zero when originating a packet,
and ignore the field when receivi
In your previous mail you wrote:
> About your proposal, if we set the globally unique bit on,
> you get IIDs
> which are no more globally unique. If it is off, this won't avoid
> collision... The only advantage is the clarity, i.e. last argument.
The state of the bit is not th
On Fri, 21 Dec 2001, Francis Dupont wrote:
>> => be serious, autotunnels are phased out, configured tunnels and 6to4
>> are mutually exclusive...
>
>mutually exclusive? I don't think so.
>
> => if you have a configured tunnel you can use native addresses so
> you don't need a 6
On Fri, 21 Dec 2001, Brian E Carpenter wrote:
> Pekka Savola wrote:
> > This is getting too implementation-specific, so I guess we had better kill
> > this thread, at least from here...
>
> In fact, it would be a fundamental error to make protocol choices on the
> basis of perceived implementatio
Beginners may also want to keep up with the current specs for
IPv6 used in infiniBAND. Only the essential elements are used.
http://www.infinibandta.org
- Original Message -
From: "Brian E Carpenter" <[EMAIL PROTECTED]>
To: "Tony Hain" <[EMAIL PROTECTED]>
Cc: "Margaret Wasserman" <[EMAIL
In your previous mail you wrote:
> => be serious, autotunnels are phased out, configured tunnels and 6to4
> are mutually exclusive...
mutually exclusive? I don't think so.
=> if you have a configured tunnel you can use native addresses so
you don't need a 6to4 router. They are m
> On Fri, 21 Dec 2001 01:23:45 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 3. there are currently RFC2292-style applications deployed. It is easy
>> for such applications to migrate to rfc2292bis-03 than to
>> rfc2292bis-02. (The opposite argument may apply for
>> rfc2292
Tony Hain wrote:
...
> I think the group is converging on modifing that text to:
>
> Hosts or routers that do not support the functions of the Flow Label
> field are required to set the field to zero when originating a packet,
> and ignore the field when receiving a packet. All routers are requir
If NSIS came up with something like that, they would be alarmingly
far out of their objectives. That kind of signalling is already
fully defined by intserv and diffserv.
Brian
Tony Hain wrote:
>
> Muhammad Jaseemuddin wrote:
> > I completely agree with you that unless we have a
> > signalli
Tony is 100% correct in all his comments. I'd add that
hop-by-hop options are not even on the radar screen for
hardware implementation, but for QOS flows we absolutely
need things that hardware can process at line speed.
Brian
Tony Hain wrote:
>
> Margaret Wasserman wrote:
> > What is wrong
Margaret,
The current flow label definition is vague and useless and people
designing line-speed ASICs and network processors can't use it.
If it is defined architecturally as an immutable e2e value, there
are immediate ways to use it in hardware that will work for any
semantics we may later add
Francis Dupont wrote:
...
>> PS: I can read between the lines that an end-to-end usage of
> the flow label is proposed. IMHO this is only a waste of bits,
> the flow label is in the header in order to be available to
> intermediate nodes. For end-to-end options, a destination header
> fits better.
Margaret Wasserman wrote:
...
> >Hosts or routers that do not support the functions of the Flow Label
> >field are required to set the field to zero when originating a packet,
> >and ignore the field when receiving a packet. All routers are required
> >to pass the field on unchanged when forwardin
Margaret Wasserman wrote:
...
> >Hosts or routers that do not support the functions of the Flow Label
> >field are required to set the field to zero when originating a packet,
> >and ignore the field when receiving a packet. All routers are required
> >to pass the field on unchanged when forwardin
Date:Thu, 20 Dec 2001 17:16:58 +0100
From:"Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| I was arguing
| against letting the default routers set the
| flow label and I was saying that 'it' (setting
| the flow label by default r
Pekka Savola wrote:
>
> This is getting too implementation-specific, so I guess we had better kill
> this thread, at least from here...
In fact, it would be a fundamental error to make protocol choices on the
basis of perceived implementation glitches in today's popular operating
systems. If we
In your previous mail you wrote:
> I don't agree that we need to organize the space, but if everyone
> insists on going down this rat-hole then at least use the IANA
> allocated OUI 00-00-5E like ISATAP is doing. This will avoid the
> collision problems, plus make it clear who does t
51 matches
Mail list logo
