Wes, On Aug 17, 2010, at 09:53 MDT, George, Wes E [NTK] wrote: > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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 ... 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). 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. -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
