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]
--------------------------------------------------------------------
