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

From: David Kessens <[email-masked]>
Date: Wed, 8 Mar 2006 21:49:14 -0800

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 <[email-masked]> -----

Date: Mon, 6 Mar 2006 20:58:32 -0800
From: David Kessens <[email-masked]>
To: Kathleen Nichols <[email-masked]>
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
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.

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.

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

David Kessens
---

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

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 09 Mar 2006 09:32:36 +0100

Hello David,

Here it is some comments from an operator (ok R&D part only)  !!!

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

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