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

["Hancock, Robert" <[e-mail]>]

Paulo, Kathie,

specifically on the protocols question, it strikes me that there are two issues here:

1) in defining the scope of a proposed WG, it seems that it would be necessary to pin down more precisely the scope of any protocol work before the WG can be formed. (Is this a correct interpretation of the AD comments?) Is this going to be impossible? In the case of NSIS, the WG was *initially* chartered *only* to answer the question of what needed to be done compared to existing protocols and not do any new protocol work; maybe the same approach would work here.

2) with respect to the specific question of the inter-domain protocol, I think there would have to be really good arguments to justify anything beyond extensions to existing protocols, and so far I've not seen anything that would require any extensions at all for the case where the flows/aggregates follow well defined network paths. (This may or may not be the full scope of DCPEL. If the aggregate path is not well defined then the signalling problem becomes harder and more work may be needed.)

r.

> -----Original Message-----
> From: Paulo Mendes [mailto:[e-mail]] 
> Sent: 13 March 2006 09:58
> To: Tschofenig, Hannes; David Kessens
> Cc: [e-mail]; Olivier Dugeon
> Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter]
> 
> 
> Hi David, Hannes, and all
> 
> Here is my view about the need of DCPEL for operators and about DCPEL 
> relationship with NSIS, as I see it.
> 
> I would like to stress we have been receiving support from operators 
> since the beginning. Not only from NTT DoCoMo: I'm been helping to 
> develop DCPEL since the beginning, and although NTT DoCoMo 
> Euro-Labs is 
> a research institution I gain the support of the Japanese development 
> department since January. To NTT DoCoMo we can add France Telecom and 
> Telefonia, as mentioned by Olivier. I would like to mention that the 
> involvement of these operators in DCPEL follows their work on similar 
> topics in other fora and research projects as mentioned by Olivier.
> 
> Being even more pragmatic about the operators' need for a 
> good solution 
> to control and manage a DiffServ network, I would like to say 
> that the 
> need for such solution in increasing from DoCoMo side. We are 
> looking at 
> several possible solutions to control QoS in an all IP 
> network. So, we 
> are looking at work being done at 3GPP for instance. But we 
> think that 
> DiffServ may be a better solution for the future. The only 
> problem (big 
> one) is that there is no standard way to control and manage a 
> DiffServ 
> network. This is what DoCoMo wants: a standards set of 
> procedures, PDBs 
> for well-know traffic (voip, IPTV, video-streaming, ...), and set of 
> protocols that together will allow us to control a future 
> DiffServ network.
> 
> So DCPEL aims to focus on how to operate a DiffServ network:
> - draft-chan-tsvwg-diffserv-class-aggr-03 (discussion of which fits 
> DCPEL, IMO) provides guidelines of how multiple service 
> classes may be 
> aggregated into a forwarding treatment aggregate.
> - Independently from the fact that we need or not all the types of 
> traffic aggregates enumerated in 
> draft-chan-tsvwg-diffserv-class-aggr-03, we need to know how to make 
> them real.
> - DCPEL is focusing on this goal. There is no work in IETF for:
>    i) Define the PDBs to manage the traffic types discussed in 
> draft-chan-tsvwg-diffserv-class-aggr-03 (the authors discuss 
> a possible 
> control based on MPLS).
>    ii) Analyze what type of signaling is most suitable, and how 
> different protocols may be combined.
>    iii) Make ii) work for intra-domain management and combine it with 
> inter-domain control.
> 
> The interaction with NSIS fits in the analysis of current signaling 
> protocols and how suitable they are to help in the control of 
> a DiffServ 
> network. This is, to be able to control QoS in real networks, 
> we need a 
> little more than defining signaling protocols. Currently, we 
> have a very 
> good number of protocols available in IETF, but we need to 
> know how to 
> use them and how to inter-operate them. For instance, it may 
> be clear, 
> based on the specification of DiffServ control elements that 
> QoS-NSLP is 
> the best option for intra-domain control. Or we may conclude that 
> QoS-NSLP may need to be adapted. In the later case, the adaptation is 
> analyzed in DCPEL (focusing on DiffServ control) and is specified in 
> NSIS (focused on protocol specification). At least in some 
> projects, I 
> had some discussions about the current difficulty of standardizing a 
> control mechanism in NSIS, since NSIS is only interested in the 
> signaling part, while the mentioned mechanism may involve 
> more that that 
> (admission control, network monitoring, control of SLS, etc, etc).
> 
> As an example, I can indicate some work being presented in NSIS that, 
> IMO, is more suitable to be discussed in DCPEL: RMD - 
> draft-ietf-nsis-rmd-06.  RMD is not specifying any new NSLP, 
> although it 
> may have consequences in NSIS, if RMD needs some extensions 
> or options 
> for QoS-NSLP. RMD is more focus on the admission control and 
> controlof 
> congestion in Diffserv networks, being the signaling done 
> with QoS-NSLP.
> 
> IMO, it may be a hard job for NSIS to try to specify every 
> possible NSLP 
> on top of GIST. It would be better if NSIS provides the service level 
> protocols that are required by other WG (namely the ones 
> analysing the 
> operation of IP networks), and not to specify any protocol that fits 
> nicely on top of GIST.
> 
> To terminate, an example (just an raw example, without any discussion 
> until now :) ) of a possible interaction of DCPEL and NSIS:
>   i) The control of some PDBs requires the use of QoS-NSLP 
> edge-to-edge, 
> but combined with COPS (for signaling between edges and an 
> inter-domain 
> QoS controller, from a set of possible controllers) and SIP (for 
> signaling between terminal and network). The specification of this 
> management operation is in the scope of DCPEL. NSIS contributes with 
> QoS-NSLP.
>   ii) Same scenario as in i) but QoS-NSLP doesn't fit 
> perfectly. In this 
> case DCPEL will analyse the needed requirements to extend 
> QoS-NSLP. NSIS 
> should then analyse all the details to include these extra 
> requirements 
> in the current draft.
>   iii) QoS-NSLP doesn't fit at all in some scenarios, such as 
> inter-domain, where a path-decoupled solution is better. Some 
> people is 
> currently thinking in extending, again, QoS-NSLP for path-decoupled 
> signaling. But, how can we know that that work will be the 
> most suitable 
> for inter-domain DiffServ control? Or, even if it may be 
> used, different 
> approaches to path-decoupled signaling, even if based on 
> NSIS, may also 
> bring other advantages. This is, it is not because NSIS is going to 
> 'extend' QoS-NSLP to operate path-decoupled that all DiffServ 
> inter-domain operation control is solved. Here, I fully agree 
> with Kathie.
> 
> Cheers
> Paulo
> 
> Tschofenig, Hannes wrote:
> 
> >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.ht
> ml 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]> -----
> >>    
> >>
> >>>Date: Mon, 6 Mar 2006 20:58:32 -0800
> >>>From: David Kessens <[e-mail]>
> >>>To: Kathleen Nichols <[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
> >>
> >>    
> >>
> >
> >_______________________________________________
> >Dcpel mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/dcpel
> >
> >  
> >
> 
> 
> _______________________________________________
> Dcpel mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dcpel
> 

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