Margaret, The current flow label definition is vague and useless and people designing line-speed ASICs and network processors can't use it.
If it is defined architecturally as an immutable e2e value, there are immediate ways to use it in hardware that will work for any semantics we may later add to it. If we don't define it properly now, it will simply be 20 dead bits for ever. Brian Margaret Wasserman wrote: > > At 02:06 PM 12/20/01 , Tony Hain wrote: > >Absolutely NOT!!! We already have too many mechanisms that > >allow/encourage the value to be modified in route, and this field is the > >only one we have left that can have meaning end-to-end. THERE IS NO > >REASON TO CREATE ANOTHER ONE! We need to take an architectural stand > >here and say that if you want to modify something along the path use the > >DSCP or MPLS or VPN or GRE or your favorite random scheme. > > 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? > > >The > >host/application needs a way to inform anyone along the path that may > >care, 'this set of packets belong together'. If we allow violation of > >that principle simply because the control freaks want to be able to > >modify anything and everything, we might as well give up on ever having > >applications that expect more than random treatment from the network. > > In order for a host/application to _actually_ inform intermediate > routers that a set of packets belong together, we would need to > define a flow label that achieves that goal. > > 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. > > 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. > > 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. > > I don't understand what we gain by trying to do something > in between. > > And, in either case, I don't understand why this would need to > be specified as part of the core IPv6 specifications. > > Margaret > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
