RE: Frameformat in a l2cs gmpls rnvironment.

[Heiles Juergen <juergen.heiles@siemens.com>]

Dear Jaihyung,

the discussion now goes too much into implementations, however I would like to add my comments/questions. 

Regards

Juergen



> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr] 
> Sent: Monday, July 25, 2005 1:40 PM
> To: Heiles Juergen; per@defero.se
> Cc: ccamp@ops.ietf.org
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> 
> 
.....
> 3. use lower 3 bytes of MAC address for L2 label encoding.
>  
> 
> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> - MAC forwarding table and VLAN forwarding table. 
> Bridge control protocols, such as GARP, GVRP, GMRP, 
> manipulate one of the two dataplane entities.
> 
> Similarly, option 1 and 3 are about which one of two 
> dataplane entities 
> GMPLS protocol should control on behalf of bridge control protocols. 
> The two proposals do not intend to modify bridge behavior 
> seriously, such as MAC learning, aging, filtering. 
> Therefore, the approaches 1 and 3 are in the scope of CCAMP.

Even so your option 3 may not change the hardware it totaly changes the forwarding behaviour as it redefines the meaning of a MAC address. The MAC address is a end station address that identfies the source and sink of the MAC frame. In your proposal it will be used as link local label. It would be the same as if MPLS would use a dedicated IP address range as lable instead of its own label.
What will happen with the original MAC address when you enter such a GMPLS Ethernet domain? Will you add a new "MAC header"?

.......
> 
> The benefit of L2SC switch is explained in section 4 of 
> <draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt>
> 
> Overall objective is improving scalability, traffic engineering (TE) 
> characteristics of 802.1 bridge that it can be reliable, manageable 
> enough to replace some core routers.

This is also provided by Ethernet over MPLS even with label stacking.

> The switching technique you mentioned above, such as 
> Ethernet over MPLS as defined by PWE3 and L2VPN,
> are all actually router based technology, however this
> work is based on simple bridge architecture.
> Cost-effectiveness is the key differentiator.
>  
This is what I hear often and what I mean with "we still call it Ethernet as it will be cahep and simple as todays Ehternet".
In the end the same functionality is needed: lable lookup, label swapping, signaling protocol, routing protocol, discovery protocol, ...
So from the functionality and architecture point of view no difference exists.
One advantage compared to Ethernet over MPLS I see, is that MPLS has to be again mapped into Ethernet for transport. This addtional Ethernet layer is not needed.
In your response to Richard you mention to use a simpler routing for Ethernet in this enviroment using dynamic learning like in Ethernet. How about a unified GMPLS control plane and restoration. Will you introduce another spanning tree?



>

...