Hi Dimitri:
> on the other side, the use of the term "VLAN label" has created some
> confusion; therefore, in a next release i will simply refer
> to a "label"
> of 32 bits (unstructured) because the intention was (and still is) to
> find an easy way to map the control of the ethernet frame
> flows on each
> device they traverses without making any assumption on how
> this flow is
> processed inside each node at the data plane level (note: on label
> values, RFC 3946 took an equivalent approach - for circuits - where
> sonet/sdh multiplexing structures have been used to create unique
> multiplex entry names i.e. labels - this concept is here applied for
> "virtual" circuits), so, if the working group is willing to
> enter into a
> data plane oriented discussion to clarify the behaviour(s) onto which
> the present approach would be potentially applicable this is
> fine with
> me as long as we are within the scope of the initial motivations
So if I understand correctly there is an abstract label that represents a flow at an intermediate device but with making no representations as to how the flow transits the device. As the abstract label is not tied directly to any real implementation but is merely a useful identifier to allow two LSHs of the LSP to be tied together, So it is not a label in the sense that there is not a logical dataplane identifier in the packet encapsulation, nor does it correspond to a timeslot etc. Do I have this right?
Dave