The flow label must be kept e2e is my interpretation. Also I don't believe routers or SPs should be resetting Traffic Class and that may be a bug if this is not the case. /jim
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Kit Plummer > Sent: Monday, April 25, 2005 11:37 AM > To: Ran Liebermann > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: Flow Label consistency question > > > On Apr 25, 2005, at 8:23 AM, Ran Liebermann wrote: > > > Hi Brian and all, > > > > On 25/04/05, Brian E Carpenter wrote: > > > >> Until 6LSA explains how it will restore the label to its > >> original value, or the IETF changes its mind about immutability > >> of the label, this just isn't going to happen. I think that's > >> why the 6LSA people wrote their recent draft. > >> > > > > On this you're right. Unless a new standard will obsolete > RFC 3697 the > > label has to be restored to the original value. > > But this is exactly the point - there is no apparent necessity to > > restore the original value. If it should be used for QoS the value > > should only mean something to nodes on the path of the flow, because > > after it reaches it's destination then QoS is not important anymore > > (but anyhow we have the Traffic Class byte for that). If it > should be > > used for LSAs/TE the value shouldn't matter to the final destination > > again but only to nodes in the flow's path. If it should be used for > > some sort of a signalling to the destination - why shouldn't this > > signalling be embedded in upper layers data? > > > > The only reason for the value of be kept e2e is if this value should > > signal something to routers in the path of the flow (the reason why > > not including the value in upper layers) and still be used by the > > destination for something (for example - so that the > destination would > > know what value the source put in there in order to insert > a new value > > for returning traffic which has a meaning that's derived from the > > former value of the original data). Can you think of an application > > for that? > > Lower-level Flow(data) classification. Think isolated (or not), > military networks. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
