Margaret Wasserman wrote: > Hmmm... I've apparently hit a nerve here. But, I still don't > I get it. What goals would we further by taking "an architectural > stand" on this issue? What value would this change add to the > existing standards?
Locking the value to end-to-end immutable adds value to the process because there is no other mechanism for an application to assure that every router along the path that chooses to may see its intent. All the current mechanisms allow random administrative policies to change the message from the origin, so why would an application writer bother setting a value that he has no way of knowing that it will reach the intended remote target? > In my opinion, we have two choices: > > (1) Define these 20-bits of the IPv6 header so that they > can be used by any (or many different) flow > management system(s). > (2) Define specific semantics for this field that can be > used by intermediate routers to optimize packet > processing, without an external flow-management > system. > > It isn't possible to do both at once. You are assuming that every router along the path is part of the same administrative system and would react consistently to the marking. It is perfectly reasonable for my local administrative domain to have an interactive system to manage the values, then have some intermediate domain use a set of canned rules about src/dst/dscp/fl to achieve a specific service, and finally have a prior administrative arrangement with the remote domain to treat the packets consistently with the origin domain. If the intermediate domain is allowed to modify the bits there is no way for the remote domain to know the origin's intent. > To achieve (1), we should include only the rules required to keep > non-flow-managed nodes from interfering with mechanisms that use > this field -- those rules are already in RFC 2460. I don't think > that we should restrict this field any more than is absolutely > necessary. I agree with the last statement, but restricting the field as architecturally end-to-end immutable IS NECESSARY. If people want to mangle bits along the path, use the DSCP which is specifically designed for that purpose. > To achieve (2), we should define how routers will identify a > _single_ flow using only this field. In my opinion, this would > involve some mechanism for the routers to understand the flow > lifetime. This should be defined to be safe across source host > and router re-boots, etc. Again I agree, but the specific mechanism I would leave to a WG focused on signalling or other interactions that would manage state. > And, in either case, I don't understand why this would need to > be specified as part of the core IPv6 specifications. See first answer above ... Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
