Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 22 Jan 2008 13:27:53 -0600

CCAMP,
 
The DT proposed in their meeting presentation for their architecture and
framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
 
We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.
 
Thanks,
Deborah

---

From: "Nurit Sprecher" <[email-masked]>
Date: Tue, 22 Jan 2008 22:09:37 +0200

Hi,

I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft.

In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt
also proposed that their draft is accepted as a WG draft. Naturally, I
am in favor of this as well. Can we ask feedback for this draft as well?

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 21:28
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

CCAMP,

Thanks,

Deborah

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 22 Jan 2008 14:24:42 -0600

Hi Nurit,
 
We will poll one-by-one to ensure separation;-)
 
Deborah

From: Nurit Sprecher [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2008 3:10 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

Hi,

Best regards,

Nurit

CCAMP,

Thanks,

Deborah

---

From: "Nurit Sprecher" <[email-masked]>
Date: Tue, 22 Jan 2008 22:28:36 +0200

Hi Deborah,

I am in favor of this as well :-)

Best regards,

Nurit

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2008 22:25
To: Nurit Sprecher
Cc: [email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

Hi Nurit,

Deborah

Hi,

Best regards,

Nurit

CCAMP,

Thanks,

Deborah

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 22 Jan 2008 16:04:19 -0500

support for WG draft..
 
/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 2:28 PM
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
 
We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft.
 
Thanks,
Deborah

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 22 Jan 2008 16:13:00 -0500

In Favor,
 
Thanks,
Don 

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
	Sent: Tuesday, January 22, 2008 2:28 PM
	To: [email-masked]
	Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

	CCAMP,
	 
	The DT proposed in their meeting presentation for their
architecture and framework document to be accepted as a WG draft:

	We received a couple of comments in the meeting, we would
appreciate additional feedback on the list. Please express your support
(or otherwise) for this I-D to become a WG draft.
	 
	Thanks,
	Deborah

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 22 Jan 2008 22:16:00 +0100

All,

> appreciate additional feedback on the list.

The document states:

"The L2SC Interface Switching Capabilities MUST NOT be used to represent
interfaces capable of supporting Eth-LSPs. Interface Switching
Capability specific TE information may be defined as needed to support
the requirements of a specific Ethernet Switching Service Type."

[...]

"It is expected that there will be no case where an Eth-LSP will be
signaled, or an Eth-LSP supporting interface will be represented, using
the L2SC switching type/capability. A new switching type/capability is
required to avoid any potential current usage of the L2SC switching
type/capability in support of Ethernet."

This is explicit statement that GMPLS per RFC 3945 is not applicable.
So, it is much more than just an additional codepoint, as the control
plane behaviour is to be defined for this codepoint. So, it is the open
door for a new control plane behaviour. 

so, let's have a more basic questioning before jumping into the single
alternative resulting from this doc.:

- either it is GMPLS for Ethernet architecture and then what exist in
current RFCs should be applicable (because i do not see any rationale
for L2SC def. departure for Ethernet frame processing);

- or not it is X for Y architecture, where X is an IP control protocol
based some potentially on some existing GMPLS blocks and Y is not
compatible with the existing definition of Eth frame processing.

In the latter case, i do not know how this WG can deal with such case
(from the control plane perspective).

-d.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of BRUNGARD, 
> DEBORAH A, ATTLABS
> Sent: Tuesday, January 22, 2008 8:28 PM
> To: [email-masked]
> appreciate additional feedback on the list. Please express 
> your support (or otherwise) for this I-D to become a WG draft.
>  
> Thanks,
> Deborah
>

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 22 Jan 2008 16:34:58 -0500

Hi Dimitri

The text you quote was put in the architecture/ framework, not to
exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which
has been there for many years and may be in use. 

Perhaps the working needs to be adjusted but I don't think it is a major
issue.

Regards,
Don 

> [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> Sent: Tuesday, January 22, 2008 4:16 PM
> To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2008 16:50:25 -0500

Don,
         I agree 100%.  Furthermore there is no statement in the 
draft that 3945 doesn't apply, in fact it explicitly says just the 
opposite.  The reason for the statement in question is simply as you 
say, and to ensure full ETH-LSP definition and interoperable 
operation a new switching type/capability is required.

It's really not such a bid deal or major change.

Lou

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 22 Jan 2008 22:52:55 +0100

Don,

then two things are missing that this new xSC is not resulting in a
control plane departing from RFC 3945 and this xSC is not part
overlapping with L2SC. 

you are thus in the alternative: GMPLS for Y architecture, where Y is
not compatible with the existing definition of Eth frame processing per
L2SC ? is that correct.

thanks,
-d.

> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Tuesday, January 22, 2008 10:35 PM
> To: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; 
> [email-masked]

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 22 Jan 2008 23:11:21 +0100

Lou

what i am concerned with: is that the doc extends applicability of GMPLS
to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that
make sense ?

what's needed instead of hiding behind terms is to state GMPLS for Y,
where Y includes the set of Ethernet-based techno's under development at
places as indicated in the doc itself. instead of inducing by a title
such as "GMPLS for Ethernet" that this doc supersedes any previous work
in that
space.

-d.

> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Tuesday, January 22, 2008 10:50 PM
> To: Don Fedyk
> Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; 
> [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2008 17:28:08 -0500

I have no objection to adding "Updates: 3945" to the document header 
and matching 3945's category.

Lou

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 22 Jan 2008 23:44:49 +0100

thus the question is whether or not to ask for a change CCAMP "common
control" in DCAMP "differentiated control" per technology ? 

we never have had a techno inducing a base building block change (GMPLS
being a generalisation of MPLS-TE). i'm afraid that generalized LSP,
generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would
simply be unapplicable as known today and thus the corr. base protocol
specs unapplicable. at the end the term "GMPLS" would be emptied of any
real substance.

it's a choice but let's ask the questions from the right perspective.

-d. 

> From: Lou Berger [mailto:[email-masked]] 
> Sent: Tuesday, January 22, 2008 11:28 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; 
> [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2008 19:08:41 -0500

We've always had different switching type/capability in 
GMPLS.  Nothing new here.

L2SC was always underspecified (e.g., covers both ATM and Ether), is 
currently used by some for different purposes, and doesn't allow 
unique identification of switching capabilities of an interface.  I 
*really* don't see the unique identification of an interface's 
Ethernet switching function as any different from what is done for 
today for the other types or as any big deal or change in GMPLS 
direction or architecture.

but, that's just my perspective.

Lou

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 23 Jan 2008 10:52:50 +0100

In favor.
Attila

	CCAMP,

	 
	 
	Thanks,
	Deborah

---

From: "Anders Gavler" <[email-masked]>
Date: Wed, 23 Jan 2008 13:36:05 +0100

In favor of this!

Anders Gavler
Acreo AB
Electrum 236
SE - 164 40 Kista
Phone: +46 8 632 77 29
Homepage: http://www.acreo.se

>>> "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> 2008-01-22 20:27
>>>
CCAMP,
 
The DT proposed in their meeting presentation for their architecture
and
framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt 

Thanks,
Deborah

---

From: "David Sinicrope" <[email-masked]>
Date: Wed, 23 Jan 2008 07:30:08 -0600

Support for WG draft.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 2:28 PM
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

CCAMP,

 
Thanks,
Deborah

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 23 Jan 2008 09:47:48 -0500

In favor.
 
Hamid.

	CCAMP,

	 
	 
	Thanks,
	Deborah

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 23 Jan 2008 07:12:56 -0800

In favor.
Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
> and framework document to be accepted as a WG draft:

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 23 Jan 2008 17:31:10 -0500

Also in favor.

Cheers,
Andy

> additional feedback on the list. Please express your support (or otherwise)
> for this I-D to become a WG draft.
>
> Thanks,
> Deborah

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 24 Jan 2008 01:04:33 +0100

the question triggered by this poll is the following: if GMPLS for
Ethernet is not inline with the existing stacks what is the value of
GMPLS re-use ? what's the value to borrow the term GMPLS without its
substance ? and in practice, the issue is, if it is not GMPLS per RFC
3945, what's the value compared to any other native control stack that
would be developed at IEEE for inst. for these techno's.

you quote:

> L2SC was always underspecified (e.g., covers both ATM and Ether),

additional specification does not result in departing from the initial
definition but refinement of the initial definition (definition of a
sub-set not a side definition).

probably the document is not mature enough to respond to the
tie-breaker: what about the FIT of GMPLS for Ethernet but not within the
L2SC space (as defined today) ? but in the meantime preclude any allowed
use of GMPLS per IETF RFCs to Ethernet if they do not comply with a new
WG i-d would create a precedent in the history of this WG with really
disastrous impact (including on other application of GMPLS)

we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to
assess consequences before going one way or another and under which
conditions.

-d.

> Sent: Wednesday, January 23, 2008 1:09 AM
> > > > > > > "The L2SC Interface Switching Capabilities MUST 
> NOT be used
> > > > > > > to represent
> > > > > > > plane behaviour is to be defined for this 
> codepoint. So, it
> > > > > > > is the open
> Please express

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 23 Jan 2008 21:51:11 -0500

Hi Dimitri

The document clearly states:

"The intent of this document is to reuse and align with as much of the
   GMPLS protocols as possible.  For example reusing the IP control
   plane addressing allows the existing signaling, routing, LMP and path
   computation to be used as specified. Additions are made only to
   accommodate features of Ethernet that are not already supported by
   GMPLS.  The GMPLS protocols support a set of tools for hierarchical
   LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms
   support a variety of networks from peer to peer to UNIs and NNIs."

So your question comes down to why we make the statement on L2SC?  Like
Lou said when we discussed this we thought that L2SC came with baggage
and was not precise. The switching capabilities would be specified in
documents that address the particular Ethernet data plane.  It is true
that if there was a valid Ethernet data plane that could use L2SC
unambiguously it should fit under the architecture.  At any rate getting
this right is something that can be accomplished when this is a WG
draft. 

Regards,
Don 

> From: PAPADIMITRIOU Dimitri 
> [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 7:05 PM
> To: Lou Berger
> Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS; 
> [email-masked]
> > > > > > > > required to avoid any potential current usage 
> of the L2SC
> > > > > > switching
> > > > > > > > This is explicit statement that GMPLS per RFC 
> 3945 is not
> > > > > > applicable.
> > > > > > > > So, it is much more than just an additional 
> codepoint, as
> > > > > > the control
> > > > > > > > > architecture and framework document to be 
> accepted as a
> > > > > > WG draft:
> > > > > > > > >
> > > > > >
> > > >

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 24 Jan 2008 09:23:21 +0100

Hi Don

so, what's wrong with the definition of L2SC then ? from 3945:

   2. Layer-2 Switch Capable (L2SC) interfaces:

      Interfaces that recognize frame/cell boundaries and can switch
      data based on the content of the frame/cell header.  Examples
      include interfaces on Ethernet bridges that switch data based on
      the content of the MAC header and interfaces on ATM-LSRs that
      forward data based on the ATM VPI/VCI. 

as such the statement "A new switching type/capability is required to
avoid any potential current usage of the L2SC switching type/capability 
in support of Ethernet." is made but never explained why in the doc -

now coming down to the first sentence you indicated from your doc.

"The intent of this document is to reuse and align with as much of the
GMPLS protocols as possible.... Additions are made only to accommodate 
features of Ethernet that are not already supported by GMPLS."

It should have been something like: "This doc. details the GMPLS
protocol suite architecture for Ethernet. Extensions are made only 
to accommodate features of Ethernet that are not already supported 
by GMPLS RFCs and inline with its architecture defined in RFC 3945."

otherwise the result would be progressively that all GMPLS RFCs are
cracked down to accommodate Ethernet.

thanks,
-d.

> Sent: Thursday, January 24, 2008 3:51 AM
> To: PAPADIMITRIOU Dimitri; Lou Berger
> Cc: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent 
> redefining
> > > > > > > L2SC, which
> > > > > > > >Perhaps the working needs to be adjusted but I 
> don't think
> > > > > > > it is a major
> > > > > > > >issue.
> > > > > > > >
> > > > > > > >Regards,
> > > > > > > >Don
> > > > > > > >
> > > > > > > > > - either it is GMPLS for Ethernet 
> architecture and then
> > > > > > > what exist in
> > > > > > > > > current RFCs should be applicable (because i 
> do not see
> > > > > > > any rationale

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Jan 2008 11:00:34 -0500

All,

I think this level of theoretical/hypothetical discussion can 
continue ad infinitum.  I propose we leave the text as is, and 
revisit the decision (and text) in the context of the anticipated 
mechanism specific documents if and when someone propose to use L2SC.

WG-chairs,
         Does this make sense?  Is it acceptable?

Thanks,
Lou

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 25 Jan 2008 10:03:29 +0100

I support this as WG even if I'd like to have the Dimitri questions addressed, may in next WG version of the doc.

LBR

Diego

From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: martedì 22 gennaio 2008 20.28
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

CCAMP,

Thanks,

Deborah

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 24 Jan 2008 14:40:00 +0000

Dimitri,

I find your mail somewhat puzzling.

You appear to be saying that GMPLS as per RFC 3945 is set in stone and
nothing should modify/enhance the behaviour as specified in RFC3945 which
implies that when RFC3945 was produced the crystal ball was working
extremely well and all possible future applications of the technology had
been correctly envisaged.  I don't believe that was the case.

> would be developed at IEEE for inst. for these techno's.

If we ignore the peer model (which is unworkable in reality IMO), the value
is obvious - significant reuse of existing code, techniques, knowledge,
skills, etc.

So, we should develop the control plane from scratch because Ethernet
requires a few modifications/enhancements (which I believe are backwards
compatible) to RFC3945 - that IMO is ridiculous.

Ben

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 25 Jan 2008 12:36:23 +0100

ben 

> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> Sent: Thursday, January 24, 2008 3:40 PM
> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 
> Dimitri,
> 

this is not what i say. i am concerned in stating beforehand
RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the
doc. does not deliver any tangible explanation.

> compatible) to RFC3945 - that IMO is ridiculous.

so you seem to agree with me. departing from RFC 3945 makes
little sense. it would have been interesting to see the doc
delivering a FIT of the GMPLS protocol arch. blocks and, in
particular, label allocation and distribution for Ethernet.

thanks,
-dimitri.

---

From: <[email-masked]>
Date: Fri, 25 Jan 2008 13:26:40 -0000

Dimitri....see if this helps...in-line

> Sent: 25 January 2008 11:36
> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > nothing should modify/enhance the behaviour as specified in RFC3945 
> > which implies that when RFC3945 was produced the crystal ball was 
> > working extremely well and all possible future applications of the
> > technology had

NH=> Is your problem that you cannot differentiate between the 3 network
modes (of co-cs, co-ps and cl-ps)?  If so then looking at the work on
unified modelling in SG15/Q12 may help you.  But to give a more specific
example here:  We can take an Ethernet traffic unit and create either a
cl-ps and co-ps layer network based on this...in fact one can image 3
different layer network cases here:
-	traditional Etherent which does not have a directed routing
function, ie uses MAC learning, broadcast unknown, STP...this is a cl-ps
layer network
-	Ethernet with an IGP providing a directed routing
function....this is also a cl-ps layer network, but it is different to
the one above
-	Ethernet with a directed routing component (centralised or
distributed, ie IGP) and a signalling component that can create
connections....this would be a co-ps layer network.

These are all based on a similar traffic unit, however they form 3 quite
different layer networks (and in functional architecture terms we would
say 'the Characteristic Information is different in the 3 cases').

Now GMPLS is applying a reusable set of CP components (which is a very
good thing, as Ben points out below) for any co-cs or co-ps mode layer
network.  So we are setting up *connections* in either a space, freq or
time dimension of resource, and it is these 3 resource dimensions that
create the differences in parameters...however, the notion of a
connection is common across all these resource dimensions.  GMPLS does
not apply to the cl-ps mode, as it plainly does not have connections.

That is at least how I look at this issue.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 25 Jan 2008 13:54:23 +0000

> doc. does not deliver any tangible explanation.

OK, now I understand your concerns.  So, I think we're (you, me & the docs
authors) are actually in agreement in our thinking, just maybe that the
original wording in the doc was not the best.  I'm sure the authors can do
some wordsmithing once it is a WG doc.

> particular, label allocation and distribution for Ethernet.

Departing from RFC3945 for the sake of it makes little sense.  If there is a
justifiable reason to depart then that is fine IMO.

Ben

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 25 Jan 2008 20:49:41 +0100

neil, 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, January 25, 2008 2:27 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> NH=> Is your problem that you cannot differentiate between 
> the 3 network modes (of co-cs, co-ps and cl-ps)?  

my concern wrt specific point you bring is that the today definition in
RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with
local labels or domain-wide labels or any other equivalent to "co-ps")
does not result into a different definition than what's in. on the other
side, i do not see how would apply GMPLS for connectionless/bridged
Ethernet.  

note also that GMPLS induces label from the interface and link
characteristic (i.e. there is no "label type" in the label/label request
object.

> If so then looking at the work on

well indeed, and this is the reason why i do not see any reason to
open the space for a different set of mechanisms that would result
from this new interface switching definition.

thanks,
-d.

---

From: <[email-masked]>
Date: Sat, 26 Jan 2008 08:45:44 -0000

Thanks Dimitri...I think I am understanding your concern/point a little
better now......please see further comments below (I've snipped the mail
to the salient bits):

> > DP=> this is not what i say. i am concerned in stating beforehand
> my concern wrt specific point you bring is that the today 
> definition in RFC 3945 for L2SC,
NH=> I really don't think you should get too hung-up on what folks have
called things here, ie L2SC.  Stick with the physics.  Much of the
misunderstandings I've encountered over many years stem from the OSI Ref
Model, and the wrong impression it gives that there is only one/single
'L3 network'....it's a myth.  ALL networks (any mode) are 'L3' in the
OSI sense.  Folks also tend to make the wrong association IP=L3 and
since IP is cl-ps then cl-ps=L3.....then they come to Ethernet and
because this is often used as a server to IP they call it 'L2' (OSI
sense).  But since native Ethernet is cl-ps then surely this must also
be L3?  Of course it is L3...all networks are!

The only thing that truly matters is whether the resource you are
partitioning and labelling is time, freq or space in nature....and it's
then up to us as engineers how well we go about functionally
specifying/equipping the layer networks we create in each of the 3
modes.  And most critically here one can ONLY get deterministic resource
assignment across a network if one creates a connection object.  I could
carry on here and go into great detail of exactly how all this works and
why we have the 3 network modes, but I'll refer you to the work on
unified modelling under Q12 of SG15.  

Bottom-line:  Look to the real world of networking and ask yourself why
it is we see the 3 network modes....it really is not chance, but simply
comes down to the physics of partitioning/labelling a finite resource
(time/freq/space) domain....don't get hung-up on names for things
without such a scientific basis.

> GMPLS for Ethernet (with local labels or domain-wide labels 
> or any other equivalent to "co-ps") does not result into a 
> different definition than what's in. on the other side, i do 
> not see how would apply GMPLS for connectionless/bridged Ethernet.
NH=> I agree with you.  GMPLS is a suite of CP functional components for
use in co mode layer networks.

But my position is one based on an understanding of the physics at play
here.  This is why I tried to point out in my prior mail the importance
of understanding that we can take an Ethernet traffic unit (packet) and
apply either a cl-ps or co-ps mode behaviour to it (as a network).  This
is our choice.  This does however require that specific functional
fields of the traffic unit are present....in essence one can take
short-cuts with labelling (ie remove information) in the co modes (eg
omit SA, use link-local DA proxy labels that get swapped per hop)
because we have a connection as a network object, but one can't take
these short-cuts in the cl-ps mode because we don't have a connection.
I'll assume this is obvious to everyone.....but it does require (from
information considerations) that folks properly understand what a
connection is (and also what it is not).

But be very clear on this point:  If we use a common traffic unit to
create a cl-ps mode layer network and a co-ps mode layer network then
these are 2 quite distinct layer networks, ie they do not operate in the
same layer network space.....put more simply, we have to be careful not
to mix-up their traffic units.  The key points here are all to do with
what we call 'characteristic information' in func arch terminology, and
specifically how one assigns/manages resource.  This is perhaps less
clear to see in the co-ps mode than the co-cs mode when compared to the
cl-ps mode.  That is:  In the co-cs mode labelling and resource
assignment are fixed/deterministic actions, but in the co-ps mode they
are decoupled actions....and whilst this flexibility has some
advantages, it also carries a responsibility that lies with those
designing co-ps mode layer networks not to screw things up, eg one can
create merging constructs which result in complex resource and
fault/perf management problems for network operators...actually the
resource problem is intractable, and the only practical solution is to
throw BW at the problem.

regards, Neil

---

From: Loa Andersson <[email-masked]>
Date: Tue, 29 Jan 2008 14:04:24 +0100

Dimitri,

it is possible that you have a point that needs to be discussed,
but is this really something that should stop us from adopting the
doc as a working group document.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

---

From: "Roland Elverljung" <[email-masked]>
Date: Wed, 30 Jan 2008 09:58:47 +0100

In favor.

Regards
Roland Elverljung

>>> On 2008-01-22 at 20:27, in message
<[email-masked]>,
and

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 30 Jan 2008 10:14:37 +0100

loa,

i think the main point as ccamp is whether or not we poll for a change
or a continuation inline with RFC3945 -- when the present doc. states: 

  "It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.  A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.

[...]

  "The L2SC Interface Switching Capabilities MUST
   NOT be used to represent interfaces capable of supporting Eth-LSPs."

it raises three issues:

a) what was the previous L2SC def. per RFC 3945 meant for if not for use
also in GMPLS Ethernet context ?

b) why a "new one" ? 

this is not explained.

c) what is the "new one" implying in terms of GMPLS ?

for inst. in the intro "The intent of this document is to reuse and
align with as much of the GMPLS protocols as possible." leaves open the
issue of what as much as possible means.

and on the other "Additions are made only to accommodate features of
Ethernet that are not already supported by GMPLS." so, how shall i
interpreet the first sentence now ? inline with point a) and b) ?

the doc. in WG I-D status or not is not going to provide an answer to
these questions. sentences and statements in the doc. contradict each
other.

thanks,
-d.

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Tuesday, January 29, 2008 2:04 PM
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> definition in

---

From: "Howard Green" <[email-masked]>
Date: Wed, 30 Jan 2008 12:08:30 +0100

Hi
Dimitri seems to me to be making a very abstract and legalistic point.
 
The reason why this work is important is that the IEEE has been evolving
Ethernet to give it carrier class features, in respect of scalability,
OAM, and (with 802.1Qay) the possibility to use an external control
plane. Some of these features will very likely require or enable added
value from extensions to the functionality of GMPLS - for example, as
has already  been suggested, the addition of functionality for creating
the OAM associations. Therefore this will likely not be the same as the
possible use suggested in RFC3945, which may (at least in theory) have
been implemented somewhere. Therefore the suggestion in the draft seems
to make sense. I can't really see what important principle is being
defended by the insistence upon L2SC, which, as Don Fedyk stated, was
always somewhat underspecified.

This is not something to be debated in the abstract. The work in ccamp
should allow sensible extension of functionality where it adds value,
and this needs to be discussed on a case by case basis. Therefore we
should make it a working group document and get on with it.

regards Howard Green

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of PAPADIMITRIOU Dimitri
Sent: 30 January 2008 10:15
To: Loa Andersson
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

loa,

[...]

it raises three issues:

b) why a "new one" ? 

this is not explained.

thanks,
-d.

> it is possible that you have a point that needs to be discussed, but 
> is this really something that should stop us from adopting the doc as 
> a working group document.
> 
> /Loa
> 
> >>> this is not what i say. i am concerned in stating beforehand RFC 
> >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc. 
> >>> does not deliver any tangible explanation.
> >> NH=> Is your problem that you cannot differentiate between the 3 
> >> network modes (of co-cs, co-ps and cl-ps)?
> > 
> >> unified modelling in SG15/Q12 may help you.  But to give a more 
> >> specific example here:  We can take an Ethernet traffic unit and 
> >> create either a cl-ps and co-ps layer network based on this...in 
> >> fact one
> can image 3
> >> function, ie uses MAC learning, broadcast unknown, STP...this is a 
> >> cl-ps layer network
> >> These are all based on a similar traffic unit, however they form 3 
> >> quite different layer networks (and in functional architecture 
> >> terms we would say 'the Characteristic Information is different in 
> >> the 3 cases').
> >>
> >> network.  So we are setting up *connections* in either a space, 
> >> freq or time dimension of resource, and it is these 3 resource
> dimensions that
> >>>> If we ignore the peer model (which is unworkable in reality IMO),

> >>>> the value is obvious - significant reuse of existing code, 
> >>>> techniques, knowledge, skills, etc.
> >>>>
> >>> so you seem to agree with me. departing from RFC 3945 makes little

> >>> sense. it would have been interesting to see the doc delivering a 
> >>> FIT of the GMPLS protocol arch. blocks and, in particular, label 
> >>> allocation and distribution for Ethernet.
> >>>
> >>> thanks,
> >>> -dimitri.
> >>>> Ben
> >>>>
> >>>>
> >>>
> > 
> > 
> > 
> 
> 
> --
> Loa Andersson
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 30 Jan 2008 15:27:30 -0000

All,

We appear to be seeing good support for this document, and that suggests 
that we should take it forward, but I would like to at least make an attempt 
to close down the point raised by Dimitri. As Howard points out, this is in 
danger of becoming a legalistic discussion, but I've never been one to 
refuse the opportunity to back to first principles...

In RFC 3945 we have...

   A link may support a set of encoding formats, where support means
   that a link is able to carry and switch a signal of one or more of
   these encoding formats.  The Switching Type indicates then the type
   of switching that should be performed on a particular link for that
   LSP.  This information is needed for links that advertise more than
   one type of switching capability.

   Nodes must verify that the type indicated in the Switching Type is
   supported on the corresponding incoming interface; otherwise, the
   node must generate a notification message with a "Routing
   problem/Switching Type" indication.

Now, the question is whether we are introducing one (or more) new Switching 
Type and whether we need to be able to distinguish between them. Suppose 
(for the sake of argument) that we will over time introduce the ability to 
switch Ethernet frames under GMPLS control based on several different label 
concepts:
- 802.1Qay
- destination MAC only
- destination MAC and VLAN tag
It is likely that a GMPLS-capable Ethernet switch will want to support more 
than one of these switching paradigms on any single interface. So we have to 
decide how, during signaling, we indicate which type of LSP is requested.

There are plenty of ways that this could be done. Currently we use a 
combination of the parameters of the Generalized_Label_Request object and 
the Sender_TSpec object. The TSpec is used in the case of TDM (RFC 4606) and 
Ethernet to distinguish the Switching Granularity 
(draft-ietf-ccamp-ethernet-traffic-parameters).

As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt causes a 
problem because it appears to say that *no* Ethernet Label Switched Path 
(Eth-LSP) can be set up using an L2SC Switching Type.
   It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.

However, the draft also says...
   A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.

And this clearly says that L2SC *is* allowed.

Can we fix this by agreeing some new wording?

==
OLD
   This document does not define any specific format for an Eth-LSP
   label. Rather, it is expected that service specific documents will
   define any signaling and routing extensions needed to support that
   specific Ethernet service.  Depending on the requirements of a
   service, it may be necessary to define multiple GMPLS extensions,
   e.g., label formats, switching types, and Traffic Engineering (TE)
   routing extensions.  It is expected that all such extensions will be
   consistent with this document. It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.  A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.
NEW
   This document does not define any specific format for an Eth-LSP
   label. Rather, it is expected that service specific documents will
   define any signaling and routing extensions needed to support that
   specific Ethernet service.  Depending on the requirements of a
   service, it may be necessary to define multiple GMPLS protocol
   extensions and procedures. It is expected that all such extensions
   will be consistent with this document.

   It is expected that key a requirement will be to describe label
   formats and encodings. It may also be necessary to provide a
   mechanism to identify the required Ethernet service type in signaling
   and a way to advertise the capabilities of Ethernet switches in the
   routing protocols. These mechanisms must make it possible to
   distinguish between requests for different paradigms including new,
   future, and existing paradigms.

   The Switching Type and Interface Switching Capability Descriptor
   share a common set of values and are defined in [RFC3945], [RFC3471],
   and [RFC4202] as indicators of the type of switching that should
   ([RFC3471]) and can ([RFC4202]) be performed on a particular link for
   an LSP. The L2SC switching type is available for use by
   implementations performing layer 2 switching including ATM and
   Ethernet. To support the continued use of that switching type by
   existing implementations as well as to distinguish between each new
   Ethernet switching paradigm, a new switching type is expected to be
   needed for each new Ethernet switching paradigm that is supported.
==

Thanks,
Adrian

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 30 Jan 2008 11:39:27 -0500

Hi Adrian

This sounds good to me and certainly it was not our intent to confuse
these points.  If the new text can us forward that would be great. 

Thanks,
Don  

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 30, 2008 10:28 AM
> To: [email-masked]
> As I see it, the text at issue in 
> draft-gmpls-ethernet-arch-00.txt causes a

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 30 Jan 2008 18:23:00 +0100

> From: Howard Green [mailto:[email-masked]] 
> Sent: Wednesday, January 30, 2008 12:09 PM
> To: PAPADIMITRIOU Dimitri; Loa Andersson

receive my total disagreement. an individual submission that asks to
change an existing RFC requires discussion and particular attention (in
part., when it is the protocol arch. document) - if this not possible
then probably you have to write also a doc. asking for changing the IETF
proces - and then you come back with your individual submission.
  
> plane. 

no one i think question this. and i don't think the poll is on this
specific point. CCAMP or even IETF at large is not an authority to
decide upon IEEE technos.

> Some of these features will very likely require or enable added
> has already  been suggested, the addition of functionality 
> for creating the OAM associations. 

indeed, and your colleague has already received a list of comments to be
addressed before seeing any way forward w/ the proposed approach. 

> Therefore this will likely not be the same as the
> possible use suggested in RFC3945, which may (at least 
> in theory) have been implemented somewhere. 

the exact problem, i mentionned a couple of times. your own comment
shows that one may use GMPLS differently but may i ask WHY ? and what's
the implications ?

> Therefore the suggestion in the draft seems to make sense. 

why ?

> I can't really see what important principle is being

THE reason is that an interface SC or a related functionality has never
resulted in a specific change in the base protocol building blocks.
GMPLS is a generalized approach not a differentiated approach per
interface.

actually your last statement is not correct (L2SC is well specified in
RFC 3945) AND by the way yours does not at all better specify it.

-d.

---

From: <[email-masked]>
Date: Wed, 30 Jan 2008 18:13:34 -0000

I personally think you are making a mountain out of a molehill here
Dimitri.  And I thought I had explained why there are differences in the
treatment of layer networks depending on their mode...I clearly did a
bad job.  Sure GMPLS is a generic OOB CP suite of protocols, but the
details of the parameters used used to describe the layer network being
considered will depend on:
-	for the co-cs mode whether we are dealing with resources which
are either regular time-slices, freq or space
-	for the co-ps mode there is only irregular time-slices.

And the labelling of such resource partitions is different in each case
too...so just like it is impossible to have a common (ie single instance
of) CP running 'IP to Optics' (or any functional component for that
matter) it is impossible to have an identical set of parameters
describing each mode....this is just the physics and the way it is.  The
co-ps mode has the richest scope for 'variation' in the DP labelling of
traffic units (this is more than simply a destination proxy label
BTW....this was a point I saw Adrian alluding to)....and one can even
violate the rules of connections here and really screw-up any notion of
deterministic resource management anyway.

regards, Neil 

> Sent: 30 January 2008 17:23
> To: Howard Green; Loa Andersson
> Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R; 
> receive my total disagreement. an individual submission that 
> asks to change an existing RFC requires discussion and 
> particular attention (in part., when it is the protocol arch. 
> document) - if this not possible then probably you have to 
> write also a doc. asking for changing the IETF proces - and 
> then you come back with your individual submission.
>   
> no one i think question this. and i don't think the poll is 
> on this specific point. CCAMP or even IETF at large is not an 
> authority to decide upon IEEE technos.
> 
> > Some of these features will very likely require or enable 
> added value 
> > from extensions to the functionality of GMPLS - for example, as has 
> > already  been suggested, the addition of functionality for creating 
> > the OAM associations.
> 
> indeed, and your colleague has already received a list of 
> comments to be addressed before seeing any way forward w/ the 
> proposed approach. 
> 
> the exact problem, i mentionned a couple of times. your own 
> comment shows that one may use GMPLS differently but may i 
> ask WHY ? and what's the implications ?
> 
> THE reason is that an interface SC or a related functionality 
> has never resulted in a specific change in the base protocol 
> building blocks. GMPLS is a generalized approach not a 
> differentiated approach per interface.
> 
> actually your last statement is not correct (L2SC is well 
> specified in RFC 3945) AND by the way yours does not at all 
> better specify it.
> 
> > align with as much of the GMPLS protocols as possible." leaves open 
> > the issue of what as much as possible means.
> > 
> [mailto:[email-masked]] 
> > > >>> On Behalf Of
> > > PAPADIMITRIOU Dimitri
> > > >>>> requires a few modifications/enhancements (which I 
> believe are
> > > >>>> backwards

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 30 Jan 2008 19:32:32 +0100

adrian 

> Sent: Wednesday, January 30, 2008 4:28 PM
> To: [email-masked]

i can live with this at the condition that a statement is added about
either we do ack assessment on further implications or do not imply any
change on other GMPLS building blocks (note: there is a main difference
between change and extensions).

thanks,
-d.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 30 Jan 2008 18:39:02 -0000

Dimitri,
Thanks.

Editors,
Please submit your I-D as draft-ietf-ccamp-gmpls-ethernet-arch-00.txt making 
the changes described below.

Thanks,
Adrian

----- Original Message ----- 
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 30, 2008 6:32 PM
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

adrian

thanks,
-d.

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Jan 2008 16:47:29 -0500

Adrian,
         This seems workable to me.  Also, I don't think it was the 
intent of the draft to preclude use of L2SC for current applications, 
but rather to use new values for the new types of ether switching.  I 
think your text disambiguates this issue.

Lou

At 10:27 AM 1/30/2008, Adrian Farrel wrote:
>All,
>
>We appear to be seeing good support for this document, and that 
>suggests that we should take it forward, but I would like to at 
>least make an attempt to close down the point raised by Dimitri. As 
>Howard points out, this is in danger of becoming a legalistic 
>discussion, but I've never been one to refuse the opportunity to 
>back to first principles...
>
>In RFC 3945 we have...
>
>Now, the question is whether we are introducing one (or more) new 
>Switching Type and whether we need to be able to distinguish between 
>them. Suppose (for the sake of argument) that we will over time 
>introduce the ability to switch Ethernet frames under GMPLS control 
>based on several different label concepts:
>- 802.1Qay
>- destination MAC only
>It is likely that a GMPLS-capable Ethernet switch will want to 
>support more than one of these switching paradigms on any single 
>interface. So we have to decide how, during signaling, we indicate 
>which type of LSP is requested.
>
>combination of the parameters of the Generalized_Label_Request 
>object and the Sender_TSpec object. The TSpec is used in the case of 
>TDM (RFC 4606) and Ethernet to distinguish the Switching Granularity 
>As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt 
>causes a problem because it appears to say that *no* Ethernet Label 
>Switched Path (Eth-LSP) can be set up using an L2SC Switching Type.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 31 Jan 2008 00:40:15 +0100

neil, 

> Sent: Wednesday, January 30, 2008 7:14 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Dimitri.  

the segmentation of SCs we have in RFC 3945 is sufficient to address
your below decomposition. you have to consider that when a new techno is
to be supported by GMPLS, stacks are not going to change the full
engine/stack per specific technology -

> And I thought I had explained why there are differences in the
> bad job.  

don't worry, we very well understand the difference between a
circuit-switched and packet-switched network. 

> Sure GMPLS is a generic OOB CP suite of protocols, but the

L2SC is in the latter.
 
> violate the rules of connections here and really screw-up any 
> notion of deterministic resource management anyway.

does that imply change in the def. of L2SC as defined in RFC 3945 ? or
is it an add-on that is not impacting other RFC's mechanisms ? my
understanding is the latter but never got an answer whether or not this
is indeed the case (and proposal on how to spell this in the doc.)

the addition to adrian's text is a way out. it is to be followed by
discussions because the protocol aspects remain open. 

thanks,
-d.

> > > > >>>>> 3945, what's the value compared to any other 
> native control
> > > > >>>> stack that

---

From: <[email-masked]>
Date: Thu, 31 Jan 2008 10:35:49 -0000

Thanks Dimitri,

You asked a question below...which I have extracted/inserted below for
ease of reference:
> The

NH=> I assume you are referring to the definition of a connection (wrt
to what L2Sc really means)?  A connection can only have a single source
and it must not re-order traffic units...a subtle corollary of this is
that a connection can only have a single traffic/QoS class.  This means
connections can only be p2p or p2mp in construction.  This is a
necessary requirement for resource assignment determinism.  Assuming one
does not violate these rules (and you can't in the co-cs mode) then
there is no need to include a SA label in the traffic units of a
connection....the parent connection object carries that semantic.
Further, because a connection represents a chosen set of link
connections (hops) between the source and the sink(s)then:
-	in the case of a p2p connection the label carrying the DA
information need only be link connection unique (across the population
of clients served by the lower layer network connection on that link),
ie it can be swapped hop by hop
-	in the case of a p2mp connection the label carrying the DA is a
'name' (proxy) that respresents a set of real DAs.

These labelling short-cuts is all works fine until there are
misconnectivity defects.  But if one wants to make the network more
robust to such defects (without even using any adjunct OAM flows at all)
then including the SA in each traffic unit and not-swapping the DA in
the case of p2p connections (ie just use the real DA and not a proxy for
it) has many benefits.  Now if you start with a traffic unit that was
originally designed for cl-ps operation and use it for a co-ps operation
then the above labelling information is already present, ie one has no
need to take short-cuts on removing the SA or making the DA only link
connection unique....the cl-ps mode cannot allow such short-cuts as
there is no connection that provides this information.

Now if one chooses to create mp2p merging constructs and there is also
no SA information then you have lost information on where the traffic
unit came from.....and this lost information must be provided by some
other means (usually an appeal to a higher layer entity => which if
cl-ps (eg IP) allows SA recovery directly or if not cl-ps (eg ATM, etc)
requires a further label is added to provide this information, eg PW
label in MPLS).  But this is only dealing with the loss of SA
information caused by merging....we still have the issue that merging
constructs cannot have deterministic resource allocation.

I'm not sure that answers your question, because it assumes the above is
understood (implicit?) in the definition of what L2SC really means....I
suspect the above considerations have not really been taken into
account.

regards, Neil

> Sent: 30 January 2008 23:40
> To: Harrison,N,Neil,DMF R; [email-masked]; [email-masked]
> Cc: Niven-jenkins,B,Ben,DMF R; [email-masked]; 
> the segmentation of SCs we have in RFC 3945 is sufficient to 
> address your below decomposition. you have to consider that 
> when a new techno is to be supported by GMPLS, stacks are not 
> going to change the full engine/stack per specific technology -
> 
> details of 
> > the parameters used used to describe the layer network being
> does that imply change in the def. of L2SC as defined in RFC 
> 3945 ? or is it an add-on that is not impacting other RFC's 
> mechanisms ? my understanding is the latter but never got an 
> answer whether or not this is indeed the case (and proposal 
> on how to spell this in the doc.)
> 
> the addition to adrian's text is a way out. it is to be 
> followed by discussions because the protocol aspects remain open. 
> 
> thanks,
> -d.
> 
> > regards, Neil
> > 
> > > > The reason why this work is important is that the IEEE has been 
> > > > evolving Ethernet to give it carrier class features, in 
> respect of
> > > scalability,
> > > > Therefore this will likely not be the same as the possible use 
> > > > suggested in RFC3945, which may (at least in theory) have been 
> > > > implemented somewhere.
> > > 
> defended by 
> > > > the insistence upon L2SC, which, as Don Fedyk
> > > stated, was
> > > > a) what was the previous L2SC def. per RFC 3945 meant 
> for if not 
> > > > for use also in GMPLS Ethernet context ?
> > > > 
> > > > b) why a "new one" ?
> > > > 
> > > > this is not explained.
> > > >