Subject: Closing the GELS Mailing List

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Sep 2007 10:27:26 +0100

We propose to close the GELS mailing list.

Loa wrote...

> I tend to support this, but it begs two questions:
>
> - when will the charter update be ack'ed?

I don't know, and I can't promise that it will be ack'ed. but the Routing 
ADs appear to support the change.

> - in the (unlikely) case where we don't get an ack for
>  gels work the gels-list won't be needed anyhow, so;
>  isn't the effect of the of your statement below that
>  the gels-list is dead as of now? Especially since the
>  on thing we are discussing at the moment is the charter
>  update and this is on the ccamp list??

Absolutely.

I'll give you all a last chance to scream.

Thanks,
Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 6 Sep 2007 15:59:47 +0200

adrian,

you could leave the gels list for the list for the techno-specific
discussions and the ccamp list for the non-techno specific discussions

in any case, i believe the value of gels was so far to allow open
discussion on a topic that was on charter 

-> question: does proposed incorporation in charter (with milestones to
be better shaped inline with progress of IEEE) elevate any other need ?
complete decoupling of discussion has been shown to be difficult to be
realized in the past

thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, September 06, 2007 11:27 AM
> To: [email-masked]; gels
> Cc: Ross Callon
> Subject: Closing the GELS Mailing List
> 
> I don't know, and I can't promise that it will be ack'ed. but 
> the Routing ADs appear to support the change.
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 6 Sep 2007 16:26:42 +0200

attila - yes. but CCAMP is only about "Control" -

-d.

> [mailto:[email-masked]] On Behalf Of Attila Takacs (IJ/ETH)
> Sent: Thursday, September 06, 2007 4:25 PM
> To: Adrian Farrel; [email-masked]; gels
> Cc: Ross Callon
> Subject: RE: Closing the GELS Mailing List
> 
> Hi all,
> 
> I support closing the gels list. 
> 
> Since decoupling the discussions into "techno-specific" and GMPLS
> specific part is very difficult, if at all possible, I do not 
> see how to
> benefit from a separate forum for techno-specific aspects. IMHO, it
> would be much clearer having a single forum for all related 
> discussions
> anyway.
> 
> Best regards,
> Attila
> 
> 
> > gels work the 
> > > gels-list won't be needed anyhow, so;  isn't the effect of 
> > the of your 
> > > statement below that  the gels-list is dead as of now? Especially 
> > > since the  on thing we are discussing at the moment is 
> the charter

---

From: "Attila Takacs (IJ/ETH)" <[email-masked]>
Date: Thu, 6 Sep 2007 16:24:45 +0200

Hi all,

Since decoupling the discussions into "techno-specific" and GMPLS
specific part is very difficult, if at all possible, I do not see how to
benefit from a separate forum for techno-specific aspects. IMHO, it
would be much clearer having a single forum for all related discussions
anyway.

Best regards,
Attila

> > since the  on thing we are discussing at the moment is the charter

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 6 Sep 2007 10:41:12 -0400

Hi Adrian

Dmitri does have a point that if there is a topic that heads into the
"weeds" we could direct it to the GELS list explicitly.  

Is there a cost of keeping it open?

Regards,
Don  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of PAPADIMITRIOU Dimitri
Sent: Thursday, September 06, 2007 10:00 AM
To: Adrian Farrel; [email-masked]; gels
Cc: Ross Callon
Subject: RE: Closing the GELS Mailing List

adrian,

thanks,
-dimitri.

---

From: "Attila Takacs (IJ/ETH)" <[email-masked]>
Date: Thu, 6 Sep 2007 17:01:43 +0200

Hi Don,

This sounds good, however I doubt that it can be smoothly enforced. How
to determine when a discussion is to be moved to the gels list, and,
maybe, when is it eligible to be moved back to ccamp? It will be
difficult to follow up mixed threads.

On the other hand, I suspect that most of the ccamp list members are
also subscribed to the gels list so I do not really see the benefit of
having two lists; expect setting different filtering rules in your
mailer (well, this might be an argument enough in itself :-))

Best regards,
Attila

> [mailto:[email-masked]] On Behalf Of Don Fedyk
> Sent: Thursday, September 06, 2007 4:41 PM
> To: PAPADIMITRIOU Dimitri; Adrian Farrel; [email-masked]; gels
> Cc: Ross Callon
> Dmitri does have a point that if there is a topic that heads 
> into the "weeds" we could direct it to the GELS list explicitly.  
> 
> [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> you could leave the gels list for the list for the 
> techno-specific discussions and the ccamp list for the 
> non-techno specific discussions
> 
> in any case, i believe the value of gels was so far to allow 
> open discussion on a topic that was on charter 
> 
> complete decoupling of discussion has been shown to be 
> difficult to be realized in the past
> 
> thanks,
> -dimitri.
> 
> 
>  
> 
> > I don't know, and I can't promise that it will be ack'ed. but the 
> > Routing ADs appear to support the change.
> > 
> > > - in the (unlikely) case where we don't get an ack for  gels work 
> > > the gels-list won't be needed anyhow, so;  isn't the 
> effect of the 
> > > of your statement below that  the gels-list is dead as of now? 
> > > Especially since the  on thing we are discussing at the moment is 
> > > the charter  update and this is on the ccamp list??
> > 
> > Absolutely.
> >

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 6 Sep 2007 11:53:14 -0400

> Sent: Thursday, September 06, 2007 10:41 AM

Is there a cost for discussing them at CCAMP? I prefer a central place
for all discussions.   

Thanks

Regards... Zafar

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 6 Sep 2007 11:54:24 -0400

> Sent: Thursday, September 06, 2007 10:27 AM
> To: Attila Takacs (IJ/ETH); Adrian Farrel; [email-masked]; gels
> Cc: Ross Callon

And for interface with Standards Body owning forwarding. Not to mention
we are all "technical". What else is left? 

Thanks

Regards... Zafar 

> > specific part is very difficult, if at all possible, I do 
> not see how 
> > to benefit from a separate forum for techno-specific 
> aspects. IMHO, it 
> > discussions anyway.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 6 Sep 2007 20:57:22 +0200

zafar

the main problem remains - to take a base example
in its work plan Adrian mentions

2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)"

[...]
- Label allocation and swapping rules 
[...]

is that not a forwarding component discussion ?

beside the fact that there is an assumption on what
label means and how it is represented in data plane

thanks,
-d.

> From: Zafar Ali (zali) [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 5:54 PM
> To: PAPADIMITRIOU Dimitri; Attila Takacs (IJ/ETH); Adrian 
> Farrel; [email-masked]; gels
> Cc: Ross Callon

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Sep 2007 09:59:28 +0100

I think this thread is a representation in miniature of the issues 
involved...

- All the emails in this thread have been copied to both mailing lists
- All the participants in the thread are subscribed to both mailing lists

No, it doesn't cost to have both lists active.
No, it doesn't cost to have all of the threads on CCAMP.

Please note that we should not discuss the data plane. If you don't 
understand (or don't like, or don't want to use) the data plane you should 
have your discussions in private or at the IEEE.

Dimitri said...

> is that not a forwarding component discussion ?

It is certainly informed by the forwarding component (i.e. the definition of 
the data plane), but the rules we need to define are the rules for the 
control plane. I.e. (and for example, only) if the forwarding plane defines 
that the label allocated on the upstream interface must be numerically one 
greater than the label allocated on the downstream interface, this rule must 
be referenced in the control plane specification. This is important since it 
is a constraint placed on the normal per-interface operation of GMPLS. That 
makes it CCAMP work.

> 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.

Thanks,
Adrian

---

From: "tom.petch" <[email-masked]>
Date: Fri, 7 Sep 2007 12:25:46 +0200

Adrian

Just to break the pattern, I am not on the GELS list - never got round to it -
and would be very happy to see them merged.

A list should reflect a community of interest and I think that there is only one
here.  The work of CCAMP has a wider impact on other SDOs and liaisons form a
significant part of CCAMP's work.  Where GELS is different is the SDO to liaise
with, but I do not see that as justification for a separate list.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>; "Zafar
Ali (zali)" <[email-masked]>; "Attila Takacs (IJ/ETH)"
<[email-masked]>; <[email-masked]>; "gels" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>
Sent: Friday, September 07, 2007 10:59 AM
Subject: Re: Closing the GELS Mailing List

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 7 Sep 2007 17:35:41 +0200

adrian

> From: Adrian Farrel [mailto:[email-masked]] 
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Attila Takacs 
> (IJ/ETH); [email-masked]; gels
> Cc: Ross Callon

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.

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 19:07:28 +0100

Dimitri wrote 07 September 2007 16:36 in response to Adrian <snipped>

> 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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 7 Sep 2007 20:22:49 +0200

point is: 

whether the ethernet frame header fields can be interpreted as "labels"
that follows label switching rules applicable to an LSR and what are the
implications on forwarding component behaviour when considering such
"label encoding"

note: per 3031 a label is: a short fixed length physically contiguous
identifier which is used to identify a FEC, usually of local
significance. 
 
-d.
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 8:07 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 7 Sep 2007 14:46:53 -0400

Dmitri 

Quoting from GMPLS RFC 3945 seems far more applicable given we are
talking a Generalized label switch router (LSR).

"2. Layer-2 Switch Capable (L2SC) interfaces:

      Interfaces that recognize frame/cell boundaries and can switch
      data based on the content of the frame/cell header.  Examples
      include interfaces on Ethernet bridges that switch data based on
      the content of the MAC header and interfaces on ATM-LSRs that
      forward data based on the ATM VPI/VCI. "

Don 

-----Original Message-----

point is: 

 
-d.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 7 Sep 2007 12:21:21 -0700 (PDT)

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 

[email-masked] wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian 

regards, Neil

---------------------------------
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 7 Sep 2007 21:28:32 +0200

hi adrian,

> Sent: Friday, September 07, 2007 8:40 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Hi Dimitri,
> >> 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.
> 
> this effort
> 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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 7 Sep 2007 21:59:20 +0200

don, 

interesting 3 years ago you blaim me on the same list when i quoted this
definition when discussing applicability of GMPLS to Ethernet ;-)

the evolution of Ethernet forwarding components themselves leads to an
open issue today compared to the situation we observed a couple of years
ago. if this would not be true one would have not seen since this
definition has been written end 2000 in rfc3945 that there has been
lot's efforts in various bodies involved in Ethernet to incorporate as
part of that technology properties that would facilitate Ethernet
network operations -- and this due to its expected applicability in
environments for which that technology has not been initially designed
for -- and this is whole point actually (*)

back to the point: when that definition was written down it was
understood that adding GMPLS control plane to an Ethernet fowarding
plane would lead to address such expectations. nevertheless, we ack'ed
since the GELS BoF (held by Loa and myself) in 2005 that the
"combination" would be possible if one of the following conditions hold

- IEEE provides a data plane spec. that allows accommodating the fwd'ing
behaviour determined by GMPLS (and all related routing paradigms)

- IEEE ack's that some if its header's field can be processed
equivalently to a per-platform/link-local switching "label" with all its
resulting implications (if fact the answer was never totally clear at
the end)

- GMPLS evolves to sustain all control modes connectionless fwd'ing
would allow (this option was not even discussed)

=> hence, the question remains open. i would love to see progress on
that matter (at least that IEEE tells us yes or no) but for the time
being we're left with unilateral interpretations that are blocking real
progress from the std perspective (the problem is mainly not technical
... it is the problem that CCAMP faces each time its prefered control
plane protocol suite tries to cover a technology)

(*) it was felt 2 or 3 years ago that operators could help and provide
us with their expectation in that respect but no real outcome came out
of various tentatives to obtain such type of operational feedback

> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 8:47 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> > > > CCAMP although

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 21:55:07 +0100

OK, thanks.  I tend to take my cues from the unified modelling work
where I can see (and challenge if need be) the logical derivation of how
labelling and resource partitioning work in each network mode....I don't
see that degree of rigour in the shorter statement below.  Is there
something technically incorrect in what I stated previously?

regards, Neil

> From: PAPADIMITRIOU Dimitri
> [mailto:[email-masked]] 
> Sent: 07 September 2007 19:23
> To: Harrison,N,Neil,JCGA1 R; [email-masked]; 
> whether the ethernet frame header fields can be interpreted
> as "labels" that follows label switching rules applicable to 
> an LSR and what are the implications on forwarding component 
> behaviour when considering such "label encoding"
> 
> 
> note: per 3031 a label is: a short fixed length physically
> contiguous identifier which is used to identify a FEC, 
> usually of local significance. 
>  
> -d.
> > > > 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.
> > > 

> > > 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.
> > 
> > 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
> > 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

> > 'route discriminator label' and a local extension to the SA
> or DA, ie
> > it provides the ability to identify disjoint paths between nodal end

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 21:54:51 +0100

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:[email-masked]] 
Sent: 07 September 2007 20:21
To: Harrison,N,Neil,JCGA1 R; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
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 

[email-masked] wrote: 

Dimitri wrote 07 September 2007 16:36 in response to Adrian 

regards, Neil

  _____  

Sick sense of humor? Visit Yahoo! TV's Comedy
<http://us.rd.yahoo.com/evt=47093/*http://tv.yahoo.com/collections/222>
with an Edge to see what's on, when.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Sep 2007 19:40:07 +0100

Hi Dimitri,

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.

> 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.

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.

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

A

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 7 Sep 2007 14:32:55 -0700 (PDT)

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

[email-masked] wrote:   Message    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:[email-masked]] 
Sent: 07 September 2007    20:21
To: Harrison,N,Neil,JCGA1 R;    [email-masked]; [email-masked]; [email-masked];    [email-masked]; [email-masked];    [email-masked]
Cc: [email-masked]
Subject: RE:    Closing the GELS Mailing List

   Hi Neil,

   
   Cheers,
   Igor    

regards, Neil

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

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 22:42:27 +0100

Hi Igor, I'd disagree with you for the reasons I attempted to explain to
Dimitri, ie depends on the network mode....in the cl-ps mode the SA
*label* is pretty important.  The only reason we have usually not
traditionally incorporated a SA label in co mode network traffic units
is that, under misconnectivity defect-free conditions, it is redundant
information...the connection itself provides that information.  However,
there are important benefits to be had from having a SA in each/every
traffic unit, and if these are already there 'for free' then it would be
sheer folly not to recognise them for what they are and use them.
 
regards, Neil...have great weekend yourself, I'm signing off now.

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: 07 September 2007 22:33
To: Harrison,N,Neil,JCGA1 R; [email-masked];

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

 
regards, Neil

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: 07 September 2007 20:21
To: Harrison,N,Neil,JCGA1 R; [email-masked];

Hi Neil,

regards, Neil

  _____  

  _____  

Yahoo! oneSearch: Finally, mobile
<http://us.rd.yahoo.com/evt=48252/*http://mobile.yahoo.com/mobileweb/one
search?refer=1ONXIC> search that gives answers, not web links.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 7 Sep 2007 14:58:42 -0700 (PDT)

I fully understand what are saying and I think we are in agreement here: I am not saying that SA is unimportant, quite on the contrary. What I am saying is that SA is not a label in the CP signaling sense, rather, it is a property that is signaled in the opposite direction compared to one the label is signaled (like bandwidth, link affinities, etc.)

Igor

[email-masked] wrote:   Message    Hi Igor, I'd disagree with you for the reasons I attempted to explain to  Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is  pretty important.  The only reason we have usually not traditionally  incorporated a SA label in co mode network traffic units is that, under  misconnectivity defect-free conditions, it is redundant information...the  connection itself provides that information.  However, there are important  benefits to be had from having a SA in each/every traffic unit, and if these are  already there 'for free' then it would be sheer folly not to recognise them for  what they are and use them.

   -----Original Message-----
From: Igor Bryskin    [mailto:[email-masked]] 
Sent: 07 September 2007    22:33
To: Harrison,N,Neil,JCGA1 R;    [email-masked]; [email-masked]; [email-masked];    [email-masked]; [email-masked];    [email-masked]
Cc: [email-masked]
Subject: RE:    Closing the GELS Mailing List

Have a great    weekend.
Igor

[email-masked] 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:[email-masked]] 
Sent: 07 September 2007        20:21
To: Harrison,N,Neil,JCGA1 R;        [email-masked]; [email-masked];        [email-masked]; [email-masked]; [email-masked];        [email-masked]
Cc: [email-masked]
Subject: RE:        Closing the GELS Mailing List

       Hi Neil,

       
       Cheers,
       Igor        

regards, Neil

       

---------------------------------
Shape Yahoo! in your own image.  Join our Network Research Panel today!

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 8 Sep 2007 10:02:44 +0200

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.

> Sent: Friday, September 07, 2007 9:21 PM
> To: [email-masked]; PAPADIMITRIOU Dimitri; 
> 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 
> So, IMO IEEE should be responsible for the definition of data 
> plane labels, while CCAMP for control plane labels.
>  
> Cheers,
> Igor 
> 
> 
> having both a SA
> ________________________________
> 
> Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge 
> <http://us.rd.yahoo.com/evt=47093/*http://tv.yahoo.com/collect
> ions/222> to see what's on, when. 
>

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 8 Sep 2007 06:36:15 -0700 (PDT)

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

-d.

       
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.

---

From: <[email-masked]>
Date: Sat, 8 Sep 2007 15:32:36 +0100

Thanks Igor...just want to slightly correct/amend something
below...please see in-line:

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: 08 September 2007 14:36
To: PAPADIMITRIOU Dimitri; Harrison,N,Neil,JCGA1 R; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
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). 
NH=> Yes, it is true that having a SA label in each/every traffic unit
is an important advantage...and so is having a DA address label (for
forwarding) that does not have to be swapped.  As I pointed out before,
one can take some short-cuts and traditional co-ps mode technologies
have (perhaps unconsciously?) done so, viz:
 -    if one respects the requirements of a connection then you can omit
the SA label from the DP traffic units....as under defect-free
conditions it is redundant information.  However, this means OAM
(essentially a CV flow that contains the SA label) should (but really
ought to be must for customer integrity/security reasons) be run on ALL
connections (irrespective of their importance) as one cannot predict a
priori where misconnectivity defects will occur.  But this is
significantly operationally inferior to having the SA information
carried in the traffic unit as this makes the network inherently robust
to such defects without any OAM at all.
-    wrt forwarding one only needs to resolve/identify (ie label) the
number of client instances that a given server layer resource partition
can support per client link connection.....noting that said labels are
indeed indirection proxies for the true DA anyway.  However, this is
also operationally inferior to using a true connection DA for forwarding
that is not swapped.
 
Now if you don't respect the requirements of a connection, and both LDP
and PHP in MPLS don't as they create mp2p constructs, then you have to
appeal to a higher layer entity to effect a demerging function, ie
essentially recover the lost SA information.  If the client is a cl-ps
mode technology with non-overlapping addresses this can do the job
directly.  If this is not the case you have to add the lost information
some other way....and in MPLS this is done by adding a further 1-hop LSP
where the label here now takes on the semantic of SA.  But this is
actually not a very sensible approach because one of the key operational
things we need in any layer network is consistent Characteristic
Information (ie consistent traffic unit structure, consistent traffic
unit functional field semantics and consistent OAM).  Why is this
important?  Well, if one has misconnectivity defects present it is
important that the trail (co mode) or flow (cl mode) termination points
handles the traffic units and OAM in a consistent and predictable way.
MPLS does not have consistent CI....indeed I can list at least 4
different semantics of a label and more will emerge as folks consider
new applications like p2mp constructs.
 
There are many other consequences of merging constructs, but I don't
want to get into these here.
 
regards, Neil
 
  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:
<!--[if !supportLists]-->a)     <!--[endif]-->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;
<!--[if !supportLists]-->b)    <!--[endif]-->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

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

-d.

  _____  

Ready for the edge of your seat? Check out
<http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/> tonight's top
picks on Yahoo! TV.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 8 Sep 2007 18:38:22 +0200

igor  

> 	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 

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.
> Sent: Saturday, September 08, 2007 3:36 PM
> 	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. 
> 	 
> 	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 
> 	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
> 	
> 	
> 	
> 	
> 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. 
>

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 9 Sep 2007 08:12:57 -0700 (PDT)

Dimitri,
   
  Please, see in line.
   
  Igor
 
 PAPADIMITRIOU Dimitri <[email-masked]> wrote:
  igor 

 
 we are not taking a data plane specification in its basic sense for
 which CCAMP adds a control plane.
   
  IB>>  I totally disagree. That is exactly what we should do in CCAMP and my understanding is that this is what operators expect us to do.
   
   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. 

   
  IB>> Again, this is exactly opposite to my understanding. IMO we should consider only connection-oriented Ethernet, such as 802.1ay for PBB-TE or, say, 802.1xyz for VID cross-connected Ethernet (only after such data plane is endorsed by IEEE). We should not consider any connectionless Ethernet (802.1ad,ah, etc.).: GMPLS so far  is/was all about connections and nothing else: to correct deficiencies of connectionless Ethernet native control plane ((R,M)STPs) in CCAMP IMO is as inappropriate as correcting deficiencies of MPLS in ITU (I mean designing T-MPLS)
   
  Cheers,
  Igor  

 
 -d.
 > on 

       
---------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.

---

From: <[email-masked]>
Date: Mon, 10 Sep 2007 13:40:01 +0100

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

[email-masked] <> wrote:
>> 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.
> 
> 
>> DMAC/VID? just VID?  nothing as in case of statically configured
>> connections? Is it network-scope? node-scope?
>> Cc: [email-masked] Subject: RE: Closing the GELS Mailing List
>> 
>> 	Dimitri,
>> 
>> 	> plane labels, while CCAMP for control plane labels. 	>
>> 	> Cheers,
>> 	> Igor
>> 	>
>> 	>
>> 	> > CCAMP although > > > "what is a label" would come to us from
>> 	the data plane 	> > specification. > >
>> 	> > distribution" protocol in IETF - being domain-wide or
>
>> 	link-local > > -
>> 	> >
>> 	information field ? > >
>> 	> 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.
>> 	>
>> 	> '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
>> 	> 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. >
>> 	> does not change the fact that this is what they are. So
> I'm
>> 	not clear > what your real point is here.
>> 	>
>> 	> regards, Neil
>> 	>
>> 	>
>> 	>
>> 	>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 12 Sep 2007 07:54:48 +0200

> No, it doesn't cost to have both lists active.

well - it does for me, since the gels-list is not on one of
the ietf-servers, and tends to be hit by quite a bit of spam
and the IETF spam filters can't be applied; I have to sift
through quite a bit of debris, floatsam and junk to try to find
any nuggets in the stream
if I've to do that for things that the wg chairs say could go to
the ccamp list anyway I'd rather do something else.

Adrian,
when can I close the list?

/Loa

> understand (or don't like, or don't want to use) the data plane you
> should have your discussions in private or at the IEEE.
> 
> Dimitri said...
> 
> It is certainly informed by the forwarding component (i.e. the
> definition of the data plane), but the rules we need to define are the
> rules for the control plane. I.e. (and for example, only) if the
> forwarding plane defines that the label allocated on the upstream
> interface must be numerically one greater than the label allocated on
> the downstream interface, this rule must be referenced in the control
> plane specification. This is important since it is a constraint placed
> on the normal per-interface operation of GMPLS. That makes it CCAMP work.
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com