Re: Frameformat in a l2cs gmpls rnvironment.

["Adrian Farrel" <adrian@olddog.co.uk>]

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