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 be
On 2011-06-30 04:42, Thomas Narten wrote:
> I'm generally OK with this text.
>
> Brian E Carpenter 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
I'm generally OK with this text.
Brian E Carpenter 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 stateless
> method of flow
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 fine with this text.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
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,
> > 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 defau
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
> reaso
On 2011-06-29 01:12, Thomas Narten wrote:
> Jari Arkko 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 cl
On 2011-06-29 01:06, Thomas Narten wrote:
> Brian E Carpenter 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 expla
Jari Arkko 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 knowledge about
Brian E Carpenter 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 to do? I don't see
right
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 (and presumably even for IPv4) when a fragme
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 multip
RJ Atkinson 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 worse" in the q
On 27 Jun 2011, at 15:49 , Thomas Narten wrote:
> RJ Atkinson 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 all will have
RJ Atkinson 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 all will have some Flow Label value B.
> With high probability, (A
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
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
>
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 a
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
>
Ran, Jari, All,
To emphasize some of the excellent points that Ran made ...
On Jun 21, 2011, at 9:00 AM, RJ Atkinson wrote:
> Separately, packet re-ordering can (and routinely does) happen
> in the deployed world already, regardless of contents of the
> Flow Label field. So receiving nodes alre
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 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
>
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)
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
Ran and others,
For the case of non-fragmented packets, use of the full 5 input
parameters ought to be mandated.
For the case of fragmented packets, use of reduced inputs that
are available in the IPv6 header alone should be permitted
as an option for implementers.
I think you are making i
-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 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 sc
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 rewri
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 deplo
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 labe
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
33 matches
Mail list logo
