Subject: RE: Layer 2 Switching Caps LSPs

From: "David Allan" <[email-masked]>
Date: Thu, 27 Jan 2005 16:37:34 -0500

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 28 Jan 2005 01:35:03 +0100

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:
> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Jan 2005 12:15:26 -0000

Thanks Dave,

Just one point...

Is there any difference (from the point of view of the network) between a
VLAN with just two sites, and an LSP that uses the (same along the whole
path) VLAN tag to route data?

Clearly there is a difference in hardware with respect to the way that the
hardware is programmed from the control plane.)

Adrian
----- Original Message ----- 
From: "David Allan" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>; "'Shahram Davari'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 27, 2005 9:37 PM
Subject: RE: Layer 2 Switching Caps LSPs