Subject: Layer 2 Switching Caps LSPs

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Jan 2005 11:46:16 -0000

All,

There is a draft (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we
have discussed at several of the more recent CCAMP meetings, and have
decided that the subject is within scope for our charter.

The questions we have faced have been:
- is the problem well enough articulated?
- is this the solution that the WG wants to pursue?
- is there a high enough level of interest in this work?

If the answer to all three questions is "yes" then we can adopt the draft
as a WG document and move forwards.

Note: I think there are a large number of minor issues to clear up with
this draft, but hopefully this is orthogonal to whether we make this a WG
draft or not.

Thanks,
Adrian

---

From: 조재형 <[email-masked]>
Date: Wed, 26 Jan 2005 16:50:46 +0900

Dear all,

I most welcome the decision that the subject dealt in

Papadimitriou’s draft is within the scope of CCAMP charter.

Regarding the issue of VLAN switching, this is clearly not the feature

defined in IEEE 802.1Q. However, I do not think IETF should

wait until IEEE define new architecture. I am wondering

if the scope of CCAMP work exclude any technology requiring

modification on legacy hardware structure.

If it is not, considering industry needs on high-performance

Ethernet switch, I think it is desirable the scope of work

include both control plane and data plane. However, I also

stress that the extent of work must be discussed and defined

in a separate requirement document prior to architectural work.

I raised this issue in

http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lesrequirement-00.txt,

with some discussion on other candidate technologies.

Unfortunately, I didn’t get enough response on the proposal

to date. Definitely, there are other technologies we can

consider for L2SC interface. I hope people pay attention

on the draft and also draft-jaihyung-ccamp-lesframework-00.txt

Regarding Papadimitriou’s proposal, I have some doubts on

compatibility issue. I think it may not be used with Ethernet

switches allocating VID for different purpose. I am wondering

how VLAN information of customer network can be delivered

across provider network.

Other point to comment is, personally I think it is desirable to

focus just on Ethernet interface. The draft is too heavy

compared to other Ethernet control protocols such as MSTP.

In fact, RSVP and IP routing protocols are all heavy to Ethernet.

Why should ISPs providing just metro-Ethernet service must

know all the unnecessary options devised for TDM and ATM?

I think it will be helpful to industry if CCAMP work on

dedicated, lightweight specification for Ethernet only network.

Thank you

Jaihyung Cho

ETRI, Korea

phone :       042) 860-5514

oversea: +82-42-860-5514

fax:         +82-42-861-5550

-----원본 메시지-----
보낸 사람: "Shahram Davari" <[email-masked]>
보낸 날짜: 2005-01-26 오전 6:25:36
받는 사람: "'Adrian Farrel'" <[email-masked]>, "[email-masked]" <[email-masked]>
참조:
제목: RE: Layer 2 Switching Caps LSPs

Hi,

The only issue that I have is with VLAN switching. Since VLAN switching
is not a standard 802.1Q behavior, it can't be used with existing Ethernet
hardware. Therefore the scope of this draft is not limited to control-plane,
and requires new data-plane that is not defined in IEEE yet.

If the VLAN switching is removed from the draft, I support accepting it as
a WG draft.

Yours,
-Shahram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Sunday, January 23, 2005 6:46 AM
> To: [email-masked]
> Subject: Layer 2 Switching Caps LSPs
>
>
> All,
>
> There is a draft
> (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we

---

From: [email-masked]
Date: Wed, 26 Jan 2005 10:31:03 +0100

Adrian,

For me the answer is affirmative to all three questions. However, it might
be appropriate to expand on the motivations after the introduction in terms
of protocol fit as the current version only provides a functional fit.

Regards,
Bart.

-------- Original Message --------
Subject: Layer 2 Switching Caps LSPs
Date: Sun, 23 Jan 2005 11:46:16 -0000
From: Adrian Farrel <[email-masked]>
To: <[email-masked]>

All,

Thanks,
Adrian

.

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Jan 2005 10:38:01 -0500

Hi Dimitri

> dave - there was a lengthy off-line discussion suggested by 
> the chairs 
> intended to explain you the scope of the draft and its 
> relatioship with 
> the ethernet data plane (after the question you raised during the f2f 
> meeting) - this has been done and we have explained (via a lengthy 
> exchange of e-mails) that this document and so the use of gmpls to 
> control ethernet frame flows, is not targeting control of bridged 
> ethernet environments 

Yes, I have archived that discussion, consumes a reaonsable amount of my
disk space ;-)

- if this is not clear from the current 
> document 
> introduction we would have also to work on this part of the 
> document - 

Yes I do beleive the document needs work to clarify many of the sources of
confusion we discussed, my suggestion is an applicability statement

> therefore, the below reference to MSTP is not in the current 
> scope; 

I think the question is what has utility relative to existing standards,
ability to define an ethernet FEC as either a port (Single spanning tree
topology) or MSTP instance (multiple spanning trees) so that the GMPLS
signalled topology can be resolved to somthing Ethernet understands has
utility.

> 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

Yes, if we are discussing labels and not FECs and a label is required to
discriminate the exsiting flow IMO it should be an MPLS label. This puts us
back towards Deborah's analogy that this is PW signalling (a la dry
martini...my interpretation), if so haven't we already specified the control
plane in another WG?

Dave

---

From: [email-masked]
Date: Fri, 28 Jan 2005 16:48:28 +0100

dave,  the response to your last question (and this was also part of the discussion thread) is the negative - moreover i would like to remember you that the FEC concepts in the present context is not the one you implicitly assume as we are in a RSVP-TE context not an LDP one

see in-line

> control ethernet frame flows, is not targeting control of bridged

Yes, I have archived that discussion, consumes a reaonsable amount of my disk space ;-)

[dp] but was apparetnly not sufficient ;-)

> introduction we would have also to work on this part of the

Yes I do beleive the document needs work to clarify many of the sources of confusion we discussed, my suggestion is an applicability statement

> therefore, the below reference to MSTP is not in the current

I think the question is what has utility relative to existing standards, ability to define an ethernet FEC as either a port (Single spanning tree topology) or MSTP instance (multiple spanning trees) so that the GMPLS signalled topology can be resolved to somthing Ethernet understands has utility.

[dp] the notion of FEC is odd in the present context -we have lengthily consumed this discussion -

> me as long as we are within the scope of the initial motivations

Yes, if we are discussing labels and not FECs and a label is required to discriminate the exsiting flow IMO it should be an MPLS label. This puts us back towards Deborah's analogy that this is PW signalling (a la dry martini...my interpretation), if so haven't we already specified the control plane in another WG?

[dp] see above
Dave

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Jan 2005 08:06:30 -0800

What do you mean by just two sites?

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, January 28, 2005 7:15 AM
> To: David Allan; Shahram Davari
> Cc: [email-masked]
> Subject: Re: Layer 2 Switching Caps LSPs
> 
> 
> Thanks Dave,
> 
> Just one point...
> 
> Is there any difference (from the point of view of the 
> network) between a
> VLAN with just two sites, and an LSP that uses the (same 
> along the whole
> path) VLAN tag to route data?
> 
> Clearly there is a difference in hardware with respect to the 
> way that the
> hardware is programmed from the control plane.)
> 
> Adrian
> ----- Original Message ----- 
> From: "David Allan" <[email-masked]>
> To: "'Adrian Farrel'" <[email-masked]>; "'Shahram Davari'"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, January 27, 2005 9:37 PM
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> > Hi Adrian:
> >
> > Your suggestion is in a way reasonable but with the caveat 
> that in IEEE
> > terms, a bridging topology is currently all VLANs (802.1Q single
> spanning
> > tree) or partitioned into specific ranges (I believe 64 in 802.1s
> although I
> > do not claim to be an expert).
> >
> > If the PEs were to implement a bridge function and we were 
> using GMPLS
> to
> > interconnect them, then the control plane should be 
> identifying either
> all
> > VLANs (single spanning tree, which I beleive the draft covers by
> referring
> > simply to Ethernet port) or a VLAN range to be associated 
> with the LSP
> > consistent with 802.1s if it is to operate to interconnect bridges
> defined
> > by the IEEE...
> >
> > I suspect assuming any other behavior (e.g. LSP for single VLAN tag)
> would
> > go outside the boundary of what is currently defined...so 
> alignment with
> > 802.1s IMO would be a minimum requirement if we are to 
> consider carrying
> > VLAN information in GMPLS signalling....
> >
> > cheers
> > Dave
> >
> > You wrote....
> > > Hi,
> > >
> > > The authors of the draft might like to clarify for the list
> > > exactly what data plane operations they are suggesting. To me
> > > it seems possible that the draft is proposing VLAN ID
> > > *swapping*. But an alternative is that the VLAN ID is used as
> > > a label, but that the same label is used for the full length
> > > of the LSP.
> > >
> > > Adrian
> >
> >
> >
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Jan 2005 08:07:27 -0800

Dimitri,

Could you please clarify this question.

Thanks,
Shahram

> Sent: Thursday, January 27, 2005 3:30 PM
> To: Shahram Davari; [email-masked]
> exactly what
> data plane operations they are suggesting. To me it seems 
> possible that
> the draft is proposing VLAN ID *swapping*. But an alternative 
> is that the
> VLAN ID is used as a label, but that the same label is used 
> for the full
> length of the LSP.
> 
> Adrian
> 
> From: "Shahram Davari" <[email-masked]>
> To: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, January 25, 2005 9:25 PM
> > If the VLAN switching is removed from the draft, I support 
> accepting it
> as
> > a WG draft.
> >
> > Yours,
> > -Shahram
> >

---

From: [email-masked]
Date: Fri, 28 Jan 2005 17:41:46 +0100

sharam, the draft does not propose a specific data plane switching processing, but allows distinction of a mode where the whole flow traversing an interface (port mode) is retrieved at the outgoing interface from a mode allowing tracking of multiple flows traversing the same interface and the most obvious one was the use of the VLAN ID value as it implicitly determines the mapping with the data plane - but as i said clarifications are to be added here because this term did generate some confusion - note also that this draft does not discuss any specific ethernet frame processing

Shahram Davari <[email-masked]>
01/28/2005 08:07 PST

To: "'Adrian Farrel'" <[email-masked]>, [email-masked]
cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

Thanks,
Shahram

> To: "'Adrian Farrel'" <[email-masked]> <[email-masked]>

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Jan 2005 13:39:42 -0500

Hi Adrian:
> network) between a VLAN with just two sites, and an LSP that 
> uses the (same along the whole

If by two sites you mean a link between two NEs, yes there is a difference.

If by two sites you mean a very simple VLAN in the context of a larger
network that may have many other VLANs, I beleive the answer is also yes.

My understanding (and I welcome correction) is that currently any specified
intermediate device that queues and steers traffic on the basis of an
Ethernet VLAN tag is by definition a bridge and it will do P2P and MP2P fan
in exclusively on the basis of VLAN tag, and only inspects the mac address
when there is a choice of more than one output port. 

Further that as specified bridges do not generally provide unique treatment
per VLAN tag, as the number of spanning trees permitted does not correspond
to the entire VLAN range. 

There are also OAM implications etc. associated with such a device being an
Ethernet device. It would be desirable that such a device implemented MIP
(maintenance intermediate point) functionality.

cheers
Dave

> way that the hardware is programmed from the control plane.)
> 
> Adrian
> To: "'Adrian Farrel'" <[email-masked]>; "'Shahram 
> Davari'" <[email-masked]>
> Cc: <[email-masked]>
> > Your suggestion is in a way reasonable but with the caveat that in 
> > IEEE terms, a bridging topology is currently all VLANs 
> (802.1Q single
> spanning
> > go outside the boundary of what is currently defined...so alignment 
> > with 802.1s IMO would be a minimum requirement if we are to 
> consider 
> > carrying VLAN information in GMPLS signalling....
> >
> > cheers
> > Dave
> >
> > You wrote....
> > > Hi,
> > >
> > > The authors of the draft might like to clarify for the 
> list exactly 
> > > what data plane operations they are suggesting. To me it seems 
> > > possible that the draft is proposing VLAN ID *swapping*. But an 
> > > alternative is that the VLAN ID is used as a label, but that the 
> > > same label is used for the full length of the LSP.
> > >
> > > Adrian
> >
> >
> >
> 
> 
>

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Jan 2005 13:54:59 -0500

Hi Dimitri:
 
>  on  the other side, the use of the term "VLAN label" has created some 

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?

Dave

---

From: [email-masked]
Date: Fri, 28 Jan 2005 20:17:44 +0100

dave - see in-line

"David Allan" <[email-masked]>
Sent by: [email-masked]
01/28/2005 13:54 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

> 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

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Jan 2005 14:30:39 -0500

>> 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)

I think this is where we ended up talking past each other a lot last time
around. To me such an abstact construct is more logically akin to a "name"
or "LSP application" which in general terms is the FEC (in general terms,
not LDP specific). And for OAM purposes (for example) is an easier concept
to follow than a label that has no actual data plane instantiation....it is
easier to test consistency when there is a level of indirection between the
LSP setup and the dataplane implementation if the LSP has a globally unique
name....rather than a chain of locally administered abstract values...

IMO the abstract 32 bit value would offer superior clarity to using a VLAN
tag value. IMO a name would be even better...

rgds
Dave

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Jan 2005 11:50:27 -0800

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

Dave

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Jan 2005 12:12:19 -0800

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: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

Dave

---

From: [email-masked]
Date: Fri, 28 Jan 2005 22:06:27 +0100

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

01/28/2005 12:12 PST

To: Shahram Davari <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Sorry Dimitri,

-Shahram
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

-Shahram
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line

Dave

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 28 Jan 2005 16:09:55 -0600

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Sorry Dimitri,

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Shahram Davari
	Sent: Friday, January 28, 2005 2:50 PM
	To: [email-masked]'; David Allan
	Cc: [email-masked]'; 'Adrian Farrel';
[email-masked]
	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: [email-masked]
[mailto:[email-masked]]
		Sent: Friday, January 28, 2005 2:18 PM
		To: David Allan
		Cc: [email-masked]';
[email-masked]'; 'Adrian Farrel'; Shahram Davari;
[email-masked]
		Subject: RE: Layer 2 Switching Caps LSPs

		dave - see in-line 

		To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
		cc: "[email-masked]'" <[email-masked]>,
"'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'"
<[email-masked]>, [email-masked]
		bcc: 
		Subject: RE: Layer 2 Switching Caps LSPs

		
		> 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

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Jan 2005 14:24:14 -0800

Deborah,
 
If GMPLS is used as a replacement of Ethernet Spanning Tree protocol, could you please explain what kind of OAM is needed to run on these so-called LSPs? Ethernet OAM or MPLS OAM? 
 
-Shahram

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Friday, January 28, 2005 5:10 PM
To: Shahram Davari; [email-masked]; David Allan
Cc: [email-masked]; Adrian Farrel; [email-masked]
Subject: 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: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari

Sorry Dimitri,

 
-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

Dave

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 28 Jan 2005 15:49:51 -0800

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, [email-masked] 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
>
>
>To: Shahram Davari <[email-masked]>, Dimitri 
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>
>cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" 
><[email-masked]>, [email-masked]
>bcc:
>Cc: [email-masked]'; [email-masked]'; 'Adrian 
>Farrel'; Shahram Davari; [email-masked]
>cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" 
><[email-masked]>, "'Shahram Davari'" <[email-masked]>, 
>[email-masked]
>bcc:
>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

---

From: <[email-masked]>
Date: Sat, 29 Jan 2005 00:01:56 -0000

Deborah I am a little unclear on a few things here....please see
in-line:
 
 -----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: 28 January 2005 22:10
To: Shahram Davari; [email-masked]; David Allan
Cc: [email-masked]; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Hi Shahram,

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 regions  
NH=> 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, Neil 
 
Deborah

  _____  

Sorry Dimitri,

 
-Shahram

-----Original Message-----

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]';
'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, "'Adrian
Farrel'" <[email-masked]>, "'Shahram Davari'"
<[email-masked]>, [email-masked]
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs

> 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

---

From: [email-masked]
Date: Sat, 29 Jan 2005 01:09:59 +0100

indeed the L2LSP approach does not target the two below listed category of equipment (i.e. .1q bridges and IP/MPLS LSRs) - so what is the exact question/issue from this perspective ? now the point is not only in reducing the overhead - but on the underlying operations when those are not required - on the other side it could be interesting that you extend a bit on the scalability of EoMPLS - to which scaling dimensions are you referring here ?

ps: concerning the last point i suggest a further reading of RFC 3945 (this could also help sorting the question on how GMPLS applies to packet LSPs)

Ali Sajassi <[email-masked]>
01/28/2005 15:49 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari <[email-masked]>
cc: Shahram Davari <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

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

Sorry Dimitri,

-Shahram
-----Original Message-----
From: [email-masked] mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

-Shahram
-----Original Message-----
From: [email-masked] mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line

Dave

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 28 Jan 2005 17:06:04 -0800

At 01:09 AM 1/29/2005 +0100, [email-masked] wrote:

>indeed the L2LSP approach does not target the two below listed category of 
>equipment (i.e. .1q bridges and IP/MPLS LSRs) - so what is the exact 
>question/issue from this perspective ?

So the question I'd like to ask is what type of end-user applications you 
have in mind that would require the VLANs to be stitched together this way?

>now the point is not only in reducing the overhead - but on the underlying 
>operations when those are not required

In this case, I'd like to know the details of how maintainability (OAM) and 
reliability (redundancy) aspects of the operations are addressed ?

>- on the other side it could be interesting that you extend a bit on the 
>scalability of EoMPLS - to which scaling dimensions are you referring here ?

To number of connections which is independent from number of VLANs. BTW, 
when talking about VLAN stitching, you are only limited to 4K VLANs per 
interface (4K connections) even if that interface is 10GE, so why do you 
want to impose such limitations in the aggregation (and/or core) networks.

-Ali

>ps: concerning the last point i suggest a further reading of RFC 3945 
>(this could also help sorting the question on how GMPLS applies to packet LSPs)
>
>cc: Shahram Davari <[email-masked]>, Dimitri 
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>, 
>"[email-masked]'" <[email-masked]>, "'Adrian Farrel'" 
>without any obvious benefit. Is saving a few byte in the header the 
>primary objective in here ?

---

From: [email-masked]
Date: Sat, 29 Jan 2005 11:44:47 +0100

indeed the L2LSP approach does not target the two below listed category of equipment (i.e. .1q bridges and IP/MPLS LSRs) - so what is the exact question/issue from this perspective ?
So the question I'd like to ask is what type of end-user applications you have in mind that would require the VLANs to be stitched together this way?

=> what do you mean by end-user in this context ? this said, the first target is to address ethernet terminating hosts but not limited to (it has been pointed during the previous f2f meeting that the initial version covers point-to-point ethernet frame flows)

now the point is not only in reducing the overhead - but on the underlying operations when those are not required
In this case, I'd like to know the details of how maintainability (OAM) and reliability (redundancy) aspects of the operations are addressed

=> concerning ETH OAM it is not addressed as part of this document (ETH OAM is addressed via IEEE and the present document let's the possibility for making of any suitable mechanism it delivers - this is consistent with the approach we have taken here where we specifically address control aspects)

- on the other side it could be interesting that you extend a bit on the scalability of EoMPLS - to which scaling dimensions are you referring here ?
To number of connections which is independent from number of VLANs. BTW, when talking about VLAN stitching, you are only limited to 4K VLANs per interface (4K connections) even if that interface is 10GE, so why do you want to impose such limitations in the aggregation (and/or core) networks.

=> well this has been already discussed as part of this thread - there is no such "VLAN stitching" operation and with in the next revision (in terms of number) we will have the possibility to reach 2^32

-Ali

-Ali

---

From: Shahram Davari <[email-masked]>
Date: Mon, 31 Jan 2005 06:38:40 -0800

Dimitri,
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, January 29, 2005 5:45 AM
To: Ali Sajassi
Cc: [email-masked]; Ali Sajassi; Shahram Davari; David Allan; [email-masked]'; 'Adrian Farrel'; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

In order to implement the Ethernet VLAN L2SC of your draft, what kind of Hardware is needed?
Can you reuse existing standard hardware or you need a different hardware?

The ETH OAM defined in IEEE assumes Connectionless behavior. For example the loopback or trace-route assumes that every intermediate node knows how to send the reply back to the ingress. Since GMPLS creates
a Connection-oriented network, I am not sure how it can reuse ETH OAM !!!!!

How can you reach 2^32 ? And if it is not VLAN stitching, then could you simply explain the operation? aren't you sending label request from downstream to upstream? I am confused !!!!!!!!!! 

-Ali

-Ali