Subject: RE: Frameformat in a l2cs gmpls rnvironment.

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 22 Jul 2005 09:23:59 -0500

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] <mailto:[email-masked]> >
	To: "Loa Andersson" <[email-masked] <mailto:[email-masked]> >
	Cc: <[email-masked] <mailto:[email-masked]> >
	Sent: Friday, July 22, 2005 11:41 AM
	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.
	> 
	> 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
	> >>>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] <mailto:[email-masked]> 
	> >                                             [email-masked] <mailto:[email-masked]> 
	> >
	> 
	> 
	> 
	> 

============================================================
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: "Igor Bryskin" <[email-masked]>
Date: Fri, 22 Jul 2005 11:10:31 -0400

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,

  Regards,
  Ben

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

    Hi,

    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.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 22 Jul 2005 16:18:30 +0100

Ben,

You raised some questions that I can answer with my chair hat comfortably
on.

> I think Juergen has raised an important question.

Yes, it is an important question, even if we are getting ahead of
ourselves. I take the question and the excitement as good evidence that we
are rapidly moving beyond the issue of whether requirements exist and are
now discussing how to implement.

> How frames are labeled (and the related data plane forwarding behavior)
is
> not defined by the control plane.

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.

> The control plane serves to provision the data plane, not define it.

Yes.

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

Such text would not be welcomed by the chairs who specifically instructed
it to be left out.
You may want to see a complete solution presented in one go, but the
chairs want to see the deployment scenarios separated from the solutions
work.
The debate about how to label packets is distinctly unhelpful in
determining what we want to be able to achieve with GMPLS control of
Ethernet networks. Further, the requirements may drive us towards one
solution rather than another, so placing the solution within the
requirements/framework I-D would be dangerous.

> In any case, the labeling and forwarding behavior should be defined by
these
> referenced standards, not by GMPLS.

I think you will find that there are adequate standards for forwarding
data in Ethernet, without any new standards being defined. The choice
which will ultimately be made (FOR EXAMPLE between MAC addresses, VLAN
TAGs, or new TPIDs) does not touch existing forwarding paradigms, but
might change how those forwarding paradigms are installed.

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

Are you?

I would be surprised if this work introduced new data plane standards.

Thanks,
Adrian