[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Layer 2 Switching Caps LSPs


There are two categories of Ethernet switches out there:

1) pure L2 switches - existing IEEE (.1q) bridges
2) L2/L3 switches - capable of both bridging and MPLS/IP switching (including support for EoMPLS)

Considering the current L2/L3 switches can support PtP Ethernet services end-to-end in a scalable way using EoMPLS, then the question is why do we need yet another alternate mechanism to provide the same end service without any obvious benefit. Is saving a few byte in the header the primary objective in here ?
It should be noted that the proposed use of GMPLS control plane is not compatible with either of the above two category of switches and thus cannot be leveraged by them.

-Ali
 
At 10:06 PM 1/28/2005 +0100, Dimitri.Papadimitriou@alcatel.be wrote:

this a vast topic that can be answered in several ways - however one short response can be why (when you are not in an IP/MPLS environment) is there any rationale to mandate an MPLS transport network to carry Ethernet payload while techniques exist to achieve the same level of control using GMPLS (*) without the burden of having to consider the cost of an additional IP/MPLS data plane by using directly an Ethernet data plane - one example (among many) is the possibility to use the MAC layer directly (over an Ethernet PHY for instance) without having to consider an ETH-over-PW-over-MPLS environment where at the end you will have to carry the MPLS packets over another data link layer that could be the ETH MAC layer itself ?

(*) i shoud say even better because the GMPLS mechanisms and added value for packet (PSC) networks are (still) not widely considered as the de-facto control plane for such environments even if we hope this will be the case with the (MPLS to GMPLS) migration phase for PSC networks that is going to be (hopefully) in the next revision of the CCAMP charter - this said the control plane associated to PW is still restricted to LDP therefore i am not sure this is ever going to achieve the same level of control and capabilities than those considered in the present L2LSP context


Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ccamp@ops.ietf.org
01/28/2005 12:12 PST

To: Shahram Davari <Shahram_Davari@pmc-sierra.com>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <dallan@nortelnetworks.com>
cc: "'dpapadimitriou@psg.com'" <dpapadimitriou@psg.com>, "'Adrian Farrel'" <adrian@olddog.co.uk>, ccamp@ops.ietf.org
bcc:
Subject: RE: Layer 2 Switching Caps LSPs


Sorry Dimitri,

Let me correct my previous email:

What is the application driving the change of the Ethernet switch control-plane to GMPLS.  Why not just do Ethernet over MPLS?

-Shahram
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: 'Dimitri.Papadimitriou@alcatel.be'; David Allan
Cc: 'dpapadimitriou@psg.com'; 'Adrian Farrel'; ccamp@ops.ietf.org
Subject: RE: Layer 2 Switching Caps LSPs


Dimitri,

What the application deriving changing the Ethernet switch data-plane to GMPLS.  Why not do Ethernet over MPLS?

-Shahram
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: 'Dimitri.Papadimitriou@alcatel.be'; 'dpapadimitriou@psg.com'; 'Adrian Farrel'; Shahram Davari; ccamp@ops.ietf.org
Subject: RE: Layer 2 Switching Caps LSPs



dave - see in-line

"David Allan" <dallan@nortelnetworks.com>
Sent by: owner-ccamp@ops.ietf.org
01/28/2005 13:54 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "'dpapadimitriou@psg.com'" <dpapadimitriou@psg.com>, "'Adrian Farrel'" <adrian@olddog.co.uk>, "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>, ccamp@ops.ietf.org
bcc:
Subject: RE: Layer 2 Switching Caps LSPs


Hi Dimitri:

>  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

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)


Dave