On Wed, 12 Mar 2003, Alex Conta wrote: > > On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > > > The 3-tuple of the Flow Label and the Source and Destination Address > > > > fields enables efficient IPv6 flow classification, where only IPv6 > > > > main header fields in fixed positions are used. > > > > > > > > ==> this might require some extra analysis somewhere (not in that > > > > particular place, I think). In particular, this seems to say that once > > > > this is published people can happily move to using the three-tuple > > > > classification. The reality is probably quite different, and one must > > > > also consider the big portion of nodes which do not mark the flows. > > > > > > The goal of this document is not to describe use cases. It is > > > to set the minimum conditions hosts and routers must meet. I do > > > not believe we should add use cases to this document. > > > > I believe the original text does not give a realistic picture of the > > situation. > > > > For the purpose of minimum conditions, the text could be removed > > altogether, of course -- that would be fine by me. I could also live with > > (by a thread :-) the current version, but I really believe it should be > > changed slightly. > > > > I would suggest we take your statement that "you could live with the > current version". > > I do not think that what is to be said, can be said significantly > better, than the way it is said in the draft, in plain, simple, accurate > English.
Ok. > > > > 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. > > > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > > requires (at least) de-facto API so applications could set Flow Label > > > > values -- and as such does not exist. If it did (and I believe there's > > > > work in progress), there would *have to be* a normative reference to it). > > > > So, clearly a MUST seems to a big no-no. > > > > > > But this is a statement about what hosts must do to make the flow label > > > useful. > > > > No, that's not correct, or either of us is misunderstanding the paragraph > > above (if so, a wording change is needed). > > > > The nodes (kernel, in particular) are able to mark flows by itself, > > without any interaction from the applications -- so having apps have a > > MUST possibility to influence the flow labeling is undoubtedly useful, but > > certainly not something requiring MUST, considering the current situation. > > > > In simplified translation, the text says that the IP layer is not the > only layer selecting flow label values. This is the way it MUST be: in a > node, which is sourcing labeled packets, the flow label value is in the > same category with other fields of the IPv6 header: clients of the IP > layer (layers above) MUST be able to set the value, if they need to. ... > > Note: I'd argue for MUST myuself if we had had a standard (or even > > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > > year before this being sent to the IESG. > > > > The (this) requirement is not conditional to the existence of an API, or > an API function call mechanism. Rather the API, or the API function > call, or the API function call parameter, is a consequence of this > requirement, which is the way it should be. No, I have to disagree with this approach. In this case, making a normative reference to an API document (which would delay the publication of flow label specification until the API is published) would be OK, but I'm not sure that's what folks would want. For *applications* and application writers (which are also the customers of flow label spec here) requiring that implementations provide any programming interface at all, one specific to the implementation is the worst choice possible. So, if one would like to write portable applications, you'd have to use each implementation-specific programming interface for every implementation. That seems counter-productive and unacceptable, IMO -- but I'd like to hear what application writers would say about that. I agree with the need of a way to have applications to be able to influence the flow label, but a MUST would possibly lead to one of the below: 1) all implementations implementing different programming interfaces; a non-starter for applications 2) implementations not implementing all of the flow label spec, ie. just blatantly ignoring the MUST (compare with the temporary/public address knob in the default address selection, in RFC3484 sect 5r7 -- this was a bad last-minute compromise which nobody have implemented AFAIK) 3) implementations waiting for an API before implementing the flow label spec > > > If you want to standardize a socket API extension that's fine, > > > the Open Group exists for that. However, I believe a MUST is needed. > > > > A MUST without a means is bad practise, IMO. > > > > This sets the rule, from the protocol stack angle, for the flow label > related API, API function call, or API function call parameter(s). The > rule will bring the "means". I guess we disagree on the usability of the API for application writers if the API is not uniform enough. Personally, I view an implementation-specific API for something generic like this useless (as a programmer). > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > > is currently using or has recently used when creating new flows. Flow > > > > Label values previously used with a specific pair of source and > > > > destination addresses MUST NOT be assigned to new flows with the same > > > > address pair within 120 seconds of the termination of the previous > > > > flow. > > > > > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > > > value which was previously used, and send the packet, the operating system > > > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > > > s/reuse/unintentionally reuse/, or some other rewording? > > > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > > we included an algorithm, but the WG wanted it removed, so we removed it. > > > > Yes, the stack can do it easily -- no doubt about that -- but it's > > *wrong*; this is connected to the security issue, below. > > > > There were people that requested this particular behavior. I wonder if they realized the implications. I'm sure that e.g. people focusing on the network part of the flow label would really appreciate having a flow labels guaranteed to be distinct, so their use in QoS and whatever would be a lot simplified, but that ignores the big picture at the expense of looking at only part of the solution space. > So, were you saying earlier that if the text in the draft > > ***MUST ensure that it does not reuse Flow Label values....*** > > were: > > ***MUST ensure that it does not unintentionally reuse Flow Label > values....*** > > it would be OK with you ? I find that acceptable. Extra text in security considerations would still be required, though (as noted later in my message). > > > > methods MUST meet the following basic requirements: > > > > > > > > ==> this and the following points seem a little oddly placed in this memo: > > > > they seem out-of-place, as the rest of the memo seems to concentrate on > > > > entirely different issues. Personally I view specifying how source nodes > > > > should label flows one thing, and the rest entirely another. But I can > > > > live with these, even though I think they're more fit to a non-standards > > > > track document. > > > > > > Then you don't want a change here? > > > > I can live without it -- waiting to hear others' opinions -- but I think > > the source node behaviour is entirely different issue from the network > > treatment. > > Here is another opinion. The two are the essential aspects of the flow > label mechanism: setting the flow label in nodes sourcing packets(1), > and processing flow labels in nodes receiving labeled packets (2) > [packet forwarding nodes]. Note that (2) also semantically includes the destination nodes, not just in-between routers, if you're not careful with the terminology. As I read it, you wrote that as a disagreement, but IMO that sounds very much like a partial agreement to me: that flow labeling consists of two different functions. These functions have entirely different requirements and considerations, but naturally, both are required to implement flow labeling. I was just arguing that "2" and "1+1" still makes "2", but "1+1" could be simpler for those that are only interested in the first or second "1", etc. > > > > 5.1 Theft and Denial of Service > > > > > > > > ==> this section mainly deals with issues relating to forging all of the > > > > source,destination,label three-tuple (exception is the last paragraph, > > > > which deals with a trusted-node-but-untrusted-user/application case), > > > > which protects mainly against a DoS attack (resource depletion). > > > > > > > > This seems to overlook the most important part: the typical model today is > > > > that operators perform differentiation of flows *themselves*: this > > > > document proposes to shift that, *over an administrative boundary*, to the > > > > source nodes, which suddenly become trusted to do the right thing. > > > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > > > The labeling with current "service model" leads to differentiation. I'll > > try to reword it again below. If the "service model" would be such that > > the source node is *not* expected to label flows correctly, I'd certainly > > agree. > > From the point of view of the "operators model", servicing packets based > on packet classification, labeling flows is essentially not different > than setting other packet header fields, which are used for packet > classification, so I do not understand why you see a difference. There > is no intention in the draft to shift the current model to a different > one, to any "administrative body" on the source nodes. The spec very clearly states that flow labeling enables classification based on (src, dst, flow label). That is clearly different than (src, dst, protocol, srcport, dstport). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
