John, In line comments...
On 2011-03-10 04:48, John Leslie wrote: > Brian E Carpenter <[email protected]> wrote: >> I'm not hearing much in response to the open issue: >> >> Should we delete most of the text concerning stateful methods >> of handling the flow label? > > I don't really have a horse in that race, but at first blush I'd say > the I-D goes into too much detail about stateful handling. > > IMHO, most handling (assuming it happens at all) will be stateless, > and will greatly resemble "damage" (as in what we route-around). > >> In fact I'm not hearing much at all. Should I ask the WG Chairs >> to conclude that everybody is OK with these drafts? That would >> save us some time in Prague... > > I won't be in Prague... :^( > > But while this I-D is a step in the right direction, where I think > we ought to get should allow much more leeway in setting -- even > changing -- Flow Labels _by_prior_arrangement_. The draft creates that leeway - apart from the Section 4 text about stateful methods. > > The basic assumption that Flow Labels will be set by the sender and > passed unchanged is certainly correct in the absence of arrangements > that specify particular processing. > > I am a bit nervous about _always_ allowing a zero Flow Label to be > changed without sender consent... > > But clearly, there _can_ be no protection against such changes -- > or any changes, for that matter. > > My intuition is that any time the Traffic Class is changed during > forwarding, rules about Flow Label particular to that Traffic Class > should apply. There was considerable pushback in the WG to adding the concept of local domains to the flow label definition. > > Further, there probably need to be _various_ largely out-of-band > mechanisms to validate a contractual basis for special handling of > packets based upon Flow Labels. There could be one or more in-band > mechanisms if we had what I'll call a "Middlebox Options" extension > header (between Hop-by-Hop and Destination Options) to store validation > information. Yes, but that's in the stateful part that you're arguing above should be replaced by "more leeway". > > Fundamentally, I don't believe the completely-insecure Flow Label > can serve by itself as sufficient justification for special handling; > and I don't believe that the sender alone can justify special handling > by _all_ the different service-providers along the forwarding path. > I think more infrastructure will need to evolve. Ditto. > > Legislating what we can't specify any means to enforce isn't wise... > > ==== > > Disclaimer: I in some sense "represent" the ConEx WG, where several > folks want to reserve one bit from the Flow Label for ConEx use. I am > _not_ the right person to put the case for that, because frankly I > don't agree with the idea. Nonetheless, it seems reasonable to me to > allow things like that on an Experimental basis if clearly labeled > by setting an Experimental Traffic Class. Ditto. What the draft is talking about is default behaviour, absent anything requiring prior agreement or signalling. I take your whole comment as a recommendation to remove section 4. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
