-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Shane Amante Sent: Tuesday, August 17, 2010 2:00 PM To: George, Wes E [NTK] Cc: Pascal Thubert (pthubert); 6man 6man; [email protected]; Mohacsi Janos; Tony Hain Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable
Wes, On Aug 17, 2010, at 09:53 MDT, George, Wes E [NTK] wrote: > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Shane > Amante > Sent: Tuesday, August 03, 2010 1:20 PM > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > > > Because of your last two bullets I have to ask the following. How would a > receiving host deterministically distinguish (1) flow-labels that were > created by network devices (just a 5-tuple was put into a flow-label) vs. (2) > flow-labels that were created by a source-host w/ a pseudo-random number + > 5-tuple[1]? (Please read on before answering :-) > [[WEG]] Perhaps I'm oversimplifying, but wouldn't it be possible to use one > bit to flag who set it? 0 for end-host 1 for network or vice versa? Yes, that > requires us to define who falls into what category, but that's manageable. IMHO, this would likely be the start of a slippery slope. Specifically, a few points to bear in mind: 1) Once you "steal" one bit to note who set the flow-label, who's the say that requests to steal more bits don't surface? For example, perhaps someone wants another bit to indicate if the remaining bits are mutable (i.e.: changeable by other downstream network elements) or immutable? Or, perhaps, a third (or, fourth) bit to indicate if the flow-label is: a) 'locally-defined'; b) a "normal" hash of the IPv6 header's 3- or 5-tuple; or, c) some other well-defined application (e.g.: ROLL's request for a "InstanceID" to be inserted into the FL field). Granted, some applications could get compressed together and one might be able to overload one-bit position to mean multiple things ... but, in general, this is just asking for trouble and, inevitably, people would want to leave 1 or 2 bits unused/reserved so that if/when you needed to define yet more interpretations of the FL you had bits to do so ... [[WEG]] I get that, and I share your concern. I'm not necessarily advocating this as a solution, more thinking out loud. However, since we're already mulling the idea of a 12/8 split (as per the subject line) maybe stealing a few bits for administrative flags is not as big of a deal given the value that might (?) be derived from having the info. That's all I'm saying. 2) We have to get router vendors to build the logic to pay attention to and/or ignore the appropriate combination of "flags" bits in order that, for example, intermediate routers would be able to identify *when* to use the left-over FL bits as an input key for LAG and/or ECMP. (Likewise, host vendors, etc. would have to implement similar logic to know when they should pay attention and parse incoming FL's). [[WEG]] Agree, this is non-trivial, although it's not like router vendors aren't already going to have to do some implementation work in order to be able to look for/act on/(re)write the value in the FL header that they're presently ignoring. I think the LOE is going to be about the same as long as we define it up front and don't change it midstream. Instead of all that complexity, I'd really prefer a very simple approach that just clarified the semantics of the flow-label in RFC 3697, preferably along the the lines that FL's must be constructed in a way that uniquely identifies a "flow" to intermediate routers (or, L2/L2.5 switches) in the network ... in order that a FL could always "safely" be used as an input-key to LAG or ECMP load-balancing. Assuming that general design philosophy is agreed upon, then it's likely a variety of "application"-type drafts can safely be built upon a RFC 3967bis, e.g.: draft-blake, draft-donley, etc., assuming they don't conflict with the underlying semantics of the FL. [[WEG]] I generally agree (I always prefer simpler), but I think it'll end up coming back to your original assertion about hosts vs network, and if we have to try to compromise so that both can use it, you might end up needing some of that complexity. This e-mail may contain Sprint Nextel 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 --------------------------------------------------------------------
