.
> Also, in many cases, as described in other documents, such re-marking is
> effectively impossible.
>
> Yours,
> Joel M. Halpern
>
> On 1/31/2011 8:07 AM, Jarno Rajahalme wrote:
>>
>>> ISSUE 9. The changes to section 2 include this paragraph. Please read all
> ISSUE 10. Section 2 also says:
>
>Forwarding nodes such as routers and load balancers MUST NOT depend
>only on Flow Label values being randomly distributed. In any usage
>such as a hash key for load balancing, the Flow Label bits MUST be
>combined with bits from other sources w
> ISSUE 9. The changes to section 2 include this paragraph. Please read all
> of it, since the first sentence out of context causes confusion:
>
>2. To enable stateless load distribution at any point in the
>Internet, a network domain MUST NOT forward packets outside the
>dom
> ISSUE 7. Section 5 says:
>
>To enable applications and transport protocols to define what packets
>constitute a flow, the source node MUST provide means for the
>applications and transport protocols to specify the Flow Label values
>to be used with their flows. The use of the m
> ISSUE 5. Section 2 says:
>
>IPv6 nodes MUST NOT assume that the Flow Label value in a incoming
>packet is identical to the value set by the source node.
>
> QUESTION: This needs to be reconciled with the security usage mentioned in
> draft-gont-. Would SHOULD NOT be acceptable?
IMO "
> ISSUE 4. The Introduction previously included:
>
>Doing this [setting the flow label]
>enables load spreading and receiver oriented resource allocation, for
>example.
>
> The phrase "receiver oriented resource allocation" has been deleted because
> we don't know what it means.
>
Issue 3:
> ISSUE 3. 3697bis RECOMMENDS pseudo-random flow label values. The goal is be
> able to
> use just the 3-tuple {dest addr, source addr, label} as input to load
> distribution hashes. There have been a couple of objections to this:
> - This property is not required for effective hashes
Brian,
Here is my take on the issues 1 & 2:
> Open issues in 3697bis
>
> --
> ISSUE 1. A basic assumption in RFC 3697 is that flow labelling mechanisms will
> be stateful and may need signaling. The changes discussed in the WG clearly
> address a stateless approach that needs no sign
Thomas Narten wrote:
> why we can't make such assignments permanent. (Note: I'd agree with
> you that the assignments shouldn't be permanent if there was a case to
> be made that it may become necessary to reclaim them at some future
> time. Is there?)
>
What if someone manages to hoard the addre
