RE: Frameformat in a l2cs gmpls rnvironment.

[<neil.2.harrison@bt.com>]

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
> 
> Thanks,
> Adrian
> 
> 
>