From nobody Thu May 1 13:17:10 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87C31A09C8 for ; Thu, 1 May 2014 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIyFJ24TWJFe for ; Thu, 1 May 2014 13:17:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 059A81A6FA9 for ; Thu, 1 May 2014 13:17:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDS29436; Thu, 01 May 2014 20:16:58 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 1 May 2014 21:15:37 +0100 Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 1 May 2014 21:16:57 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.2]) by dfweml701-chm.china.huawei.com ([169.254.1.127]) with mapi id 14.03.0158.001; Thu, 1 May 2014 13:16:51 -0700 From: Leeyoung To: LUIS MIGUEL CONTRERAS MURILLO , "d.king@lancaster.ac.uk" , "mohamed.boucadair@orange.com" , "jingrq@ctbri.com.cn" Thread-Topic: Comments about draft-leeking-actn-problem-statement Thread-Index: Ac9lW40QCrcmZOTgQlyl3p+4uTgCHwAGR/fQ Date: Thu, 1 May 2014 20:16:51 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BE267D@dfweml706-chm.china.huawei.com> References: <823234EF5C7C334998D973D822FF801B6F13B3C0@EX10-MB1-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B6F13B3C0@EX10-MB1-MAD.hi.inet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.79] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BE267Ddfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/1nUQ-2qxdi4tXdRYM8BXIoV-sb0 Cc: "actn@ietf.org" Subject: Re: [Actn] Comments about draft-leeking-actn-problem-statement X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:17:09 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BE267Ddfweml706chmchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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:lmcm@tid.es] Sent: Thursday, May 01, 2014 12:42 PM To: Leeyoung; d.king@lancaster.ac.uk; mohamed.boucadair@orange.com; jingrq@= ctbri.com.cn 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 cust= omers "... by Network Providers and Service Providers ...". I would suggest= to rephrase in the following way: "... by Network Providers and / or Servi= ce Providers ...", because of the different nature of the service that coul= d be provided (e.g., pure transport service vs more sophisticated added-val= ue service) YOUNG>> Accepted. .- In the same section, end of 1st paragraph, you state: "Deploying and ope= rating these new applications and services using traditional network archit= ectures limits network efficiency, ...". I'm not so sure that it is motivat= ed by the network architectures, but by the technologies in use. I would su= ggest 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 aff= ect network architecture. How about "traditional network technologies and a= rchitectures" .- In the same section, 2nd paragraph, you mention: "...may be used by spec= ific applications and services.". I would add also users (or customers), li= ke: "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 n= o own physical equipment or infrastructure. This is not always true. For in= stance, if you consider MVNOs you can find cases where the MVNO owns the co= re platforms (SGSN, GGSN) including the required connectivity infrastructur= e and uses the network of another service provider to collect the traffic o= f 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 pr= ovisioning". Not clear what does it mean. Maybe are you referring to servic= e instead of server? YOUNG>> Actually I think "server" layer is correct. The discussion is in th= e context of transport networks are the server layer for the upper layer cl= ients. .- Section 4.1. In my understanding more information would be needed. I wou= ld include at least: (i) Information about the provider (ii) Geographical information. This could be relevant e.g. f= or legal reasons. (iii) Information about resource cost, consumption, etc. (iv) Information about resiliency (protection/restoration capa= bilities, 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 pr= ovider). YOUNG>> Good term here - resource publishing, can you elaborate this defini= tion 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 te= nd 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, monitorin= g, 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 s= ure if this would be part of the attributes you listed there, or if those a= ttributes are consequence of the physical media, and then it needs to be li= sted apart. YOUNG>> Yes, this is a good list. Attributes are not detailed out in the cu= rrent 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 prot= ected), etc, which are no so related to the scheduling. I can contribute wi= th 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 fo= r independent transport resources". Not sure what you refer about independe= nt in the context of the sentence. YOUNG>> Will remove "independent". .- Section 4.8. In the second bullet you include "self-service", but it see= ms to be redundant with the term "on-demand" previously used in that senten= ce. 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 m= y mind are ideas around transport service recovery requirements, according = to distinct SLA considerations, and the impact of that on the service provi= ded 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 sh= ould consider also: (i) Security aspects from the service point of view. For i= nstance, encryption capabilities as part of the service capabilities that c= ould be requested by the customer. (ii) Security aspects from the customer/provider relationshi= p point of view. For instance aspects like authentication, authorization, l= ogging, etc. YOUNG>> Fine with me. .- Section 4.11. The scope of this section can be very wide. When talking a= bout 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 tec= hnology used (e.g., wired vs wireless). YOUNG>> I think the customer provides the QoS and service performance requi= rement; then it is up to the operators how to map these requirements into n= etwork technology it chooses to deliver the service. Can you provide why wi= reless 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 r= outing was wired transport like SONET link; then alternate routing choice w= as microwave. We mixed these routing, but it was transparent to the custome= r. .- I would include two more sections to the ACTN objectives and requirement= s chapter. (i) Optimization, as capability of the service provider to= optimize the provided transport infrastructure without impacting the custo= mer 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 horizon= tal 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 Provid= ers ..." =3D> "... by Network and Service Providers ...", or "... by Networ= k and / or Service Providers ...", in case you accept my suggestion above. .- In the same section, 3rd bullet: "... via an data model ..." =3D> "... v= ia a data model ..." .- Section 3.1, first bullet: "... bandwidth to uses." =3D> "... bandwidth = to users." .- Section 4, 2nd paragraph: "... consider transport appropriate metrics ..= ." =3D> ""... 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 wri= ting 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=F3nica I+D / Global CTO unit / Telef=F3nica Distrito Telef=F3nica, Edificio Sur 3, Planta 3 28050 Madrid Espa=F1a / Spain lmcm@tid.es ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --_000_7AEB3D6833318045B4AE71C2C87E8E1729BE267Ddfweml706chmchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Luis,

 

Thanks for providing g= reat input to the document. I cc’ed this email thread to the ACTN lis= t for the sake of other audiences.

Please see inline for = my comment.

 

Thanks.

Young

 

From: LUIS MIG= UEL CONTRERAS MURILLO [mailto:lmcm@tid.es]
Sent: Thursday, May 01, 2014 12:42 PM
To: Leeyoung; d.king@lancaster.ac.uk; mohamed.boucadair@orange.com; = jingrq@ctbri.com.cn
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 Servic= e Providers …”. I would suggest to rephrase in the following wa= y: “… by Network Providers and / or Service Providers …&#= 8221;, 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 paragr= aph, you state: “Deploying and operating these new applications and s= ervices 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 sugg= est to refer to technologies instead of architectures.

 

YOUNG>> Reasonab= le. 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 net= work technologies and architectures”

 

.- In the same section, 2nd paragraph, yo= u 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 t= alk about provisioning computation scheme and virtual control capabilities = to customers, but considering the recursiveness mentioned later, I would ad= d that those customers can be also service providers themselves.

 

YOUNG>> Good poi= nt. 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 whe= re the MVNO owns the core platforms (SGSN, GGSN) including the required connectivity infrastructure and uses t= he 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 co= ntext of transport networks are the server layer for the upper layer client= s.

 

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

(i)         &n= bsp;        Information about the provider

(ii)         &= nbsp;      Geographical information. This could be relevant e.g. for legal reas= ons.

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

(iv)         &= nbsp;    Information about resiliency (protection/restoration capabilities, f= or instance)

I can contribute with the corresponding text if you = agree.

 

YOUNG>> Sure, Th= ese are good lists from operators like you, Telefonica.

 

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

 

YOUNG>> Good ter= m here – resource publishing, can you elaborate this definition a bit= more detailed?

 

.- Section 4.2. You refer to distributed computing o= bjects for manipulating network resources. I’m not sure if this is an= appropriate term. I would tend to refer to information models.<= /p>

 

YOUNG>> Do you m= ean “distributed computing information model” as opposed to = 220;distributed computing objects”?

 

.- Section 4.3. The mentioned data models, apart fro= m being used to request resources, would be needed for network operation, c= onfiguration, monitoring, KPI customization, etc. I would include this to t= he text.

 

YOUNG>> Good sug= gestion. What is KPI customization? Can you elaborate this term?

 

.- In the same section, I would include some additio= nal bullet:

(i)         &n= bsp;        Administrative information (resource ownership)

(ii)         &= nbsp;      Physical media (electrical, optical, radio) – but not sure if = this would be part of the attributes you listed there, or if those attribut= es are consequence of the physical media, and then it needs to be listed ap= art.

 

YOUNG>> Yes, this is a good list. Attributes are not detai= led 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 se= ctions. 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 corre= sponding text for the Allocation part if you agree.

 

YOUNG>> Please d= o that.

 

.- Section 4.7. At the end of the 1st par= agraph you quote “… competing for independent transport resourc= es”. Not sure what you refer about independent in the context of the = sentence.

 

YOUNG>> Will rem= ove “independent”.

 

.- Section 4.8. In the second bullet you include = 220;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-servi= ce refers to the way the client  of resources makes use of the allocat= ed resources to them. What do you think?

 

.- For section 4.9 I could provide content if you ag= ree. What it comes to my mind are ideas around transport service recovery r= equirements, according to distinct SLA considerations, and the impact of th= at on the service provided to the customer.

 

YOUNG>> Sure, fe= el free to do that.

 

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

(i)         &n= bsp;        Security aspects from the service point of view. For instance, encry= ption capabilities as part of the service capabilities that could be reques= ted by the customer.

(ii)         &= nbsp;      Security aspects from the customer/provider relationship point of vi= ew. For instance aspects like authentication, authorization, logging, etc.<= o:p>

 

YOUNG>> Fine with me.

 

.- Section 4.11. The scope of this section can be ve= ry 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 p= rovide this detail.

 

.- Section 4.12 talks about technology independence,= which is right, but in my opinion the customer should have the right of de= ciding 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 technolog= y 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 alterna= te routing choice was microwave. We mixed these routing, but it was transparent to the customer.

 

.- I would include two more sections to the ACTN obj= ectives and requirements chapter.

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

(ii)         &= nbsp;      Multi-domain support, as needed when the customer makes use of trans= port network capabilities from different service providers.

I can contribute with the text for these two new sec= tions if you think they make sense.

 

YOUNG>> Be my gu= est. This will be a more complete list.

 

.- In section 4.13.4. I would also mention interoper= ability (a more horizontal approach), not only legacy support (a more verti= cal approach).

 

YOUNG>> Provide = some text.

 

Finally, I have found a number of typos, I think, pl= ease note.

 

.- In section 1, Introduction: “… by Net= work Providers and Service Providers …” =3D> “… = by Network and Service Providers …”, or “… by Netwo= rk and / or Service Providers …”, in case you accept my suggest= ion above.

 

.- In the same section, 3rd bullet: ̶= 0;… via an data model …” =3D> “… via a dat= a model …”

 

.- Section 3.1, first bullet: “… bandwid= th to uses.” =3D> “… bandwidth to users.”

 

.- Section 4, 2nd paragraph: “̷= 0; consider transport appropriate metrics …” =3D> “= 220;… consider appropriate transport metrics …””

 

YOUNG>> Thanks f= or your check on this.

 

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

 

YOUNG>> It was v= ery useful.

 

Thanks,

 

Best regards

 

__________________________________

Luis M. Contreras

 

Technology and Planning

Transport, IP and Interconnection Networks

Telef=F3nica I+D / Global CTO unit / Telef=F3nic= a

 

Distrito Telef=F3nica, Edificio Su= r 3, Planta 3

28050 Madrid

Espa=F1a / Spain=

 

lmc= m@tid.es

 

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/= ES/PAGINAS/disclaimer.aspx

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BE267Ddfweml706chmchi_-- From nobody Wed May 28 08:19:14 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD68E1A0425 for ; Wed, 28 May 2014 08:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRrem3T0rusj for ; Wed, 28 May 2014 08:19:09 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3424D1A0394 for ; Wed, 28 May 2014 08:19:09 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id x19so3054251ier.41 for ; Wed, 28 May 2014 08:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gk/DYjTeAB+gQfcAN7cnHNKal06tDGXhCouqTHJSTiQ=; b=MXbvOLr1HbtfAwN1hR3tpc8U4CnUKj/CJDt8bOkskBtxCQJRvbWl76kUye9LlRWrtp uw5dXXHghy+hr19mD3gab66Jq80lA0Wg9wbijHDbG2+eTOfHXJOVCPppIazHOHRjnIhN NZuVDqYoMMg50ryjjKLPvEa8fpQNyS8Cino2wt8MwY/sxneRcfEGXENv6xzc1RvhxtsJ yKtf3OIYWMfR+MPdw5OtXlnAditFke0rxnAko7suaEkYWabgwEmNIvIhoMtor1O4/SIF HpGdpa91m09McpD9CHahBqK61hTTtilIJDMbgOEOwcQurKaitmrAtCPxBWjf+J85Znec fNcA== MIME-Version: 1.0 X-Received: by 10.50.43.134 with SMTP id w6mr1895998igl.3.1401290345378; Wed, 28 May 2014 08:19:05 -0700 (PDT) Received: by 10.50.179.98 with HTTP; Wed, 28 May 2014 08:19:05 -0700 (PDT) In-Reply-To: <20140528044205.32374.26512.idtracker@ietfa.amsl.com> References: <20140528044205.32374.26512.idtracker@ietfa.amsl.com> Date: Wed, 28 May 2014 20:49:05 +0530 Message-ID: From: Dhruv Dhody To: "actn@ietf.org" Content-Type: multipart/alternative; boundary=089e01184b0c442b0204fa7755e0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/v9lbBGEQHvG7Xs_vrQcZ3WpFMvM Subject: [Actn] Fwd: New Version Notification for draft-dhody-actn-poi-use-case-02.txt X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:19:10 -0000 --089e01184b0c442b0204fa7755e0 Content-Type: text/plain; charset=UTF-8 Hi All, We have updated the ACTN usecase draft regarding Packet+Optical Integration (POI). The main changes: - Detailed Introduction - A new section on POI Scenario - Figure describing coordination between multiple domains - Bin as new Co-author http://www.ietf.org/rfcdiff?url2=draft-dhody-actn-poi-use-case-02 Any reviews/comments would be appreciated. Regards, Dhruv ---------- Forwarded message ---------- From: Date: Wed, May 28, 2014 at 10:12 AM Subject: New Version Notification for draft-dhody-actn-poi-use-case-02.txt To: Daniele Ceccarelli , Oscar Gonzalez de Dios , Dhruv Dhody , Xian Zhang < zhang.xian@huawei.com>, Bin-Yeong Yoon A new version of I-D, draft-dhody-actn-poi-use-case-02.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhody-actn-poi-use-case Revision: 02 Title: Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN) Document date: 2014-05-26 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-dhody-actn-poi-use-case-02.txt Status: https://datatracker.ietf.org/doc/draft-dhody-actn-poi-use-case/ Htmlized: http://tools.ietf.org/html/draft-dhody-actn-poi-use-case-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-actn-poi-use-case-02 Abstract: This document describes the Abstraction and Control of Transport Networks (ACTN) use cases related to Packet and Optical Integration (POI), that may be potentially deployed in various transport networks and apply to different applications. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e01184b0c442b0204fa7755e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

We have updated the ACTN usecase draft regarding Packet+Optica= l Integration (POI).=C2=A0

The main changes:
- Detailed Introduction
- A new section on POI Scenario
- Figure describing coordination be= tween multiple domains
= - Bin as new Co-author=C2=A0

Any rev= iews/comments would be appreciated.

Regar= ds,
Dhruv

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, May 28, 2014 at 10:12 AM
Subject: New Version Notification fo= r draft-dhody-actn-poi-use-case-02.txt
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.co= m>, Oscar Gonzalez de Dios <ogo= ndio@tid.es>, Dhruv Dhody <dhruv.ietf@gmail.com>, Xian Zhang <zhang.xian@huawei.com>, Bin-Yeong Yoon <byyun@etri.re.kr>



A new version of I-D, draft-dhody-actn-poi-use-case-02.txt
has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-dhody-actn-poi-use-case
Revision: =C2=A0 =C2=A0 =C2=A0 02
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Optical Integration (POI) U= se Cases for Abstraction and Control of Transport Networks (ACTN)
Document date: =C2=A02014-05-26
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://www.ietf.org/internet-drafts/draft-dhody-actn-poi-use-case-02.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.= ietf.org/doc/draft-dhody-actn-poi-use-case/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/dr= aft-dhody-actn-poi-use-case-02
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.= ietf.org/rfcdiff?url2=3Ddraft-dhody-actn-poi-use-case-02

Abstract:
=C2=A0 =C2=A0This document describes the Abstraction and Control of Transpo= rt
=C2=A0 =C2=A0Networks (ACTN) use cases related to Packet and Optical Integr= ation
=C2=A0 =C2=A0(POI), that may be potentially deployed in various transport n= etworks
=C2=A0 =C2=A0and apply to different applications.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e01184b0c442b0204fa7755e0-- From nobody Wed May 28 16:22:29 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587251A06D5 for ; Wed, 28 May 2014 16:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl0KNjMtDyLH for ; Wed, 28 May 2014 16:22:25 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53A1A0779 for ; Wed, 28 May 2014 16:22:24 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N6B002SQ4X645@tid.hi.inet> for actn@ietf.org; Thu, 29 May 2014 01:22:19 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3B.62.04155.63A86835; Thu, 29 May 2014 03:15:35 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N6B002ST4X745@tid.hi.inet> for actn@ietf.org; Thu, 29 May 2014 01:22:19 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.165]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Thu, 29 May 2014 01:22:19 +0200 Date: Wed, 28 May 2014 23:22:43 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "actn@ietf.org" Message-id: <3B5FC708-4E77-419A-85B5-B37199B80CE2@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: New draft on NFV-related use cases Thread-index: AQHPesur56j4jzyJXEGCe2Gtm5FNMg== X-AuditID: 0a5f4e69-f79426d00000103b-11-53868a364f2b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsXCFe9nqGve1RZscGg7o8WWngtsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+PRFqWAZT8Wv3ga2BsY/3F2MHBwSAiYSu+4HdTFyApliEhfu rWfrYuTiEBLYzijxpvkRO4Tzg1Hiw+IvrCBVQgIbGSVOdZiBNLMIqEocuFkAEmYDMh81/2YH CQsLaEs03cyDmKkg8efcYxYQW0RAWWLx4T9sIDavgKXE1qd7weLMAmYSKxZ8YoeIC0r8mHyP BWQMs4C6xJQpuRAl4hLNrTehyhUlpi1qYASxGQVkJd7Nn88KUi4iYCAxZ2EUhKkn8WkzK8QB AhJL9pxnhrBFJV4+/sc6gVF0FpK9s5DsnYWwdxaSvbOQ7F3AyLqKUaw4qSgzPaMkNzEzJ93A SC8jUy8zL7VkEyMkPjJ3MC7fqXKIUYCDUYmH94NLW7AQa2JZcWXuIUYJDmYlEV6NcKAQb0pi ZVVqUX58UWlOavEhRmkOFiVxXuZ3RQFCAumJJanZqakFqUUwWSYOTqkGRqMi10sxGozz5t7b vszraV9T6YcpE9k33O25I31/jdqOIK80kZw5uVbHo8PeRDysWPr+Ukb19gCDiOtnm7svs/w6 uaCGX2gpz4TJs9bZyF+JXBKqH5jmxZjMXJHwegrXxLx/O+dMkWJaUGoZlr/2b0tEa6vzLw2/ HQk/DUM2ckrMKc19r9Mno8RSnJFoqMVcVJwIAJXSCrSLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/mctuD1ptWBWL2mR0o96hQe-ykD0 Subject: [Actn] New draft on NFV-related use cases X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:22:27 -0000 SGksDQoNCldlIChZb3VuZyBhbmQgeW91cnMgZnJpZW5kbHkpIGhhdmUgcmVjZW50bHkgdXBsb2Fk ZWQgYSBkcmFmdCBkZXNjcmliaW5nIGEgKHNldCBvZikgdXNlIGNhc2UocykgZm9yIHRoZSBtZWNo YW5pc21zIHdlIGFyZSBzdGFydGluZyB0byBkaXNjdXNzIGluIEFDVE4uIFRoZSBkcmFmdCBhbmFs eXplcyB0aGUgbmVlZCBmb3IgbXVsdGktZG9tYWluLCBtdWx0aS10ZWNobm9sbG9neSB0cmFuc3Bv cnQgbmV0d29yayBhYnN0cmFjdGlvbnMsIGVzcGVjaWFsbHkgaW4gdGhlIGxpZ2h0IG9mIHRoZSBy ZXF1aXJlbWVudHMgb2YgTmV0d29yayBGdW5jdGlvbnMgVmlydHVhbGl6YXRpb24gYW5kIHRoZSBz dXBwb3J0IGl0IHdpbGwgcmVxdWlyZSBmcm9tIHRoZSB0cmFuc3BvcnQgbmV0d29yayBpbmZyYXN0 cnVjdHVyZS4NCg0KWW91IGhhdmUgYSBmaXJzdCB2ZXJzaW9uIGF2YWlsYWJsZSBhdCBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb3Blei1hY3RuLXZuby1tdWx0aWRvbWFpbnMtMDAN Cg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmll cm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUu dGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQg OTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNl cGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBh YmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJl c3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUg dGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1l ci5hc3B4DQo= From nobody Fri May 30 00:19:15 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154CD1A0770 for ; Thu, 29 May 2014 21:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdcNb8RH5-eL for ; Thu, 29 May 2014 21:35:41 -0700 (PDT) Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id CC14D1A0766 for ; Thu, 29 May 2014 21:35:41 -0700 (PDT) Received: from UTMC1101.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 790D61284 for ; Fri, 30 May 2014 13:35:36 +0900 (JST) Received: from UTMC1134 (unknown [10.5.16.201]) by UTMC1101.kddi.com (Postfix) with SMTP id 4DF0775A for ; Fri, 30 May 2014 13:35:36 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 761251C7B for ; Fri, 30 May 2014 13:35:31 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1123.kddi.com (Postfix) with ESMTP id 5B0211C37 for ; Fri, 30 May 2014 13:35:31 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id s4U4ZVZx005454 for ; Fri, 30 May 2014 13:35:31 +0900 Received: from LTMC1006.kddi.com.mid_29368729 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id s4U4Ye7P004566 for ; Fri, 30 May 2014 13:34:40 +0900 Received: from KDDI1202PC0730 ([10.200.121.252] [10.200.121.252]) by post-zip.kddi.com with ESMTPA; Fri, 30 May 2014 13:34:40 +0900 From: "Kenji Kumaki" To: References: <20140529154521.31458.85543.idtracker@ietfa.amsl.com> In-Reply-To: <20140529154521.31458.85543.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 13:34:40 +0900 Message-Id: <009301cf7bc0$78c18740$6a4495c0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGIf3P6iMIOC4DbWUg22mBU3goUUpvmfZ2g Content-Language: ja X-SA-MID: 29368729 X-WAuditID: 1405301335310000412952 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/actn/rjnF_VPuYxJNrOrFof-W9ralcgU X-Mailman-Approved-At: Fri, 30 May 2014 00:19:13 -0700 Subject: [Actn] FW: I-D Action: draft-kumaki-actn-multitenant-vno-00.txt X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 04:35:44 -0000 Hi We just submitted the following draft. Comments and feedback would be highly appreciated. Thanks, Kenji --- Kenji Kumaki, Ph.D. Head of IP & Optical Core Networks KDDI Corporation -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, May 30, 2014 12:45 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-kumaki-actn-multitenant-vno-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ACTN : Use case for Multi Tenant VNO Authors : Kenji Kumaki Takuya Miyasaka Filename : draft-kumaki-actn-multitenant-vno-00.txt Pages : 9 Date : 2014-05-29 Abstract: This document provides a use case that addresses the need for facilitating virtual network operation: creation and operation of multi-tenant virtual networks that use the common core network resources. This will accelerate a rapid service deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. This use case addresses the aforementioned needs within a single operator network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kumaki-actn-multitenant-vno-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri May 30 01:53:37 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A141A6EFC for ; Fri, 30 May 2014 01:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpNCCqiDClLB for ; Fri, 30 May 2014 01:53:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF031A075C for ; Fri, 30 May 2014 01:53:33 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-ad-53884707daa5 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.60.16420.70748835; Fri, 30 May 2014 10:53:27 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.173]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Fri, 30 May 2014 10:53:27 +0200 From: Daniele Ceccarelli To: "actn@ietf.org" Thread-Topic: New Version Notification for draft-ceccarelli-actn-framework-02.txt Thread-Index: AQHPe+RGmTU4D/W0GkGzdBZsoIB27JtY0NLw Date: Fri, 30 May 2014 08:53:26 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812711BC0@ESESSMB301.ericsson.se> References: <20140530085054.16286.3385.idtracker@ietfa.amsl.com> In-Reply-To: <20140530085054.16286.3385.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS67e0ewwZl2K4stPRfYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVse3hZ9aCNwIVRw8+ZG1g3CLQxcjJISFgIvHm5homCFtM4sK9 9WwgtpDAUUaJKV8ruxi5gOwljBLnvjQCFXFwsAlYSTw55ANSIyKgLLH48B+wemGBIIn5z8+y Q8SDJf5t+cYMYRtJfHtxEKyGRUBV4uz5F4wgNq+Ar8SzU5sYIXY5SBy4cw6shlPAUeLG+ecs IDajgKzEhN2LwGqYBcQlbj2ZD3WngMSSPeeZIWxRiZeP/7FC2IoSH1/tYwQ5k1lAU2L9Ln2I VkWJKd0P2SHWCkqcnPmEZQKj6CwkU2chdMxC0jELSccCRpZVjKLFqcVJuelGxnqpRZnJxcX5 eXp5qSWbGIHRcHDLb9UdjJffOB5iFOBgVOLhXVDaHizEmlhWXJl7iFGag0VJnPeiRnWwkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaCK5I3fL57Lde8ca/MOzPLap10i9hvb/kbtaW+yixh 95c4mcz3Wy7q+N6a5eKmlcFnC17MMbnDbRXVsKSuqNl5va1U+P5XB2LeR4ua5nRt3vPu2cmV cV1sU478Opf4z/n+teklW4971oQe/nNExeHc1oTfWY7vy1c5xkXriu3ZL1+iJaFyWUKJpTgj 0VCLuag4EQAatGuxZwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/ZBM-UHJziWyXz585PmGwZEP2wLs Subject: [Actn] FW: New Version Notification for draft-ceccarelli-actn-framework-02.txt X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:53:35 -0000 SGkgQUNUTmVycyENCg0KQWxzbyB0aGUgZndrIGhhcyBiZWVuIHVwZGF0ZWQgYWRkaW5nIGEgc2Vj dGlvbiBvbiBtdWx0aS1kb21haW4gbWFuYWdlbWVudCBpbiBBQ1ROIGVudmlyb25tZW50LiANCg0K Q29tbWVudHMgYXJlIG1vcmUgdGhhbiBhcHByZWNpYXRlZC4NCg0KQlINCkRhbmllbGUgKCYgY28t YXV0aG9ycykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiB2 ZW5lcmTDrCAzMCBtYWdnaW8gMjAxNCAxMDo1MQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgTHV5 dWFuIEZhbmc7IFlvdW5nIExlZTsgTHV5dWFuIEZhbmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgWW91 bmcgTGVlOyBEaWVnbyBSLiBMb3BlejsgRGllZ28gTG9wZXoNClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMi50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29y ay0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFuaWVsZSBDZWNj YXJlbGxpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmsNClJldmlzaW9uOgkwMg0KVGl0bGU6CQlGcmFtZXdv cmsgZm9yIEFic3RyYWN0aW9uIGFuZCBDb250cm9sIG9mIFRyYW5zcG9ydCBOZXR3b3Jrcw0KRG9j dW1lbnQgZGF0ZToJMjAxNC0wNS0zMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOgkJMjcNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAyLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmsvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdv cmstMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZv ciBhYnN0cmFjdGlvbiBhbmQgY29udHJvbCBvZg0KICAgdHJhbnNwb3J0IG5ldHdvcmtzLg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==