[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Closing the GELS Mailing List
igor
> 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;
IEEE 802.1 does not deal with the data plane in that sense. it defines
"control" of forwarding components it is an issue we need to consider.
we are not taking a data plane specification in its basic sense for
which CCAMP adds a control plane. to the modes 802.1 currently considers
MSTP (domain-wide bridging through spanning tree), SPB (shortest-path
tree bridging) and PBB-TE (for which we have no outline so far) result
in specification detailing operations of forwarding components.
if i take the latter its is intended to "support provisioning systems
that explicitly select traffic engineered paths within Provider Backbone
Bridge Networks (P802.1ah) by allowing a network operator to disable
unknown destination address forwarding and source address learning for
administratively selected VLAN Identifiers, while allowing other network
control protocols to dynamically determine active topologies for other
services." ... far from being a data plane specification in its base
sense.
> 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.
i will use examples to make this clearer to allow something along the
PBB-TE line work is ongoing to define states which force the port state
being learning off and forwarding on (for all VID allocated to PBB-TE
but not to MSTP), disable broadcast/unknown unicast while allowing
filtering of unicast only (both are control of MAC relay operations),
etc. -> all these control-driven operation fall outside CCAMP scope (at
least as far as my understanding goes)
-> the question is not "IEEE defines the data plane and IETF the control
plane"
=> the question is which control components can CCAMP consider that
complements amended 802.1ah bridge control & operation: data path
setup/provisioning mechanism (explicit source-initiated routing) ?
traffic engineering which first requires to see which TE model IEEE will
consider ? others ?
-d.
> -----Original Message-----
> From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Saturday, September 08, 2007 3:36 PM
> To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;
> 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
>
> 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.
> >
>
>
>
>
> ________________________________
>
> Ready for the edge of your seat? Check out tonight's top
> picks
> <http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/> on
> Yahoo! TV.
>