[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Closing the GELS Mailing List



Title: Message
True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly.

Have a great weekend.
Igor

neil.2.harrison@bt.com wrote:
Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right.  It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm.  Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection.
 
regards, Neil
-----Original Message-----
From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007 20:21
To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; 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 to see what's on, when.


Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.