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

RE: Layer 2 Switching Caps LSPs

Hi Shahram,
 
Thanks for all the interest, as Dimitri doesn't seem to be available today, I'll do my best French to answer-
 
The use of GMPLS for Ethernet is a very different application than Ethernet over MPLS. It not only provides a control plane which may be used for L2SC, it also provides the capability to support an end-to-end L2 LSP automated set up across GMPLS regions (e.g. Ethernet/GFP_SONET which I recalled mentioned on an earlier mail). The GMPLS architecture document describes the benefits for using GMPLS with PSC and L2SC. This draft was not intended to introduce any new switching capabilities than already discussed in gmpls-arch, RFC3471, RFC3473. We hoped with the draft to be proactive in detailing the use of GMPLS signaling for L2 LSPs (with the hopes of preventing mis-interpretations). We all are aware of the current market interest on Ethernet. Considering the discussion, the draft has definitely initiated discussion.
 
Dave - also thanks - I'll let Dimitri answer in detail, though one comment on Ethernet OAM. The use of GMPLS as a control plane for Ethernet is the same as GMPLS for SONET (or GMPLS for LSC) with regards to data plane monitoring.
 
Deborah

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; 'Dimitri.Papadimitriou@alcatel.be'; David Allan
Cc: 'dpapadimitriou@psg.com'; 'Adrian Farrel'; ccamp@ops.ietf.org
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