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
>
Ran,
On 2011-06-22 01:03, RJ Atkinson wrote:
> Earlier, Brian Carpenter wrote:
>> I'd have to trawl the archive to find all the arguments,
>> but the main issue was that any attempt to include semantics
>> in the bits of the flow label leads to complexity that
>> probably can't be handled at line
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:
> I'd have to trawl the archive to find all the arguments,
> but the main issue was that any attempt to include semantics
> in the bits of the flow label leads to complexity that
> probably can't be handled at line speed in a scaleable way.
That claim presumes that
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
12 matches
Mail list logo
