I have a few comments/questions on the general flow label topic.
They are not specific to draft-rajahalame-ipv6-flow-label-00.txt,
but they do apply to this proposal, as well as others.
I've hesitated to raise this issue for fear of being publicly
stoned, but...
It seems to me that an IPv6-spec
On the whole I think this looks like quite a reasonable approach, certainly
none of the substantive changes from 2460 bother me.
I have two comments ...
The first is one of my pet peeves - the over use of those 2119 capitalised
words in places they don't belong. Perhaps the worst example is fro
Margaret Wasserman wrote:
>
> I have a few comments/questions on the general flow label topic.
> They are not specific to draft-rajahalame-ipv6-flow-label-00.txt,
> but they do apply to this proposal, as well as others.
>
> I've hesitated to raise this issue for fear of being publicly
> stoned,
Thanks for the response, Brian.
> > Are there reasons for preferring to put a flow label inside the
> > IPv6 header? Is this being done on the advice of folks who are
> > standardizing label switching technologies?
> >
>No, because it has nothing to do with label switching. It's much
>more to
Margaret Wasserman wrote:
>
> Thanks for the response, Brian.
>
> > > Are there reasons for preferring to put a flow label inside the
> > > IPv6 header? Is this being done on the advice of folks who are
> > > standardizing label switching technologies?
> > >
> >No, because it has nothing to do
Margaret Wasserman writes:
> If I seem to be missing an important point or concept, please send
> some hints or pointers.
Margaret,
I don't think you're alone wondering what all the
fuss is about with the flow label since it's
fairly obvious that normal Intserv classifiers
function equivalentl
MAIL PROTECTED]>
Cc: "Brian E Carpenter" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, December 17, 2001 8:21 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> Margaret Wasserman writes:
> > If I seem to be missing an important point or concept, ple
is *not* a routing label.".
Craig.
-Original Message-
From: James Kempf [mailto:[EMAIL PROTECTED]]
Sent: December 17, 2001 1:06 PM
To: Michael Thomas; Margaret Wasserman
Cc: Brian E Carpenter; [EMAIL PROTECTED]
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
Mike,
You forgot
;.
>
> Craig.
>
> -Original Message-
> From: James Kempf [mailto:[EMAIL PROTECTED]]
> Sent: December 17, 2001 1:06 PM
> To: Michael Thomas; Margaret Wasserman
> Cc: Brian E Carpenter; [EMAIL PROTECTED]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
>
Brian E Carpenter writes:
> Yes, the flow label is explicitly excluded from AH. So it could be modified
> en route and you can't authenticate its value. Assuming we decide to use
> it as an end2end value, that could be viewed as a bug.
That would be a pretty funny view. The only
way to m
I agree; I meant that even at the receiving end you can't authenticate it,
let alone the intermediate hops.
Brian
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > Yes, the flow label is explicitly excluded from AH. So it could be modified
> > en route and you can't authenticate its
ilto:[EMAIL PROTECTED]]
> Sent: 18 December 2001 16:43
> To: Michael Thomas
> Cc: Craig Dunk; 'James Kempf'; Margaret Wasserman;
> [EMAIL PROTECTED]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
>
> I agree; I meant that even at the receiving end
Kempf'; Margaret Wasserman;
> > [EMAIL PROTECTED]
> > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> >
> >
> > I agree; I meant that even at the receiving end you can't
> > authenticate it,
> > let alone the intermediate hops.
> >
>
Date:Wed, 19 Dec 2001 11:37:55 +0100
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| We can note the discrepancy, but I doubt if we can change
| IPSEC at this point in time.
We wouldn't want to anyway. The draft doesn't make the fie
ld we just ignore AH? (Who is
using it anyway?)
Jarno
> -Original Message-
> From: ext Robert Elz [mailto:[EMAIL PROTECTED]]
> Sent: 19. joulukuuta 2001 13:25
> To: Brian E Carpenter
> Cc: [EMAIL PROTECTED]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
> AH: It could be possible to change AH, but it might not be
> worth it. The
> main problem would be the interoperability problem between
> a source sending
> non-zero flow label and including it in the AH computation,
> and an old
> destination receiving it and replacing 0's for
Hesham,
> I had a preliminary idea and was going to write something
> about it. Basically the sender can generate the flow label
> based on a hash of the source and destination port numbers.
> This is straight forward enough. If we want to make it
> more sophisticated then we can add another n
> > I had a preliminary idea and was going to write something
> > about it. Basically the sender can generate the flow label
> > based on a hash of the source and destination port numbers.
> > This is straight forward enough. If we want to make it
> > more sophisticated then we can a
In your previous mail you wrote:
The current draft states that a non-zero label could be changed by an
intermediate node to a non-zero value. However, during the discussion on the
topic in SLC it was concluded (IMO) that this is undesirable, and it would
be more useful (and sound) to
In your previous mail you wrote:
I had a preliminary idea and was going to write something
about it. Basically the sender can generate the flow label
based on a hash of the source and destination port numbers.
=> this kind of things was already proposed... The main
objection is this r
"Hesham Soliman (ERA)" wrote:
>
>
> > > I had a preliminary idea and was going to write something
> > > about it. Basically the sender can generate the flow label
> > > based on a hash of the source and destination port numbers.
> > > This is straight forward enough. If we want to make i
[EMAIL PROTECTED] wrote:
>
> The current draft states that a non-zero label could be changed by an
> intermediate node to a non-zero value. However, during the discussion on the
> topic in SLC it was concluded (IMO) that this is undesirable, and it would
> be more useful (and sound) to keep the v
Date:Thu, 20 Dec 2001 11:18:50 +0100
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The only way to restore the original
| value is if you carry it with the packet (nothing else is safe).
I'm not sure that is true. To take a (very
Francis,
You wrote:
> In your previous mail you wrote:
>
>The current draft states that a non-zero label could be
> changed by an
>intermediate node to a non-zero value. However, during the
> discussion on the
>topic in SLC it was concluded (IMO) that this is
> undesirable, and i
Robert Elz wrote:
...
> So I'm not sure it is quite true to say that it would never make sense
> for an ISP to do this (including putting the label back on exit) - but
> as long as the label received is the same as the label transmitted,
> there's no way to tell what is going on inside there, nor
[EMAIL PROTECTED] wrote:
...
> Francis,
> > => I disagree: if the end node is too dumb to set itself the label
> > (i.e. just uses in any case the zero value) and the first router
> > for instance sets the label when needed then the zero value should
> > not be immutable. I don't use dumb hosts (:
Date:Thu, 20 Dec 2001 14:13:26 +0200
From:[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| However, if the change from zero value to non-zero value is banned, then the
| end-to-end value would always be immutable,
Really? When I read the draft I saw three m
> > > > I had a preliminary idea and was going to write something
> > > > about it. Basically the sender can generate the flow label
> > > > based on a hash of the source and destination port numbers.
> > > > This is straight forward enough. If we want to make it
> > > > more s
>
> In your previous mail you wrote:
>
>I had a preliminary idea and was going to write something
>about it. Basically the sender can generate the flow label
>based on a hash of the source and destination port numbers.
>
> => this kind of things was already propose
> | - Or assume that the host distributes different flows
> to different default
> | routers. How will you guarantee that the routers will
> not pick the same flow
> | label values (which would be a problem if the flows go
> to the same
> | destination)?
> |
> | -
"Hesham Soliman (ERA)" wrote:
...
> > > => 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't really
Date:Thu, 20 Dec 2001 16:26:54 +0100
From:"Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| => Sorry but this is very unrealistic.
It wasn't meant to be realistic, just an example to show it can be done.
| Setting the flow label at th
> | I don't think that should be allowed.
>
> Huh? What shouldn't be allowed? Not having multiple default
> routers? That is, you're saying everyone must have more than one?
> That would be rather ambitious.
=> Indeed, but that's not what I was saying :)
or at least not what I
Hi All,
I am wondering why we should specify the use of the flow label as
part of the base IPv6 specifications at all. Why do we need
these rules as part of IPv6?
The flow label does not, by itself, provide any useful information
that a router can use to classify a flow and/or optimize pack
In your previous mail you wrote:
The analogy to the situation with RSVP is not 100% applicable. We could make
all the IPv6 sources to mark the packets with flow labels, even if they had
no interest in participating in any kind of resource reservations. If we
could raise the bar for t
.
-Original Message-
From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
Sent: December 20, 2001 11:50 AM
To: [EMAIL PROTECTED]
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
Hi All,
I am wondering why we should specify the use of the flow label as
part of the base IPv6 specifications
g rules or security policies?
>
> Craig.
>
> -Original Message-
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
> Sent: December 20, 2001 11:50 AM
> To: [EMAIL PROTECTED]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
> Hi All,
>
> I am won
Margaret Wasserman wrote:
> The flow label does not, by itself, provide any useful information
> that a router can use to classify a flow and/or optimize packet
> handling. In fact, without knowledge of a specific signalling
> mechanism or flow-establishment mechanism, the router can't
> use the
Francis Dupont writes:
> In your previous mail you wrote:
>
>The current draft states that a non-zero label could be changed by an
>intermediate node to a non-zero value. However, during the discussion on the
>topic in SLC it was concluded (IMO) that this is undesirable, and it
Francis Dupont writes:
> => I didn't say that dumb host/smart router is good, I did say this is
> a common scenario. But I am tired of flow label discussions, usually
> they go nowhere. Please count me as a "keep current (non) specs" supporter.
So here's the end-game for the flow label
a
>It is valid to say that a flow label can not be used in isolation, but I
>believe you are locking it too tightly to current implementations of QoS
>handling. If we consider that the flow label could be used as a modifier
>to a DSCP, flow lifetime is irrelevant, or more properly 'this packet'.
Margaret Wasserman wrote:
> There is not way to identify "all packets of a single flow" without
> having a set of fields that identify a unique flow (src addr, dest
> addr and flow label?) PLUS the concept of a flow lifetime.
> Otherwise, you may end up dropping packets that belong to a later
> fl
In your previous mail you wrote:
=> 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.
If breaking the key is a concern you can do
things to fix that (e.g. like adding x below
At 02:06 PM 12/20/01 , Tony Hain wrote:
>Absolutely NOT!!! We already have too many mechanisms that
>allow/encourage the value to be modified in route, and this field is the
>only one we have left that can have meaning end-to-end. THERE IS NO
>REASON TO CREATE ANOTHER ONE! We need to take an arc
In message <[EMAIL PROTECTED]>, Brian E Carpenter writes:
>We can note the discrepancy, but I doubt if we can change
>IPSEC at this point in time.
>
Of course, IPsec excludes the flow label from AH because at the time
IPsec was being standardized, the v6 folks didn't know what they wanted
to do
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.
Th
Margaret Wasserman wrote:
> Hmmm... I've apparently hit a nerve here. But, I still don't
> I get it. What goals would we further by taking "an architectural
> stand" on this issue? What value would this change add to the
> existing standards?
Locking the value to end-to-end immutable adds val
Steven M. Bellovin wrote:
> Of course, IPsec excludes the flow label from AH because at the time
> IPsec was being standardized, the v6 folks didn't know what
> they wanted
> to do with that field.
Which is still the case, with the exception that it really needs to be
restricted to immutable beca
>Locking the value to end-to-end immutable adds value to the process
>because there is no other mechanism for an application to assure that
>every router along the path that chooses to may see its intent. All the
>current mechanisms allow random administrative policies to change the
>message fro
Margaret:
I completely agree with you that unless we have a
signalling/flow-establishment mechanism we cannot really define the
flow-label usage in a meaninful way. Perhaps we should wait until new
NSIS sginalling might come-up with some usage and mechanism for this
bit-space.
- Muhammad Ja
Margaret Wasserman wrote:
> What is wrong with a hop-by-hop option? Isn't that the "right"
> mechanism for an IPv6 host to send a "message" that is processed
> by all routers in the path?
Hop-by-hop options will be slower to process, and the point is that the
origin knows which packets belong to
Muhammad Jaseemuddin wrote:
> I completely agree with you that unless we have a
> signalling/flow-establishment mechanism we cannot really define the
> flow-label usage in a meaninful way. Perhaps we should wait until new
> NSIS sginalling might come-up with some usage and mechanism for this
> bi
The flow label, as defined in the draft, eliminates the need of
infrastructure devices to snoop at transport (end-to-end) headers. This
is a big achievement: after all, the Network should not
process anything beyond the network headers.
Host-to-host headers are for processing at source and destin
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
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
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,
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
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
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 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
TED]>
Cc: "Margaret Wasserman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 5:20 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> Tony is 100% correct in all his comments. I'd add that
> hop-by-hop options are not even on the
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:
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:
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
Thomas" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 8:03 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> In your previous mail you wrote:
>
> I&#
>=> 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
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
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
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
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
=> 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
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
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
> 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
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
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
- 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:4
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
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
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
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
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
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
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
>...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
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
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
- 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 Bria
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
Date:Fri, 21 Dec 2001 10:18:27 -0800 (PST)
From:Michael Thomas <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
|Um, no. I don't want my telephant's local policy --
Then leave them - they'll never learn as long as people just accept it.
|Yes, yes, big
- Original Message -
From: "Robert Elz" <[EMAIL PROTECTED]>
> one. So far, I see no evidence of harm at all - nothing more than
> queasiness at the thought of the network altering anything in a packet,
> even when the source host has said it is OK for it to be altered (I'm not
> sure h
In your previous mail you 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
In your previous mail you wrote:
> => I still don't understand what is the difference between
> x and hash(P1 || P2 || x) where x can be something specific
> to this flow.
=> Well it doesn't have to be flow specific.
=> you wrote "x can be something specific"...
If you
I concur. The flow label should be set by the source host and remain
immutable as it travels over the network.
Rich
At 12:20 PM 12/21/01 +0100, Brian E Carpenter wrote:
>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 im
Glenn Morrow wrote:
> If "function A" wants the field immutable so be it. The signaling for "function A"
>needs to convey the mutability rules to affected parties
> either implicitly or by optionality.
This is broken. You can't signal to routers that aren't aware of
the "function A", because t
The IANA assignment approach comes afterwards - once we get the
immutability property in the standard, we can use IANA assigned
values without further work. For diffserv we would use the
PHB ID values of RFC 3140, but there is no need to specify that
as part of the flow label definition; it comes
- Original Message -
From: "Richard Carlson" <[EMAIL PROTECTED]>
> I concur. The flow label should be set by the source host and remain
> immutable as it travels over the network.
>
Just like the TOS field in IPv4 ?
Jim Fleming
http://www.IPv8.info
--
> I concur. The flow label should be set by the source host and remain
> immutable as it travels over the network.
great! now if we'd only make the same declaration for the source
and destination address...
Keith
IETF IPng W
MAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, December 24, 2001 9:32 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> > I concur. The flow label should be set by the source host and remain
> > immutable as it travels over the network.
>
> great! now if we&#x
1 - 100 of 122 matches
Mail list logo
