Subject: RE: Proposed CCAMP recharter

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Fri, 3 Aug 2007 10:33:47 +0200

Hi Adrian.

I agree with Dimitri about the use of the term "Ethernet". As we don't control IP but MPLS-TE, we're looking into controlling a "connection-oriented Ethernet" which isn't really Ethernet and not supported by typical "Ethernet switches". On the other hand, (echoing Dimitri again) we are also considering Ethernet services over any GMPLS-controlled layer.

I also agree it is useless to rearrange all short-term milestones (unlike the charter which has a more long-term value).

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of dimitri papadimitriou

adrian

couple of points on editorship:

- MRN req + eval. should imho be ready by end Aug.

- concerning the i/w document i'd like to suggest referring to MPLS-TE 
(rather than MPLS) since applying only to RSVP-TE

- also you refer to a solution for the latter but we just have req. and 
a framework since so far -> are u sure solution would be ready by Sep'07
or alternatively the former doc shall be split and further discussed

we need also a milestone for input to the MPLS security doc. but not 
sure this has to be recorded

concerning the charter, two specific comments

- like also mentioned during the second meeting, clarifying the term 
Ethernet types would be suggested otherwise entering in an open-ended
discussion about what is allowed/not allowed, desired/not-desired, 
possible/not possible, etc. and probably focus on the analytical work 
here (something we should have probably done in the GELS context but 
did not happen) - side note here it was always felt useful to have 
operational use case described as well but that work did also never happen

- is this milestone also including Ethernet service signaling e.g. MEF ? 
in that case i would suggest to make a clear distinction here ?

thanks,
-d.

Adrian Farrel wrote:
> Hi,
> 
> As discussed at the meeting(s) we should consider a small recharter to 
> put the GELS work clearly in scope and to indicate that we will work 
> with IEEE 802.1 as necessary.
> 
> We should take the opportunity to rejig the milestones, but noting that 
> a bunch of (overdue) milestones are about to be completed it is moot 
> whether we should rearrange them all. Basically, I am too lazy to do 
> that and propose just to change the ones that are further out.
> 
> I would like to ask you all to look at this and comment. In particular: 
> are the document editors happy with these targets?
> 
> ADs - your opinions too, please.
> 
> The changes proposed are...
> ===
> First paragraph
> OLD
> The CCAMP working group coordinates the work within the IETF defining a 
> common control plane and a separate common measurement plane for 
> physical path and core tunneling technologies of Internet and telecom 
> service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, 
> ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG.
> 
> NEW
> The CCAMP working group coordinates the work within the IETF defining a 
> common control plane and a separate common measurement plane for 
> physical path and core tunneling technologies of Internet and telecom 
> service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, 
> TDM switches, Ethernet switches, ATM and Frame Relay switches, and MPLS 
> GRE, in cooperation with the MPLS WG.
> ===
> Final paragraph
> OLD
> In doing this work, the WG will work closely with at least the following 
> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also 
> cooperate with the ITU-T.
> 
> NEW
> In doing this work, the WG will work closely with at least the following 
> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also 
> cooperate with the ITU-T, and the IEEE 802.1.
> ===
> Milestones (only those changed or new)
> 
> Aug 2007    First version WG I-D for Protocol solutions for MLN/MRN
> Aug 2007    First version WG I-D GMPLS OAM Requirements
> Sep 2007    Submit Informational I-D for Analysis of inter-domain issues 
> for disjoint and protected paths for IESG review
> Sep 2007    Submit MPLS to GMPLS migration strategies I-D for IESG review
> Sep 2007    Submit MPLS-GMPLS interworking requirements and solutions 
> I-D for IESG review
> Sep 2007    First version WG I-Ds for control of Ethernet networks
> Oct 2007    Submit Requirements for Multi-Layer and Multi-Region 
> Networks I-D for IESG review
> Oct 2007    Submit Evaluation of existing protocols for MLN/MRN for IESG 
> review
> Oct 2007    First version of WG I-D for additional MIB module to cover 
> RSVP-TE signaling extensions
> Dec 2007    Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
> Jan 2008    Submit ASON Routing solutions I-D for IESG review
> Feb 2008    Submit GMPLS OAM Requirements I-D for IESG review
> Mar 2008    Submit Protocol solutions for MLN/MRN I-D for IESG review
> Apr 2008    Submit MIB module for RSVP-TE signaling extensions for MIB 
> doctor and IESG review
> May 2008    Submit protocol extensions for control of Ethernet networks 
> for IESG review
> Dec 2008    Recharter or close Working Group
> ====
> 
> Thanks,
> Adrian
> 
> 
> 
> .
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Aug 2007 17:33:26 +0100

Hi Julien,

> I agree with Dimitri about the use of the term "Ethernet". As we don't
> control IP but MPLS-TE, we're looking into controlling a "connection-
> oriented Ethernet" which isn't really Ethernet and not supported by
> typical "Ethernet switches".

OK. I'll modify the text I just suggested to Dimitri, to say 
"connection-oriented"

> On the other hand, (echoing Dimitri again)
> we are also considering Ethernet services over any GMPLS-controlled
> layer.

Agree. But don't think we need milestones.

> I also agree it is useless to rearrange all short-term milestones (unlike 
> the
> charter which has a more long-term value).

I tend to agree, but I suspect that the IESG will find it hard to approve a 
re-charter with dates that have been passed.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Aug 2007 17:27:08 +0100

Hi Dimitri,

> - MRN req + eval. should imho be ready by end Aug.

Sure. But by the time we have been through WG last call and done the updates 
:-(

> (rather than MPLS) since applying only to RSVP-TE

Right. As reflected in the actual names of the I-Ds.

> - also you refer to a solution for the latter but we just have req. and a 
> framework since so far -> are u sure solution would be ready by Sep'07

I'll strike "and solutions" from the milestone.

> we need also a milestone for input to the MPLS security doc. but not sure 
> this has to be recorded

Do we need a specific milestone for this?
The work is being done in the MPLS WG with consultation to CCAMP. I think 
this is just a case of CCAMP needing to review proactively and reactively, 
and needing to generate text according to what we find.

> possible/not possible, etc. and probably focus on the analytical work here 
> (something we should have probably done in the GELS context but did not 
> happen) - side note here it was always felt useful to have operational use 
> case described as well but that work did also never happen

OK, so you'd like the charter to reflect something of the rules of 
engagement that we set out in GELS?

In that case, we will need to add a specific item to the list of scope 
topics in the charter.

- Work on procedures and extensions to GMPLS for the control
  of Ethernet devices for data planes that are already approved by
  an SDO with responsibility for the Ethernet data plane. It is
  expected that the primary SDO in this case is the IEEE. Note
  that the specification or modification of Ethernet data planes is
  out of scope.

> in that case i would suggest to make a clear distinction here ?

Some work, I think, is within scope and does not need a specific milestone. 
We don't need to introduce milestones for every I-D.

Thanks,
Adrian

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 15 Aug 2007 20:15:30 -0400

Hi Adrian

Hi Adrian

The description of the term "connection-oriented" does not hold quite
the same meaning in the IEEE as in the IETF.  In IEEE, my understanding
is that unicast and multicast services in Ethernet are all considered
"connections" or "associations" when they are part of the same Service
VLAN or Service Instance. So many types of Ethernet services can be
considered "connection-oriented".    

Therefore the term "connection-oriented" might be confusing. (The IETF
also considers TCP "connection oriented" even though IP is
connectionless datagram based.) 

I would suggest we use something descriptive like "Explicit Route
Controlled Paths", or "Automating Configured Ethernet Paths".  

Just a suggestion,
Don   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Hi Julien,

> charter which has a more long-term value).

I tend to agree, but I suspect that the IESG will find it hard to
approve a 
re-charter with dates that have been passed.

Thanks,
Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 16 Aug 2007 10:29:07 +0200

don & adrian

 > Controlled Paths", or "Automating Configured Ethernet Paths".

i think the concern is to draw a line between VLAN-bridged Ethernet/MSTP 
and X/Y, where Y is what is under discussion at CCAMP and X is what one 
tries with this thread to qualify e.g. "source-controlled and 
explicitly-routed Ethernet data paths" (approved by an SDO responsible 
for the Ethernet data plane) or something along these lines would 
prevent that confusion.

-d.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 16 Aug 2007 06:31:42 -0700 (PDT)

Hi Don,

I disagree with you on this. 

It all depends on definition of connection. If one agrees on the following major properties of a p2p/p2mp connection:

a) single source;
b) zero flexibility in forwarding packets along the connection;
c) deterministic resource reservation 

then one can see the difference between, say, Ethernet service (which is an association between source(s) and destination(s)) and Ethernet connection (which is a set of network resources connecting the source to the destination(s)). Ethernet services may be provided by either connection-oriented or connectionless Ethernet networks. Ethernet services, as we know, may be also provided by non-Ethernet (e.g. IP/MPLS) networks).
PBB-TE IMO is all about Ethernet connections rather than Ethernet services.

The bottom line: I think it is correct to have the "connection-oriented Ethernet" clause in the CCAMP charter.

Igor

Don Fedyk <[email-masked]> wrote: Hi Adrian

Hi Adrian

Just a suggestion,
Don   

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

Thanks,
Adrian 

---------------------------------
Pinpoint customers who are looking for what you sell.

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 16 Aug 2007 09:47:29 -0400

Hi Adrian
 
It's OK you disagree. :-)  I myself would have used the term connection
oriented a while back. However I have observed that others have a
different interpretation and connection oriented Ethernet is confusing
to that crowd. I do believe this a difference between service and
network as you point out but traditional Ethernet has a tighter coupling
between network and service and the distinction is more subtle. Ethernet
packets are not forwarded in a hop by hop paradigm, they follow a VLAN
or source based tree always. 
 
So rather than put confusing text I prefer what Adrian has proposed.  
 
Regards,
Don 

________________________________

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: Thursday, August 16, 2007 9:32 AM
	To: Fedyk, Don (BL60:1A00); Adrian Farrel; MEURIC Julien
RD-CORE-LAN
	Cc: [email-masked]
	Subject: RE: Proposed CCAMP recharter

	Hi Don,

	It all depends on definition of connection. If one agrees on the
following major properties of a p2p/p2mp connection:
	
	a) single source;
	
	then one can see the difference between, say, Ethernet service
(which is an association between source(s) and destination(s)) and
Ethernet connection (which is a set of network resources connecting the
source to the destination(s)). Ethernet services may be provided by
either connection-oriented or connectionless Ethernet networks. Ethernet
services, as we know, may be also provided by non-Ethernet (e.g.
IP/MPLS) networks).
	PBB-TE IMO is all about Ethernet connections rather than
Ethernet services.
	
	The bottom line: I think it is correct to have the
"connection-oriented Ethernet" clause in the CCAMP charter.
	
	Igor
	
	Don Fedyk <[email-masked]> wrote: 

		Hi Adrian
		
		Hi Adrian
		
		The description of the term "connection-oriented" does
not hold quite
		the same meaning in the IEEE as in the IETF. In IEEE, my
understanding
		is that unicast and multicast services in Ethernet are
all considered
		"connections" or "associations" when they are part of
the same Service
		VLAN or Service Instance. So many types of Ethernet
services can be
		considered "connection-oriented". 
		
		Therefore the term "connection-oriented" might be
confusing. (The IETF
		also considers TCP "connection oriented" even though IP
is
		connectionless datagram based.) 
		
		I would suggest we use something descriptive like
"Explicit Route
		Controlled Paths", or "Automating Configured Ethernet
Paths". 
		
		Just a suggestion,
		Don 
		
		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of Adrian Farrel
		Hi Julien,
		
		> typical "Ethernet switches".
		
		OK. I'll modify the text I just suggested to Dimitri, to
say 
		"connection-oriented"

		
		> I also agree it is useless to rearrange all short-term
milestones
		(unlike 
		> charter which has a more long-term value).
		
		I tend to agree, but I suspect that the IESG will find
it hard to
		approve a 
		re-charter with dates that have been passed.
		
		Thanks,
		Adrian 

	
________________________________

	Pinpoint customers
<http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yahoo.com/arp/
sponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&s=Y&s2=EM&b=50> who
are looking for what you sell.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 16 Aug 2007 07:20:35 -0700 (PDT)

Adrian is proposing:

- Work on GMPLS procedures and extensions to support source-controlled and explicitly-routed Ethernet data paths for Ethernet data planes that are already approved by an SDO with  responsibility for the Ethernet data plane....

IMO this is lacking the fact that while computing the mentioned paths we will consider various TE proprieties of Ethernet links, and while setting up the paths we will perform resource reservation. I mean explicitly routed paths may be computed and established without any TE considerations, and that's not what we are planning to do in CCAMP. 

So, I would change the text to something like:

- Work on GMPLS procedures and extensions to support Traffic Engineered Ethernet data paths for Ethernet data planes that are already approved by an SDO with  responsibility for the Ethernet data plane....

 It's OK you disagree. :-)  I myself would have used  the term connection oriented a while back. However I have observed that others  have a different interpretation and connection oriented Ethernet is confusing to  that crowd. I do believe this a difference between service and network as you  point out but traditional Ethernet has a tighter coupling between network and  service and the distinction is more subtle. Ethernet packets are not forwarded  in a hop by hop paradigm, they follow a VLAN or source based tree always.  

 Regards,
 Don 

To: Fedyk, Don (BL60:1A00); Adrian Farrel; MEURIC Julien    RD-CORE-LAN

Hi Don,

a) single source;

Igor

Hi Adrian

Just a suggestion,
Don      

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

Thanks,
Adrian 

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 16 Aug 2007 17:39:25 +0200

> [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: Thursday, August 16, 2007 4:21 PM
> To: Don Fedyk; Adrian Farrel; MEURIC Julien RD-CORE-LAN
> Cc: [email-masked]
> - Work on GMPLS procedures and extensions to support 
> source-controlled and explicitly-routed Ethernet data paths 
> for Ethernet data planes that are already approved by an SDO 
> with  responsibility for the Ethernet data plane....
> 
> IMO this is lacking the fact that while computing the 
> mentioned paths we will consider various TE proprieties of 
> Ethernet links, and while setting up the paths we will 
> perform resource reservation. I mean explicitly routed paths 
> may be computed and established without any TE 
> considerations, and that's not what we are planning to do in CCAMP. 
>
> - Work on GMPLS procedures and extensions to support Traffic 
> Engineered Ethernet data paths for Ethernet data planes that 
> are already approved by an SDO with  responsibility for the 
> Ethernet data plane....

if you do so, you then come back to the initial issue. TE data
paths & mechanisms are not CCAMP specific (and may applied to 
bridged Ethernet) hence you would not characterize the Ethernet
mode - see my previous post - 

so suggest to rephrase as:

- Work on traffic-engineering mechanisms and extensions to 
  support source-controlled and explicitly-routed Ethernet  
  data paths for Ethernet data planes that are already approved 
  by an SDO with responsibility for the Ethernet data plane. It 
  is expected that the primary SDO in this case is the IEEE. 
  Note that the specification or modification of Ethernet data 
  planes is out of scope.

-d.

> 	It's OK you disagree. :-)  I myself would have used the 
> term connection oriented a while back. However I have 
> observed that others have a different interpretation and 
> connection oriented Ethernet is confusing to that crowd. I do 
> believe this a difference between service and network as you 
> point out but traditional Ethernet has a tighter coupling 
> between network and service and the distinction is more 
> subtle. Ethernet packets are not forwarded in a hop by hop 
> paradigm, they follow a VLAN or source based tree always. 
> 	 
> 		It all depends on definition of connection. If 
> one agrees on the following major properties of a p2p/p2mp connection:
> 		
> 		a) single source;
> 		then one can see the difference between, say, 
> Ethernet service (which is an association between source(s) 
> and destination(s)) and Ethernet connection (which is a set 
> of network resources connecting the source to the 
> destination(s)). Ethernet services may be provided by either 
> connection-oriented or connectionless Ethernet networks. 
> Ethernet services, as we know, may be also provided by 
> non-Ethernet (e.g. IP/MPLS) networks).
> 		The bottom line: I think it is correct to have 
> the "connection-oriented Ethernet" clause in the CCAMP charter.
> 		
> 		Igor
> 		
> 			The description of the term 
> "connection-oriented" does not hold quite
> 			Therefore the term 
> "connection-oriented" might be confusing. (The IETF
> 			> I also agree it is useless to 
> rearrange all short-term milestones
> 			(unlike 
> 			> the
> <http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yaho
> o.com/arp/sponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&
> s=Y&s2=EM&b=50> who are looking for what you sell. 
> 
> 
> Yahoo! oneSearch: Finally, mobile search that gives answers 
> <http://us.rd.yahoo.com/evt=48252/*http://mobile.yahoo.com/mob
> ileweb/onesearch?refer=1ONXIC> , not web links. 
>