Subject: Frameformat in a l2cs gmpls rnvironment.

From: Pär Mattsson <[email-masked]>
Date: Fri, 22 Jul 2005 11:36:44 +0200 (CEST)

Hi all.
After reading the draft
(draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) and thinking
for awhile on different ways to implementing this, i was wondering what
alternatives there is for the framformat for this. I understand that one
option is using TPID=8100, but what became of the lokal significant label,
and that all switches should be able to switch current ethernet format at
the same time. How to distinguish between GMPLS and VLAN ?
Do anybody have any comment on this ?

Regards.
Per

---

From: Heiles Juergen <[email-masked]>
Date: Fri, 22 Jul 2005 15:17:19 +0200

GMPLS for SONET/SDH has no impact on the SONET/SDH data plane. It introduces a control plane for connection setup instead of a network management based connection setup. GMPLS for Ethernet can work in the same way. Ethernet as such is cl, but VLANs are setup and GMPLS can provide a control plane for VLAN setup. The Ethernet data plane is not changed and MAC address learning and forwarding is still be done within a VLAN. So no change to the Ethernet data plane. No GMPLS traffic is introduced, it is still VLAN traffic.
Introducing a dedicated GMPLS label for Ethernet (GMPLS traffic) goes beyond GMPLS as a control plane technique.

Regards

Juergen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 12:05 PM
> To: Pär Mattsson
> Cc: [email-masked]
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> 
> Per and Dimitri,
> 
> I would like to come down stronger than that, for me it is
> a very strong requirement that the same switch can handle
> both VLANs and GMPLs trafic correctly. I can't dsee how that
> could be done if using the VLAN tpid to indicate GMPLS
> traffic.
> 
> /Loa
> 
> Pär Mattsson wrote:
> >>hi par, one of the possibilities that has been considered 
> to cope with
> >>this requirement is to use a dedicated TPID for the Ethernet labeled
> >>frames; this would allow differentiated processing with non-labeled
> >>framesthanks.
> > 
> > 
> > That seems to make more sence. If that frame is to be sized 
> like a 802.1q
> > frame. There is not that much space left to a label. Or is 
> the demand to
> > use jumboframes ?
> > Has there been any discussion on labelstacking, and mainly 
> where to place
> > the information?
> > 
> > Regards.
> > Per
> > 
> > 
> > 
> 
> 
> -- 
> 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: [email-masked]
Date: Fri, 22 Jul 2005 16:03:13 +0200

hi juergen,

if well understand your point of view, you would be in favor of setting up path without introducing any specific indication in the data plane Ethernet frame flow

more precisely, once the "logical path" is setup using the control plane, the forwarding behaviour would remain unchanged from legacy Ethernet behaviour (i.e MAC address learning and forwarding based on MAC DA) in this case, the control plane function replaces the VLAN id configuration performed today manually on a per interface basis ? - please confirm

now, i would interested to know what in your view would be the role of 802.1d and related in this context (also there are several levels of interaction possible here)

Heiles Juergen <[email-masked]>
Sent by: [email-masked]
07/22/2005 15:17 ZE2

To: Loa Andersson <[email-masked]>, Pär Mattsson <[email-masked]>
cc: [email-masked]
bcc:
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Regards

Juergen

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 22 Jul 2005 13:19:53 -0400

Dimitri,

The question is simple: is it possible today to statically provision L2LSPs that could, say, support e2e QoS? If not, may be it is to early to discuss aspects of dynamic provisioning of such LSPs? Is it possible/reasonable, in your opinion, to "detail how forwarding information can be exchanged via the control plane (and then installed)" without having in mind "a specific forwarding behavior"?
How do you know which forwarding information is needed for the forwarding nobody has defined yet?
The other question is do we need at all e2e QoS, route control, fast recovery? Sounds like exciting idea, but does all that commercially make sense? So, I guess, we need two things before we can move forward:
a) validation of the idea by the providers;
b) definition of the data plane behavior;

Igor
  ----- Original Message ----- 
  From: [email-masked] 
  To: Igor Bryskin 
  Cc: Mack-Crane, T. Benjamin ; Adrian Farrel ; Pär Mattsson ; Loa Andersson ; [email-masked] 
  Sent: Friday, July 22, 2005 12:21 PM
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  igor - i am not sure which point they exactly have - the purpose of this document is to detail how forwarding information can be exchanged via the control plane (and then installed) not to define a specific forwarding behaviour

  thanks,

  - dimitri.

  "Igor Bryskin" <[email-masked]>
  Sent by: [email-masked]
  07/22/2005 11:10 AST

  To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, Pär Mattsson <[email-masked]>, "Loa Andersson" <[email-masked]>
  cc: <[email-masked]>
  bcc: 
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  I think Ben and Juergen have a point here. There is nothing that could be dynamically provisioned that could not be also provisioned by management. In other words data plane is the King here. We need data plane standard(s) on how we encode a label, whether we need a label stack or not, how the labeled traffic is supposed to be treated, how labeled traffic co-exist with non-label traffic, etc. This is something that not for CCAMP to define. Take for example TDM networks. GMPLS only provides a way to dynamically provision G.707 networks. Hence there is a need in parallel standardization activities in ITU. Only after that we can discuss how all that could be dynamically provisioned, that is the aspects of control plane. 

  Igor
  ----- Original Message ----- 
  From: Mack-Crane, T. Benjamin 
  To: Adrian Farrel ; Pär Mattsson ; Loa Andersson 
  Cc: [email-masked] 
  Sent: Friday, July 22, 2005 10:23 AM
  Subject: RE: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  I think Juergen has raised an important question.  How frames are labeled (and the related data plane forwarding behavior) is not defined by the control plane.  The control plane serves to provision the data plane, not define it.  In the framework draft it is not clear what data plane standards are covered by the stated control plane requirements.  Some references should be supplied.  In any case, the labeling and forwarding behavior should be defined by these referenced standards, not by GMPLS.

  (I am assuming definition of new data plane standards is out of scope for CCAMP.)

  Regards,
  Ben

------------------------------------------------------------------------------

  From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
  Sent: Friday, July 22, 2005 8:37 AM
  To: Pär Mattsson; Loa Andersson
  Cc: [email-masked]
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  It is always refreshing how engineers jump straight to a discussion of the solution :-)

  Perhaps we can assume that the framework draft is a good representation of the problem space, and that we are ready to start discussing the solutions.

  One (perhaps the only?) significant question to answer is how the frames will be labelled. This question is one we must come to as soon as we are confident that the requirements need to be addressed at all.

  As has been pointed out, there are several possibilities and to pick from these we need to understand:
  1. Do we need to support explicit label stacking?
     Note that this is not supported in TDM, LSC or FSC.
  2. Do we need to be able to control (perhaps through an
     external signaling controller) existing hardware and 
     install LSPs through existing networks?
  3. Do we need to support existing function simultaneous to
     the support of GMPLS L2 LSPs?

  I think that from a chair's perspective I can give some limited guidance.

  A. These questions must be raised and answered in the framework I-D
  B. The answer to question 3 is "yes". This means that the use of labels
     must not significantly deplete any namespace used to support other
     function.
  C. CCAMP is chartered to look at the control of transport networks. This
     includes Metro, but I am unsure about Campus. It does not cover 
     signaling to the desktop.

  Thanks,
  Adrian

  ----- Original Message ----- 
  From: "Pär Mattsson" <[email-masked]>
  To: "Loa Andersson" <[email-masked]>
  Cc: <[email-masked]>
  Sent: Friday, July 22, 2005 11:41 AM
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  > If you ever want that same switch to handle traffic for a directly
  > connected  host (not to uncommen) you would want that to use normal
  > ethernet macaddress switching. So of course you do not want to have to
  > choose between vlan and gmpls, you would want both at the same time.
  > 
  > /per
  > 
  > 
  > >
  > > /Loa
  > >
  > > Pär Mattsson wrote:
  > >>>hi par, one of the possibilities that has been considered to cope with
  > >> That seems to make more sence. If that frame is to be sized like a
  > >> 802.1q
  > >> frame. There is not that much space left to a label. Or is the demand to
  > >> use jumboframes ?
  > >> Has there been any discussion on labelstacking, and mainly where to
  > >> place
  > >> the information?
  > >>
  > >> Regards.
  > >> Per
  > >>
  > >>
  > >>
  > >
  > >
  > > --
  > > Loa Andersson
  > >

  ============================================================
  The information contained in this message may be privileged
  and confidential and protected from disclosure. If the reader
  of this message is not the intended recipient, or an employee
  or agent responsible for delivering this message to the
  intended recipient, you are hereby notified that any reproduction,
  dissemination or distribution of this communication is strictly
  prohibited. If you have received this communication in error,
  please notify us immediately by replying to the message and
  deleting it from your computer. Thank you. Tellabs
  ============================================================

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 22 Jul 2005 13:25:06 -0500

Igor,
 
I, too, am baffled by the notion of requirements for control of an unspecified data plane.
 
Regards,
Ben

________________________________

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: Friday, July 22, 2005 12:20 PM
	To: [email-masked]
	Cc: Mack-Crane, T. Benjamin; Adrian Farrel; Pär Mattsson; Loa Andersson; [email-masked]
	Subject: Re: Frameformat in a l2cs gmpls rnvironment.

	Dimitri,

	Igor

		----- Original Message ----- 
		From: [email-masked] 
		To: Igor Bryskin <mailto:[email-masked]>  
		Cc: Mack-Crane, T. Benjamin <mailto:[email-masked]>  ; Adrian Farrel <mailto:[email-masked]>  ; Pär Mattsson <mailto:[email-masked]>  ; Loa Andersson <mailto:[email-masked]>  ; [email-masked] 
		Sent: Friday, July 22, 2005 12:21 PM
		Subject: Re: Frameformat in a l2cs gmpls rnvironment.

		thanks,

		- dimitri.

		

		Hi,

		Igor
		----- Original Message ----- 
		From: Mack-Crane, T. Benjamin <mailto:[email-masked]>  
		To: Adrian Farrel <mailto:[email-masked]>  ; Pär Mattsson <mailto:[email-masked]>  ; Loa Andersson <mailto:[email-masked]>  
		Cc: [email-masked] 
		Sent: Friday, July 22, 2005 10:23 AM
		Subject: RE: Frameformat in a l2cs gmpls rnvironment.
		
		Hi,

		
		Regards,
		Ben
		
________________________________

		Hi,

		

		
		
		Thanks,
		Adrian

---

From: <[email-masked]>
Date: Fri, 22 Jul 2005 21:11:45 +0100

Adrian....with an operators hat on ;-)

Yes, you are right on most points here....few remarks in-(snipped)line:

> > BMC=> How frames are labeled (and the related data plane forwarding
> > behavior)
> is
> > not defined by the control plane.
> 
> AF=> It is true to say that this is not defined by the control plane. 
> Nevertheless, the control plane passes labels around and it is 
> important to define how those labels will be interpreted. I refer you 
> to all of the non-packet labeling mechanisms already defined: you will

> see that they do not define how the data is labeled, but they do 
> define how the signaled label maps to the labeled data.
NH=> Largely right Adrian....but on a wider note, I wish (and goodness
knows how I wish, esp in MPLS/PWE3) we had a stronger understanding of
func arch and the 3 networking modes.  It is the very nature of the
co-cs mode's 'label' that is key here, ie folks can't abuse this mode as
the nature of label means it's self-protecting to a large degree (I'll
ignore the 'topology on the fly' folks who quite clearly live in their
own world).  And remember a label is something that affects the
client->server layer adaptation, BUT it is essentially owned/defined by
the server layer and not the client.  But all this labelling stuff is
traffic data-plane oriented and has nothing to do with the
control-plane.  As Igor put it recently, the data-plane is King....and
indeed its is, the control-plane is merely there to serve it.

The role/significance of the control plane itself also changes in the 3
modes.  In the cl-ps mode it is 'almost everything' (well distributed
routing is THE issue here) but when we get down to SDH/OTNs and the
co-cs mode its not so important.  Here it's the management-plane that
dominates everything, even IF there is a control-plane...and then its
really mainly signalling.

It's the co-ps mode that is the odd-man out.  Let me point out that MPLS
DOES define a new data-plane (so its not like GMPLS at all)....and its
from an examination of THAT data-plane structure/behaviour that one
uncovers a host of problems.  I'll spare you a lengthy discourse on the
topic but I think/hope most folks should grasp what I mean by this.
> 
> > BMC=>The control plane serves to provision the data plane, not 
> > define it.
> 
> AF=>Yes.
NH=> Exactly.
> 
> > BMC=>In the framework draft it is not clear what data plane
> standards are
> > covered by the stated control plane requirements. Some references
> > should be supplied.
> 
> AF=>Such text would not be welcomed by the chairs who
> specifically instructed it to be left out.
NH=> They are wise IMO....don't screw-up the data-plane.  Take a leaf
from where this has been defined for the co-ps mode (ie MPLS/PWs)......I
don't think the results are that good (understatement).

> > BMC=>(I am assuming definition of new data plane standards is 
> out of scope
> for
> > CCAMP.)
> 
> AF=>Are you?
> 
> I would be surprised if this work introduced new data plane standards.
NH=> I would be horrified based on past experience....leave the
data-plane which has been defined elsewhere alone please.

regards, Neil

---

From: <[email-masked]>
Date: Fri, 22 Jul 2005 21:11:43 +0100

Dimitri,  
 
What do you mean by 'interferring elements'.....this sounds like some
'behind closed doors sect' at work.  I thought Adrian's post was (as
usual) plain/clear as to intent.
 
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: 22 July 2005 16:51
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

adrian - ok much thanks for the clarification - 

i wanted to be sure that the working group consensus is going to be the
element of decision for putting this item in the working list - and we
won't have other interfering elements in the decision process - 

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
07/22/2005 16:08
Please respond to "Adrian Farrel"

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <[email-masked]>
bcc: 
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Dimitri,

> what do you EXACTLY mean with the following sentence
>
> "This question is one we must come to as soon as we are confident that
the
> requirements need to be addressed at all."
>
> please clarify - btw who is "we" in this context ?

"We" means "the CCAMP working group"

> this sentence reads to me as "CCAMP has not yet committed to work on
this
> topic" is my reading correct ? or do you mean something else with this
?

Your reading is exactly correct as stated.
I refer you to your email to the list on 19th July. You asked...
> - if yes, is the interest in GMPLS for Ethernet in-/out-side the
>   CCAMP WG community strong enough to consider the corr. GMPLS
>   signaling and routing requirements (second part of the document)
>   as part of the CCAMP WG effort ?

Thus, the purpose of the I-D was to crystalize the authors' thoughts on
GMPLS control of Ethernet switching and to initiate discussion on
whether
the proposed deployment models are realistic and desirable. Following a
positive answer and assuming support (by CCAMP) for the doing the work
(in
CCAMP) all that remains is to add the work to the charter (see previous
charter discussions) and get on with it.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Fri, 22 Jul 2005 21:11:44 +0100

And you are so right on this Igor.  The nice thing about the co-cs mode is that the data-plane has not been defined here and works great.  Adding a (forced) OOB control-plane is not a big deal.....in fact as we move to the duct the control-plane is of much lesser interest/importance (this is not to belittle it, its just a fact)   Where the data-plane has been defined however, for the co-ps mode in MPLS and the PW stuff its unfortunately spawned, it's (how shall I put this politely) 'not so great'.  Can I make a plea NOT to screw-up ethernet by attempting to replicate MPLS....in any case the ethernet data-plane belongs to IEEE.  I would advise folks here to leave this well alone.
 
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 22 July 2005 16:11
To: Mack-Crane, T. Benjamin; Adrian Farrel; Pär Mattsson; Loa Andersson
Cc: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Hi,

Igor

----- Original Message ----- 
From: Mack-Crane, T. Benjamin <mailto:[email-masked]>  
To: Adrian Farrel <mailto:[email-masked]>  ; Pär Mattsson <mailto:[email-masked]>  ; Loa Andersson <mailto:[email-masked]>  
Cc: [email-masked] 
Sent: Friday, July 22, 2005 10:23 AM
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Hi,

 
Regards,
Ben

  _____  

Hi,

 

 
 
Thanks,
Adrian
 
----- Original Message ----- 
From: "Pär Mattsson" < <mailto:[email-masked]> [email-masked]>
To: "Loa Andersson" < <mailto:[email-masked]> [email-masked]>
Cc: < <mailto:[email-masked]> [email-masked]>
Sent: Friday, July 22, 2005 11:41 AM
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

> > Kista, Sweden                      email:   <mailto:[email-masked]> [email-masked]
> >                                              <mailto:[email-masked]> [email-masked]
> >
> 
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 22 Jul 2005 22:22:12 +0100

And me too Ben/Igor.  But go look at MPLS when folks DID define a data-plane here....don't anyone dare tell me 'this is good' (or the PW stuff it spawned) because I know otherwise.
 
reqards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mack-Crane, T. Benjamin
Sent: 22 July 2005 19:25
To: Igor Bryskin; [email-masked]
Cc: Adrian Farrel; Pär Mattsson; Loa Andersson; [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Igor,

Regards,
Ben

  _____  

Dimitri,

Igor

----- Original Message ----- 
From: [email-masked] 
To: Igor Bryskin <mailto:[email-masked]>  
Cc: Mack-Crane, T. Benjamin <mailto:[email-masked]>  ; Adrian  <mailto:[email-masked]> Farrel ; Pär  <mailto:[email-masked]> Mattsson ; Loa  <mailto:[email-masked]> Andersson ; [email-masked] 
Sent: Friday, July 22, 2005 12:21 PM
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

thanks,

- dimitri.

Hi,

Igor
----- Original Message ----- 
From: Mack-Crane, T.  <mailto:[email-masked]> Benjamin 
To: Adrian Farrel <mailto:[email-masked]>  ; Pär Mattsson <mailto:[email-masked]>  ; Loa  <mailto:[email-masked]> Andersson 
Cc: [email-masked] 
Sent: Friday, July 22, 2005 10:23 AM
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Hi,

Regards,
Ben

  _____  

Hi,

Thanks,
Adrian

---

From: [email-masked]
Date: Sat, 23 Jul 2005 01:21:55 +0200

[snip]

> Can I make a plea NOT to screw-up ethernet by attempting to replicate
MPLS

by definition of "Ethernet", this is an explicit non-goal, also the
document does not intend to replicate RFC 3031

> ...in any case the ethernet data-plane belongs to IEEE.

i don't think the document under discussion states the opposite - all the
contrary section 7.1 states

IEEE "should be consulted on the scenarios and framework proposed in this
document and any solutions developed in the IETF context should be reviewed
by the appropriate IEEE working groups to ensure the solution is not
harmful
to 802.1 networks."

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Sat, 23 Jul 2005 13:19:24 +0900

Dear Juergen, Par and all,

The proposed framework of L2SC was not intended to suggest 
any specific solution. It is still an open question. 
As Adrian noted, it only aims to present requirements 
as in scenarios that may drive people toward next step in many 
viable solutions.

In fact, there are other options we may also consider for L2 label encoding. 
IEEE 802.1 Ethernet bridges forward frames based on 48bits of MAC address, 
and additionally using VLAN tag. 

When the purpose of GMPLS control over Ethernet is not to create new dataplane 
but to utilize IEEE 802.1 bridge architecture, we may consider using 
one of the two forwarding methods, MAC forwarding or VLAN forwarding. 
(and perhaps any other combination of fields in MAC, but I'll not discuss it)
 
Use of VLAN ID for label encoding may automate VLAN configuration 
using IP protocols. However, GMPLS protocol cannot use the field exclusively 
because public/private operators already use VLAN for various purpose. 
There is a potential conflict with existing use of VLAN and GMPLS use of VLAN label.  
Furthermore, scalability of VLAN ID has been frequently noted as weakness 
because the size of VLAN ID is at most 4096 (12bit). 

The scalability may be improved if the scope of VLAN label is confined to 
link-local, and some additional swapping function of VLAN ID is introduced in 
Internal Sublayer [802.1D] of GMPLS implemented switch. 
However, this will only be effective when the configuration of network 
is mesh structure that multiple LSP paths exist. If the configuration of network 
is star or tree shape, as normal configuration of access network, 
LSPs concentrate in root node and total number of 
LSPs that the network can hold still be limited by available label space 
at a few root links. 

For these reasons, I do not think any form of VLAN ID label is 
an appropriate choice for layer-2 label encoding.
 
There are some other proposals assuming new assignment of Ethernet 
Length/Type value (e.g. new TPID in VLAN tag) and re-definition of 
information fields placed between 802.3 MAC header and IP packet. 
In this case, only the format of VLAN tag or extended VLAN tag 
is borrowed, however, inside the switching hardware, the filter and relay, 
etc. are totally different new dataplane switch.

I do not see such approach is a GMPLS implementation for Ethernet 
because the core switching technique is not 802.1 Ethernet bridge at all.
 
The other option we may consider is using MAC address filed as below.

+-------+-------+-------+-------+-------+-------+ 
| 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | 
+-------+-------+-------+-------+-------+-------+
+-----------------------+-----------------------+ 
|  OUI Prefix (=GMPLS)  |   DA-label (24bit)    | 
+-----------------------+-----------------------+ 
|  OUI Prefix (=GMPLS)  |   SA-label (24bit)    | 
+---------------+-------+-----------------------+ 
| Length/Type   | 
+---------------+

IEEE is designated by the ISO Council to act as the registration authority 
for the higher three-octet of OUI number in the MAC address 
to be used by manufacturer. Ethernet manufacturer may generate 
global unique MAC address using the OUI prefix and address block of 
lower three-octet (24bit). Taking advantage of the addressing scheme, 
GMPLS may use the lower three-octet exclusively if a unique OUI number 
is reserved for the protocol. With this labeling scheme, GMPLS will 
control MAC forwarding entry, not VLAN table.
 
All Ethernet frames controlled by GMPLS will have identical OUI number 
that they can easily be distinguished from other Ethernet frames. 
In principle, the label lookup hardware is identical to MAC lookup 
hardware in this labeling scheme. Therefore GMPLS implemented 
switch may still function as normal Ethernet bridge to the frames 
that OUI number is not GMPLS. This also facilitates GMPLS implemented 
switches being deployed in operating Ethernet with minimum service disruption.
 
Note also that above proposed label encoding method is transparent 
to the use of Ethernet Length/Type field. End-user device may use 
the Length/Type field as defined in IEEE 802.3 protocol. 
It also allows network operators configure VLAN for their own purpose. 
When IEEE 802.1p is used in conjunction with L2-LSP, the priority 
field of VLAN tag can also be used for imposing consistent TE policy in 
legacy switches and GMPLS switches.
 
Any way, my conclusion is, there are other options we may consider, 
and this issue is still open to discuss.
 
Thanks,
 
Sincerely,
 
Jaihyung

-----?? ???----- 
?? ??: "Heiles Juergen" <[email-masked]> 
?? ??: 2005-07-22 ?? 10:23:43 
?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Loa, 

I interpret the ID as a proposal to use GMPLS for VLAN setup. So GMPLS and VLAN to not compete. The VLAN is at the data plane and GMPLS at the control plane. The question is how and should different control plane techniques like GMPLS and (GVRP and STB) work together? 

Regards 

Juergen 

> Sent: Friday, July 22, 2005 2:53 PM 
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> Richard, 
> I agree to most of this. Since we have doubts about the viability 
> of taking GMPLS all the way to end-user or enterprise I think it 
> would be good, from a wg perspective, if we agreed to solve the 
> core network problems first. 
> 
> Do you have any comment on the requirement to run both VLANs and 
> GMPLS on the same switch? 
> 
> /Loa 
> 
> [email-masked] wrote: 
> > Regardless of whether or not a switch is directly connected 
>  > to hosts, it must be able to forward packets using the 
> connectionless 
>  > Ethernet data plane. This is due to the fundamental 
> requirement that 
>  > for GMPLS switches to be able to exchange control information with 
>  > each other, a data plane for control traffic must be present. 
>  > This is akin to using the IP data plane for MPLS signalling in an 
>  > IP/MPLS network. An alternative would be to use a static reserved 
>  > L2-LSP for control traffic in the same way that reserved VPI/VCIs 
>  > are used for PNNI signalling in ATM. 
> > 
> > Regarding connecting hosts to GMPLS switches, I personally don't 
>  > think extending L2-LSPs into the enterprise/home network is 
>  > commercially viable. However, if you do want to use GMPLS switches 
>  > in the home/enterprise network and for some reason don't want to 
>  > extend L2-LSPs down to the host then you will not be performing 
>  > normal Ethernet Mac address switching anyway. Instead you will 
>  > need some kind of policy on the switch that maps connectionless 
>  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a 
>  > L2-LSP. This is because multiple L2-LSPs to the same destination 
>  > (e.g. a gateway router) may exist for different services/flows 
>  > (e.g. video download, VoIP call, etc.). 
> > 
> > Regards, 
> > Richard 
> > 
> > 
> >>From: [email-masked] [mailto:[email-masked]]On 
> >>Behalf Of Par Mattsson 
> >>Sent: 22 July 2005 11:42 
> >>To: Loa Andersson 
> >>Cc: [email-masked] 
> >>>Par Mattsson wrote: 
> >>>>>this requirement is to use a dedicated TPID for the 
> >> 
> >>Ethernet labeled 
> >>

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Sat, 23 Jul 2005 13:38:50 +0900

Richard, 
 
IEEE recommends to use Ethernet Length/Type code for distinguishing control frames.
All GARP, GVRP, GMPR and other proposed OAM frame follow this rule.
IEEE particulary discourages using some number in data forwarding address 
being used for exchange of control data. An example is using some multicast address 
for exchange of hello frames. This rule is also applied to the case of VLAN forwarding.
I think this policy is to prevent control chaos with other L2 protocols.
We need to be careful in taking approach to use some L2-LSP exclusively 
for control plane because it may result in unwanted conflict with both people and machine.
 
Regards,
 
Jaihyung

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-22 ?? 8:44:08 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Regardless of whether or not a switch is directly connected to hosts, it must be able to forward packets using the connectionless Ethernet data plane. This is due to the fundamental requirement that for GMPLS switches to be able to exchange control information with each other, a data plane for control traffic must be present. This is akin to using the IP data plane for MPLS signalling in an IP/MPLS network. An alternative would be to use a static reserved L2-LSP for control traffic in the same way that reserved VPI/VCIs are used for PNNI signalling in ATM. 

Regarding connecting hosts to GMPLS switches, I personally don't think extending L2-LSPs into the enterprise/home network is commercially viable. However, if you do want to use GMPLS switches in the home/enterprise network and for some reason don't want to extend L2-LSPs down to the host then you will not be performing normal Ethernet Mac address switching anyway. Instead you will need some kind of policy on the switch that maps connectionless Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a L2-LSP. This is because multiple L2-LSPs to the same destination (e.g. a gateway router) may exist for different services/flows (e.g. video download, VoIP call, etc.). 

Regards, 
Richard

---

From: [email-masked]
Date: Sat, 23 Jul 2005 12:32:19 +0200

neil - to be perfectly clear -

during last round of discussion some individuals started speaking using authoritative and impersonal arguments such as "Ethernet belongs to another SDO i.e. the IEEE"

the DT and most people discussing this thread are perfectly aware of this (see section 7.1) and all what it implies; now, such element may be (potentially) interfering in the present discussion but this is simply a fact for which the CCAMP WG (iff a consensus is found) has to cope with; the problem statement document has tried to be as explicit as possible with that respect; this section 7.1 says that IEEE will be consulted and its feedback will be considered iff CCAMP finds enough interest in starting a working item on GMPLS (IP) control plane for Ethernet (based on the proposed scenarios) so as to start working on the requirements (listed in this document) as part of the CCAMP WG effort * but we are not that far yet *

however, this argument can not be used as the cornerstone in the present stage of decision process which is simply whether CCAMP WG wants to work or not on a GMPLS (IP) control plane for Ethernet; so, it is inappropriate to argue from the CCAMP perspective by making use of the potential reaction(s) of the IEEE, in particular, knowing there is no intention to initiate a work item on Ethernet data plane

<[email-masked]>
07/22/2005 21:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[email-masked]>
cc: <[email-masked]>
bcc:
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Dimitri,

What do you mean by 'interferring elements'.....this sounds like some 'behind closed doors sect' at work.  I thought Adrian's post was (as usual) plain/clear as to intent.

regards, Neil
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 22 July 2005 16:51
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

i wanted to be sure that the working group consensus is going to be the element of decision for putting this item in the working list - and we won't have other interfering elements in the decision process -

Dimitri,

the
> please clarify - btw who is "we" in this context

this

Thus, the purpose of the I-D was to crystalize the authors' thoughts on
GMPLS control of Ethernet switching and to initiate discussion on whether
the proposed deployment models are realistic and desirable. Following a
positive answer and assuming support (by CCAMP) for the doing the work (in
CCAMP) all that remains is to add the work to the charter (see previous
charter discussions) and get on with it.

Thanks,
Adrian

---

From: Heiles Juergen <[email-masked]>
Date: Mon, 25 Jul 2005 09:20:19 +0200

Hi Dimitri,
 
what I described is the straight forward approach like it is used for SONET/SDH or OTN. A pure control plane approach for setup of connectivity. You could even keep the restriction of a domain local VLAN ID as defined by IEEE. It is "just" a restriction of matrix connectivity like some older SONET/SDH equipment also has (e.g. no time slot interchange in a ring). So it would have no major impact on 802.1d except for the definition of a control plane communications channel as mentioned by Richard.
In case we make any changes to the data plane behavior like disabling of MAC address learning and MAC address based forwarding and introduction of a dedicated label we introduce a new layer network like MPLS did for IP. This has much wider impact and should be carefully considered.
 
Regards
 
Juergen

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 22, 2005 4:03 PM
To: Heiles Juergen
Cc: Loa Andersson; Par Mattsson; [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

hi juergen,

Regards

Juergen

---

From: Heiles Juergen <[email-masked]>
Date: Mon, 25 Jul 2005 11:44:34 +0200

Dear Jaihyung,

you mention several options that could be used as a label. Most of them have strong impacts on the data plane and introduce new layer networks. Is this in the scope of CCAMP? What is the goal, to introduce a control plane for a existing L2 technology or introduce a new L2 technology? What would be the benefit of such a new L2 co switching technology compared to Ethernet over MPLS as defined by PWE3 and L2VPN?
You mentioned to use the MAC address or part of it as a label. The TRILL working group is defining shortest path routing for Ethernet. How would this fit together?

Regards

Juergen

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: Saturday, July 23, 2005 6:19 AM
> To: Heiles Juergen; [email-masked]
> Cc: [email-masked]
> I interpret the ID as a proposal to use GMPLS for VLAN setup. 
> So GMPLS and VLAN to not compete. The VLAN is at the data 
> plane and GMPLS at the control plane. The question is how and 
> should different control plane techniques like GMPLS and 
> (GVRP and STB) work together? 
> 
> Regards 
> 
> Juergen 
> 
> 
> [mailto:[email-masked]]On 
> > >>Behalf Of Par Mattsson 
> > >>Sent: 22 July 2005 11:42 
> > >>To: Loa Andersson 
> > >>Cc: [email-masked]

---

From: <[email-masked]>
Date: Mon, 25 Jul 2005 10:54:36 +0100

Jaihyung, 

As both you and Adrian thought that I was talking about an Ethernet Control plane, I mustn't have adequately articulated my point. When I mentioned a "data plane for control traffic" below, I was not talking about an Ethernet control plane. I was referring to the transport of GMPLS IP control protocol traffic over a standard 802.1 data plane, using either untagged frames or a common VLAN ID.

Regards,
Richard

> Sent: 23 July 2005 05:39
> To: Spencer,R,Richard,XDE73 R
> Cc: [email-masked]
> connectionless Ethernet data plane. This is due to the 
> fundamental requirement that for GMPLS switches to be able to 
> exchange control information with each other, a data plane 
> for control traffic must be present. This is akin to using 
> the IP data plane for MPLS signalling in an IP/MPLS network. 
> An alternative would be to use a static reserved L2-LSP for 
> control traffic in the same way that reserved VPI/VCIs are 
> used for PNNI signalling in ATM. 
> 
> Regarding connecting hosts to GMPLS switches, I personally 
> don't think extending L2-LSPs into the enterprise/home 
> network is commercially viable. However, if you do want to 
> use GMPLS switches in the home/enterprise network and for 
> some reason don't want to extend L2-LSPs down to the host 
> then you will not be performing normal Ethernet Mac address 
> switching anyway. Instead you will need some kind of policy 
> on the switch that maps connectionless Ethernet packets (e.g. 
> based on MAC src/dest, 802.1p, VLAN) to a L2-LSP. This is 
> because multiple L2-LSPs to the same destination (e.g. a 
> gateway router) may exist for different services/flows (e.g. 
> video download, VoIP call, etc.). 
> 
> Regards, 
> Richard 
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 25 Jul 2005 11:59:27 +0200

Hi Richard,
            actually the usage of a specific VLAN tag for the control plane
seems to me a good idea.

It is a fast and simple way to distinguish data plane traffic from control
plane traffic.

Regards

Diego

<[email-masked]>@ops.ietf.org on 25/07/2005 11.54.36

To:    <[email-masked]>
cc:    <[email-masked]>

Jaihyung,

As both you and Adrian thought that I was talking about an Ethernet Control
plane, I mustn't have adequately articulated my point. When I mentioned a
"data plane for control traffic" below, I was not talking about an Ethernet
control plane. I was referring to the transport of GMPLS IP control
protocol traffic over a standard 802.1 data plane, using either untagged
frames or a common VLAN ID.

Regards,
Richard

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Mon, 25 Jul 2005 20:39:47 +0900

hi, Juergen

>Dear Jaihyung, 
> 
>you mention several options that could be used as a label. 
>Most of them have strong impacts on the data plane and introduce 
>new layer networks. Is this in the scope of CCAMP? What is the goal, 

In below mail, I discussed about three proposed approaches.

1. using VLAN tag as it is for L2 label encoding.

2. defining new protocol ID (TPID) and borrow VLAN tag format, 
?or extended VLAN tag to implement label swapping.

3. use lower 3 bytes of MAC address for L2 label encoding.

802.1Q bridge forwards Ethernet frames using two dataplane tables 
- MAC forwarding table and VLAN forwarding table. 
Bridge control protocols, such as GARP, GVRP, GMRP, 
manipulate one of the two dataplane entities.

Similarly, option 1 and 3 are about which one of two dataplane entities 
GMPLS protocol should control on behalf of bridge control protocols. 
The two proposals do not intend to modify bridge behavior 
seriously, such as MAC learning, aging, filtering. 
Therefore, the approaches 1 and 3 are in the scope of CCAMP.

(% note however, I would regard implementing label swapping 
function is acceptable change considering the Internal Sublayer 
design of 802.1D bridge.)

However, option 2 is about what TPID code we will 
choose to implement new switching function. 
The switch of this implementation should have new hardware 
design in addition to normal bride hardware. 
I think such proposal as option 2 is out of CCAMP scope. 

>to introduce a control plane for a existing L2 technology or 
>introduce a new L2 technology? What would be the benefit 
>of such a new L2 co switching technology compared to Ethernet 
>over MPLS as defined by PWE3 and L2VPN?

The benefit of L2SC switch is explained in section 4 of 
<draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt>

Overall objective is improving scalability, traffic engineering (TE) 
characteristics of 802.1 bridge that it can be reliable, manageable 
enough to replace some core routers.
The switching technique you mentioned above, such as 
Ethernet over MPLS as defined by PWE3 and L2VPN,
are all actually router based technology, however this
work is based on simple bridge architecture.
Cost-effectiveness is the key differentiator.

In access or enterprise network, capability of providing end-to-end 
L2-LSP will enable service providers policing, measuring, charging 
application flows using Ethernet based network. This will eventually 
improve income structure and introduce new session based commercial 
service. I have been discussing this aspect in mail thread of 
title 'End-to-end L2-LSP'.  Please read the mail thread and comment
on the discussion.

>You mentioned to use the MAC address or part of it as a label. 
>The TRILL working group is defining shortest path routing for Ethernet. 
>How would this fit together?

TRILL employs new encapsulation layer outside of Ethernet frames. 
However in my proposal of option-3, I simply use the Ethernet header 
to encode GMPLS label. 

The overall format of rbridge is  [Ethernet][r-tag][Ethernet][ data..] 
It is not LSP based technology but a connectionless routing bridge. 
TTL count is very important in rbridge because frames are routed 
hop-by-hop and it may loop.

Whereas in option-3 above, Ethernet frames that have certain 
OUI prefix in MAC address are forwarded via a path that 
GMPLS protocol has configured on MAC forwarding table.

Thanks
 
Jaihyung

-----?? ???----- 
?? ??: "Heiles Juergen" <[email-masked]> 
?? ??: 2005-07-25 ?? 6:44:34 
?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Dear Jaihyung, 

Regards 

Juergen

---

From: Heiles Juergen <[email-masked]>
Date: Mon, 25 Jul 2005 14:32:40 +0200

Dear Jaihyung,

the discussion now goes too much into implementations, however I would like to add my comments/questions. 

Regards

Juergen

> Sent: Monday, July 25, 2005 1:40 PM
.....
> Therefore, the approaches 1 and 3 are in the scope of CCAMP.

Even so your option 3 may not change the hardware it totaly changes the forwarding behaviour as it redefines the meaning of a MAC address. The MAC address is a end station address that identfies the source and sink of the MAC frame. In your proposal it will be used as link local label. It would be the same as if MPLS would use a dedicated IP address range as lable instead of its own label.
What will happen with the original MAC address when you enter such a GMPLS Ethernet domain? Will you add a new "MAC header"?

.......
> enough to replace some core routers.

This is also provided by Ethernet over MPLS even with label stacking.

> Cost-effectiveness is the key differentiator.
This is what I hear often and what I mean with "we still call it Ethernet as it will be cahep and simple as todays Ehternet".
In the end the same functionality is needed: lable lookup, label swapping, signaling protocol, routing protocol, discovery protocol, ...
So from the functionality and architecture point of view no difference exists.
One advantage compared to Ethernet over MPLS I see, is that MPLS has to be again mapped into Ethernet for transport. This addtional Ethernet layer is not needed.
In your response to Richard you mention to use a simpler routing for Ethernet in this enviroment using dynamic learning like in Ethernet. How about a unified GMPLS control plane and restoration. Will you introduce another spanning tree?

...

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Mon, 25 Jul 2005 23:37:15 +0900

hi, Juergen
 
see some in-line below,

>Even so your option 3 may not change the hardware it totaly changes 
>the forwarding behaviour as it redefines the meaning of a MAC address. 
>The MAC address is a end station address that identfies the source 
>and sink of the MAC frame. In your proposal it will be used as link 
>local label. 

There's no (in principle) physical change in the MAC forwarding behavior. 
GMPLS will configure MAC forwarding entry as if static entry 
is configured in MAC table by operator.

Suppose a network that Ethernet bridges interconnect routers. 
Normally single L2 data path is established between routers by MAC learning. 
If an operator manually configure another MAC forwarding path in the 
bridges, two L2 paths are established between routers.

Of course such configuration is not possible in 802.1 bridged network. 
However, GMPLS implementation may automate such configuration 
of semi-static MAC forwarding entry that otherwise be configured 
manually by operator.

>It would be the same as if MPLS would use a dedicated 
>IP address range as lable instead of its own label.

You may think it different perspective. 
MPLS forwards data using shim header, and the shim label is, 
again, encapsulated by Ethernet header. From the view of 
input and output link, Ethernet header (i.e. MAC addresses) is 
replaced at every hop together with shim label.

What if the router knows which Ethernet header is to be replaced 
to which Ethernet header in next link? Does it still need to lookup 
MPLS shim header at L3 level? In this case, it is sufficient for 
the switch performing swap operation in L2SC level. 
 
The whole idea of GMPLS is employing common control over 
underlying transport method, and in the case of Ethernet, 
the major transport method of Ethernet frame is MAC forwarding 
using Ethernet address, and so is GMPLS implementation for Ethernet.

>What will happen with the original MAC address when you enter 
>such a GMPLS Ethernet domain? Will you add a new "MAC header"?

You are actually referring three cases,

1. in local network that host forwards Ethernet frame via L2-LSP 
2. in core edge that provides L2VPN service 
3. in network that legacy switch and GMPLS switches are 
   interconnected.
 
In 1, Ethernet address is swapped to GMPLS prefixed address 
and forwarded via established L2-LSP.

In 2, user frames are encapsulated as you said.

In 3, normal Ethernet frames are forwarded via normal STP path, 
however GMPLS frames may be forwarded via different path 
established using RSVP-TE.

...... 
>This is also provided by Ethernet over MPLS even with label stacking.

but not by Ethernet bridges. 
When the price of Ethernet bridge is compared to MPLS router just by 
port and switching capacity, it is nearly ten times cheaper. 
What we are trying to do is delivering the capability of MPLS switch 
at the price of Ethernet switch.

>This is what I hear often and what I mean with "we still call 
>it Ethernet as it will be cahep and simple as todays Ehternet". 
>In the end the same functionality is needed: lable lookup, 
>label swapping, signaling protocol, routing protocol, discovery protocol, ... 

I understand well how today's routers become a machine of millions of gates. 
This is the solution I struggled for some years to simplify it best. 
That's why I am trying to preserve the original simplicity of hardware 
architecture of 802.1 Ethernet bridge. 

>One advantage compared to Ethernet over MPLS I see, is that 
>MPLS has to be again mapped into Ethernet for transport. 
>This addtional Ethernet layer is not needed.
>In your response to Richard you mention to use a simpler routing 
>for Ethernet in this enviroment using dynamic learning like in Ethernet. 
>How about a unified GMPLS control plane and restoration. 
>Will you introduce another spanning tree?

No, I'll just propose another way to achieve TE-LSP 
without relying on pre-established routing table. 
Please take a time to see 
<draft-jaihyung-ccamp-arpsignal-00.txt> 
and read the section about flood-routing.

thanks
 
Jaihyung 

-----?? ???----- 
?? ??: 2005-07-25 ?? 9:32:40 

Dear Jaihyung, 

Regards 

Juergen 

> Subject: RE: Frameformat in a l2cs gmpls rnvironment. 
.... 

...... 

..

---

From: <[email-masked]>
Date: Mon, 25 Jul 2005 16:44:55 +0100

I fully agree with Juergen's comments. The key question that's still not clear in my mind here is, what is the real motivation for this work? Is it to simply support dynamic VLAN provisioning for Ethernet based on shortest/TE paths using GMPLS instead of using OSS? Or is it to develop an alternative CO-PS solution (to say ATM or MPLS) using the Ethernet frame structure, regardless of whether or not the Ethernet forwarding behaviour (and hardware) needs to be modified?

If the scope of the proposal does not prevent the Ethernet forwarding behaviour being modified resulting in "the switching hardware, the filter and relay, etc. are totally different new dataplane switch", then this seems to be contradictory to an earlier comment from Dimitri that said "the definition of any data plane behaviour is outside of the scope of the DT charter and the document it produced". This also raises questions regarding the role of the IEEE and what the applications/goals/benefits of the new Ethernet forwarding behaviour will be. 

If on the other hand the goal is to use the Ethernet data plane as it stands today based on MAC address learning/switching, but to replace manual/OSS VLAN provisioning with a GMPLS CP, it seems to me that there is a fundamental difference between this proposal and all other GMPLS solutions. In all the GMPLS solutions I'm aware of, the label signalled via GMPLS (e.g. ATM VPI/VCI, WDM wavelength, etc.) is also used for forwarding in the data plane. However in this case, data plane forwarding is not based on a label (VLAN ID) but on an address, i.e. the destination MAC address. Instead, the label is used to restrict the broadcast domain (e.g. to a P2P path), which (following MAC flooding/learning) results in the packets belonging to a particular VLAN following the same path. Although the result is effectively the same, the fact that forwarding is not based on the label signalled using GMPLS may cause complications. For example, when a failure occurs, in addition to re-routing or switching over to backup paths, the MAC databases/tables of all effected nodes must be purged on a per VLAN basis.

Looking at section 4, I agree that one obvious benefit (as mentioned in section 4) would be the ability to dynamically calculate loop-free shortest/TE paths, which would allow operators to switch off spanning tree. However as Juergen points out, this is one of the goals for the TRILL WG (although the solution proposed is different), so I would like to understand what the common/opposing goals are. Another example from section 4 is the point about improving scalability by introducing IP addressing with GMPLS rather relying on MAC addresses, which are not hierarchical. This point is only valid if the control plane is being used to carry Ethernet addresses. So, this might be a valid point when comparing the TRILL solution to the GMPLS solution for example, but is not valid when comparing a standard 802.1 Ethernet network to a GMPLS L2-LSP network. The reason being that both solutions are still based on data plane learning using MAC addresses and are therefore both subject to the same data plane scaling issues, i.e. for the solution to scale to large numbers of Ethernet customers, MAC-in-MAC encapsulation will be required. Therefore, what will the benefits of using L2-LSPs with MAC-in-MAC be compared to encapsulating Ethernet in MPLS PWs?

Regards,
Richard

> Behalf Of Heiles Juergen
> Sent: 25 July 2005 10:45
> To: CHO, JAI HYUNG; Heiles Juergen; [email-masked]
> Cc: [email-masked]
> Most of them have strong impacts on the data plane and 
> introduce new layer networks. Is this in the scope of CCAMP? 
> What is the goal, to introduce a control plane for a existing 
> L2 technology or introduce a new L2 technology? What would be 
> the benefit of such a new L2 co switching technology compared 
> to Ethernet over MPLS as defined by PWE3 and L2VPN?
> You mentioned to use the MAC address or part of it as a 
> label. The TRILL working group is defining shortest path 
> routing for Ethernet. How would this fit together?
> 
> 
> Regards
> 
> Juergen
>   
> 
> 
> 
>

---

From: [email-masked]
Date: Mon, 25 Jul 2005 23:37:01 +0200

hi richard

> I fully agree with Juergen's comments. The key question that's still not
> clear in my mind here is, what is the real motivation for this work?

motivations are detailed in section 4 - this said, i need some
clarification from your side to provide a more detailed answer to your
initial question

> Is it to simply support dynamic VLAN provisioning for Ethernet based on
> shortest/TE paths using GMPLS instead of using OSS?

among other - yes

> Or is it to develop an alternative CO-PS solution (to say ATM or MPLS)
> using the Ethernet frame structure, regardless of whether or not the
> Ethernet forwarding behaviour (and hardware) needs to be modified?

this is not an objective

however, and this is where the whole difficulty of the exercise stands, as
the DT was not chartered to specifically detail the data plane
behaviour/fowarding behaviour there is indeed a whole spectrum of such
behaviour that can sustain these requirements - reason why this work item
(even if we get a consensus as part of this WG) requires consultation of
the IEEE as stated in section 7.1

> If the scope of the proposal does not prevent the Ethernet forwarding
> behaviour being modified resulting in "the switching hardware, the filter
> and relay, etc. are totally different new dataplane switch", then this
seems
> to be contradictory to an earlier comment from Dimitri that said "the
> definition of any data plane behaviour is outside of the scope of the DT
> charter and the document it produced".

and this statement still holds as the DT work is concerned - note: some
individuals have expressed opinions in terms of data plane support but this
is not part of the scope of the present DT charter but these is a logical
consequence of initiating such a work item within a community of engineers

> This also raises questions regarding the role of the IEEE and what the
> applications/goals/benefits of the new Ethernet forwarding behaviour will
> be.

indeed - this is the reason why the document has explicitly stated that
consultation with the IEEE must be ensured to progress with this item

> If on the other hand the goal is to use the Ethernet data plane as it
stands
> today based on MAC address learning/switching, but to replace manual/OSS
> VLAN provisioning with a GMPLS CP, it seems to me that there is a
> fundamental difference between this proposal and all other GMPLS
solutions.
> In all the GMPLS solutions I'm aware of, the label signalled via GMPLS
(e.g.
> ATM VPI/VCI, WDM wavelength, etc.) is also used for forwarding in the
data
> plane. However in this case, data plane forwarding is not based on a
label
> (VLAN ID) but on an address, i.e. the destination MAC address. Instead,
the
> label is used to restrict the broadcast domain (e.g. to a P2P path),
which
> (following MAC flooding/learning) results in the packets belonging to a
> particular VLAN following the same path. Although the result is
effectively
> the same, the fact that forwarding is not based on the label signalled
using
> GMPLS may cause complications. For example, when a failure occurs, in
> addition to re-routing or switching over to backup paths, the MAC
> databases/tables of all effected nodes must be purged on a per VLAN
basis.

indeed, flushing and re-learning aspects must be addressed - and this is
the kind of feedback we expect to receive from the IEEE

> Looking at section 4, I agree that one obvious benefit (as mentioned in
> section 4) would be the ability to dynamically calculate loop-free
> shortest/TE paths, which would allow operators to switch off spanning
tree.
> However as Juergen points out, this is one of the goals for the TRILL WG
> (although the solution proposed is different), so I would like to
understand
> what the common/opposing goals are. Another example from section 4 is the
> point about improving scalability by introducing IP addressing with GMPLS
> rather relying on MAC addresses, which are not hierarchical. This point
is
> only valid if the control plane is being used to carry Ethernet
addresses.

i do not understand this last statement - would you clarify ? -

> So, this might be a valid point when comparing the TRILL solution to the
> GMPLS solution for example, but is not valid when comparing a standard
802.1
> Ethernet network to a GMPLS L2-LSP network. The reason being that both
> solutions are still based on data plane learning using MAC addresses and
are
> therefore both subject to the same data plane scaling issues, i.e. for
the
> solution to scale to large numbers of Ethernet customers, MAC-in-MAC
> encapsulation will be required.

indeed MAC-in-MAC is currently under definition to solve such kind of
problems, however the present approach does not intend to be used for
establishing an LSP per pair of MAC SA-DA when the #Ethernet terminating
hosts >> #network nodes;

also to clarify a specific point in the context of the present discussion,
this work item is not intended to solve ALL the specific issues and
problems related to the use of an Ethernet data plane in any operational
conditions; this document has simply identified several scenario where the
use of GMPLS protocol suite may be considered in order to facilitate (some
of the) Ethernet network operations

> Therefore, what will the benefits of using L2-LSPs with MAC-in-MAC be
> compared to encapsulating Ethernet in MPLS PWs?

some of the TRILL WG objectives are indeed overlapping with the present
effort however the respective approaches are not identical; TRILL does not
intend to make use of any signaling mechanism/source-routing protocol;
TRILL is intended to specifically cover "CAMPUS" networks (even if its
scope could be larger) by defining an "intermediate" technology between IP
and Ethernet to circumvent the drawbacks of the latter (in particular wrt
to 802.1d and related)

concerning the differences between the present work item and Ethernet over
PW/MPLS, i refer you to the introduction of the document under discussion

i hope this clarifies (at least some of your doubts)

thanks,
- dimitri.