RE: Layer 2 Switching Caps LSPs

["David Allan" <dallan@nortelnetworks.com>]

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

-> more precisely the draft does not mandate any specific representation at
the data plane 
> level (so the last statement goes a step beyond my statement) - in
particular this 
> representation does not assume a modification of the ethernet frame format
- this follows the 
> approach of RFC 3471 where the wavelength label for instance is simply a
32-bit value that is 
> interpreted locally (after negotiation) but yes this abstraction does not
mandate an exact 
> 1:1 representation with the ethernet data plane (in fact the initial
document suggested one 
> such representation but it seems that using specific terms creates some
confusion)

I think this is where we ended up talking past each other a lot last time
around. To me such an abstact construct is more logically akin to a "name"
or "LSP application" which in general terms is the FEC (in general terms,
not LDP specific). And for OAM purposes (for example) is an easier concept
to follow than a label that has no actual data plane instantiation....it is
easier to test consistency when there is a level of indirection between the
LSP setup and the dataplane implementation if the LSP has a globally unique
name....rather than a chain of locally administered abstract values...

IMO the abstract 32 bit value would offer superior clarity to using a VLAN
tag value. IMO a name would be even better...

rgds
Dave