Re: Layer 2 Switching Caps LSPs

[dimitri papadimitriou <dpapadimitriou@psg.com>]

dave - there was a lengthy off-line discussion suggested by the chairs 
intended to explain you the scope of the draft and its relatioship with 
the ethernet data plane (after the question you raised during the f2f 
meeting) - this has been done and we have explained (via a lengthy 
exchange of e-mails) that this document and so the use of gmpls to 
control ethernet frame flows, is not targeting control of bridged 
ethernet environments - if this is not clear from the current document 
introduction we would have also to work on this part of the document - 
therefore, the below reference to MSTP is not in the current scope; 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

thanks,
- dimitri.

David Allan wrote:
> Hi Adrian:
>
> Your suggestion is in a way reasonable but with the caveat that in IEEE
> terms, a bridging topology is currently all VLANs (802.1Q single spanning
> tree) or partitioned into specific ranges (I believe 64 in 802.1s although I
> do not claim to be an expert). 
>
> If the PEs were to implement a bridge function and we were using GMPLS to
> interconnect them, then the control plane should be identifying either all
> VLANs (single spanning tree, which I beleive the draft covers by referring
> simply to Ethernet port) or a VLAN range to be associated with the LSP
> consistent with 802.1s if it is to operate to interconnect bridges defined
> by the IEEE...
>
> I suspect assuming any other behavior (e.g. LSP for single VLAN tag) would
> go outside the boundary of what is currently defined...so alignment with
> 802.1s IMO would be a minimum requirement if we are to consider carrying
> VLAN information in GMPLS signalling....
>
> cheers
> Dave
>
> You wrote....
>
> > Hi,
> >
> > The authors of the draft might like to clarify for the list 
> > exactly what data plane operations they are suggesting. To me 
> > it seems possible that the draft is proposing VLAN ID 
> > *swapping*. But an alternative is that the VLAN ID is used as 
> > a label, but that the same label is used for the full length 
> > of the LSP.
> >
> > Adrian
>
>
>
> .