[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Frameformat in a l2cs gmpls rnvironment.
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)
> > 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.
> > 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
> > 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.