RE: Closing the GELS Mailing List

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>]

 hi adrian,

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> Sent: Friday, September 07, 2007 8:40 PM
> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
> Subject: Re: Closing the GELS Mailing List
> 
> Hi Dimitri,
> 
> >>> beside the fact that there is an assumption on what
> >>> label means and how it is represented in data plane
> >>
> >> 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
> 
> I expect the IEEE specification to define the forwarding paradigm.
> 
> For example: Frames in 802.1Qay are forwarded based on the 
> checksum value
> carried in the frame.
> 
> I expect us to build a GMPLS solution that can be used to 
> configure/install
> that forwarding paradigm.
> 
> If (for example) the destination MAC is the forwarding 
> trigger, and the
> destination MAC is also intended to have genuine network-wide 
> scope and
> identify the recipient of the frame to the whole network, 
> then the label is
> (by definition) network-scoped.
> 
> > 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 ?
> 
> No. That is like saying that TDM and lambda were out of scope 
> for GMPLS because their definitions didn't refer to labels.

we were confronted to that problem a couple of years ago. the
difference with techno's that do not encode label in the "data
plane" is that in the present case, the forwarding itself was
label value dependent

> The point is that a label is the identifier by which traffic 
> on an interface
> may be identified for forwarding. The data plane spec should 
> indicate what
> that identifier is, and we call that a label and have to pass 
> it around in
> signaling.

this is already an extended version of a classical label def.

now, speaking about "label" switching router induces a behaviour that
was not felt "respectful" to the
operations of an Ethernet switch.

it was felt that the control plane was constraining the fwd'ing plane -
in brief, the point was incorporating a source-initiated explicitly
routed data path establishment (with or without the
associated resource reservation) was inducing behaviour not currently
supported by the Ethernet forwarding component - the reason for
maintaining the GELS list at that time was explicitly to maintain a
place where such discussion could happen

> I have no idea whether that means that the .1Q spec is in 
> scope or not.

independently of this i think we're entering the discussion that was the
key reason why efforts did not succeed... .1Q spec did not change since
then in order to accommodate this. there is a simple hope that another
ongoing effort would allow for such kind of behaviour.

> A
> 
> 
>