Wes,
On 2010-05-11 02:39, George, Wes E IV [NTK] wrote:
> One additional thought I had... if we move towards locally-defined flow
> label, we probably still need a use case and some direction for traffic that
> originates in tunnels prior to entering a network that is locally defining
> flow labels. Specifically, whatever method is employed to generate the flow
> label as packets come in is still going to be based on some set of data from
> the packet that may or may not be easily found by a PE or ASBR in the
> multiple layers of headers a tunneled protocol may generate, and the outer
> packet may not have enough info to generate an appropriate value for the flow
> label - multiple flows may look like the same flow because they have the same
> src/dst and protocol because they're being tunneled between the same
> endpoints, for example.
>
> So, it may make sense to have a method where the device responsible for doing
> the encapsulation [should | must] insert a random value into the outer
> header's flow label that is based on some useful data from the inner headers.
That is what draft-carpenter-flow-ecmp says
Brian
To the concern about whether it will be random enough, and whether it will
conflict with the locally-significant flow labels, if
it is based on the same criteria used for the locally significant flow labels,
it's at least mostly safe to assume it'll be
useful, and likely it'll be better than not having it. If we go with something
like the previous draft, where the first few bits
should be set using a defined flag value so that devices that see that value
know not to re-mark those flow labels as the
packets come into the network, we might have a way to make flow label more
useful for traffic that is otherwise not visible
enough to the transporting network to take advantage of this work, without
having to worry about preserving the value across
multiple networks.
>
> Thanks
> Wes George
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> George, Wes E IV [NTK]
> Sent: Friday, May 07, 2010 5:03 PM
> To: Brian E Carpenter; 6man
> Subject: RE: [Fwd: I-D Action:draft-carpenter-6man-flow-update-03.txt]
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Brian
> E Carpenter
> Sent: Thursday, May 06, 2010 9:11 PM
> To: 6man
> Subject: [Fwd: I-D Action:draft-carpenter-6man-flow-update-03.txt]
>
> Secondly, it offers the WG a binary choice as the main decision:
>
> "There appear to be two viable approaches:
> 1. Definitively forbid locally defined use of the flow label.
> Strengthen RFC 3697 to say that hosts SHOULD set a pseudo-random
> label value, which would clarify and limit its possible uses. In
> particular, its use for load balancing and possibly as a nonce
> would be encouraged.
> 2. Encourage locally defined use of the flow label. This approach
> would make the flow label mutable and would exclude any use case
> depending on end-to-end immutability. It would encourage
> applications of a pseudo-random flow label, such as load
> balancing, on a local basis, but it would exclude end-to-end
> applications such as [I-D.blake-ipv6-flow-label-nonce]."
>
> [[WEG]] I prefer option 2. I echo Shane's concerns that I don't trust end
> hosts to be random enough (or random in the right way) to ensure that I can
> actually load-balance using flow label as even a partial input on a
> load-balancing hash decision. Further, that SHOULD in option 1 means that I
> can't assume that anything other than a zero value will be there when
> considering whether to use flow label as a part of my hash, making it just
> one more way that flow label won't be used.
>
> I tend to think that the lack of a header checksum makes the flow label's
> immutability a bad assumption for end hosts (or end networks) to make anyway.
> I also haven't seen a compelling use case for an immutable flow label that
> makes #2 a bad idea by comparison. As I said at the mic in Anaheim, I'd
> rather see us use Flow label to solve a problem that we actually have, like
> needing to make loadbalancing work better, rather than reserving it for some
> compelling future use that no one can seem to come up with yet. [as an aside,
> blake-nonce is now expired and doesn't appear to have much in the way of
> support that I could find]
>
> Moreover, I think that there are multiple other ways to manage a need to have
> persistent data within a header between endpoints across multiple domains,
> including extension headers, (especially if standardized under
> draft-krishnan-ipv6-exthdr) as well as transport-layer headers, or even
> payload data, most of which have mechanisms to ensure that the data hasn't
> been mucked with somewhere in the middle. I know there are concerns about
> scale when extension headers are involved, but I can say that in our core,
> we're basically treating them like IPv4 options - we ignore the options/EH,
> but pass the packet through the router if it's not "for us." So from that
> perspective, core routers don't care how many extension headers the packet
> has, nor what people are trying to do with them. This may still be an issue
> on PEs and other middleboxes like firewalls, but if we move towards
> standardizing the headers, perhaps not so much.
>
> Thanks,
> Wes George
>
> This e-mail may contain Sprint Nextel Company proprietary information
> intended for the sole use of the recipient(s). Any use by others is
> prohibited. If you are not the intended recipient, please contact the sender
> and delete all copies of the message.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> This e-mail may contain Sprint Nextel Company proprietary information
> intended for the sole use of the recipient(s). Any use by others is
> prohibited. If you are not the intended recipient, please contact the sender
> and delete all copies of the message.
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
