Re: GMPLS support for Ethernet switching

[Dimitri.Papadimitriou@alcatel.be]

hi - see in-line (i put gels mailing list in cc.)




"Fahad Dogar" <fahad.dogar@gmail.com>
Sent by: owner-ccamp@ops.ietf.org
24/04/2006 16:36
 
        To:     ccamp@ops.ietf.org
        cc: 
        Subject:        GMPLS support for Ethernet switching


Hi all,

I have few questions related to the draft on GMPLS support for
Ethernet switching by D.Papadimitriou et al.:

i) The draft discusses that connection oriented ethernet is suitable
for metro and core networks where ethernet is used for transport. I am
not too clear on the architecture in which ethernet LSPs would be
used. Are we considering point to point type ethernet connections
between switches/routers  i.e. where the bandwidth is not shared.
Example: Two peer routers connected through an ethernet interface, so
effectively complete bandwidth is available.

[dp] this would be either a port based ethernet LSP, supported today
in RFC 3473/3471 no specific issue or a frame based ethernet LSP
this is where different labeling techniques have been proposed; 

Or are we talking about multiple switches in a GMPLS enabled cloud
that are part of the SAME LAN and  bandwidth  is shared. I am not sure
how  bandwidth reservations would be done in this sceneario.

[dp] we are not talking about LAN environments 

ii) Please correct me if I am wrong but it seems that the traffic
engineering benefits of GMPLS support for Ethernet are also available
in Ethernet over MPLS. (I am considering that connection oriented
Ethernet is used in metro/core networks only). However, by providing
GMPLS support for Ethernet we are able to do away with IP/MPLS layer
and thus we can have an all Ethernet network (with only ethernet
switches). Is this the primary reason for using GMPLS support for
Ethernet rather than Ethernet over MPLS? Can someone comment on this?

[dp] this approach intends to deliver source routed TE label switched
path establishment (through control plane upgrade) for metro/aggregation
and core Ethernet networks 

iii) The draft discusses various options for ethernet label, all of
which seem to require modification in the forwarding plane of
Ethernet? Is this something that can implemented easily i.e. change in
forwarding plane? Why can't we consider MAC address or VLAN tag as the
label?

[dp] this question has been lengthily debated on the GELS mailing list,
(i refer you there as well as to last meeting discussion material)

[dp] in brief, and as of today, SVID labels (using SVID translation) and 
MAC+SVID label (using SVL switches) are two feasible techniques for the 
.1ad environments

Thanks in advance,
Fahad