[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Closing the GELS Mailing List
Colleagues,
It would appear to me that we are going around in circles and that they
are basically the same circles that we have gone around before. This
would incorrectly imply that we have gone nowhere.
IMO the path is quite simple and outlined in Adrian's e-mail dated 5th
September. The design team produce documents (1) & (2) ("GMPLS
Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" & "GMPLS
control of P2P TE for PBB-TE (802.1Qay)").
The second document describes our understanding of the 802.1Qay data
plane including swapping rules.
We liaise these to IEEE and if we got them (i.e. our understanding of
the data plane) right then we can go ahead and define the data plane
specific control protocol machinery. If we didn't quite get them right
IEEE tell us and we adjust the documents accordingly.
So let's wait & see what the design team create & what the IEEE reaction
to those documents is.
Ben
owner-ccamp@ops.ietf.org <> wrote:
> 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.