Subject: Re: [Actn] Comments about draft-leeking-actn-problem-statement

From: Leeyoung <[email-masked]>
Date: Thu, 1 May 2014 20:16:51 +0000

Hi Luis,

Thanks for providing great input to the document. I cc'ed this email thread to the ACTN list for the sake of other audiences.
Please see inline for my comment.

Thanks.
Young

From: LUIS MIGUEL CONTRERAS MURILLO [mailto:[email-masked]]
Sent: Thursday, May 01, 2014 12:42 PM
To: Leeyoung; [email-masked]; [email-masked]; [email-masked]
Subject: Comments about draft-leeking-actn-problem-statement

Dear authors,

I've gone through your draft, finding it very interesting. I have a number of comments/suggestions for it.

.- In section 1, Introduction, you refer to services being provided to customers "... by Network Providers and Service Providers ...". I would suggest to rephrase in the following way: "... by Network Providers and / or Service Providers ...", because of the different nature of the service that could be provided (e.g., pure transport service vs more sophisticated added-value service)

YOUNG>> Accepted.

.- In the same section, end of 1st paragraph, you state: "Deploying and operating these new applications and services using traditional network architectures limits network efficiency, ...". I'm not so sure that it is motivated by the network architectures, but by the technologies in use. I would suggest to refer to technologies instead of architectures.

YOUNG>> Reasonable. I think some network architectures are dependent on the technologies in use, for instance, OSPF protocol dictates AREA 0 partition from other non-Area 0 areas. Then this is an example that technologies affect network architecture. How about "traditional network technologies and architectures"

.- In the same section, 2nd paragraph, you mention: "...may be used by specific applications and services.". I would add also users (or customers), like: "may be used by specific applications, services and users."

YOUNG>> Accepted.

.- In the same section, 3rd bullet, you talk about provisioning computation scheme and virtual control capabilities to customers, but considering the recursiveness mentioned later, I would add that those customers can be also service providers themselves.

YOUNG>> Good point. I will add this note.

.- In section 1.1 you mention that a virtual network service provider has no own physical equipment or infrastructure. This is not always true. For instance, if you consider MVNOs you can find cases where the MVNO owns the core platforms (SGSN, GGSN) including the required connectivity infrastructure and uses the network of another service provider to collect the traffic of its users (access and backhaul segments). I would rephrase that.

YOUNG>> OK. Good suggestions.

.- In section 1.1, in Transport Networks bullet: you write "server layer provisioning". Not clear what does it mean. Maybe are you referring to service instead of server?

YOUNG>> Actually I think "server" layer is correct. The discussion is in the context of transport networks are the server layer for the upper layer clients.

.- Section 4.1. In my understanding more information would be needed. I would include at least:

(i)                  Information about the provider

(ii)                Geographical information. This could be relevant e.g. for legal reasons.

(iii)               Information about resource cost, consumption, etc.

(iv)              Information about resiliency (protection/restoration capabilities, for instance)
I can contribute with the corresponding text if you agree.

YOUNG>> Sure, These are good lists from operators like you, Telefonica.

.- Also in section 4.1, I would consider not only resource discovery (to be performed by the customer) but also resource publishing (by the network provider).

YOUNG>> Good term here - resource publishing, can you elaborate this definition a bit more detailed?

.- Section 4.2. You refer to distributed computing objects for manipulating network resources. I'm not sure if this is an appropriate term. I would tend to refer to information models.

YOUNG>> Do you mean "distributed computing information model" as opposed to "distributed computing objects"?

.- Section 4.3. The mentioned data models, apart from being used to request resources, would be needed for network operation, configuration, monitoring, KPI customization, etc. I would include this to the text.

YOUNG>> Good suggestion. What is KPI customization? Can you elaborate this term?

.- In the same section, I would include some additional bullet:

(i)                  Administrative information (resource ownership)

(ii)                Physical media (electrical, optical, radio) - but not sure if this would be part of the attributes you listed there, or if those attributes are consequence of the physical media, and then it needs to be listed apart.

YOUNG>> Yes, this is a good list. Attributes are not detailed out in the current draft. Your physical media is one of the attributes in mind.

.- Section 4.4 refers to scheduling and allocation. In my opinion, it would be better to separate both concepts in different sections. Allocation has implications respect to SLA, service properties (e.g., protected vs no protected), etc, which are no so related to the scheduling. I can contribute with the corresponding text for the Allocation part if you agree.

YOUNG>> Please do that.

.- Section 4.7. At the end of the 1st paragraph you quote "... competing for independent transport resources". Not sure what you refer about independent in the context of the sentence.

YOUNG>> Will remove "independent".

.- Section 4.8. In the second bullet you include "self-service", but it seems to be redundant with the term "on-demand" previously used in that sentence.

YOUNG>> I think on-demand is with respect to the timing of service request while self-service refers to the way the client  of resources makes use of the allocated resources to them. What do you think?

.- For section 4.9 I could provide content if you agree. What it comes to my mind are ideas around transport service recovery requirements, according to distinct SLA considerations, and the impact of that on the service provided to the customer.

YOUNG>> Sure, feel free to do that.

.- In section 4.10 I would include more stuff. From my point of view, it should consider also:

(i)                  Security aspects from the service point of view. For instance, encryption capabilities as part of the service capabilities that could be requested by the customer.

(ii)                Security aspects from the customer/provider relationship point of view. For instance aspects like authentication, authorization, logging, etc.

YOUNG>> Fine with me.

.- Section 4.11. The scope of this section can be very wide. When talking about policies it is possible to refer to policies in the field of: control, security, provisioning, resource usage, etc. I can as well contribute with text here if you agree.

YOUNG>> Please provide this detail.

.- Section 4.12 talks about technology independence, which is right, but in my opinion the customer should have the right of deciding what kind of technology used (e.g., wired vs wireless).

YOUNG>> I think the customer provides the QoS and service performance requirement; then it is up to the operators how to map these requirements into network technology it chooses to deliver the service. Can you provide why wireless vs. wired matters to the particular customer? When I worked for AT&T, we have several routing options for a certain service. The first choice routing was wired transport like SONET link; then alternate routing choice was microwave. We mixed these routing, but it was transparent to the customer.

.- I would include two more sections to the ACTN objectives and requirements chapter.

(i)                  Optimization, as capability of the service provider to optimize the provided transport infrastructure without impacting the customer services

(ii)                Multi-domain support, as needed when the customer makes use of transport network capabilities from different service providers.
I can contribute with the text for these two new sections if you think they make sense.

YOUNG>> Be my guest. This will be a more complete list.

.- In section 4.13.4. I would also mention interoperability (a more horizontal approach), not only legacy support (a more vertical approach).

YOUNG>> Provide some text.

Finally, I have found a number of typos, I think, please note.

.- In section 1, Introduction: "... by Network Providers and Service Providers ..." => "... by Network and Service Providers ...", or "... by Network and / or Service Providers ...", in case you accept my suggestion above.

.- In the same section, 3rd bullet: "... via an data model ..." => "... via a data model ..."

.- Section 3.1, first bullet: "... bandwidth to uses." => "... bandwidth to users."

.- Section 4, 2nd paragraph: "... consider transport appropriate metrics ..." => ""... consider appropriate transport metrics ...""

YOUNG>> Thanks for your check on this.

I hope you can find these comments useful. Let me know if I can help on writing this draft for the suggested additional content.

YOUNG>> It was very useful.

Thanks,

Best regards

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

[email-masked]<mailto:[email-masked]>

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx