Ran Liebermann wrote: > 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.
The 6LSA BS is just that. People want an MPLS label without having to do the work of building an MPLS network. Get over the thought that there is only one policy entity on the path and realize that if some router mucks with the FL then the next policy decision will be based on invalid bits. The Flow is e2e, and the label that describes that flow is also e2e. > 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 WTFO??? QoS is potentially important all the way up the stack. Just because you don't see the value does not mean that a stack will not prioritize packet handling after the packets are received. > (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? Signalling is needed at every policy decision point along the path, including the receiver. The DSCP is mutable and the FL is not. For consistent policy decisions there has to be a set of bits that are exactly as set at the origin. > > 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? Consider an app that has multiple data streams running over different ports. A receiver might use those for bundling during stack processing. > > Other than that, using the label for 6LSAs would just spare the need > to encapsulate the packet with MPLS. MPLS is a localized function. IP is about traversing multiple administrations and types of L2 media. 6LSA is nothing more than a way to break an end to end architecture by trying to put localized L2 semantics in the end to end header. Get over it. If you want local label semantics build an MPLS network. For those that need end to end capabilities use IP and don't mangle the headers. Tony > > Regards, > -- > Ran. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
