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? Other than that, using the label for 6LSAs would just spare the need to encapsulate the packet with MPLS. Regards, -- Ran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
