Dimitri,
As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS?s great deficiency is the lack of LSP source ID in the MPLS label). The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet.
The conclusions in the context of co Ethernet:
a) Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable;
b) Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID? nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that.
Cheers,
Igor
> So, IMO IEEE should be responsible for the definition of data
> plane labels, while CCAMP for control plane labels.
a label distribution protocol is a set of
procedures by which one node
informs another of the label/FEC bindings it has made
if these labels are distributed via the gmpls control plane driving
population of the LIBs to which difference are u pointing out here ? so,
not sure to see the point (whatever the number of levels of indirection
between the fwd'ing plane encoding and control plane encoding u will
always fall back on the former, the label distribution protocol
exchanges a piece of information used by the nodes to perform their
forwarding decision)
-d.
> -----Original Message-----
> From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Friday, September 07, 2007 9:21 PM
> To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;
> adrian@olddog.co.uk; zali@cisco.com;
> Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
> Cc: rcallon@juniper.net
> Subject: RE: Closing the GELS Mailing List
>
> Hi
Neil,
>
> I think there is a difference between a "data plane label"
> which is a Layer Information (LI) used by a given server
> layer and a "control plane label", which is a piece of
> information signaled between adjacent controllers for the
> purpose of connection provisioning. IMO the former is always
> a superset of the latter. Let's take, for instance,
> connection oriented Ethernet. MAC SA is a very important part
> of the data plane label because it identifies the source of
> the connection. However, the connection frames are forwarded
> according to MAC DA/VID, and hence connection ingress node,
> for example, needs only be signaled with this tuple by the
> downstream neighbor, hence the control plane label is MAC
> DA/VID (or just VID, for those who like the idea of the VID
> cross-connects architecture).
>
> So, IMO IEEE should be responsible
for the definition of data
> plane labels, while CCAMP for control plane labels.
>
> Cheers,
> Igor
>
>
> neil.2.harrison@bt.com wrote:
>
> Dimitri wrote 07 September 2007 16:36 in response to Adrian
>
> > >
> > > This is also something we would expect to describe within
> > > CCAMP although
> > > "what is a label" would come to us from the data plane
> > specification.
> >
> > do i interpreet correctly your statement that if the
> > specification that CCAMP is going to receive from IEEE does
> > not speak about "label" and its encoding there will be no
> > place to discuss any "label processing" and "label
> > distribution" protocol in IETF - being domain-wide or
> link-local
> > -
> >
> > in that case, isn't the .1Q specification
outside scope of
> > this effort since not referring - as of today at least - to
> > any "label" semantic as part of the Ethernet frame header
> > information field ?
> >
> > thanks,
> > -d.
>
> What do you think a MAC DA, MAC SA and VID are? These
> are all 'labels'.
>
> You also have to remember that the nature of the labels
> required in a
> traffic unit are determined by the type of the network
> mode one is
> dealing with.
>
> In the co-cs and co-ps modes we have a construction known as a
> 'connection'. This implies specific architectural
> requirements....but
> the most significant, for this discussion at least, is
> that a connection
> must have a single source. What this means is that one
> does not have to
> incorporate a SA label in a co mode traffic
> unit....under
defect-free
> conditions it is redundant information as the
> connection itself provides
> the source information. {Compare this to the cl-ps mode
> which does not
> have connections...here having a SA in the traffic unit
> is essential}
>
> Ergo why co-cs and co-ps mode technologies to date that
> respect the
> requirements of a connection have only focussed on
> incorporating a DA
> (forwarding) label. Further, these forwarding labels
> only need to be
> distinct in resolving some number (N say) of different
> client layer
> (link-connection) instances within a server layer
> (network connection)
> resource partition. However, there are advantages from
> having both a SA
> and DA label in a co-ps traffic unit that are network
> unique and not
> just link-connection unique (ie not swapped)....the
> inherent
robustness
> under misconnectivity defects (without any adjunct OAM
> flow) is one of
> these. And of course, these are the nature of the
> native labels one
> already gets in Ethernet due to its cl-ps mode origins.
> So why would
> one even contemplate not using these since they are
> already there?
>
> The VID label is slightly different in that one can
> consider it as a
> 'route discriminator label' and a local extension to
> the SA or DA, ie it
> provides the ability to identify disjoint paths between
> nodal end
> points.
>
> The mere fact IEEE may not refer to the above
> quantities as 'labels'
> does not change the fact that this is what they are. So
> I'm not clear
> what your real point is here.
>
> regards, Neil
>
>
>
>
>
________________________________
>
> Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
> > ions/222> to see what's on, when.
>