On Jun 28, 2011, at 2:51 PM, Jari Arkko wrote:
I'm fine with this text.
As am I.
Bob
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
I'm generally OK with this text.
Brian E Carpenter brian.e.carpen...@gmail.com writes:
o This option, if implemented, would presumably be of value in
first-hop or ingress routers. It might place a considerable per-
packet processing load on them, even if they adopted a
Thomas, Brian,
Sure. But why should that impact how the Flow Label is rewritten from
zero to something else?
Because different routers might pick different labels for packets
that belong to the same flow.
Yes, that was my concern.
But, this implies packets from the same flow are
Brian E Carpenter brian.e.carpen...@gmail.com writes:
o The deployment of this option MUST be consistent with [RFC4311].
[BC: This last sentence is to cover Jari's point about a router knowing it's
appropriate for it to set the label.]
Could you please explain what the above is intended
Jari Arkko jari.ar...@piuha.net writes:
Bob,
In addition, I'm not sure I understand how a router knows that it
is a first hop router.
IMO, this is not necessarily intended to be something routers just
know automatically. The point is that routers closer to the source
tend to have better
On 2011-06-29 01:06, Thomas Narten wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
o The deployment of this option MUST be consistent with [RFC4311].
[BC: This last sentence is to cover Jari's point about a router knowing it's
appropriate for it to set the label.]
Could
On 2011-06-28 11:40, Jari Arkko wrote:
I still have an uneasy feeling about the changing flow IDs across the
same TCP session. It feels wrong.
That being said, Ran's argument that different classifications for
fragmented/non-fragmented packets already happening for load-balancing
reasons
That all said, any router that sees a Flow Label of zero, and wants to
change it to something better presumably should/can. When would that
NOT be the case?
If the network manager of the site decides not to do it there? I think
it needs to be configurable.
Absolutely, and by default
By way of introduction, I have a preference for standards text to be as short
as possible, because the more we say, the more likely we are to be wrong
(especially when speculating about future router design). So here is my
next proposal for the text about routers setting the flow label. As always,
I'm fine with this text.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Brian,
On 6/25/11 9:06 PM, Brian E Carpenter wrote:
Hi,
The discussion Jari's issue has died down, so I'd like to propose some
revised text:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is
Brian,
On Jun 25, 2011, at 7:06 PM, Brian E Carpenter wrote:
Hi,
The discussion Jari's issue has died down, so I'd like to propose some
revised text:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is
On 27 Jun 2011, at 15:49 , Thomas Narten wrote:
RJ Atkinson rja.li...@gmail.com writes:
In the approach I outlined, for some given flow where the
originating node did not set a Flow Label value, the
non-fragmented packets all will have some Flow Label value A,
while fragmented packets
RJ Atkinson rja.li...@gmail.com writes:
For the case where the Flow Label is zero, I fully expect that routers
will use the currently deployed behaviour. So having 2 different
Flow Label values in the case I describe at top yields **identical**
behaviour as today -- therefore not obviously
Bob,
In addition, I'm not sure I understand how a router knows that it is a first
hop router. Are there cases where a device might mistakenly believe it is a
first hop router at a point where the traffic has already been load-balanced to
multiple routers? Are there situations where the
Hi,
The discussion Jari's issue has died down, so I'd like to propose some revised
text:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is
RECOMMENDED that the forwarding node sets the flow label field for
On 22 Jun 2011, at 00:07 , Shane Amante wrote:
An example which routinely happens in today's networks would be link
restoration.
In that case, the network is restoring traffic from a much longer path to a
shorter, more optimal path in the network. Depending on the transmission rate
of
Earlier, Brian Carpenter wrote:
As far as routers go, I think we have to say that an implementor has
to choose between a reassembly-based solution using the 5-tuple and
simply using the 2-tuple (maybe also the fragmentation ID - there is
some scope for ingenuity here).
OBSERVATION:
A deployed
Earlier, Jari Arkko wrote:
In addition, I'm not sure I understand how a router knows that it is a first
hop router.
My understanding is that the IPv6 WG's compromise regarding
the Flow Label covert channel issue that has been worked out
expressly permits any IPv6 security gateway to rewrite
On 2011-06-22 00:51, RJ Atkinson wrote:
Earlier, Brian Carpenter wrote:
As far as routers go, I think we have to say that an implementor has
to choose between a reassembly-based solution using the 5-tuple and
simply using the 2-tuple (maybe also the fragmentation ID - there is
some scope for
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: Monday, June 20, 2011 6:21 PM
To: Jari Arkko
Cc: IETF IPv6 Mailing List; draft-ietf-6man-flow-3697...@tools.ietf.org
Subject: Re: AD review of draft-ietf-6man-flow-3697bis
On 21 Jun 2011, at 10:13 , Jari Arkko wrote:
I think you are making it easier than it really is.
Here's the problem.
The first packet arrives and its small. The router can read the 5-tuple.
All fine so far. Picking
flowid = f(5-tuple)
The next packet arrives, only this time it is
CLARIFICATION:
I agree with Brian and George that for the case where a router
is inserting a Flow Label value into a fragmented packet,
it is desirable (and normally practical) to include the
Fragment ID field as an input.
So that would give 3 input values (Source IP, Dest IP,
Fragment ID)
I agree with Brian and George that for the case where a router is inserting a
Flow Label value into a fragmented packet, it is desirable (and normally
practical) to include the Fragment ID field as an input.
So that would give 3 input values (Source IP, Dest IP, Fragment ID) for
On 21 Jun 2011, at 12:47 , Christian Huitema wrote:
Really? The fragment ID can change with each packet, correct? Imagine a UDP
stream that for some reason uses large packets. Or maybe some large packets
and some small packets. Isn't the proposal going to result in different
packets of
I have reviewed this draft.
I think it is in good shape and can move forward once we resolve one
issue. Here's the issue:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is
RECOMMENDED that the forwarding node
Jari,
Thanks for the review.
On 2011-06-21 04:09, Jari Arkko wrote:
I have reviewed this draft.
I think it is in good shape and can move forward once we resolve one
issue. Here's the issue:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the
Jari,
On Jun 20, 2011, at 9:09 AM, Jari Arkko wrote:
I have reviewed this draft.
I think it is in good shape and can move forward once we resolve one issue.
Here's the issue:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value.
28 matches
Mail list logo
