AW: AW: [Dcpel] FWD: [Re: proposed charter]

["Tschofenig, Hannes" <[e-mail]>]

Hi Olivier, 
 
Hello Hannes,

Thanks to your pointer.

I remember at the beginning of NSIS WG the great debate about on-path vs. off-path. The conclusion have been to choose to study only on-path within NSIS. In parallel, a BoF was setup to attempt to create an off-path WG. Unfortunately this was cancel too.

NSIS was always chartered with a focus on path-coupled signaling in mind. 
Still, there was a lot of interest on transition scenarios that require some path-decoupled processing. In some sense, this is almost a philosophical discussion. 
 
For example, is RFC 2749 (about COPS and RSVP interaction) off-path/path-decoupled signaling? What about RFC 3084? 
 
Unfortunately, the term "off-path" is a little bit overloaded and means different things to different people (like the term 'NGN' is heavily overloaded as well). This caused a lot of confusion. If there is confusion then it is, in general, quite good to think about it a little bit longer. 
That's what we did. 

So, I'm surprise and the same time happy to see that NSIS will again start studying off-path or try to attempt a BoF.  
 
Don't be surprised. These aspects have been topic for many, many discussions in the past. 

In my opinion, DCPEL and off-path NSIS have more or less the same objective looking at 2 different approaches. Perhaps a good deal will to merge the 2 initiatives to form a larger and greater consensus. 
 
Why do you think that they look at two different approaches?
 

In the same time, some ideas from EuQoS project (http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-00.txt <http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-00.txt> ) have been submit to the NSIS WG about a such approach (in fact, we used NSIS for our Resource Manager communication). 
 
We have been in contact with the authors based on the NSIS interim meeting in May 2005 and the interop in Paris a few months later. 
It is very interesting to see this type of input. 
 
 
Ciao
Hannes
 
Regards,

Olivier

Tschofenig, Hannes a écrit : 

		Hi Olivier, 
		Hi David, 
		
		I agree with David that there is essentially a lot of protocol work (hopefully "only" extensions) that seems to be envisioned by DCPEL. A few weeks ago Georgios has sent a mail asking for the relationship between the IETF work and other QoS work that is currently being done outside the IETF. There are many proposals being made today that need to be considered. These organizations are, for various reasons, really crazy about QoS and QoS signaling. As I noted at the last IETF meeting I think that the best place for these discussions is the Transport Area where this type of protocol discussions already happened in the past. 
		
		The IETF NSIS work has discussed various aspects of path-decoupled signaling approaches in the past and there are still proposals floating around. You might be interesting to see that there will be a discussion about this subject at the next IETF meeting. See http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.html It might be interesting for you to attend the NSIS WG session to share your thoughts with other QoS minded people. Furthermore, a number of us have been in contact with the ITU-T (and the ITU-T liaison person from the ITU-T side, Hui-Lan Lu, in particular), including John Loughney and myself, to discuss how their requirements can be brought to the IETF/NSIS working group to have a fruitful discussion. 
		
		Ciao
		Hannes
		
		  

			Hello David,
			
			Here it is some comments from an operator (ok R&D part only)  !!!
			
			David Kessens a écrit :
			    

				Kathie asked me whether I would be willing to share the 
				      

			following mail
			    

				with the group on my current thinking regarding a bof for dcepl.
				
				I obviously have no problem with that so please see below 
				      

			for my mail
			    

				to Kathie regarding this topic. I, and the other ADs CC'ed on this
				mail, are interested in your comments.
				
				I hope this helps,
				
				David Kessens
				---
				
				----- Forwarded message from David Kessens 
				      

			<[e-mail]> <mailto:[e-mail]>  -----
			    

				Date: Mon, 6 Mar 2006 20:58:32 -0800
				From: David Kessens <[e-mail]> <mailto:[e-mail]> 
				To: Kathleen Nichols <[e-mail]> <mailto:[e-mail]> 
				Subject: Re: proposed charter
				
				
				Kathie,
				
				On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote:
				  
				      

					Attached is a draft charter. Scott and Paulo haven't had a
					chance to weigh in on it, so I might get some good input
					there. I would hope to have better milestones after an
					organizational meeting or BoF.
					    
					        

				I am sorry for the delay in my response. We normally spend some time
				to do an internal review with the IAB and IESG and I was waiting for
				Allison who promised comments.
				
				I am sympathic to the goals of this proposed work and I 
				      

			have received
			    

				various comments from the IAB stating so.
				
				However, I also received comments that this work could be 
				      

			conflicting
			    

				with existing IETF work in the NSIS and TSV working group.
				
				While the proposed charter doesn't necessarily would 
				      

			require protocol
			    

				work, the drafts that I read would more or less require this. As you
				know, the Ops part of the Ops&Mgmt area usually doesn't do protocol
				work and limits itself to issues that are relevant to the operations
				  
				      

			I'm agree with your remarks. But, IMHO, the DCPEL WG have to 
			deal with 
			protocol: Not produce new protocol, but adapt or suggest 
			modifications 
			to relevant WG. For exemple, DCPA inter-domain communication 
			could use 
			NSIS. But, since NSIS have not yet design for this, it certainly need 
			some modifications or, at least, to setup a new NSLP stack 
			liek QoS-NSLP 
			(thanks to the 2 layers signalling of NSIS which could facilitate the 
			work). Another example concern the SLS interface aka the interface 
			between service and DCPEL. Again, some stuff are usable like 
			SIP, XML, 
			... but need some adaptation to carry properly the SLS from 
			the service 
			to the DCPEL.
			    

				of the Internet. In addition, to make sure that things are relevant
				for operators, we normally want to have feedback, support and
				involvement from operators to avoid situations where 
				      

			vendors build all
			    

				kind of complex solutions for problems that operators don't have.
				
				So far, I have seen some support from academia, research efforts
				within larger corporations and some vendors, but I have seen little
				evidence that this group is going to solve a problem that operators
				want to be solved. As I already mentioned in an earlier mail, I am
				really somewhat surprised that I haven't seen any operator 
				      

			on the list
			    

				commenting that we need to start this work as I did expect 
				      

			that myself.
			    

				  
				      

			Sorry to contradict you, but, if you look carefully at the 
			mailing list, 
			you could see that I support DCPEL initiative from the beginning 
			(10/14/2005). During the last IETF meeting, FTR&D support this work 
			during the OPS AREA meeting. In the same time, through the 
			European IST 
			projet EuQoS, I request support from other operator like TID 
			(Telefonica 
			I+D). Generally speaking, in Europe, most of the operator are 
			search for 
			such functionalities. Look to the work done in other fora such as 
			ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the 
			DSL Forum. 
			In fact, IETF is the only place where QoS control, and in particular 
			resource control, are not study in the scope proposed by the DCEPL 
			initiative.
			    

				Considering these issues, I think that it probably is not 
				      

			in your best
			    

				interest to pursue a bof for this IETF.
				
				We will first need a much clearer answer on what problem is going to
				be solved *for operators*, get real support from operators 
				      

			behind this
			    

				effort and after that we need to figure out whether that 
				      

			solution will
			    

				involve protocol work or not.
				  
				      

			I could discuss this directly by phone as I'm not agree with 
			you. But, 
			operator need and want a global solution to setup and 
			exchange QoS. If 
			you just look at the VoIP service, inter-domain correspond to the 
			"international" part of the traditional PSTN. For the moment, 
			only study 
			are conduct to the access network. But, it is not sufficient. For the 
			moment, people think that over-provisioning will solve this 
			issue. This 
			is true for the bandwidth, but not for the other QoS 
			parameters such as 
			jitter, delay, loss ... However, VoIP services are vey 
			sensible to the 
			jitter and the delay. Without inter-domain and global QoS 
			solution, it 
			could not be possible to deploy a global VoIP QoS solution. 
			In the same 
			way, all multi-media service (IP TV, VoD, ...) need also QoS control. 
			Adopting a signaling like NSIS is certainly a great solution, 
			but which 
			will be deploy not before 5 or 10 years due to the time scale 
			operator 
			renew their transfer plane equipments. At the opposite, a 
			control plane 
			such as DCPEL propose, could be deploy very quickly without changing 
			their transfer plane.
			
			Today, operator are in a such situation that there is some industrial 
			solution on the market, but no standard to compare them or inter-oper 
			without development or major adaptation.
			
			Finally, ITU and ETSI will finalize first standard of the 
			RACF function, 
			but too much dedicated to conversational service. IMHO, it is 
			really a 
			mess that IETF will not conduct study on diffserv control plane.
			    

				You can probably convince me to hold a bof anyways but considering
				the above stumbling blocks, I would advise you not to do so.
				  
				      

			I'm agree that the charter need more clarification and scope 
			need more 
			focus. But, this is a very complex subject. All peoples with whom I 
			discussed about this, have a different opinion on the technical 
			solution, but all are agree to said that we need a solution.
			
			Best regards,
			
			Olivier Dugeon
			    

				David Kessens
				---
				
				_______________________________________________
				Dcpel mailing list
				[e-mail]
				https://www1.ietf.org/mailman/listinfo/dcpel
				
				  
				      

			-- 
			Project Manager for Network architecture and switching Division
			 & FT/DR&D/CORE/M2I           | 
			mailto:[e-mail]
			 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
			 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85
			
			
			
			_______________________________________________
			Dcpel mailing list
			[e-mail]
			https://www1.ietf.org/mailman/listinfo/dcpel
			
			    

		
		  


	-- 
	Project Manager for Network architecture and switching Division
	 & FT/DR&D/CORE/M2I           | mailto:[e-mail]
	 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
	 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85

_______________________________________________
Dcpel mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel