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.NH=> So its must be OOB yes?...which is a key corollary of GMPLS. So is OOB is a key driver then, as it sure is a consequence?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 regionsNH=> Is there a good definition of what a 'GMPLS region' is as I don't know what this means.....is it perhaps one where there is no MPLS?(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.NH=> Are you meaning native ethernet or something else?Considering the discussion, the draft has definitely initiated discussion.NH=> Its sure created some confusion......and I don't think you have really answered Shahram's question, which to remind you was: Why GPMLS and not over MPLS? Can you please be precise as to what are the key drivers/requirements here as I am struggling to grasp the intent. The seemingly obvious ones are that if we have GMPLS we don't need MPLS at all here and we can use an OOB control-plane....is that correct?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.NH=> Since GMPLS is nothing more that an OOB control-plane, and SDH, for example, has its own data-plane OAM which has nothing to do with the control-plane, you must therefore be saying that the OAM is 'whatever is specified for ethernet'.....because there is no MPLS data-plane. Is that right....seems to be?thanks....regards, NeilDeborah
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 LSPsSorry 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 LSPsDimitri,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 LSPsdave - 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 LSPsHi 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