From nobody Wed Oct 1 05:58:07 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 E80951A036C for ; Wed, 1 Oct 2014 05:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 aXqe8LQPmKCc for ; Wed, 1 Oct 2014 05:57:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1791A0346 for ; Wed, 1 Oct 2014 05:57:57 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-01-542bfa53adde Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.3D.21432.35AFB245; Wed, 1 Oct 2014 14:57:55 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.79]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Wed, 1 Oct 2014 14:57:55 +0200 From: Daniele Ceccarelli To: Dhruv Dhody , Leeyoung , "actn@ietf.org" Thread-Topic: ACTN architecture Thread-Index: Ac/Om8qi9g/D/THATIaDRn5wbOi7GACBkWJQABkBmyAAFQGYgAIQSSFgAIF+6iAAdV6lwA== Date: Wed, 1 Oct 2014 12:57:54 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48127951F7@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE481276015F@ESESSMB301.ericsson.se> <23CE718903A838468A8B325B80962F9B865F029E@szxeml556-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1729C348CB@dfweml706-chm> <23CE718903A838468A8B325B80962F9B865F50B1@szxeml556-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3A082@dfweml706-chm> <23CE718903A838468A8B325B80962F9B86600573@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B86600573@szxeml556-mbs.china.huawei.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.17] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48127951F7ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+JvjW7wL+0Qg6dvNS229Fxgs+hfcYbF Yto8Vwdmj5Yjb1k9liz5yRTAFMVlk5Kak1mWWqRvl8CVMb1lJXPBjRnMFVs+nGZpYFz/jKmL kZNDQsBEou/KJjYIW0ziwr31QDYXh5DAUUaJHT1NYAkhgUWMEh9msncxcnCwCVhJPDnkAxIW EciWWN3VwQ5iCwvISaz4eYgFIi4vcf3FBUaQchGBMIkb561AwiwCKhKrXraCTeQV8JXYf/Q0 M8Sq5cwSLb0nWEESnED1r+58BpvJKCArMWH3IkYQm1lAXOLWk/lQNwtILNlznhnCFpV4+fgf K8guCQFFieX9chDl+RIHpzxihdglKHFy5hOWCYwis5BMmoWkbBaSMoi4nsSNqVPYIGxtiWUL XzND2LoSM/4dYkEWX8DIvopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjML4ObvltsIPx5XPH Q4wCHIxKPLwJM7RDhFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY1jfoysTPwYEfH18d/UWZ4WXrUE7W5/t/dTv/Zb3r72wrM0vhdaU5DvCx48sWLTWZ73W lcAzaiv/ZTI8U25zNpa5a7+xLvjEt6fJf8oPrPr4ru6S+uXnSoes955UdU1SYlx2yO5Ap2fo YvtwM/GJ750s9Py8338ssnknvM77XVXeSsE+U2udk0osxRmJhlrMRcWJAB1o4qWQAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/-jB3Gf0SvOANoPv7XQkaUTKqs1M Subject: Re: [Actn] ACTN architecture 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, 01 Oct 2014 12:58:05 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48127951F7ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dhruv, Young, Trying to keep the reply as simple as possible: >[Dhruv 3]: I completely agree with you on this point. And thus prefer if w= e do not dwell much on Daniele Case b, hierarchy among the PNC and PNC-PNC = interface being out of scope and focus of ACTN. Ok, it makes sense. >[Dhruv 3]: we have not used the term 'multi-domain coordinator' in the dra= ft-ceccarelli-actn-framework-03; but we use it in charter text, perhaps we = can relook into this. Yep, we need to fix that. Thanks Daniele From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com] Sent: luned=EC 29 settembre 2014 07:05 To: Leeyoung; Daniele Ceccarelli; actn@ietf.org Subject: RE: ACTN architecture Hi Young, Thanks for the update to http://datatracker.ietf.org/doc/draft-ceccarelli-a= ctn-framework/ I will send my comments on the update in a separate thread... Rest inline w= ith tag [Dhruv 3] (snip) Reposting my architecture considerations and Young's replies in a dedicated= thread. 1. On multidomain issues: One question here: How do we want to manage = multi-domain? I see two ways: a. A coordinator of virtual network controllers - i.e. 1:1 relationshi= p between virtual network controller and physical network controller plus a= coordinator of virtual network controllers on top b. A coordinator of physical network controllers - i.e. a coordinator = of physical network controllers (1:N relationship between coordinator and P= NCs) with a virtual network controller on top? (1:1 relationship between PN= C coordinator and the VNC) Maybe we should consider both architectures, maybe pick one. YOUNG>> These options seem to be detailed architecture that the upcoming ar= chitecture document should address in detail. My personal opinion is that b= oth architectures need to be considered as a starting point. There may be o= ther variations. Then we may narrow the scope as an initial baseline archit= ecture. [[DanCe]] Agree. Let's keep track of both of them. [Dhruv]: In the current architecture document we do not use the term 'coord= inator'; In the charter it says - "Multi-domain network coordination function in ACT= N is built on a control hierarchy where a multi-domain coordinator interact= s with each domain controller (e.g., EMS/NMS, GMPLS/PCE control plane, SDN = controller) for abstracting network resource information to provide virtual= network control functions. This virtual network control functions are embe= dded in a multi-domain network coordinator to support various services/clie= nts/applications to create and manage their own virtual networks that share= the common transport network resources." To me this reads as the coordinator and virtual network control function ar= e embedded together. If we feel that multiple options are okay and need to = be studied, we should relax the text in the charter. YOUNG>> I think VNC-PNC construct is the main architecture interface of ACT= N. Although Architecture document is being prepared, the current assumption= is that PNC has a minimum module as proxy to communicate with VNC. When VN= C deals with multi-domain networks, multi-domain coordination function aris= es within the VNC. I think this is case a (Per Daniele). The coordinator V= NC has to deal with multiple VNCs or PNCs with VN proxy function. [Dhruv 2]: In my opinion what Daniele suggest is more like - Daniele Case a: Virtual network Coordinator | | -------------+------------ | | | | | | VNC VNC VNC | | | | | | PNC PNC PNC Daniele Case b: VNC | | Physical network Coordinator | | -------------+------------ | | | | | | PNC PNC PNC Here the key difference is - 'multi-domain coordinator function' to be enga= ging with VNCs or PNCs in the southbound. YOUNG 2> Yes. Agree. >From your description I gather that the 'multi-domain coordinator function'= can interact with multiple VNC (case a) or interact with multiple PNC (cas= e b) which I also think is valid. Making this look like.... Multi-domain Coordinator (parent | -VNC) | -------------+------------ | | | | | | VNC VNC VNC | | | | | | PNC PNC PNC YOUNG 2> This above diagram is basically the same as Daniele's Case a. VNC | (probably embedded | together) Multi-domain Coordinator | | -------------+------------ | | | | | | PNC PNC PNC YOUNG 2> This is very close to Daniele's Case b except the 'Multi-dom= ain coordinator' is not explicitly defined as Physical Network Coordinator.= In the charter description, we embedded the multi-domain coordination fun= ction as part of VNC. Here VNC and MD coordinator can be decoupled as anoth= er possibility. The above diagram is different from Daniele's Case b if we= assume the interface between PNCs and the MD coordinator is of physical na= ture or of virtual nature. If this is of physical nature, then this interfa= ce may be slightly different from VNC-PNC interface (which we called VPI fo= r Case a. This is a PNC-PNC interface in a hierarchical fashion, for the la= ck of a better term PPI interface. What is the difference between VNC-PNC = and PNC-PNC interfaces? Since we are dealing with virtualization as the mai= n charter item, I would prefer to focus on VNC-PNC construct as Case a and = also for Case b if we were to interpret the interface between MD Coordinato= r and PNCs is of virtual nature. [Dhruv 3]: I completely agree with you on this point. And thus prefer if we= do not dwell much on Daniele Case b, hierarchy among the PNC and PNC-PNC i= nterface being out of scope and focus of ACTN. For case b (per Daniele), I think we are only concerned about VNC-PNC (as 1= :1) while how the PNC coordinator deals with its domain PNC controller is o= ut of scope of ACTN work in my view. In this case, we are only dealing wi= th the VNC with the PNC coordinator. Multi-domain coordination is "delegat= ed" to the PNC level. [Dhruv 2]: I am not sure what you mean here? YOUNG 2> Please see my above comment. So I think your point is that the current charter is more or less case a's = perspective. But I think case a is the base-line case to which ACTN work s= hould be focused on. Case b is subset of case a. I am not to sure The charter text thus seems more closely related to case (b) where a multi-= domain coordinator interacts with domain controllers (PNC) and this functio= n resides with virtual network control function. [Dhruv 2]: Yes. YOUNG 2> Yes, with an understanding that the [VNC+MD Coordinator] is int= erfacing with PNCs in a virtual manner. [Dhruv 3]: we have not used the term 'multi-domain coordinator' in the draf= t-ceccarelli-actn-framework-03; but we use it in charter text, perhaps we c= an relook into this. Again on multidomain: maybe we could improve the architecture draft saying = is centralized and what is distributed. E.g. VPN prefixes exchange could be= distributed (controllers speaking MP-BGP with each other) while provisioni= ng could be hierarchical (i.e. the coordinator asks controller A to provisi= on a path with domain A and asks controller B to provide a path within B so= to have an end to end path crossing domains A and B)...H-PCE like. YOUNG>> Good point. I agree that the architecture draft should discuss thes= e dichotomy of control regimes (e.g., centralized vs. distributed). One que= stion I have: are you assuming the coordinator also speaks MP-BGP with lowe= r level PN controllers? If not, would the coordinator need to collect the V= PN prefixes using the interface between the coordinator and each PNC (that = speaks MP-BGP)? Then can this be viewed as a centralized component? [[DanCe]] The scenarios that come to my mind are more "horizontal". I would= say the either the nodes speak MP-BGP with each other across the domains = (in case of distributed protocols) or the controllers gets the information = from its own domain and then speak MP-BGP with the other controllers "on be= half of their domains" [Dhruv]: I feel this is highly dependent on the physical network controller= s, if its a PCE it has its own way to do inter-PCE communication and if the= controller runs BGP it may directly interact with other controller. IMHO = the ACTN architecture should not impose any restriction on this interaction= , nor make it a pre-requisite as in some case the two controller may not be= able to interact with each other directly (different technology, vendor sp= ecific NMS etc). YOUNG>> I agree with you on this. Regards, Dhruv --_000_4A1562797D64E44993C5CBF38CF1BE48127951F7ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dhruv, Young, =

Trying to keep the rep= ly as simple as possible:

 

>[Dhruv 3]: I completely agree with you on this point. And thus prefer if = we do not dwell much on Daniele Case b, hierarchy among the PNC and PNC-PNC interface being out of scope and focus of ACTN.   &n= bsp;       

 

Ok, it makes sense.

 

>[Dhruv 3]: we have not used the ter= m ‘multi-domain coordinator’ in the draft-ceccarelli-actn-frame= work-03; but we use it in charter text, perhaps we can relook into this.

 

Yep, we need to fix th= at.

 

Thanks

Daniele

 

From: Dhruv Dh= ody [mailto:dhruv.dhody@huawei.com]
Sent: luned=EC 29 settembre 2014 07:05
To: Leeyoung; Daniele Ceccarelli; actn@ietf.org
Subject: RE: ACTN architecture

 

Hi Young,

 

Thanks for the update to http://datatracker.ietf.org/doc/draf= t-ceccarelli-actn-framework/

I will send my comments on the update in a= separate thread… Rest inline with tag [Dhruv 3]

 

(snip)

 

Reposting my architect= ure considerations and Young’s replies in a dedicated thread.

 

 

1.&= nbsp;     On multidomain= issues: One question here: How do we want to manage multi-domain? I see tw= o ways:

a. &nbs= p;    A coordinator = of virtual network controllers – i.e. 1:1 relationship between virtua= l network controller and physical network controller plus a coordinator of = virtual network controllers on top

b. &nbs= p;    A coordinator = of physical network controllers – i.e. a coordinator of physical netw= ork controllers (1:N relationship between coordinator and PNCs) with a virt= ual network controller on top? (1:1 relationship between PNC coordinator and the VNC)

Maybe we should consider both architectures, maybe pick one.<= o:p>

 

YOUNG>> These option= s seem to be detailed architecture that the upcoming architecture document = should address in detail. My personal opinion is that both architectures ne= ed to be considered as a starting point. There may be other variations. Then we may narrow the scope as an initial baseli= ne architecture.

[[DanCe]] Agree. Let&#= 8217;s keep track of both of them.

[Dhruv]: In the= current architecture document we do not use the term ‘coordinator= 217;;

In the charter = it says – “Multi-domain network coordination function in ACT= N is built on a control hierarchy where a multi-domain coordinator interact= s with each domain controller (e.g., EMS/NMS, GMPLS/PCE control plane, SDN c= ontroller) for abstracting network resource information to provide virtual = network control functions. This virtual network control functions are embed= ded in a multi-domain network coordinator to support various services/clients/applications to create and manage thei= r own virtual networks that share the common transport network resources.”  

To me this read= s as the coordinator and virtual network control function are embedded toge= ther. If we feel that multiple options are okay and need to be studied, we should relax the text in the charter.  

 

YOUNG>> I= think VNC-PNC construct is the main architecture interface of ACTN. Althou= gh Architecture document is being prepared, the current assumption is that PNC has a minimum module as proxy to communicate with VNC. When VN= C deals with multi-domain networks, multi-domain coordination function aris= es within the VNC.  I think this is case a (Per Daniele). The coordina= tor VNC has to deal with multiple VNCs or PNCs with VN proxy function.

[Dhruv 2]: &nbs= p;In my opinion what Daniele suggest is more like -

Daniele Case a:=

 

  &nb= sp;            =   Virtual network Coordinator

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =   -------------+------------

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            VNC&n= bsp;          VNC  &= nbsp;       VNC

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            PNC&n= bsp;          PNC  &= nbsp;       PNC

  &nb= sp;      

 

Daniele Case b:=          

  &nb= sp;            =             &nb= sp; VNC          &nb= sp;

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =   Physical network Coordinator

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;             = ;            &n= bsp; |

  &nb= sp;            =   -------------+------------

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            PNC&n= bsp;          PNC  &= nbsp;       PNC

 

Here the key difference is – ‘multi-domain coordinator func= tion’ to be engaging with VNCs or PNCs in the southbound.

 

YOUNG 2> Yes. Agree.

 

From your description I gather that the ‘multi-domain coordinator= function’ can interact with multiple VNC (case a) or interact with multiple PNC (case b) which I also think is valid.

Making this look like….

  &nb= sp;            =      Multi-domain Coordinator (parent=

  &nb= sp;            =             &nb= sp;  |          &nbs= p;    -VNC)

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =   -------------+------------

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            VNC&n= bsp;          VNC  &= nbsp;       VNC

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            PNC&n= bsp;          PNC  &= nbsp;       PNC     =  

  &nb= sp;            =

  YOUNG 2> This above diagram is basically the same as= Daniele’s Case a.      

  =             &nb= sp;         =

  &nb= sp;            =             &nb= sp; VNC          &nb= sp;

  &nb= sp;            =             &nb= sp;  | (probably embedded

  &nb= sp;            =             &nb= sp;  |  together)

  &nb= sp;            =     Multi-domain Coordinator     &n= bsp;            = ;            &n= bsp;   

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =             &nb= sp;  |

  &nb= sp;            =   -------------+------------

  &nb= sp;            = |             = |            |<= /o:p>

  &nb= sp;            = |             = |            |<= /o:p>

   &n= bsp;            = ; PNC          PNC &= nbsp;        PNC

 

  &nb= sp;  YOUNG 2>  This is very close to Daniele’s= Case b except the ‘Multi-domain coordinator’ is not explicitly= defined as Physical Network Coordinator.  In the charter description,= we embedded the multi-domain coordination function as part of VNC. Here VNC and MD coo= rdinator can be decoupled as another possibility.  The above diagram i= s different from Daniele’s Case b if we assume the interface between = PNCs and the MD coordinator is of physical nature or of virtual nature. If this is of physical nature, then this inte= rface may be slightly different from VNC-PNC interface (which we called VPI= for Case a. This is a PNC-PNC interface in a hierarchical fashion, for the= lack of a better term PPI interface.  What is the difference between VNC-PNC and PNC-PNC interfaces? Since we ar= e dealing with virtualization as the main charter item, I would prefer to f= ocus on VNC-PNC construct as Case a and also for Case b if we were to inter= pret the interface between MD Coordinator and PNCs is of virtual nature.  

 <= /o:p>

[Dhruv 3]: I completely agree with you = on this point. And thus prefer if we do not dwell much on Daniele Case b, h= ierarchy among the PNC and PNC-PNC interface being out of scope and focus of ACTN.         &= nbsp; 

 <= /o:p>

For case b (per= Daniele), I think we are only concerned about VNC-PNC (as 1:1) while how t= he PNC coordinator deals with its domain PNC controller is out of scope of ACTN work in  my view.  In this case, we are onl= y dealing with the VNC with the PNC coordinator.  Multi-domain coordin= ation is “delegated” to the PNC level.  =

[Dhruv 2]: I am= not sure what you mean here?

 

YOUNG 2> =  Please see my above comment.

 

So I think your= point is that the current charter is more or less case a’s perspecti= ve.  But I think case a is the base-line case to which ACTN work should be focused on. Case b is subset of case a.

 

I am not to sure

 

The charter text thus seems more closely related to case (b) where a mu= lti-domain coordinator interacts with domain controllers (PNC) and this function resides with virtual network control function.

[Dhruv 2]: Yes.

 YOUNG 2&= gt;   Yes, with an understanding that the [VNC+MD Coordinator= ] is interfacing with PNCs in a virtual manner.

 

[Dhruv 3]: we have not used the term &#= 8216;multi-domain coordinator’ in the draft-ceccarelli-actn-framework= -03; but we use it in charter text, perhaps we can relook into this.

     &nbs= p;         

Again on multidomain: maybe we could improve the architecture draft sa= ying is centralized and what is distributed. E.g. VPN prefixes exchange cou= ld be distributed (controllers speaking MP-BGP with each other) while provisioning could be hierarchical (i.e. the= coordinator asks controller A to provision a path with domain A and asks c= ontroller B to provide a path within B so to have an end to end path crossi= ng domains A and B)…H-PCE like.

 

YOUNG>> Good poi= nt. I agree that the architecture draft should discuss these dichotomy of c= ontrol regimes (e.g., centralized vs. distributed). One question I have: ar= e you assuming the coordinator also speaks MP-BGP with lower level PN controllers? If not, would the coordinator need= to collect the VPN prefixes using the interface between the coordinator an= d each PNC (that speaks MP-BGP)? Then can this be viewed as a centralized c= omponent?

[[DanCe]] The scenario= s that come to my mind are more “horizontal”. I would say the e= ither the nodes speak MP-BGP with each other across the domains  (in c= ase of distributed protocols) or the controllers gets the information from its own domain and then speak MP-BGP with the other c= ontrollers “on behalf of their domains”

 

 

[Dhruv]: I feel= this is highly dependent on the physical network controllers, if its a PCE= it has its own way to do inter-PCE communication and if the controller runs BGP  it may directly interact with other controller. = IMHO the ACTN architecture should not impose any restriction on this intera= ction, nor make it a pre-requisite as in some case the two controller may n= ot be able to interact with each other directly (different technology, vendor specific NMS etc).

 

YOUNG>> I= agree with you on this.

 

 

Regards,

Dhruv

--_000_4A1562797D64E44993C5CBF38CF1BE48127951F7ESESSMB301erics_-- From nobody Wed Oct 1 06:22:23 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 4E75E1A03F9 for ; Wed, 1 Oct 2014 06:22:19 -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 KWJO3Zz85q-N for ; Wed, 1 Oct 2014 06:22:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEB61A038E for ; Wed, 1 Oct 2014 06:21:54 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-05-542bfff1c013 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.C0.21432.1FFFB245; Wed, 1 Oct 2014 15:21:53 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.79]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Wed, 1 Oct 2014 15:21:53 +0200 From: Daniele Ceccarelli To: Leeyoung , LUIS MIGUEL CONTRERAS MURILLO , "adrian@olddog.co.uk" , "actn@ietf.org" Thread-Topic: [Actn] ACTN architecture and interfaces Thread-Index: Ac/cDiPXMQFQG+jkRVKDqJnlOJCGwQAAHQEAAAY44bAAAgn18AACmsogAE/OlsA= Date: Wed, 1 Oct 2014 13:21:53 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481279525E@ESESSMB301.ericsson.se> References: <03bc01cfdc0e$2c346d80$849d4880$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C3ABB3@dfweml706-chm> <67fc7b199bea4c9f836686a244c6a920@DB4PR06MB576.eurprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE27@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE44@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3AE44@dfweml706-chm> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3Rvfjf+0Qgx2d8hZbei6wWfzoucFs 8enhJWaLafNcLc49n8HmwOqxc9Zddo+WI29ZPZYs+cnksWLzSkaPzt/MAaxRXDYpqTmZZalF +nYJXBkvrnxlKfhQUrGku5e5gfFDYRcjJ4eEgInEs7+TmSFsMYkL99azdTFycQgJHGWU+H3l CDuEs4hR4tKiFqAMBwebgJXEk0M+IHERgQOMEgcfHWEE6WYWUJG4dWw5C4gtDDT1zfpesKki AqYS+3ffYISw/SS+3//MBGKzANXfu/4SrIZXwFdiZ9s8Zohl25kk7m3eBFbEKeAq8XLSXXYQ m1FAVmLC7kVQy8Qlbj2ZzwRxtoDEkj3noV4QlXj5+B8ryKESAooSy/vlQExmAU2J9bv0IToV JaZ0P2SHWCsocXLmE5YJjGKzkAydhdAxC0nHLCQdCxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp 5aWWbGIERt3BLb8NdjC+fO54iFGAg1GJhzdhhnaIEGtiWXFl7iFGaQ4WJXHehefmBQsJpCeW pGanphakFsUXleakFh9iZOLglGpgVLRR6tdX/aA/Td3n0iN22Sk7Vum2/r3UGSL2dtWyst+X Dj53PLWE/Zqk74P6GwaLd27w4rZ/4PDr/0He8KBq3Ry5M3kPb9a+b+2aVJT9PPrBnOWv7n8p rHM78DMuxT34x537jGpbWvyvPOBzeBX4r2zyvPNzrworunhzOnYt1nPOPeM7b809FiWW4oxE Qy3mouJEAAPPhOqbAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/nw0Il0_lC9qikocUobUrViHML_U Cc: 'Alia Atlas' Subject: Re: [Actn] ACTN architecture and interfaces 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, 01 Oct 2014 13:22:19 -0000 SGkgWW91bmcsIEx1aXMsDQoNCkludGVyZXN0aW5nIHRvcGljLiBJIGNvbmN1ciB3aXRoIFlvdW5n IHdoZW4gc2F5aW5nIHRoYXQgdGhlIGludGVyZmFjZSBiZXR3ZWVuIGEgVk5DcyBpbiBhIHJlY3Vy c2l2ZSBhcmNoaXRlY3R1cmUgaXMgb2YgInR5cGUiIEIuIA0KUmVnYXJkaW5nIHRoZSB0d28gZGlm ZmVyZW50IG9wdGlvbnMgYmVsb3c6DQoNCj4gYSkgVk5DIChQcm92aWRlciBYKSAtLS0gaS9mIEIu MiAtLS0tLSBWTkMgKFByb3ZpZGVyIFkpIC0tLS0gaS9mIEMgLS0tLSBQTkMNCj4gKFByb3ZpZGVy IFkpDQo+IGIpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjEgLS0tLS0gVk5DIChQcm92aWRl ciBYKSAtLS0tIGkvZiBDIC0tLS0gUE5DDQo+IChQcm92aWRlciBYKQ0KDQpJIHNlZSB0aGUgcmVj dXJzaXZlbmVzcyBvZiBWTkNzIHdpdGhpbiB0aGUgc2FtZSBwcm92aWRlciAoIGIpIGFzIGFuIGV4 dHJlbWVseSB1bmNvbW1vbiBjb3JuZXIgY2FzZXMsIHdoaWNoLCBpZiBuZWVkZWQsIG1pZ2h0IGJl IGFkZHJlc3NlZCBhcyBhIHBhcnRpY3VsYXIgY2FzZSBvZiBhKS4gDQpJcyB0aGVyZSBhIHJlYXNv biBmb3IgYSBwcm92aWRlciB0byBoYXZlIGEgcmVjdXJzaXZlbmVzcyBvZiBWTkNzPyBJZiB0aGUg Z29hbCBpcyB0byBlbmhhbmNlIHNjYWxhYmlsaXR5IEkgd291bGQgc2F5IHRoYXQgaXQgaXMgYSBt YXR0ZXIgaW5jcmVhc2luZyB0aGUgbnVtYmVyIG9mIFBOQyB1bmRlciB0aGUgY29udHJvbCBvZiB0 aGUgc2FtZSBWTkMgYnV0IEkgdGhpbmsgY2FzZSBhKSBpcyBlbm91Z2guDQoNCkJSDQpEYW5pZWxl DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQUNUTiBbbWFpbHRvOmFj dG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQo+IFNlbnQ6IG1hcnRl ZMOsIDMwIHNldHRlbWJyZSAyMDE0IDAxOjA4DQo+IFRvOiBMZWV5b3VuZzsgTFVJUyBNSUdVRUwg Q09OVFJFUkFTIE1VUklMTE87IGFkcmlhbkBvbGRkb2cuY28udWs7DQo+IGFjdG5AaWV0Zi5vcmcN Cj4gQ2M6ICdBbGlhIEF0bGFzJw0KPiBTdWJqZWN0OiBSZTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0 dXJlIGFuZCBpbnRlcmZhY2VzDQo+IA0KPiBIaSBMdWlzLA0KPiANCj4gSSBtZWFudA0KPiANCj4g YikgVk5DIChQcm92aWRlciBYKSAtLS0gaS9mIEIuMSAtLS0tLSBWTkMgKFByb3ZpZGVyIFgpIC0t LS0gaS9mIEMgLS0tLSBQTkMNCj4gKFByb3ZpZGVyIFgpDQo+IA0KPiBTb3JyeS4NCj4gWW91bmcN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFDVE4gW21haWx0bzph Y3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWV5b3VuZw0KPiBTZW50OiBNb25k YXksIFNlcHRlbWJlciAyOSwgMjAxNCA1OjU4IFBNDQo+IFRvOiBMVUlTIE1JR1VFTCBDT05UUkVS QVMgTVVSSUxMTzsgYWRyaWFuQG9sZGRvZy5jby51azsgYWN0bkBpZXRmLm9yZw0KPiBDYzogJ0Fs aWEgQXRsYXMnDQo+IFN1YmplY3Q6IFJlOiBbQWN0bl0gQUNUTiBhcmNoaXRlY3R1cmUgYW5kIGlu dGVyZmFjZXMNCj4gDQo+IEhpIEx1aXMsDQo+IA0KPiBUaGlzIGNhc2UgaXMgYSBiaXQgYWR2YW5j ZWQgdG9waWMgKGEgdmFyaWF0aW9uIGZyb20gdGhlIGJhc2UgYXJjaGl0ZWN0dXJlKSBidXQgSQ0K PiB0aGluayBpdCBpcyBhIGdvb2QgdG9waWMgdG8gZ3JhcHBsZSBzb29uZXIgdGhhbiBsYXRlci4N Cj4gDQo+IFlvdXIgc2NlbmFyaW9zIG1ha2UgbWUgdGhpbmsgd2UgbWlnaHQgbmVlZCB0byBoYXZl IHR3byBkaW1lbnNpb25zIGluIHRoZQ0KPiBpbnRlcmZhY2UgZGVmaW5pdGlvbiBmb3IgSW50ZXJm YWNlIEIuIFBlcmhhcHMgQi4xIGFuZCBCLjIgd2hlcmUgQi4xIGFuIGludGVybmFsDQo+IGludGVy ZmFjZSBhbmQgQi4yIGFuIGV4dGVybmFsIGludGVyZmFjZS4gQW4gaW50ZXJuYWwgaW50ZXJmYWNl IG1lYW5zIHRoZSB0d28NCj4gZW5kIGVudGl0aWVzIGJlbG9uZyB0byB0aGUgc2FtZSBvcGVyYXRv ciB3aGlsZSBhbiBleHRlcm5hbCBpbnRlcmZhY2UgbWVhbnMNCj4gdGhlIHR3byBlbmQgZW50aXRp ZXMgYmVsb25nIHRvIHR3byBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgb3BlcmF0b3JzLiBGb3IN Cj4gVk5DLVBOQywgd2UgbWF5IG5vdCBuZWVkIHRvIGRpc3Rpbmd1aXNoIGludGVybmFsIG9yIGV4 dGVybmFsIGFzIHRoZQ0KPiBhc3N1bXB0aW9uIG1hZGUgd2FzIGl0IGlzIG9ubHkgaW50ZXJuYWwg KG9mIGNvdXJzZSwgdGhpcyBhc3N1bXB0aW9uIGNhbiBiZQ0KPiByZWxheGVkIGluIGEgbW9yZSBn ZW5lcmFsIGNhc2UsIGJ1dCBmb3Igbm93IGxldCB1cyBzdGF5IHdpdGggdGhpcyBhc3N1bXB0aW9u DQo+IGZvciB0aGlzIHRocmVhZCkuDQo+IA0KPiBXaXRoIHRoaXMgaW4gbWluZCwgSSB0aGluayB0 aGUgYmFzZSBhcmNoaXRlY3R1cmUgaW4gRmlndXJlIDUgaW4gU2VjdGlvbiA2LjEuMSBpcw0KPiBt b3JlIG9yIGxlc3MgQ05DICAtLS0gaS9mIEIuMSAtLS0tLSBWTkMgLS0tLWkvZiBDIC0tLS0tIFBO Q3MuDQo+IA0KPiBOb3RlIHRoYXQgVk5DIGlzIGFzc3VtZWQgdG8gcHJvdmlkZSBtdWx0aS1kb21h aW4gY29vcmRpbmF0aW9uIGZ1bmN0aW9uDQo+IChpbnRlcmZhY2luZyBtdWx0aXBsZSBQTkNzKS4N Cj4gDQo+IFRoZSBjYXNlIHlvdSBicm91Z2h0IHVwIGlzIG1vcmUgb3IgbGVzczoNCj4gDQo+IGEp IFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjIgLS0tLS0gVk5DIChQcm92aWRlciBZKSAtLS0t IGkvZiBDIC0tLS0gUE5DDQo+IChQcm92aWRlciBZKQ0KPiBiKSBWTkMgKFByb3ZpZGVyIFgpIC0t LSBpL2YgQi4xIC0tLS0tIFZOQyAoUHJvdmlkZXIgWCkgLS0tLSBpL2YgQyAtLS0tIFZOQw0KPiAo UHJvdmlkZXIgWCkNCj4gDQo+IE5vdGU6IENOQy1WTkMgaXMgb21pdHRlZCBhcyB0aGlzIGNhbiBi ZSBlaXRoZXIgQi4xIG9yIEIuMiBkZXBlbmRpbmcgb24gdGhlDQo+IHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIENOQyBhbmQgVk5DLg0KPiANCj4gSSB3b3VsZCBzYXkgdGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIFZOQ3MgYXJlIG1vcmUgb3IgbGVzcyBpL2YgQiAocmF0aGVyIHRoYW4NCj4gaS9mIEMpIGFz IHRoZXkgYXJlIG1vcmUgb3IgbGVzcyBzaW1pbGFyIHRvIENOQy1WTkMuIFRoYXQgaXMgdGhlIHJl YXNvbiBmb3IgdGhlDQo+IGFib3ZlIG1hcHBpbmcgYSkgYW5kIGIpLg0KPiANCj4gVGhpcyBpcyBh biBpbnRlcmVzdGluZyBkaXNjdXNzaW9uLiBJIG1pZ2h0IGhhdmUgbWlzc2VkIHlvdXIgcG9pbnRz IGFuZCBJIGFtDQo+IHN1cmUgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW50IHBlcnNwZWN0aXZlcy4N Cj4gTGV0J3Mgc2VlIGhvdyBvdGhlciBmb2xrcyBsb29rIGF0IHRoaXMgcHJvYmxlbS4NCj4gDQo+ IEJlc3QgcmVnYXJkcywNCj4gWW91bmcNCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE8NCj4gW21haWx0 bzpsdWlzbWlndWVsLmNvbnRyZXJhc211cmlsbG9AdGVsZWZvbmljYS5jb21dDQo+IFNlbnQ6IE1v bmRheSwgU2VwdGVtYmVyIDI5LCAyMDE0IDQ6MDIgUE0NCj4gVG86IExlZXlvdW5nOyBhZHJpYW5A b2xkZG9nLmNvLnVrOyBhY3RuQGlldGYub3JnDQo+IENjOiAnQWxpYSBBdGxhcycNCj4gU3ViamVj dDogUkU6IFtBY3RuXSBBQ1ROIGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlcw0KPiANCj4gSGkg WW91bmcNCj4gDQo+IE9uZSBxdWVzdGlvbiByYWlzZWQgdG8gbWUgd2hlbiB0aGlua2luZyBhYm91 dCByZWN1cnNpdmVuZXNzIGluIHRoaXMNCj4gYXJjaGl0ZWN0dXJlLiBXaGF0IHdvdWxkIGJlIHRo ZSBzY2hlbWEgaW4gY2FzZSB3aGVyZSBhIFZOQyBjb21tdW5pY2F0ZXMNCj4gd2l0aCBhbm90aGVy IFZOQz8gVGhpcyBjb3VsZCBiZSBhbiBzY2VuYXJpbyB3aGVyZSBhIHZpcnR1YWwgbmV0d29yaw0K PiBwcm92aWRlciBidWlsZHMgaXRzIG9mZmVyZWQgdHJhbnNwb3J0IG5ldHdvcmsgY2FwYWJpbGl0 aWVzIHRvdGFsIG9yIHBhcnRpYWxseSBvbg0KPiB0b3Agb2YgYW5vdGhlciB2aXJ0dWFsIG5ldHdv cmsgcHJvdmlkZXIuDQo+IA0KPiBUaGVyZSBhcmUgc29tZSBhbHRlcm5hdGl2ZXM6DQo+IA0KPiBh KSBDTkMgLS0gKGkvZiBCKSAtLSBWTkMgLS0geyAtLSAoaS9mIEIpIC0tIFZOQyAtLSAoaS9mIEMp IC0tIFBOQ30NCj4gYikgQ05DIC0tIChpL2YgQikgLS0gVk5DIC0tIHsgLS0gKGkvZiBDKSAtLSBW TkMgLS0gKGkvZiBDKSAtLSBQTkN9DQo+IGMpIGJvdGggb2YgdGhlbQ0KPiANCj4gUmVnYXJkcw0K PiANCj4gTHVpcw0KPiANCj4gDQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERlOiBB Q1ROIFttYWlsdG86YWN0bi1ib3VuY2VzQGlldGYub3JnXSBFbiBub21icmUgZGUgTGVleW91bmcg RW52aWFkbw0KPiBlbDogbHVuZXMsIDI5IGRlIHNlcHRpZW1icmUgZGUgMjAxNCAyMDowOA0KPiBQ YXJhOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBhY3RuQGlldGYub3JnDQo+IENDOiAnQWxpYSBBdGxh cycNCj4gQXN1bnRvOiBSZTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFuZCBpbnRlcmZhY2Vz DQo+IA0KPiBIaSBBZHJpYW4sDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgYnJpbmdpbmcgdXAgdGhp cyBhcmNoaXRlY3R1cmUgZGlzY3Vzc2lvbiB0byB0aGUgbGlzdC4gSSBmZWVsIGl0DQo+IG1pZ2h0 IGJlIHVzZWZ1bCB0byBicmluZyB1cCBoZXJlIEZpZ3VyZSA1Og0KPiANCj4gICAgICAgICAgICAg ICAgIC4tLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tICAgfA0K PiAgICAgICAgICAgICAgIHwgQXBwbGljYXRpb24gfC0tDQo+ICAgICAgICAgICAgICAgIC0tLS0t LS0tLS0tLS0NCj4gICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAg ICB8IEkvRiBBICAgICAgICAgICAgICAgICAtLS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAgICAg ICB2ICAgICAgICAgICAgICAgICAgICAgICggICAgICAgICkNCj4gICAgICAgICAgICAgICAgIC0t LS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0gICAgICAgICAgLQ0KPiAgICAgICAgICAgICAgICB8 IEN1c3RvbWVyICAgICB8ICAgICAgICAgICAoICBDdXN0b21lciAgKQ0KPiAgICAgICAgICAgICAg ICB8ICBOZXR3b3JrICAgICB8LS0tLS0tLS0tPiggICAgTmV0d29yayAgICkNCj4gICAgICAgICAg ICAgICAgfCAgIENvbnRyb2xsZXIgfCAgICAgICAgICAgKCAgICAgICAgICAgICkNCj4gICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0gICAgICAgICAgLQ0KPiAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICggICAgICAgICkNCj4gICAg ICAgICAgICAgICAgICAgICAgfCBJL0YgQiAgICAgICAgICAgICAgICAgLS0tLS0tLS0NCj4gICAg ICAgICAgICAgICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgIF4gICAgXg0KPiAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgOiAgICA6DQo+ICAgICAg ICAgICAgICAgIHwgVmlydHVhbCAgICAgIHwgICAgICAgICAgICAgICA6ICAgICAuDQo+ICAgICAg ICAgICAgICAgIHwgIE5ldHdvcmsgICAgIHwgICAgICAgICAgICAgICA6ICAgICAgLg0KPiAgICAg ICAgICAgICAgICB8ICAgQ29udHJvbGxlciB8ICAgICAgICAgICAgLS0tLS0tLS0gICAuIEkvRiBF DQo+ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICggICAgICAgICkg ICAuDQo+ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgLSAgICAgICAg ICAtICAgLg0KPiAgICAgICAgICAgICAgICAgICAgICB8IEkvRiBDICAgICAgICAgICAgKCAgUGh5 c2ljYWwgICkgICAuDQo+ICAgICAgICAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICgg ICAgTmV0d29yayAgICkgICAuDQo+ICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLSAg ICAgICAoICAgICAgICAgICAgKSAgICAgLS0tLS0tLS0NCj4gICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfC0tLS0tPiAtICAgICAgICAgIC0gICAgICggICAgICAgICkNCj4gICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgfCAgICAgICAgKCAgICAgICAgKSAgICAgLSAgICAg ICAgIC0NCj4gICAgICAgICAgICAgICAgfCBQaHlzaWNhbCAgICAgfC0tICAgICAgICAgIC0tLS0t LS0tICAgICAoICBQaHlzaWNhbCAgKQ0KPiAgICAgICAgICAgICAgICB8ICBOZXR3b3JrICAgICB8 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+KCAgICBOZXR3b3JrICAgKQ0KPiAgICAgICAgICAgICAg ICB8ICAgQ29udHJvbGxlciB8ICAgICAgICAgSS9GIEQgICAgICAgICAgICggICAgICAgICAgICAp DQo+ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0gICAgICAgICAtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoICAgICAgICApDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0NCj4gDQo+IA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDUuIEFDVE4gSW50ZXJmYWNlcw0KPiANCj4g QXMgeW91IHBvaW50ZWQgb3V0LCB0aGUgcXVvdGVkIGNoYXJ0ZXIgYW5kIFNlY3Rpb24gNi4xLjEg b2YgdGhlIGZyYW1ld29yaw0KPiBkcmFmdCBhcmUgY29uc2lzdGVudCBpbiB0aGF0IGJvdGggb2Yg dGhlbSBsaW1pdCB0aGUgc2NvcGUgb2YgQUNUTiB3b3JrIHRvIEkvRg0KPiBCIGFuZCBJL0YgQyAo RmlndXJlIDUpIHRoYXQgY29ycmVzcG9uZCB0byB0aGUgQ05DLVZOQyBhbmQgVk5DLVBOQw0KPiBp bnRlcmZhY2UsIHJlc3BlY3RpdmVseS4gT3RoZXIgaW50ZXJmYWNlcyBhcmUgb3V0IG9mIHNjb3Bl LiBUaGV5IGFyZSBzaG93biBmb3INCj4gYW4gaWxsdXN0cmF0aW9uIHB1cnBvc2UgdG8gZ2l2ZSB0 aGUgb3ZlcmFyY2hpbmcgY29udGV4dCBvZiBBQ1ROLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBZ b3VuZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQUNUTiBbbWFp bHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4g U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTQgMTI6NTMgUE0NCj4gVG86IGFjdG5AaWV0 Zi5vcmcNCj4gQ2M6ICdBbGlhIEF0bGFzJw0KPiBTdWJqZWN0OiBbQWN0bl0gQUNUTiBhcmNoaXRl Y3R1cmUgYW5kIGludGVyZmFjZXMNCj4gDQo+IEhpLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgbGF0 ZXN0IHJldmlzaW9uIG9mDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtY2VjY2FyZWxs aS1hY3RuLWZyYW1ld29yay0wMy50eHQNCj4gSSBmaW5kIHRoZSBuZXcgRmlndXJlIDUgcGFydGlj dWxhcmx5IGhlbHBmdWwgaW4gdW5kZXJzdGFuZGluZyB0aGUgcG90ZW50aWFsDQo+IHNjb3BlIG9m IHRoZSBBQ1ROIHdvcmsuIEFuZCB0aGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIGF0IHRoaXMgc3Rh Z2UgaWYgdGhlDQo+IHByb2Nlc3Mgd2UgYXJlIHRyeWluZyB0byB3b3JrIG91dCBleGFjdGx5IHdo YXQgYW4gQUNUTiB3b3JraW5nIGdyb3VwIG1pZ2h0DQo+IHdvcmsgb24gaWYgaXQgd2FzIGNyZWF0 ZWQuDQo+IA0KPiBMb29raW5nIGF0IHRoZSB2MS4zIGRyYWZ0IGNoYXJ0ZXIgdGV4dCBhdA0KPiBo dHRwczovL3NpdGVzLmdvb2dsZS5jb20vc2l0ZS9hY3RuYm9mL2hvbWUvY2hhcnRlci1wcm9wb3Nh bCBJIHNlZS4uLg0KPiA+IFRoaXMgYXJjaGl0ZWN0dXJlIHNob3dzIHRocmVlDQo+ID4gY29udHJv bCBjb21wb25lbnRzOiB0aGUgQ3VzdG9tZXIgTmV0d29yayBDb250cm9sbGVyIChDTkMpIHJlc3Bv bnNpYmxlDQo+ID4gZm9yIHNlcnZpY2luZyByZXF1ZXN0cyBmcm9tIGFwcGxpY2F0aW9ucyAoc3Vj aCBhcyBPU1MvTk1TKSwgdGhlDQo+ID4gVmlydHVhbCBOZXR3b3JrIENvbnRyb2xsZXIgKFZOQykg cmVzcG9uc2libGUgZm9yIHJlYWxpemluZyBjdXN0b21lcg0KPiA+IG5ldHdvcmtzIG91dCBvZiBw aHlzaWNhbCBuZXR3b3JrIHJlc291cmNlcywgYW5kIHRoZSBQaHlzaWNhbCBOZXR3b3JrDQo+ID4g Q29udHJvbGxlciAoUE5DKSByZXNwb25zaWJsZSBmb3IgY29udHJvbCBhbmQgcHJvdmlzaW9uaW5n IGluIHBoeXNpY2FsDQo+ID4gbmV0d29ya3MuIFRoZSBhcmNoaXRlY3R1cmUgc2hvd3MgdGhlIG5l ZWQgZm9yIGludGVyZmFjZXMgYmV0d2VlbiB0aGVzZQ0KPiBjb21wb25lbnRzLg0KPiANCj4gSSBq dXN0IHdhbnQgdG8gY2hlY2sgd2hhdCB0aGlzIG1lYW5zLiBJIHJlYWQgaXQgYXMgc2F5aW5nIHRo YXQgaW50ZXJmYWNlcyBCIGFuZA0KPiBDIGFzIHNob3duIG9uIEZpZ3VyZSA1IGFyZSBpbiBzY29w ZSBmb3IgYW4gQUNUTiB3b3JraW5nIGdyb3VwLCBidXQgYWxsIG90aGVyDQo+IGludGVyZmFjZXMg c2hvd24gb24gdGhlIGZpZ3VyZSBhcmUgbm90IGluIHNjb3BlLiBJIGJlbGlldmUgdGhpcyBpcyBj b25zaXN0ZW50DQo+IHdpdGggU2VjdGlvbiA2LjEuMSBvZiB0aGUgZHJhZnQuDQo+IA0KPiBDYW4g eSdhbGwgY29uZmlybSB0aGF0IHRoaXMgaXMgeW91ciB1bmRlcnN0YW5kaW5nIGFuZCB3aGF0IHlv dSB3YW50IHRvIHdvcmsNCj4gb24gYW5kIGV4Y2x1ZGUuDQo+IA0KPiBUaGFua3MsDQo+IEFkcmlh bg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gQUNUTiBtYWlsaW5nIGxpc3QNCj4gQUNUTkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjdG4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFDVE4gbWFpbGluZyBsaXN0DQo+IEFDVE5AaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY3RuDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gRXN0ZSBtZW5zYWplIHkg c3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8s DQo+IHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNp YWwgeSBlcyBwYXJhIHVzbw0KPiBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUg ZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbw0KPiBpbmRpY2FkbywgcXVl ZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nD s24geS9vIGNvcGlhDQo+IHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBl biB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpDQo+IGhhIHJlY2liaWRvIGVz dGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUNCj4g aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uDQo+IA0KPiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNz aW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KPiBpbmZvcm1hdGlvbiBpbnRlbmRl ZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZA0KPiBh Ym92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUNCj4gaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMNCj4gY29tbXVuaWNhdGlvbiBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbg0KPiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0 byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUNCj4gcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9u IGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCj4gDQo+IEVzdGEgbWVuc2FnZW0gZSBzZXVz IGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldQ0KPiBkZXN0aW5hdMOhcmlv LCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBl IMOpIHBhcmENCj4gdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGlu by4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvDQo+IGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8s IGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HD p8Ojbw0KPiBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRh IGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvDQo+IHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBt ZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvDQo+IGNvbXVuaXF1ZSBpbWVk aWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6Nv DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFD VE4gbWFpbGluZyBsaXN0DQo+IEFDVE5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hY3RuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEFDVE4gbWFpbGluZyBsaXN0DQo+IEFDVE5AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY3RuDQo= From nobody Wed Oct 1 10:08:05 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 11E8A1A1A62 for ; Wed, 1 Oct 2014 10:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 AUH7nMmoYOdz for ; Wed, 1 Oct 2014 10:07:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17201A1A72 for ; Wed, 1 Oct 2014 10:07:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKD07995; Wed, 01 Oct 2014 17:07:44 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Oct 2014 18:07:43 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 1 Oct 2014 10:07:40 -0700 From: Leeyoung To: Daniele Ceccarelli , "LUIS MIGUEL CONTRERAS MURILLO" , "adrian@olddog.co.uk" , "actn@ietf.org" Thread-Topic: [Actn] ACTN architecture and interfaces Thread-Index: Ac/cDiPXMQFQG+jkRVKDqJnlOJCGwQAAHQEAAAY44bAAAgn18AACmsogAE/OlsAAB9bZcA== Date: Wed, 1 Oct 2014 17:07:39 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3B42A@dfweml706-chm> References: <03bc01cfdc0e$2c346d80$849d4880$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C3ABB3@dfweml706-chm> <67fc7b199bea4c9f836686a244c6a920@DB4PR06MB576.eurprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE27@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE44@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481279525E@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481279525E@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/TZCbFFJYs8k-PeGw0R9GhJ-XfOw Cc: 'Alia Atlas' Subject: Re: [Actn] ACTN architecture and interfaces 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, 01 Oct 2014 17:07:50 -0000 SGkgRGFuaWVsZSwNCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IFZOQy1WTkMgZm9yIHRoZSBzYW1l IHByb3ZpZGVyIGlzIGEgY29ybmVyIGNhc2Ugd2hlcmUgQ2FzZSBhKSBjYW4gY292ZXIgd2VsbCB3 aXRoIHRydXN0L3NlY3VyaXR5IGNvbnN0cmFpbnQgYXNwZWN0IGJlaW5nIHJlbGF4ZWQuIEJ1dCBJ IHdhbnRlZCBMdWlzIHRvIGNvbW1lbnQgb24gdGhhdDsgaGUgbWF5IGJlIGF3YXJlIG9mIHRoZSBj YXNlIGxpa2UgdGhhdCBhcyBUZWxlZm9uaWNhIGlzIGRlYWxpbmcgd2l0aCBnbG9iYWwgbmV0d29y a3Mgd2hlcmUgSSBjYW4gc2VlIGEgcG90ZW50aWFsIGZvciB0aGF0IGNhc2UuDQoNClRoYW5rcywN CllvdW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYW5pZWxlIENlY2Nh cmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXSANClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAwMSwgMjAxNCA4OjIyIEFNDQpUbzogTGVleW91bmc7IExVSVMgTUlH VUVMIENPTlRSRVJBUyBNVVJJTExPOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBhY3RuQGlldGYub3Jn DQpDYzogJ0FsaWEgQXRsYXMnDQpTdWJqZWN0OiBSRTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJl IGFuZCBpbnRlcmZhY2VzDQoNCkhpIFlvdW5nLCBMdWlzLA0KDQpJbnRlcmVzdGluZyB0b3BpYy4g SSBjb25jdXIgd2l0aCBZb3VuZyB3aGVuIHNheWluZyB0aGF0IHRoZSBpbnRlcmZhY2UgYmV0d2Vl biBhIFZOQ3MgaW4gYSByZWN1cnNpdmUgYXJjaGl0ZWN0dXJlIGlzIG9mICJ0eXBlIiBCLiANClJl Z2FyZGluZyB0aGUgdHdvIGRpZmZlcmVudCBvcHRpb25zIGJlbG93Og0KDQo+IGEpIFZOQyAoUHJv dmlkZXIgWCkgLS0tIGkvZiBCLjIgLS0tLS0gVk5DIChQcm92aWRlciBZKSAtLS0tIGkvZiBDIC0t LS0gDQo+IFBOQyAoUHJvdmlkZXIgWSkNCj4gYikgVk5DIChQcm92aWRlciBYKSAtLS0gaS9mIEIu MSAtLS0tLSBWTkMgKFByb3ZpZGVyIFgpIC0tLS0gaS9mIEMgLS0tLSANCj4gUE5DIChQcm92aWRl ciBYKQ0KDQpJIHNlZSB0aGUgcmVjdXJzaXZlbmVzcyBvZiBWTkNzIHdpdGhpbiB0aGUgc2FtZSBw cm92aWRlciAoIGIpIGFzIGFuIGV4dHJlbWVseSB1bmNvbW1vbiBjb3JuZXIgY2FzZXMsIHdoaWNo LCBpZiBuZWVkZWQsIG1pZ2h0IGJlIGFkZHJlc3NlZCBhcyBhIHBhcnRpY3VsYXIgY2FzZSBvZiBh KS4gDQpJcyB0aGVyZSBhIHJlYXNvbiBmb3IgYSBwcm92aWRlciB0byBoYXZlIGEgcmVjdXJzaXZl bmVzcyBvZiBWTkNzPyBJZiB0aGUgZ29hbCBpcyB0byBlbmhhbmNlIHNjYWxhYmlsaXR5IEkgd291 bGQgc2F5IHRoYXQgaXQgaXMgYSBtYXR0ZXIgaW5jcmVhc2luZyB0aGUgbnVtYmVyIG9mIFBOQyB1 bmRlciB0aGUgY29udHJvbCBvZiB0aGUgc2FtZSBWTkMgYnV0IEkgdGhpbmsgY2FzZSBhKSBpcyBl bm91Z2guDQoNCkJSDQpEYW5pZWxlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExl ZXlvdW5nDQo+IFNlbnQ6IG1hcnRlZMOsIDMwIHNldHRlbWJyZSAyMDE0IDAxOjA4DQo+IFRvOiBM ZWV5b3VuZzsgTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE87IGFkcmlhbkBvbGRkb2cuY28u dWs7IA0KPiBhY3RuQGlldGYub3JnDQo+IENjOiAnQWxpYSBBdGxhcycNCj4gU3ViamVjdDogUmU6 IFtBY3RuXSBBQ1ROIGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlcw0KPiANCj4gSGkgTHVpcywN Cj4gDQo+IEkgbWVhbnQNCj4gDQo+IGIpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjEgLS0t LS0gVk5DIChQcm92aWRlciBYKSAtLS0tIGkvZiBDIC0tLS0gDQo+IFBOQyAoUHJvdmlkZXIgWCkN Cj4gDQo+IFNvcnJ5Lg0KPiBZb3VuZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IExlZXlvdW5nDQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI5LCAyMDE0IDU6NTggUE0NCj4g VG86IExVSVMgTUlHVUVMIENPTlRSRVJBUyBNVVJJTExPOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBh Y3RuQGlldGYub3JnDQo+IENjOiAnQWxpYSBBdGxhcycNCj4gU3ViamVjdDogUmU6IFtBY3RuXSBB Q1ROIGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlcw0KPiANCj4gSGkgTHVpcywNCj4gDQo+IFRo aXMgY2FzZSBpcyBhIGJpdCBhZHZhbmNlZCB0b3BpYyAoYSB2YXJpYXRpb24gZnJvbSB0aGUgYmFz ZSANCj4gYXJjaGl0ZWN0dXJlKSBidXQgSSB0aGluayBpdCBpcyBhIGdvb2QgdG9waWMgdG8gZ3Jh cHBsZSBzb29uZXIgdGhhbiBsYXRlci4NCj4gDQo+IFlvdXIgc2NlbmFyaW9zIG1ha2UgbWUgdGhp bmsgd2UgbWlnaHQgbmVlZCB0byBoYXZlIHR3byBkaW1lbnNpb25zIGluIA0KPiB0aGUgaW50ZXJm YWNlIGRlZmluaXRpb24gZm9yIEludGVyZmFjZSBCLiBQZXJoYXBzIEIuMSBhbmQgQi4yIHdoZXJl IA0KPiBCLjEgYW4gaW50ZXJuYWwgaW50ZXJmYWNlIGFuZCBCLjIgYW4gZXh0ZXJuYWwgaW50ZXJm YWNlLiBBbiBpbnRlcm5hbCANCj4gaW50ZXJmYWNlIG1lYW5zIHRoZSB0d28gZW5kIGVudGl0aWVz IGJlbG9uZyB0byB0aGUgc2FtZSBvcGVyYXRvciB3aGlsZSANCj4gYW4gZXh0ZXJuYWwgaW50ZXJm YWNlIG1lYW5zIHRoZSB0d28gZW5kIGVudGl0aWVzIGJlbG9uZyB0byB0d28gDQo+IGRpZmZlcmVu dCBhZG1pbmlzdHJhdGl2ZSBvcGVyYXRvcnMuIEZvciBWTkMtUE5DLCB3ZSBtYXkgbm90IG5lZWQg dG8gDQo+IGRpc3Rpbmd1aXNoIGludGVybmFsIG9yIGV4dGVybmFsIGFzIHRoZSBhc3N1bXB0aW9u IG1hZGUgd2FzIGl0IGlzIG9ubHkgDQo+IGludGVybmFsIChvZiBjb3Vyc2UsIHRoaXMgYXNzdW1w dGlvbiBjYW4gYmUgcmVsYXhlZCBpbiBhIG1vcmUgZ2VuZXJhbCANCj4gY2FzZSwgYnV0IGZvciBu b3cgbGV0IHVzIHN0YXkgd2l0aCB0aGlzIGFzc3VtcHRpb24gZm9yIHRoaXMgdGhyZWFkKS4NCj4g DQo+IFdpdGggdGhpcyBpbiBtaW5kLCBJIHRoaW5rIHRoZSBiYXNlIGFyY2hpdGVjdHVyZSBpbiBG aWd1cmUgNSBpbiANCj4gU2VjdGlvbiA2LjEuMSBpcyBtb3JlIG9yIGxlc3MgQ05DICAtLS0gaS9m IEIuMSAtLS0tLSBWTkMgLS0tLWkvZiBDIC0tLS0tIFBOQ3MuDQo+IA0KPiBOb3RlIHRoYXQgVk5D IGlzIGFzc3VtZWQgdG8gcHJvdmlkZSBtdWx0aS1kb21haW4gY29vcmRpbmF0aW9uIGZ1bmN0aW9u IA0KPiAoaW50ZXJmYWNpbmcgbXVsdGlwbGUgUE5DcykuDQo+IA0KPiBUaGUgY2FzZSB5b3UgYnJv dWdodCB1cCBpcyBtb3JlIG9yIGxlc3M6DQo+IA0KPiBhKSBWTkMgKFByb3ZpZGVyIFgpIC0tLSBp L2YgQi4yIC0tLS0tIFZOQyAoUHJvdmlkZXIgWSkgLS0tLSBpL2YgQyAtLS0tIA0KPiBQTkMgKFBy b3ZpZGVyIFkpDQo+IGIpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjEgLS0tLS0gVk5DIChQ cm92aWRlciBYKSAtLS0tIGkvZiBDIC0tLS0gDQo+IFZOQyAoUHJvdmlkZXIgWCkNCj4gDQo+IE5v dGU6IENOQy1WTkMgaXMgb21pdHRlZCBhcyB0aGlzIGNhbiBiZSBlaXRoZXIgQi4xIG9yIEIuMiBk ZXBlbmRpbmcgb24gDQo+IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBDTkMgYW5kIFZOQy4NCj4g DQo+IEkgd291bGQgc2F5IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBWTkNzIGFyZSBtb3JlIG9y IGxlc3MgaS9mIEIgDQo+IChyYXRoZXIgdGhhbiBpL2YgQykgYXMgdGhleSBhcmUgbW9yZSBvciBs ZXNzIHNpbWlsYXIgdG8gQ05DLVZOQy4gVGhhdCANCj4gaXMgdGhlIHJlYXNvbiBmb3IgdGhlIGFi b3ZlIG1hcHBpbmcgYSkgYW5kIGIpLg0KPiANCj4gVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBkaXNj dXNzaW9uLiBJIG1pZ2h0IGhhdmUgbWlzc2VkIHlvdXIgcG9pbnRzIGFuZCANCj4gSSBhbSBzdXJl IHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMuDQo+IExldCdzIHNlZSBob3cg b3RoZXIgZm9sa3MgbG9vayBhdCB0aGlzIHByb2JsZW0uDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFlvdW5nDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IExVSVMgTUlHVUVMIENPTlRSRVJBUyBNVVJJTExPDQo+IFttYWlsdG86bHVpc21pZ3VlbC5jb250 cmVyYXNtdXJpbGxvQHRlbGVmb25pY2EuY29tXQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAy OSwgMjAxNCA0OjAyIFBNDQo+IFRvOiBMZWV5b3VuZzsgYWRyaWFuQG9sZGRvZy5jby51azsgYWN0 bkBpZXRmLm9yZw0KPiBDYzogJ0FsaWEgQXRsYXMnDQo+IFN1YmplY3Q6IFJFOiBbQWN0bl0gQUNU TiBhcmNoaXRlY3R1cmUgYW5kIGludGVyZmFjZXMNCj4gDQo+IEhpIFlvdW5nDQo+IA0KPiBPbmUg cXVlc3Rpb24gcmFpc2VkIHRvIG1lIHdoZW4gdGhpbmtpbmcgYWJvdXQgcmVjdXJzaXZlbmVzcyBp biB0aGlzIA0KPiBhcmNoaXRlY3R1cmUuIFdoYXQgd291bGQgYmUgdGhlIHNjaGVtYSBpbiBjYXNl IHdoZXJlIGEgVk5DIA0KPiBjb21tdW5pY2F0ZXMgd2l0aCBhbm90aGVyIFZOQz8gVGhpcyBjb3Vs ZCBiZSBhbiBzY2VuYXJpbyB3aGVyZSBhIA0KPiB2aXJ0dWFsIG5ldHdvcmsgcHJvdmlkZXIgYnVp bGRzIGl0cyBvZmZlcmVkIHRyYW5zcG9ydCBuZXR3b3JrIA0KPiBjYXBhYmlsaXRpZXMgdG90YWwg b3IgcGFydGlhbGx5IG9uIHRvcCBvZiBhbm90aGVyIHZpcnR1YWwgbmV0d29yayBwcm92aWRlci4N Cj4gDQo+IFRoZXJlIGFyZSBzb21lIGFsdGVybmF0aXZlczoNCj4gDQo+IGEpIENOQyAtLSAoaS9m IEIpIC0tIFZOQyAtLSB7IC0tIChpL2YgQikgLS0gVk5DIC0tIChpL2YgQykgLS0gUE5DfQ0KPiBi KSBDTkMgLS0gKGkvZiBCKSAtLSBWTkMgLS0geyAtLSAoaS9mIEMpIC0tIFZOQyAtLSAoaS9mIEMp IC0tIFBOQ30NCj4gYykgYm90aCBvZiB0aGVtDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBMdWlzDQo+ IA0KPiANCj4gLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IEFDVE4gW21haWx0bzph Y3RuLWJvdW5jZXNAaWV0Zi5vcmddIEVuIG5vbWJyZSBkZSBMZWV5b3VuZyBFbnZpYWRvDQo+IGVs OiBsdW5lcywgMjkgZGUgc2VwdGllbWJyZSBkZSAyMDE0IDIwOjA4DQo+IFBhcmE6IGFkcmlhbkBv bGRkb2cuY28udWs7IGFjdG5AaWV0Zi5vcmcNCj4gQ0M6ICdBbGlhIEF0bGFzJw0KPiBBc3VudG86 IFJlOiBbQWN0bl0gQUNUTiBhcmNoaXRlY3R1cmUgYW5kIGludGVyZmFjZXMNCj4gDQo+IEhpIEFk cmlhbiwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBicmluZ2luZyB1cCB0aGlzIGFyY2hpdGVjdHVy ZSBkaXNjdXNzaW9uIHRvIHRoZSBsaXN0LiANCj4gSSBmZWVsIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0 byBicmluZyB1cCBoZXJlIEZpZ3VyZSA1Og0KPiANCj4gICAgICAgICAgICAgICAgIC4tLS0tLS0t LS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tICAgfA0KPiAgICAgICAgICAg ICAgIHwgQXBwbGljYXRpb24gfC0tDQo+ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0NCj4g ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICB8IEkvRiBBICAg ICAgICAgICAgICAgICAtLS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAgICAgICB2ICAgICAgICAg ICAgICAgICAgICAgICggICAgICAgICkNCj4gICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0t ICAgICAgICAgICAgIC0gICAgICAgICAgLQ0KPiAgICAgICAgICAgICAgICB8IEN1c3RvbWVyICAg ICB8ICAgICAgICAgICAoICBDdXN0b21lciAgKQ0KPiAgICAgICAgICAgICAgICB8ICBOZXR3b3Jr ICAgICB8LS0tLS0tLS0tPiggICAgTmV0d29yayAgICkNCj4gICAgICAgICAgICAgICAgfCAgIENv bnRyb2xsZXIgfCAgICAgICAgICAgKCAgICAgICAgICAgICkNCj4gICAgICAgICAgICAgICAgIC0t LS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0gICAgICAgICAgLQ0KPiAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICggICAgICAgICkNCj4gICAgICAgICAgICAgICAg ICAgICAgfCBJL0YgQiAgICAgICAgICAgICAgICAgLS0tLS0tLS0NCj4gICAgICAgICAgICAgICAg ICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgIF4gICAgXg0KPiAgICAgICAgICAgICAgICAg LS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgOiAgICA6DQo+ICAgICAgICAgICAgICAgIHwg VmlydHVhbCAgICAgIHwgICAgICAgICAgICAgICA6ICAgICAuDQo+ICAgICAgICAgICAgICAgIHwg IE5ldHdvcmsgICAgIHwgICAgICAgICAgICAgICA6ICAgICAgLg0KPiAgICAgICAgICAgICAgICB8 ICAgQ29udHJvbGxlciB8ICAgICAgICAgICAgLS0tLS0tLS0gICAuIEkvRiBFDQo+ICAgICAgICAg ICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICggICAgICAgICkgICAuDQo+ICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgLSAgICAgICAgICAtICAgLg0KPiAg ICAgICAgICAgICAgICAgICAgICB8IEkvRiBDICAgICAgICAgICAgKCAgUGh5c2ljYWwgICkgICAu DQo+ICAgICAgICAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICggICAgTmV0d29yayAg ICkgICAuDQo+ICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLSAgICAgICAoICAgICAg ICAgICAgKSAgICAgLS0tLS0tLS0NCj4gICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fC0tLS0tPiAtICAgICAgICAgIC0gICAgICggICAgICAgICkNCj4gICAgICAgICAgICAgICAgIC0t LS0tLS0tLS0tLS0tICAgfCAgICAgICAgKCAgICAgICAgKSAgICAgLSAgICAgICAgIC0NCj4gICAg ICAgICAgICAgICAgfCBQaHlzaWNhbCAgICAgfC0tICAgICAgICAgIC0tLS0tLS0tICAgICAoICBQ aHlzaWNhbCAgKQ0KPiAgICAgICAgICAgICAgICB8ICBOZXR3b3JrICAgICB8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0+KCAgICBOZXR3b3JrICAgKQ0KPiAgICAgICAgICAgICAgICB8ICAgQ29udHJv bGxlciB8ICAgICAgICAgSS9GIEQgICAgICAgICAgICggICAgICAgICAgICApDQo+ICAgICAgICAg ICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgIC0gICAgICAg ICAtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoICAgICAgICApDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0NCj4gDQo+IA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDUuIEFDVE4gSW50ZXJmYWNlcw0KPiANCj4gQXMgeW91IHBvaW50 ZWQgb3V0LCB0aGUgcXVvdGVkIGNoYXJ0ZXIgYW5kIFNlY3Rpb24gNi4xLjEgb2YgdGhlIA0KPiBm cmFtZXdvcmsgZHJhZnQgYXJlIGNvbnNpc3RlbnQgaW4gdGhhdCBib3RoIG9mIHRoZW0gbGltaXQg dGhlIHNjb3BlIG9mIA0KPiBBQ1ROIHdvcmsgdG8gSS9GIEIgYW5kIEkvRiBDIChGaWd1cmUgNSkg dGhhdCBjb3JyZXNwb25kIHRvIHRoZSBDTkMtVk5DIA0KPiBhbmQgVk5DLVBOQyBpbnRlcmZhY2Us IHJlc3BlY3RpdmVseS4gT3RoZXIgaW50ZXJmYWNlcyBhcmUgb3V0IG9mIA0KPiBzY29wZS4gVGhl eSBhcmUgc2hvd24gZm9yIGFuIGlsbHVzdHJhdGlvbiBwdXJwb3NlIHRvIGdpdmUgdGhlIG92ZXJh cmNoaW5nIGNvbnRleHQgb2YgQUNUTi4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWW91bmcNCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFDVE4gW21haWx0bzphY3Ru LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQo+IFNlbnQ6IE1v bmRheSwgU2VwdGVtYmVyIDI5LCAyMDE0IDEyOjUzIFBNDQo+IFRvOiBhY3RuQGlldGYub3JnDQo+ IENjOiAnQWxpYSBBdGxhcycNCj4gU3ViamVjdDogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFu ZCBpbnRlcmZhY2VzDQo+IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGxhdGVzdCByZXZp c2lvbiBvZg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWNlY2NhcmVsbGktYWN0bi1m cmFtZXdvcmstMDMudHh0DQo+IEkgZmluZCB0aGUgbmV3IEZpZ3VyZSA1IHBhcnRpY3VsYXJseSBo ZWxwZnVsIGluIHVuZGVyc3RhbmRpbmcgdGhlIA0KPiBwb3RlbnRpYWwgc2NvcGUgb2YgdGhlIEFD VE4gd29yay4gQW5kIHRoaXMgaXMgaW1wb3J0YW50IGJlY2F1c2UgYXQgDQo+IHRoaXMgc3RhZ2Ug aWYgdGhlIHByb2Nlc3Mgd2UgYXJlIHRyeWluZyB0byB3b3JrIG91dCBleGFjdGx5IHdoYXQgYW4g DQo+IEFDVE4gd29ya2luZyBncm91cCBtaWdodCB3b3JrIG9uIGlmIGl0IHdhcyBjcmVhdGVkLg0K PiANCj4gTG9va2luZyBhdCB0aGUgdjEuMyBkcmFmdCBjaGFydGVyIHRleHQgYXQgDQo+IGh0dHBz Oi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2FjdG5ib2YvaG9tZS9jaGFydGVyLXByb3Bvc2FsIEkg c2VlLi4uDQo+ID4gVGhpcyBhcmNoaXRlY3R1cmUgc2hvd3MgdGhyZWUNCj4gPiBjb250cm9sIGNv bXBvbmVudHM6IHRoZSBDdXN0b21lciBOZXR3b3JrIENvbnRyb2xsZXIgKENOQykgDQo+ID4gcmVz cG9uc2libGUgZm9yIHNlcnZpY2luZyByZXF1ZXN0cyBmcm9tIGFwcGxpY2F0aW9ucyAoc3VjaCBh cyANCj4gPiBPU1MvTk1TKSwgdGhlIFZpcnR1YWwgTmV0d29yayBDb250cm9sbGVyIChWTkMpIHJl c3BvbnNpYmxlIGZvciANCj4gPiByZWFsaXppbmcgY3VzdG9tZXIgbmV0d29ya3Mgb3V0IG9mIHBo eXNpY2FsIG5ldHdvcmsgcmVzb3VyY2VzLCBhbmQgDQo+ID4gdGhlIFBoeXNpY2FsIE5ldHdvcmsg Q29udHJvbGxlciAoUE5DKSByZXNwb25zaWJsZSBmb3IgY29udHJvbCBhbmQgDQo+ID4gcHJvdmlz aW9uaW5nIGluIHBoeXNpY2FsIG5ldHdvcmtzLiBUaGUgYXJjaGl0ZWN0dXJlIHNob3dzIHRoZSBu ZWVkIA0KPiA+IGZvciBpbnRlcmZhY2VzIGJldHdlZW4gdGhlc2UNCj4gY29tcG9uZW50cy4NCj4g DQo+IEkganVzdCB3YW50IHRvIGNoZWNrIHdoYXQgdGhpcyBtZWFucy4gSSByZWFkIGl0IGFzIHNh eWluZyB0aGF0IA0KPiBpbnRlcmZhY2VzIEIgYW5kIEMgYXMgc2hvd24gb24gRmlndXJlIDUgYXJl IGluIHNjb3BlIGZvciBhbiBBQ1ROIA0KPiB3b3JraW5nIGdyb3VwLCBidXQgYWxsIG90aGVyIGlu dGVyZmFjZXMgc2hvd24gb24gdGhlIGZpZ3VyZSBhcmUgbm90IGluIA0KPiBzY29wZS4gSSBiZWxp ZXZlIHRoaXMgaXMgY29uc2lzdGVudCB3aXRoIFNlY3Rpb24gNi4xLjEgb2YgdGhlIGRyYWZ0Lg0K PiANCj4gQ2FuIHknYWxsIGNvbmZpcm0gdGhhdCB0aGlzIGlzIHlvdXIgdW5kZXJzdGFuZGluZyBh bmQgd2hhdCB5b3Ugd2FudCB0byANCj4gd29yayBvbiBhbmQgZXhjbHVkZS4NCj4gDQo+IFRoYW5r cywNCj4gQWRyaWFuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBBQ1ROIG1haWxpbmcgbGlzdA0KPiBBQ1ROQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWN0bg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQUNUTiBtYWlsaW5nIGxpc3QN Cj4gQUNUTkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FjdG4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBFc3Rl IG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IA0K PiBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEg byBjb25maWRlbmNpYWwgeSANCj4gZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEg byBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIA0KPiB1c3RlZC4gZWwgZGVzdGluYXRhcmlv IGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCANCj4gdXRpbGl6 YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVz dGFyIA0KPiBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBT aSBoYSByZWNpYmlkbyBlc3RlIA0KPiBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUg bm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJv Y2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCj4gDQo+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgDQo+IGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIA0K PiBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlz IG5vdCB0aGUgDQo+IGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgDQo+IGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRo aXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiANCj4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiANCj4g UGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KPiAN Cj4gRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUg YW8gc2V1IA0KPiBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmls ZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIA0KPiBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2EgDQo+IHNlbmhvcmlh IG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1 cmEsIA0KPiB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3Jp emHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIA0KPiBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8Oj byB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIA0KPiByb2dhbW9z LWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlh IGUgDQo+IHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvIA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBQ1ROIG1haWxpbmcgbGlzdA0KPiBBQ1RO QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWN0bg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBQ1RO IG1haWxpbmcgbGlzdA0KPiBBQ1ROQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYWN0bg0K From nobody Wed Oct 1 10:24: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 4C1C31A1A79 for ; Wed, 1 Oct 2014 10:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 gB1gY7bYZY2l for ; Wed, 1 Oct 2014 10:07:28 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF8E1A1A62 for ; Wed, 1 Oct 2014 10:07:27 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BD57760161; Wed, 1 Oct 2014 19:07:24 +0200 (CEST) Received: from ESTGVMSP111.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id A1ADD60164; Wed, 1 Oct 2014 19:07:24 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 19:07:24 +0200 Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 17:07:22 +0000 Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 17:07:22 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: Daniele Ceccarelli , Leeyoung , "adrian@olddog.co.uk" , "actn@ietf.org" Thread-Topic: [Actn] ACTN architecture and interfaces Thread-Index: Ac/cDiPXMQFQG+jkRVKDqJnlOJCGwQAAHQEAAAY44bAAAgn18AACmsogAE/OlsAAB+zecA== Date: Wed, 1 Oct 2014 17:07:22 +0000 Message-ID: <153bbb418eee47e484f2657ce925bdb4@DB4PR06MB576.eurprd06.prod.outlook.com> References: <03bc01cfdc0e$2c346d80$849d4880$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C3ABB3@dfweml706-chm> <67fc7b199bea4c9f836686a244c6a920@DB4PR06MB576.eurprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE27@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE44@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481279525E@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481279525E@ESESSMB301.ericsson.se> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [195.235.92.27] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB576; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(377454003)(189002)(51914003)(13464003)(51704005)(2656002)(76482002)(97736003)(99396003)(31966008)(74316001)(66066001)(107046002)(86362001)(15202345003)(76576001)(21056001)(20776003)(46102003)(92566001)(120916001)(33646002)(19580395003)(10300001)(19580405001)(87936001)(95666004)(50986999)(106356001)(105586002)(85306004)(76176999)(80022003)(561944003)(2501002)(101416001)(93886004)(4396001)(108616004)(54356999)(85852003)(2201001)(15975445006)(64706001)(16351025005)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB576; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/actn/pKvpfg-SHbZ28qTa77oqXlT_hUo X-Mailman-Approved-At: Wed, 01 Oct 2014 10:24:03 -0700 Cc: 'Alia Atlas' Subject: Re: [Actn] ACTN architecture and interfaces 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, 01 Oct 2014 17:07:33 -0000 SGkgRGFuaWVsZSwNCg0KSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91LiBTZWVtcyB0byBiZSBhIGNv cm5lciBjYXNlLCBhdCBsZWFzdCBJIGRvbid0IHJlYWxpemUgbm93IGEgY2xlYXIgc2NlbmFyaW8g Zm9yIHRoYXQuDQoNCkkgaGF2ZSBhbiBhZGRpdGlvbmFsIGNvbW1lbnQgcmVnYXJkaW5nIHRoZXNl IGlkZWFzLiBJZiB0aGUgcmVjdXJzaXZlIGFyY2hpdGVjdHVyZSBpcyBiYXNlZCBvbiB0eXBlIEIg aW50ZXJmYWNlcyBiZXR3ZWVuIFZOQyBwcm92aWRlciBYIGFuZCBWTkMgUHJvdmlkZXIgWSwgaW4g Y29udHJhc3QgdG8gbWFpbnRhaW5pbmcgYW4gaW50ZXJmYWNlIG9mIHR5cGUgQyB3aXRoIGEgUGh5 c2ljYWwgcHJvdmlkZXIgY2FsbGVkIGZvciBpbnN0YW5jZSBaLCB0aGlzIG1lYW5zIHRoYXQgUHJv dmlkZXIgWCBpcyBhd2FyZSB0aGF0IFByb3ZpZGVyIFkgaXMgbm90IGEgUGh5c2ljYWwgcHJvdmlk ZXIgKGF0IGxlYXN0IHRvdGFsbHksIGkuZS4sIG5vdCBhbGwgdGhlIHRyYW5zcG9ydCBjYXBhYmls aXRpZXMgYXJlIG93bmVkIGJ5IFByb3ZpZGVyIFkpLg0KDQpJIHdvbmRlciBpZiB0aGlzIGNvdWxk IGhhdmUgZnVydGhlciBpbXBsaWNhdGlvbnMgZnJvbSBzZXZlcmFsIHBlcnNwZWN0aXZlczogU0xB cywgaW5mb3JtYXRpb24gZXhwb3N1cmUsIGV0Yy4NCg0KSnVzdCBzaGFyaW5nIG15IHRob3VnaHRz LA0KDQpSZWdhcmRzDQoNCkx1aXMNCg0KLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCkRlOiBE YW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t XQ0KRW52aWFkbyBlbDogbWnDqXJjb2xlcywgMDEgZGUgb2N0dWJyZSBkZSAyMDE0IDE1OjIyDQpQ YXJhOiBMZWV5b3VuZzsgTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE87IGFkcmlhbkBvbGRk b2cuY28udWs7IGFjdG5AaWV0Zi5vcmcNCkNDOiAnQWxpYSBBdGxhcycNCkFzdW50bzogUkU6IFtB Y3RuXSBBQ1ROIGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlcw0KDQpIaSBZb3VuZywgTHVpcywN Cg0KSW50ZXJlc3RpbmcgdG9waWMuIEkgY29uY3VyIHdpdGggWW91bmcgd2hlbiBzYXlpbmcgdGhh dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gYSBWTkNzIGluIGEgcmVjdXJzaXZlIGFyY2hpdGVjdHVy ZSBpcyBvZiAidHlwZSIgQi4NClJlZ2FyZGluZyB0aGUgdHdvIGRpZmZlcmVudCBvcHRpb25zIGJl bG93Og0KDQo+IGEpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjIgLS0tLS0gVk5DIChQcm92 aWRlciBZKSAtLS0tIGkvZiBDIC0tLS0NCj4gUE5DIChQcm92aWRlciBZKQ0KPiBiKSBWTkMgKFBy b3ZpZGVyIFgpIC0tLSBpL2YgQi4xIC0tLS0tIFZOQyAoUHJvdmlkZXIgWCkgLS0tLSBpL2YgQyAt LS0tDQo+IFBOQyAoUHJvdmlkZXIgWCkNCg0KSSBzZWUgdGhlIHJlY3Vyc2l2ZW5lc3Mgb2YgVk5D cyB3aXRoaW4gdGhlIHNhbWUgcHJvdmlkZXIgKCBiKSBhcyBhbiBleHRyZW1lbHkgdW5jb21tb24g Y29ybmVyIGNhc2VzLCB3aGljaCwgaWYgbmVlZGVkLCBtaWdodCBiZSBhZGRyZXNzZWQgYXMgYSBw YXJ0aWN1bGFyIGNhc2Ugb2YgYSkuDQpJcyB0aGVyZSBhIHJlYXNvbiBmb3IgYSBwcm92aWRlciB0 byBoYXZlIGEgcmVjdXJzaXZlbmVzcyBvZiBWTkNzPyBJZiB0aGUgZ29hbCBpcyB0byBlbmhhbmNl IHNjYWxhYmlsaXR5IEkgd291bGQgc2F5IHRoYXQgaXQgaXMgYSBtYXR0ZXIgaW5jcmVhc2luZyB0 aGUgbnVtYmVyIG9mIFBOQyB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgc2FtZSBWTkMgYnV0IEkg dGhpbmsgY2FzZSBhKSBpcyBlbm91Z2guDQoNCkJSDQpEYW5pZWxlDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQo+IFNlbnQ6IG1hcnRlZMOsIDMwIHNldHRlbWJyZSAy MDE0IDAxOjA4DQo+IFRvOiBMZWV5b3VuZzsgTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE87 IGFkcmlhbkBvbGRkb2cuY28udWs7DQo+IGFjdG5AaWV0Zi5vcmcNCj4gQ2M6ICdBbGlhIEF0bGFz Jw0KPiBTdWJqZWN0OiBSZTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFuZCBpbnRlcmZhY2Vz DQo+DQo+IEhpIEx1aXMsDQo+DQo+IEkgbWVhbnQNCj4NCj4gYikgVk5DIChQcm92aWRlciBYKSAt LS0gaS9mIEIuMSAtLS0tLSBWTkMgKFByb3ZpZGVyIFgpIC0tLS0gaS9mIEMgLS0tLQ0KPiBQTkMg KFByb3ZpZGVyIFgpDQo+DQo+IFNvcnJ5Lg0KPiBZb3VuZw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBBQ1ROIFttYWlsdG86YWN0bi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTGVleW91bmcNCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTQg NTo1OCBQTQ0KPiBUbzogTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE87IGFkcmlhbkBvbGRk b2cuY28udWs7IGFjdG5AaWV0Zi5vcmcNCj4gQ2M6ICdBbGlhIEF0bGFzJw0KPiBTdWJqZWN0OiBS ZTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFuZCBpbnRlcmZhY2VzDQo+DQo+IEhpIEx1aXMs DQo+DQo+IFRoaXMgY2FzZSBpcyBhIGJpdCBhZHZhbmNlZCB0b3BpYyAoYSB2YXJpYXRpb24gZnJv bSB0aGUgYmFzZQ0KPiBhcmNoaXRlY3R1cmUpIGJ1dCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0b3Bp YyB0byBncmFwcGxlIHNvb25lciB0aGFuIGxhdGVyLg0KPg0KPiBZb3VyIHNjZW5hcmlvcyBtYWtl IG1lIHRoaW5rIHdlIG1pZ2h0IG5lZWQgdG8gaGF2ZSB0d28gZGltZW5zaW9ucyBpbg0KPiB0aGUg aW50ZXJmYWNlIGRlZmluaXRpb24gZm9yIEludGVyZmFjZSBCLiBQZXJoYXBzIEIuMSBhbmQgQi4y IHdoZXJlDQo+IEIuMSBhbiBpbnRlcm5hbCBpbnRlcmZhY2UgYW5kIEIuMiBhbiBleHRlcm5hbCBp bnRlcmZhY2UuIEFuIGludGVybmFsDQo+IGludGVyZmFjZSBtZWFucyB0aGUgdHdvIGVuZCBlbnRp dGllcyBiZWxvbmcgdG8gdGhlIHNhbWUgb3BlcmF0b3Igd2hpbGUNCj4gYW4gZXh0ZXJuYWwgaW50 ZXJmYWNlIG1lYW5zIHRoZSB0d28gZW5kIGVudGl0aWVzIGJlbG9uZyB0byB0d28NCj4gZGlmZmVy ZW50IGFkbWluaXN0cmF0aXZlIG9wZXJhdG9ycy4gRm9yIFZOQy1QTkMsIHdlIG1heSBub3QgbmVl ZCB0bw0KPiBkaXN0aW5ndWlzaCBpbnRlcm5hbCBvciBleHRlcm5hbCBhcyB0aGUgYXNzdW1wdGlv biBtYWRlIHdhcyBpdCBpcyBvbmx5DQo+IGludGVybmFsIChvZiBjb3Vyc2UsIHRoaXMgYXNzdW1w dGlvbiBjYW4gYmUgcmVsYXhlZCBpbiBhIG1vcmUgZ2VuZXJhbA0KPiBjYXNlLCBidXQgZm9yIG5v dyBsZXQgdXMgc3RheSB3aXRoIHRoaXMgYXNzdW1wdGlvbiBmb3IgdGhpcyB0aHJlYWQpLg0KPg0K PiBXaXRoIHRoaXMgaW4gbWluZCwgSSB0aGluayB0aGUgYmFzZSBhcmNoaXRlY3R1cmUgaW4gRmln dXJlIDUgaW4NCj4gU2VjdGlvbiA2LjEuMSBpcyBtb3JlIG9yIGxlc3MgQ05DICAtLS0gaS9mIEIu MSAtLS0tLSBWTkMgLS0tLWkvZiBDIC0tLS0tIFBOQ3MuDQo+DQo+IE5vdGUgdGhhdCBWTkMgaXMg YXNzdW1lZCB0byBwcm92aWRlIG11bHRpLWRvbWFpbiBjb29yZGluYXRpb24gZnVuY3Rpb24NCj4g KGludGVyZmFjaW5nIG11bHRpcGxlIFBOQ3MpLg0KPg0KPiBUaGUgY2FzZSB5b3UgYnJvdWdodCB1 cCBpcyBtb3JlIG9yIGxlc3M6DQo+DQo+IGEpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjIg LS0tLS0gVk5DIChQcm92aWRlciBZKSAtLS0tIGkvZiBDIC0tLS0NCj4gUE5DIChQcm92aWRlciBZ KQ0KPiBiKSBWTkMgKFByb3ZpZGVyIFgpIC0tLSBpL2YgQi4xIC0tLS0tIFZOQyAoUHJvdmlkZXIg WCkgLS0tLSBpL2YgQyAtLS0tDQo+IFZOQyAoUHJvdmlkZXIgWCkNCj4NCj4gTm90ZTogQ05DLVZO QyBpcyBvbWl0dGVkIGFzIHRoaXMgY2FuIGJlIGVpdGhlciBCLjEgb3IgQi4yIGRlcGVuZGluZyBv bg0KPiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gQ05DIGFuZCBWTkMuDQo+DQo+IEkgd291bGQg c2F5IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBWTkNzIGFyZSBtb3JlIG9yIGxlc3MgaS9mIEIN Cj4gKHJhdGhlciB0aGFuIGkvZiBDKSBhcyB0aGV5IGFyZSBtb3JlIG9yIGxlc3Mgc2ltaWxhciB0 byBDTkMtVk5DLiBUaGF0DQo+IGlzIHRoZSByZWFzb24gZm9yIHRoZSBhYm92ZSBtYXBwaW5nIGEp IGFuZCBiKS4NCj4NCj4gVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBkaXNjdXNzaW9uLiBJIG1pZ2h0 IGhhdmUgbWlzc2VkIHlvdXIgcG9pbnRzIGFuZA0KPiBJIGFtIHN1cmUgdGhhdCB0aGVyZSBhcmUg ZGlmZmVyZW50IHBlcnNwZWN0aXZlcy4NCj4gTGV0J3Mgc2VlIGhvdyBvdGhlciBmb2xrcyBsb29r IGF0IHRoaXMgcHJvYmxlbS4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBZb3VuZw0KPg0KPg0KPg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMVUlTIE1JR1VFTCBDT05UUkVS QVMgTVVSSUxMTw0KPiBbbWFpbHRvOmx1aXNtaWd1ZWwuY29udHJlcmFzbXVyaWxsb0B0ZWxlZm9u aWNhLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTQgNDowMiBQTQ0KPiBU bzogTGVleW91bmc7IGFkcmlhbkBvbGRkb2cuY28udWs7IGFjdG5AaWV0Zi5vcmcNCj4gQ2M6ICdB bGlhIEF0bGFzJw0KPiBTdWJqZWN0OiBSRTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFuZCBp bnRlcmZhY2VzDQo+DQo+IEhpIFlvdW5nDQo+DQo+IE9uZSBxdWVzdGlvbiByYWlzZWQgdG8gbWUg d2hlbiB0aGlua2luZyBhYm91dCByZWN1cnNpdmVuZXNzIGluIHRoaXMNCj4gYXJjaGl0ZWN0dXJl LiBXaGF0IHdvdWxkIGJlIHRoZSBzY2hlbWEgaW4gY2FzZSB3aGVyZSBhIFZOQw0KPiBjb21tdW5p Y2F0ZXMgd2l0aCBhbm90aGVyIFZOQz8gVGhpcyBjb3VsZCBiZSBhbiBzY2VuYXJpbyB3aGVyZSBh DQo+IHZpcnR1YWwgbmV0d29yayBwcm92aWRlciBidWlsZHMgaXRzIG9mZmVyZWQgdHJhbnNwb3J0 IG5ldHdvcmsNCj4gY2FwYWJpbGl0aWVzIHRvdGFsIG9yIHBhcnRpYWxseSBvbiB0b3Agb2YgYW5v dGhlciB2aXJ0dWFsIG5ldHdvcmsgcHJvdmlkZXIuDQo+DQo+IFRoZXJlIGFyZSBzb21lIGFsdGVy bmF0aXZlczoNCj4NCj4gYSkgQ05DIC0tIChpL2YgQikgLS0gVk5DIC0tIHsgLS0gKGkvZiBCKSAt LSBWTkMgLS0gKGkvZiBDKSAtLSBQTkN9DQo+IGIpIENOQyAtLSAoaS9mIEIpIC0tIFZOQyAtLSB7 IC0tIChpL2YgQykgLS0gVk5DIC0tIChpL2YgQykgLS0gUE5DfQ0KPiBjKSBib3RoIG9mIHRoZW0N Cj4NCj4gUmVnYXJkcw0KPg0KPiBMdWlzDQo+DQo+DQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0t LS0tDQo+IERlOiBBQ1ROIFttYWlsdG86YWN0bi1ib3VuY2VzQGlldGYub3JnXSBFbiBub21icmUg ZGUgTGVleW91bmcgRW52aWFkbw0KPiBlbDogbHVuZXMsIDI5IGRlIHNlcHRpZW1icmUgZGUgMjAx NCAyMDowOA0KPiBQYXJhOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBhY3RuQGlldGYub3JnDQo+IEND OiAnQWxpYSBBdGxhcycNCj4gQXN1bnRvOiBSZTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFu ZCBpbnRlcmZhY2VzDQo+DQo+IEhpIEFkcmlhbiwNCj4NCj4gVGhhbmtzIGZvciB5b3VyIGJyaW5n aW5nIHVwIHRoaXMgYXJjaGl0ZWN0dXJlIGRpc2N1c3Npb24gdG8gdGhlIGxpc3QuDQo+IEkgZmVl bCBpdCBtaWdodCBiZSB1c2VmdWwgdG8gYnJpbmcgdXAgaGVyZSBGaWd1cmUgNToNCj4NCj4gICAg ICAgICAgICAgICAgIC4tLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAtLS0tLS0tLS0t LS0tICAgfA0KPiAgICAgICAgICAgICAgIHwgQXBwbGljYXRpb24gfC0tDQo+ICAgICAgICAgICAg ICAgIC0tLS0tLS0tLS0tLS0NCj4gICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAg ICAgICAgICAgICB8IEkvRiBBICAgICAgICAgICAgICAgICAtLS0tLS0tLQ0KPiAgICAgICAgICAg ICAgICAgICAgICB2ICAgICAgICAgICAgICAgICAgICAgICggICAgICAgICkNCj4gICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0gICAgICAgICAgLQ0KPiAgICAgICAg ICAgICAgICB8IEN1c3RvbWVyICAgICB8ICAgICAgICAgICAoICBDdXN0b21lciAgKQ0KPiAgICAg ICAgICAgICAgICB8ICBOZXR3b3JrICAgICB8LS0tLS0tLS0tPiggICAgTmV0d29yayAgICkNCj4g ICAgICAgICAgICAgICAgfCAgIENvbnRyb2xsZXIgfCAgICAgICAgICAgKCAgICAgICAgICAgICkN Cj4gICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0gICAgICAgICAg LQ0KPiAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICggICAgICAg ICkNCj4gICAgICAgICAgICAgICAgICAgICAgfCBJL0YgQiAgICAgICAgICAgICAgICAgLS0tLS0t LS0NCj4gICAgICAgICAgICAgICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgIF4gICAg Xg0KPiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgOiAgICA6 DQo+ICAgICAgICAgICAgICAgIHwgVmlydHVhbCAgICAgIHwgICAgICAgICAgICAgICA6ICAgICAu DQo+ICAgICAgICAgICAgICAgIHwgIE5ldHdvcmsgICAgIHwgICAgICAgICAgICAgICA6ICAgICAg Lg0KPiAgICAgICAgICAgICAgICB8ICAgQ29udHJvbGxlciB8ICAgICAgICAgICAgLS0tLS0tLS0g ICAuIEkvRiBFDQo+ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICgg ICAgICAgICkgICAuDQo+ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg LSAgICAgICAgICAtICAgLg0KPiAgICAgICAgICAgICAgICAgICAgICB8IEkvRiBDICAgICAgICAg ICAgKCAgUGh5c2ljYWwgICkgICAuDQo+ICAgICAgICAgICAgICAgICAgICAgIHYgICAgICAgICAg ICAgICAgICggICAgTmV0d29yayAgICkgICAuDQo+ICAgICAgICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tLSAgICAgICAoICAgICAgICAgICAgKSAgICAgLS0tLS0tLS0NCj4gICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgfC0tLS0tPiAtICAgICAgICAgIC0gICAgICggICAgICAgICkN Cj4gICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgfCAgICAgICAgKCAgICAgICAgKSAg ICAgLSAgICAgICAgIC0NCj4gICAgICAgICAgICAgICAgfCBQaHlzaWNhbCAgICAgfC0tICAgICAg ICAgIC0tLS0tLS0tICAgICAoICBQaHlzaWNhbCAgKQ0KPiAgICAgICAgICAgICAgICB8ICBOZXR3 b3JrICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+KCAgICBOZXR3b3JrICAgKQ0KPiAgICAg ICAgICAgICAgICB8ICAgQ29udHJvbGxlciB8ICAgICAgICAgSS9GIEQgICAgICAgICAgICggICAg ICAgICAgICApDQo+ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0gICAgICAgICAtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoICAgICAgICApDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0NCj4N Cj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1LiBBQ1ROIEludGVyZmFjZXMN Cj4NCj4gQXMgeW91IHBvaW50ZWQgb3V0LCB0aGUgcXVvdGVkIGNoYXJ0ZXIgYW5kIFNlY3Rpb24g Ni4xLjEgb2YgdGhlDQo+IGZyYW1ld29yayBkcmFmdCBhcmUgY29uc2lzdGVudCBpbiB0aGF0IGJv dGggb2YgdGhlbSBsaW1pdCB0aGUgc2NvcGUgb2YNCj4gQUNUTiB3b3JrIHRvIEkvRiBCIGFuZCBJ L0YgQyAoRmlndXJlIDUpIHRoYXQgY29ycmVzcG9uZCB0byB0aGUgQ05DLVZOQw0KPiBhbmQgVk5D LVBOQyBpbnRlcmZhY2UsIHJlc3BlY3RpdmVseS4gT3RoZXIgaW50ZXJmYWNlcyBhcmUgb3V0IG9m DQo+IHNjb3BlLiBUaGV5IGFyZSBzaG93biBmb3IgYW4gaWxsdXN0cmF0aW9uIHB1cnBvc2UgdG8g Z2l2ZSB0aGUgb3ZlcmFyY2hpbmcgY29udGV4dCBvZiBBQ1ROLg0KPg0KPiBCZXN0IHJlZ2FyZHMs DQo+IFlvdW5nDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFDVE4g W21haWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVs DQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI5LCAyMDE0IDEyOjUzIFBNDQo+IFRvOiBhY3Ru QGlldGYub3JnDQo+IENjOiAnQWxpYSBBdGxhcycNCj4gU3ViamVjdDogW0FjdG5dIEFDVE4gYXJj aGl0ZWN0dXJlIGFuZCBpbnRlcmZhY2VzDQo+DQo+IEhpLA0KPg0KPiBUaGFua3MgZm9yIHRoZSBs YXRlc3QgcmV2aXNpb24gb2YNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1jZWNjYXJl bGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dA0KPiBJIGZpbmQgdGhlIG5ldyBGaWd1cmUgNSBwYXJ0 aWN1bGFybHkgaGVscGZ1bCBpbiB1bmRlcnN0YW5kaW5nIHRoZQ0KPiBwb3RlbnRpYWwgc2NvcGUg b2YgdGhlIEFDVE4gd29yay4gQW5kIHRoaXMgaXMgaW1wb3J0YW50IGJlY2F1c2UgYXQNCj4gdGhp cyBzdGFnZSBpZiB0aGUgcHJvY2VzcyB3ZSBhcmUgdHJ5aW5nIHRvIHdvcmsgb3V0IGV4YWN0bHkg d2hhdCBhbg0KPiBBQ1ROIHdvcmtpbmcgZ3JvdXAgbWlnaHQgd29yayBvbiBpZiBpdCB3YXMgY3Jl YXRlZC4NCj4NCj4gTG9va2luZyBhdCB0aGUgdjEuMyBkcmFmdCBjaGFydGVyIHRleHQgYXQNCj4g aHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvYWN0bmJvZi9ob21lL2NoYXJ0ZXItcHJvcG9z YWwgSSBzZWUuLi4NCj4gPiBUaGlzIGFyY2hpdGVjdHVyZSBzaG93cyB0aHJlZQ0KPiA+IGNvbnRy b2wgY29tcG9uZW50czogdGhlIEN1c3RvbWVyIE5ldHdvcmsgQ29udHJvbGxlciAoQ05DKQ0KPiA+ IHJlc3BvbnNpYmxlIGZvciBzZXJ2aWNpbmcgcmVxdWVzdHMgZnJvbSBhcHBsaWNhdGlvbnMgKHN1 Y2ggYXMNCj4gPiBPU1MvTk1TKSwgdGhlIFZpcnR1YWwgTmV0d29yayBDb250cm9sbGVyIChWTkMp IHJlc3BvbnNpYmxlIGZvcg0KPiA+IHJlYWxpemluZyBjdXN0b21lciBuZXR3b3JrcyBvdXQgb2Yg cGh5c2ljYWwgbmV0d29yayByZXNvdXJjZXMsIGFuZA0KPiA+IHRoZSBQaHlzaWNhbCBOZXR3b3Jr IENvbnRyb2xsZXIgKFBOQykgcmVzcG9uc2libGUgZm9yIGNvbnRyb2wgYW5kDQo+ID4gcHJvdmlz aW9uaW5nIGluIHBoeXNpY2FsIG5ldHdvcmtzLiBUaGUgYXJjaGl0ZWN0dXJlIHNob3dzIHRoZSBu ZWVkDQo+ID4gZm9yIGludGVyZmFjZXMgYmV0d2VlbiB0aGVzZQ0KPiBjb21wb25lbnRzLg0KPg0K PiBJIGp1c3Qgd2FudCB0byBjaGVjayB3aGF0IHRoaXMgbWVhbnMuIEkgcmVhZCBpdCBhcyBzYXlp bmcgdGhhdA0KPiBpbnRlcmZhY2VzIEIgYW5kIEMgYXMgc2hvd24gb24gRmlndXJlIDUgYXJlIGlu IHNjb3BlIGZvciBhbiBBQ1RODQo+IHdvcmtpbmcgZ3JvdXAsIGJ1dCBhbGwgb3RoZXIgaW50ZXJm YWNlcyBzaG93biBvbiB0aGUgZmlndXJlIGFyZSBub3QgaW4NCj4gc2NvcGUuIEkgYmVsaWV2ZSB0 aGlzIGlzIGNvbnNpc3RlbnQgd2l0aCBTZWN0aW9uIDYuMS4xIG9mIHRoZSBkcmFmdC4NCj4NCj4g Q2FuIHknYWxsIGNvbmZpcm0gdGhhdCB0aGlzIGlzIHlvdXIgdW5kZXJzdGFuZGluZyBhbmQgd2hh dCB5b3Ugd2FudCB0bw0KPiB3b3JrIG9uIGFuZCBleGNsdWRlLg0KPg0KPiBUaGFua3MsDQo+IEFk cmlhbg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBBQ1ROIG1haWxpbmcgbGlzdA0KPiBBQ1ROQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWN0bg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBQ1ROIG1haWxpbmcgbGlzdA0KPiBBQ1ROQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWN0bg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBFc3RlIG1lbnNhamUgeSBz dXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1DQo+IGRlc3RpbmF0YXJp bywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lh bCB5DQo+IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBk ZXN0aW5vLiBTaSBubyBlcw0KPiB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVk YSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLA0KPiB1dGlsaXphY2nDs24sIGRpdnVsZ2Fj acOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXINCj4gcHJvaGliaWRh IGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0 ZQ0KPiBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBp bm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNj acOzbi4NCj4NCj4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lv biBpcyBwcml2aWxlZ2VkIGFuZA0KPiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQg b25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbA0KPiBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUNCj4gaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9u LA0KPiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Np b24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0Lg0KPiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkg dG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQo+DQo+IEVzdGEgbWVuc2FnZW0gZSBzZXVzIGFu ZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldQ0KPiBkZXN0aW5hdMOhcmlvLCBw b2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOp DQo+IHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4g U2UgbsOjbyDDqSB2b3NzYQ0KPiBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZp Y2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLA0KPiB1dGlsaXphw6fDo28sIGRpdnVsZ2HD p8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhDQo+ IGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5z YWdlbSBwb3IgZXJybywNCj4gcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0 YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlDQo+IHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6Nv DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFD VE4gbWFpbGluZyBsaXN0DQo+IEFDVE5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hY3RuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEFDVE4gbWFpbGluZyBsaXN0DQo+IEFDVE5AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY3RuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBk aXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBp bmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhj bHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVk LiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxl Y3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFj acOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2 aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9z IHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEg eSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlv biBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9u IGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5l eG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUg Y29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFy YSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6Nv IMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmlj YWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8Oz cGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBs ZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCBy b2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVz bWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== From nobody Wed Oct 1 10:24:11 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 AEBF61A1A72 for ; Wed, 1 Oct 2014 10:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 df8iaNHaqL1W for ; Wed, 1 Oct 2014 10:11:37 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CB91A1A79 for ; Wed, 1 Oct 2014 10:11:36 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5CCF33A02B0; Wed, 1 Oct 2014 19:11:34 +0200 (CEST) Received: from ESTGVMSP102.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 3EEA83A021E; Wed, 1 Oct 2014 19:11:34 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 19:11:33 +0200 Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB575.eurprd06.prod.outlook.com (10.242.192.156) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 17:11:31 +0000 Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 17:11:31 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: Leeyoung , Daniele Ceccarelli , "adrian@olddog.co.uk" , "actn@ietf.org" Thread-Topic: [Actn] ACTN architecture and interfaces Thread-Index: Ac/cDiPXMQFQG+jkRVKDqJnlOJCGwQAAHQEAAAY44bAAAgn18AACmsogAE/OlsAAB9bZcAAAdFvw Date: Wed, 1 Oct 2014 17:11:30 +0000 Message-ID: <0749871d2e8d43bcb3db40c6c0efe174@DB4PR06MB576.eurprd06.prod.outlook.com> References: <03bc01cfdc0e$2c346d80$849d4880$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C3ABB3@dfweml706-chm> <67fc7b199bea4c9f836686a244c6a920@DB4PR06MB576.eurprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE27@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C3AE44@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481279525E@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3B42A@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3B42A@dfweml706-chm> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [195.235.92.27] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB575; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(164054003)(13464003)(51914003)(377454003)(2501002)(93886004)(95666004)(31966008)(76576001)(105586002)(108616004)(76176999)(92566001)(19580405001)(85306004)(33646002)(85852003)(21056001)(4396001)(561944003)(107046002)(97736003)(86362001)(87936001)(20776003)(76482002)(15202345003)(15975445006)(50986999)(99396003)(80022003)(54356999)(120916001)(101416001)(46102003)(19580395003)(66066001)(106356001)(2656002)(74316001)(64706001)(2201001)(10300001)(16351025005)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB575; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/actn/j2dbyiw3gD05-CA_iKyfBM1_XHY X-Mailman-Approved-At: Wed, 01 Oct 2014 10:24:03 -0700 Cc: 'Alia Atlas' Subject: Re: [Actn] ACTN architecture and interfaces 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, 01 Oct 2014 17:11:40 -0000 SGkgWW91bmcsIGdvb2QgcG9pbnQgdGhlIHJlZmVyZW5jZSB0byBnbG9iYWwgbmV0d29ya3MuIEhv d2V2ZXIgYXQgdGhlIGVuZCB0aGVzZSBnbG9iYWwgbmV0d29ya3MgYXJlIHN0cnVjdHVyZWQgYXMg c2VwYXJhdGVkIGRvbWFpbnMsIHNvIHdlIGNvdWxkIGFzc3VtZSB0aGVtIGFzIGFjdHVhbGx5IHNl cGFyYXRlZCBuZXR3b3Jrcy4gQW55d2F5IGxldCBtZSB0aGluayBhIGxpdHRsZSBiaXQgbW9yZSBv biB0aGF0LCBqdXN0IHRvIHJlYWxpemUgaWYgdGhlcmUgY291bGQgYmUgYSByZWFsIHVzZSBjYXNl IHN1c3RhaW5pbmcgaXQuDQoNClJlZ2FyZHMNCg0KTHVpcw0KDQotLS0tLU1lbnNhamUgb3JpZ2lu YWwtLS0tLQ0KRGU6IExlZXlvdW5nIFttYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0NCkVudmlh ZG8gZWw6IG1pw6lyY29sZXMsIDAxIGRlIG9jdHVicmUgZGUgMjAxNCAxOTowOA0KUGFyYTogRGFu aWVsZSBDZWNjYXJlbGxpOyBMVUlTIE1JR1VFTCBDT05UUkVSQVMgTVVSSUxMTzsgYWRyaWFuQG9s ZGRvZy5jby51azsgYWN0bkBpZXRmLm9yZw0KQ0M6ICdBbGlhIEF0bGFzJw0KQXN1bnRvOiBSRTog W0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFuZCBpbnRlcmZhY2VzDQoNCkhpIERhbmllbGUsDQoN CkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBWTkMtVk5DIGZvciB0aGUgc2FtZSBwcm92aWRlciBpcyBh IGNvcm5lciBjYXNlIHdoZXJlIENhc2UgYSkgY2FuIGNvdmVyIHdlbGwgd2l0aCB0cnVzdC9zZWN1 cml0eSBjb25zdHJhaW50IGFzcGVjdCBiZWluZyByZWxheGVkLiBCdXQgSSB3YW50ZWQgTHVpcyB0 byBjb21tZW50IG9uIHRoYXQ7IGhlIG1heSBiZSBhd2FyZSBvZiB0aGUgY2FzZSBsaWtlIHRoYXQg YXMgVGVsZWZvbmljYSBpcyBkZWFsaW5nIHdpdGggZ2xvYmFsIG5ldHdvcmtzIHdoZXJlIEkgY2Fu IHNlZSBhIHBvdGVudGlhbCBmb3IgdGhhdCBjYXNlLg0KDQpUaGFua3MsDQpZb3VuZw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86 ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2Jl ciAwMSwgMjAxNCA4OjIyIEFNDQpUbzogTGVleW91bmc7IExVSVMgTUlHVUVMIENPTlRSRVJBUyBN VVJJTExPOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBhY3RuQGlldGYub3JnDQpDYzogJ0FsaWEgQXRs YXMnDQpTdWJqZWN0OiBSRTogW0FjdG5dIEFDVE4gYXJjaGl0ZWN0dXJlIGFuZCBpbnRlcmZhY2Vz DQoNCkhpIFlvdW5nLCBMdWlzLA0KDQpJbnRlcmVzdGluZyB0b3BpYy4gSSBjb25jdXIgd2l0aCBZ b3VuZyB3aGVuIHNheWluZyB0aGF0IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBhIFZOQ3MgaW4gYSBy ZWN1cnNpdmUgYXJjaGl0ZWN0dXJlIGlzIG9mICJ0eXBlIiBCLg0KUmVnYXJkaW5nIHRoZSB0d28g ZGlmZmVyZW50IG9wdGlvbnMgYmVsb3c6DQoNCj4gYSkgVk5DIChQcm92aWRlciBYKSAtLS0gaS9m IEIuMiAtLS0tLSBWTkMgKFByb3ZpZGVyIFkpIC0tLS0gaS9mIEMgLS0tLQ0KPiBQTkMgKFByb3Zp ZGVyIFkpDQo+IGIpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjEgLS0tLS0gVk5DIChQcm92 aWRlciBYKSAtLS0tIGkvZiBDIC0tLS0NCj4gUE5DIChQcm92aWRlciBYKQ0KDQpJIHNlZSB0aGUg cmVjdXJzaXZlbmVzcyBvZiBWTkNzIHdpdGhpbiB0aGUgc2FtZSBwcm92aWRlciAoIGIpIGFzIGFu IGV4dHJlbWVseSB1bmNvbW1vbiBjb3JuZXIgY2FzZXMsIHdoaWNoLCBpZiBuZWVkZWQsIG1pZ2h0 IGJlIGFkZHJlc3NlZCBhcyBhIHBhcnRpY3VsYXIgY2FzZSBvZiBhKS4NCklzIHRoZXJlIGEgcmVh c29uIGZvciBhIHByb3ZpZGVyIHRvIGhhdmUgYSByZWN1cnNpdmVuZXNzIG9mIFZOQ3M/IElmIHRo ZSBnb2FsIGlzIHRvIGVuaGFuY2Ugc2NhbGFiaWxpdHkgSSB3b3VsZCBzYXkgdGhhdCBpdCBpcyBh IG1hdHRlciBpbmNyZWFzaW5nIHRoZSBudW1iZXIgb2YgUE5DIHVuZGVyIHRoZSBjb250cm9sIG9m IHRoZSBzYW1lIFZOQyBidXQgSSB0aGluayBjYXNlIGEpIGlzIGVub3VnaC4NCg0KQlINCkRhbmll bGUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBQ1ROIFttYWlsdG86 YWN0bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVleW91bmcNCj4gU2VudDogbWFy dGVkw6wgMzAgc2V0dGVtYnJlIDIwMTQgMDE6MDgNCj4gVG86IExlZXlvdW5nOyBMVUlTIE1JR1VF TCBDT05UUkVSQVMgTVVSSUxMTzsgYWRyaWFuQG9sZGRvZy5jby51azsNCj4gYWN0bkBpZXRmLm9y Zw0KPiBDYzogJ0FsaWEgQXRsYXMnDQo+IFN1YmplY3Q6IFJlOiBbQWN0bl0gQUNUTiBhcmNoaXRl Y3R1cmUgYW5kIGludGVyZmFjZXMNCj4NCj4gSGkgTHVpcywNCj4NCj4gSSBtZWFudA0KPg0KPiBi KSBWTkMgKFByb3ZpZGVyIFgpIC0tLSBpL2YgQi4xIC0tLS0tIFZOQyAoUHJvdmlkZXIgWCkgLS0t LSBpL2YgQyAtLS0tDQo+IFBOQyAoUHJvdmlkZXIgWCkNCj4NCj4gU29ycnkuDQo+IFlvdW5nDQo+ DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFDVE4gW21haWx0bzphY3Ru LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWV5b3VuZw0KPiBTZW50OiBNb25kYXks IFNlcHRlbWJlciAyOSwgMjAxNCA1OjU4IFBNDQo+IFRvOiBMVUlTIE1JR1VFTCBDT05UUkVSQVMg TVVSSUxMTzsgYWRyaWFuQG9sZGRvZy5jby51azsgYWN0bkBpZXRmLm9yZw0KPiBDYzogJ0FsaWEg QXRsYXMnDQo+IFN1YmplY3Q6IFJlOiBbQWN0bl0gQUNUTiBhcmNoaXRlY3R1cmUgYW5kIGludGVy ZmFjZXMNCj4NCj4gSGkgTHVpcywNCj4NCj4gVGhpcyBjYXNlIGlzIGEgYml0IGFkdmFuY2VkIHRv cGljIChhIHZhcmlhdGlvbiBmcm9tIHRoZSBiYXNlDQo+IGFyY2hpdGVjdHVyZSkgYnV0IEkgdGhp bmsgaXQgaXMgYSBnb29kIHRvcGljIHRvIGdyYXBwbGUgc29vbmVyIHRoYW4gbGF0ZXIuDQo+DQo+ IFlvdXIgc2NlbmFyaW9zIG1ha2UgbWUgdGhpbmsgd2UgbWlnaHQgbmVlZCB0byBoYXZlIHR3byBk aW1lbnNpb25zIGluDQo+IHRoZSBpbnRlcmZhY2UgZGVmaW5pdGlvbiBmb3IgSW50ZXJmYWNlIEIu IFBlcmhhcHMgQi4xIGFuZCBCLjIgd2hlcmUNCj4gQi4xIGFuIGludGVybmFsIGludGVyZmFjZSBh bmQgQi4yIGFuIGV4dGVybmFsIGludGVyZmFjZS4gQW4gaW50ZXJuYWwNCj4gaW50ZXJmYWNlIG1l YW5zIHRoZSB0d28gZW5kIGVudGl0aWVzIGJlbG9uZyB0byB0aGUgc2FtZSBvcGVyYXRvciB3aGls ZQ0KPiBhbiBleHRlcm5hbCBpbnRlcmZhY2UgbWVhbnMgdGhlIHR3byBlbmQgZW50aXRpZXMgYmVs b25nIHRvIHR3bw0KPiBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgb3BlcmF0b3JzLiBGb3IgVk5D LVBOQywgd2UgbWF5IG5vdCBuZWVkIHRvDQo+IGRpc3Rpbmd1aXNoIGludGVybmFsIG9yIGV4dGVy bmFsIGFzIHRoZSBhc3N1bXB0aW9uIG1hZGUgd2FzIGl0IGlzIG9ubHkNCj4gaW50ZXJuYWwgKG9m IGNvdXJzZSwgdGhpcyBhc3N1bXB0aW9uIGNhbiBiZSByZWxheGVkIGluIGEgbW9yZSBnZW5lcmFs DQo+IGNhc2UsIGJ1dCBmb3Igbm93IGxldCB1cyBzdGF5IHdpdGggdGhpcyBhc3N1bXB0aW9uIGZv ciB0aGlzIHRocmVhZCkuDQo+DQo+IFdpdGggdGhpcyBpbiBtaW5kLCBJIHRoaW5rIHRoZSBiYXNl IGFyY2hpdGVjdHVyZSBpbiBGaWd1cmUgNSBpbg0KPiBTZWN0aW9uIDYuMS4xIGlzIG1vcmUgb3Ig bGVzcyBDTkMgIC0tLSBpL2YgQi4xIC0tLS0tIFZOQyAtLS0taS9mIEMgLS0tLS0gUE5Dcy4NCj4N Cj4gTm90ZSB0aGF0IFZOQyBpcyBhc3N1bWVkIHRvIHByb3ZpZGUgbXVsdGktZG9tYWluIGNvb3Jk aW5hdGlvbiBmdW5jdGlvbg0KPiAoaW50ZXJmYWNpbmcgbXVsdGlwbGUgUE5DcykuDQo+DQo+IFRo ZSBjYXNlIHlvdSBicm91Z2h0IHVwIGlzIG1vcmUgb3IgbGVzczoNCj4NCj4gYSkgVk5DIChQcm92 aWRlciBYKSAtLS0gaS9mIEIuMiAtLS0tLSBWTkMgKFByb3ZpZGVyIFkpIC0tLS0gaS9mIEMgLS0t LQ0KPiBQTkMgKFByb3ZpZGVyIFkpDQo+IGIpIFZOQyAoUHJvdmlkZXIgWCkgLS0tIGkvZiBCLjEg LS0tLS0gVk5DIChQcm92aWRlciBYKSAtLS0tIGkvZiBDIC0tLS0NCj4gVk5DIChQcm92aWRlciBY KQ0KPg0KPiBOb3RlOiBDTkMtVk5DIGlzIG9taXR0ZWQgYXMgdGhpcyBjYW4gYmUgZWl0aGVyIEIu MSBvciBCLjIgZGVwZW5kaW5nIG9uDQo+IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBDTkMgYW5k IFZOQy4NCj4NCj4gSSB3b3VsZCBzYXkgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFZOQ3MgYXJl IG1vcmUgb3IgbGVzcyBpL2YgQg0KPiAocmF0aGVyIHRoYW4gaS9mIEMpIGFzIHRoZXkgYXJlIG1v cmUgb3IgbGVzcyBzaW1pbGFyIHRvIENOQy1WTkMuIFRoYXQNCj4gaXMgdGhlIHJlYXNvbiBmb3Ig dGhlIGFib3ZlIG1hcHBpbmcgYSkgYW5kIGIpLg0KPg0KPiBUaGlzIGlzIGFuIGludGVyZXN0aW5n IGRpc2N1c3Npb24uIEkgbWlnaHQgaGF2ZSBtaXNzZWQgeW91ciBwb2ludHMgYW5kDQo+IEkgYW0g c3VyZSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLg0KPiBMZXQncyBzZWUg aG93IG90aGVyIGZvbGtzIGxvb2sgYXQgdGhpcyBwcm9ibGVtLg0KPg0KPiBCZXN0IHJlZ2FyZHMs DQo+IFlvdW5nDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IExVSVMgTUlHVUVMIENPTlRSRVJBUyBNVVJJTExPDQo+IFttYWlsdG86bHVpc21pZ3VlbC5jb250 cmVyYXNtdXJpbGxvQHRlbGVmb25pY2EuY29tXQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAy OSwgMjAxNCA0OjAyIFBNDQo+IFRvOiBMZWV5b3VuZzsgYWRyaWFuQG9sZGRvZy5jby51azsgYWN0 bkBpZXRmLm9yZw0KPiBDYzogJ0FsaWEgQXRsYXMnDQo+IFN1YmplY3Q6IFJFOiBbQWN0bl0gQUNU TiBhcmNoaXRlY3R1cmUgYW5kIGludGVyZmFjZXMNCj4NCj4gSGkgWW91bmcNCj4NCj4gT25lIHF1 ZXN0aW9uIHJhaXNlZCB0byBtZSB3aGVuIHRoaW5raW5nIGFib3V0IHJlY3Vyc2l2ZW5lc3MgaW4g dGhpcw0KPiBhcmNoaXRlY3R1cmUuIFdoYXQgd291bGQgYmUgdGhlIHNjaGVtYSBpbiBjYXNlIHdo ZXJlIGEgVk5DDQo+IGNvbW11bmljYXRlcyB3aXRoIGFub3RoZXIgVk5DPyBUaGlzIGNvdWxkIGJl IGFuIHNjZW5hcmlvIHdoZXJlIGENCj4gdmlydHVhbCBuZXR3b3JrIHByb3ZpZGVyIGJ1aWxkcyBp dHMgb2ZmZXJlZCB0cmFuc3BvcnQgbmV0d29yaw0KPiBjYXBhYmlsaXRpZXMgdG90YWwgb3IgcGFy dGlhbGx5IG9uIHRvcCBvZiBhbm90aGVyIHZpcnR1YWwgbmV0d29yayBwcm92aWRlci4NCj4NCj4g VGhlcmUgYXJlIHNvbWUgYWx0ZXJuYXRpdmVzOg0KPg0KPiBhKSBDTkMgLS0gKGkvZiBCKSAtLSBW TkMgLS0geyAtLSAoaS9mIEIpIC0tIFZOQyAtLSAoaS9mIEMpIC0tIFBOQ30NCj4gYikgQ05DIC0t IChpL2YgQikgLS0gVk5DIC0tIHsgLS0gKGkvZiBDKSAtLSBWTkMgLS0gKGkvZiBDKSAtLSBQTkN9 DQo+IGMpIGJvdGggb2YgdGhlbQ0KPg0KPiBSZWdhcmRzDQo+DQo+IEx1aXMNCj4NCj4NCj4gLS0t LS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNA aWV0Zi5vcmddIEVuIG5vbWJyZSBkZSBMZWV5b3VuZyBFbnZpYWRvDQo+IGVsOiBsdW5lcywgMjkg ZGUgc2VwdGllbWJyZSBkZSAyMDE0IDIwOjA4DQo+IFBhcmE6IGFkcmlhbkBvbGRkb2cuY28udWs7 IGFjdG5AaWV0Zi5vcmcNCj4gQ0M6ICdBbGlhIEF0bGFzJw0KPiBBc3VudG86IFJlOiBbQWN0bl0g QUNUTiBhcmNoaXRlY3R1cmUgYW5kIGludGVyZmFjZXMNCj4NCj4gSGkgQWRyaWFuLA0KPg0KPiBU aGFua3MgZm9yIHlvdXIgYnJpbmdpbmcgdXAgdGhpcyBhcmNoaXRlY3R1cmUgZGlzY3Vzc2lvbiB0 byB0aGUgbGlzdC4NCj4gSSBmZWVsIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBicmluZyB1cCBoZXJl IEZpZ3VyZSA1Og0KPg0KPiAgICAgICAgICAgICAgICAgLi0tLS0tLS0tLS0tLS0tDQo+ICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0gICB8DQo+ICAgICAgICAgICAgICAgfCBBcHBsaWNhdGlv biB8LS0NCj4gICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAg ICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgIHwgSS9GIEEgICAgICAgICAgICAgICAgIC0t LS0tLS0tDQo+ICAgICAgICAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICAgICAgKCAg ICAgICAgKQ0KPiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgLSAg ICAgICAgICAtDQo+ICAgICAgICAgICAgICAgIHwgQ3VzdG9tZXIgICAgIHwgICAgICAgICAgICgg IEN1c3RvbWVyICApDQo+ICAgICAgICAgICAgICAgIHwgIE5ldHdvcmsgICAgIHwtLS0tLS0tLS0+ KCAgICBOZXR3b3JrICAgKQ0KPiAgICAgICAgICAgICAgICB8ICAgQ29udHJvbGxlciB8ICAgICAg ICAgICAoICAgICAgICAgICAgKQ0KPiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAg ICAgICAgICAgLSAgICAgICAgICAtDQo+ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgKCAgICAgICAgKQ0KPiAgICAgICAgICAgICAgICAgICAgICB8IEkvRiBCICAg ICAgICAgICAgICAgICAtLS0tLS0tLQ0KPiAgICAgICAgICAgICAgICAgICAgICB2ICAgICAgICAg ICAgICAgICAgICAgICAgXiAgICBeDQo+ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAg ICAgICAgICAgICAgICA6ICAgIDoNCj4gICAgICAgICAgICAgICAgfCBWaXJ0dWFsICAgICAgfCAg ICAgICAgICAgICAgIDogICAgIC4NCj4gICAgICAgICAgICAgICAgfCAgTmV0d29yayAgICAgfCAg ICAgICAgICAgICAgIDogICAgICAuDQo+ICAgICAgICAgICAgICAgIHwgICBDb250cm9sbGVyIHwg ICAgICAgICAgICAtLS0tLS0tLSAgIC4gSS9GIEUNCj4gICAgICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tICAgICAgICAgICAgKCAgICAgICAgKSAgIC4NCj4gICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAtICAgICAgICAgIC0gICAuDQo+ICAgICAgICAgICAgICAgICAg ICAgIHwgSS9GIEMgICAgICAgICAgICAoICBQaHlzaWNhbCAgKSAgIC4NCj4gICAgICAgICAgICAg ICAgICAgICAgdiAgICAgICAgICAgICAgICAgKCAgICBOZXR3b3JrICAgKSAgIC4NCj4gICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tICAgICAgICggICAgICAgICAgICApICAgICAtLS0t LS0tLQ0KPiAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8LS0tLS0+IC0gICAgICAg ICAgLSAgICAgKCAgICAgICAgKQ0KPiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICB8 ICAgICAgICAoICAgICAgICApICAgICAtICAgICAgICAgLQ0KPiAgICAgICAgICAgICAgICB8IFBo eXNpY2FsICAgICB8LS0gICAgICAgICAgLS0tLS0tLS0gICAgICggIFBoeXNpY2FsICApDQo+ICAg ICAgICAgICAgICAgIHwgIE5ldHdvcmsgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4oICAg IE5ldHdvcmsgICApDQo+ICAgICAgICAgICAgICAgIHwgICBDb250cm9sbGVyIHwgICAgICAgICBJ L0YgRCAgICAgICAgICAgKCAgICAgICAgICAgICkNCj4gICAgICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAgLSAgICAgICAgIC0NCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICggICAgICAg ICkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLS0tLS0tLQ0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDUuIEFDVE4gSW50ZXJmYWNlcw0KPg0KPiBBcyB5b3UgcG9pbnRlZCBvdXQsIHRoZSBxdW90ZWQg Y2hhcnRlciBhbmQgU2VjdGlvbiA2LjEuMSBvZiB0aGUNCj4gZnJhbWV3b3JrIGRyYWZ0IGFyZSBj b25zaXN0ZW50IGluIHRoYXQgYm90aCBvZiB0aGVtIGxpbWl0IHRoZSBzY29wZSBvZg0KPiBBQ1RO IHdvcmsgdG8gSS9GIEIgYW5kIEkvRiBDIChGaWd1cmUgNSkgdGhhdCBjb3JyZXNwb25kIHRvIHRo ZSBDTkMtVk5DDQo+IGFuZCBWTkMtUE5DIGludGVyZmFjZSwgcmVzcGVjdGl2ZWx5LiBPdGhlciBp bnRlcmZhY2VzIGFyZSBvdXQgb2YNCj4gc2NvcGUuIFRoZXkgYXJlIHNob3duIGZvciBhbiBpbGx1 c3RyYXRpb24gcHVycG9zZSB0byBnaXZlIHRoZSBvdmVyYXJjaGluZyBjb250ZXh0IG9mIEFDVE4u DQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWW91bmcNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTQg MTI6NTMgUE0NCj4gVG86IGFjdG5AaWV0Zi5vcmcNCj4gQ2M6ICdBbGlhIEF0bGFzJw0KPiBTdWJq ZWN0OiBbQWN0bl0gQUNUTiBhcmNoaXRlY3R1cmUgYW5kIGludGVyZmFjZXMNCj4NCj4gSGksDQo+ DQo+IFRoYW5rcyBmb3IgdGhlIGxhdGVzdCByZXZpc2lvbiBvZg0KPiBodHRwOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0DQo+IEkgZmluZCB0 aGUgbmV3IEZpZ3VyZSA1IHBhcnRpY3VsYXJseSBoZWxwZnVsIGluIHVuZGVyc3RhbmRpbmcgdGhl DQo+IHBvdGVudGlhbCBzY29wZSBvZiB0aGUgQUNUTiB3b3JrLiBBbmQgdGhpcyBpcyBpbXBvcnRh bnQgYmVjYXVzZSBhdA0KPiB0aGlzIHN0YWdlIGlmIHRoZSBwcm9jZXNzIHdlIGFyZSB0cnlpbmcg dG8gd29yayBvdXQgZXhhY3RseSB3aGF0IGFuDQo+IEFDVE4gd29ya2luZyBncm91cCBtaWdodCB3 b3JrIG9uIGlmIGl0IHdhcyBjcmVhdGVkLg0KPg0KPiBMb29raW5nIGF0IHRoZSB2MS4zIGRyYWZ0 IGNoYXJ0ZXIgdGV4dCBhdA0KPiBodHRwczovL3NpdGVzLmdvb2dsZS5jb20vc2l0ZS9hY3RuYm9m L2hvbWUvY2hhcnRlci1wcm9wb3NhbCBJIHNlZS4uLg0KPiA+IFRoaXMgYXJjaGl0ZWN0dXJlIHNo b3dzIHRocmVlDQo+ID4gY29udHJvbCBjb21wb25lbnRzOiB0aGUgQ3VzdG9tZXIgTmV0d29yayBD b250cm9sbGVyIChDTkMpDQo+ID4gcmVzcG9uc2libGUgZm9yIHNlcnZpY2luZyByZXF1ZXN0cyBm cm9tIGFwcGxpY2F0aW9ucyAoc3VjaCBhcw0KPiA+IE9TUy9OTVMpLCB0aGUgVmlydHVhbCBOZXR3 b3JrIENvbnRyb2xsZXIgKFZOQykgcmVzcG9uc2libGUgZm9yDQo+ID4gcmVhbGl6aW5nIGN1c3Rv bWVyIG5ldHdvcmtzIG91dCBvZiBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNlcywgYW5kDQo+ID4g dGhlIFBoeXNpY2FsIE5ldHdvcmsgQ29udHJvbGxlciAoUE5DKSByZXNwb25zaWJsZSBmb3IgY29u dHJvbCBhbmQNCj4gPiBwcm92aXNpb25pbmcgaW4gcGh5c2ljYWwgbmV0d29ya3MuIFRoZSBhcmNo aXRlY3R1cmUgc2hvd3MgdGhlIG5lZWQNCj4gPiBmb3IgaW50ZXJmYWNlcyBiZXR3ZWVuIHRoZXNl DQo+IGNvbXBvbmVudHMuDQo+DQo+IEkganVzdCB3YW50IHRvIGNoZWNrIHdoYXQgdGhpcyBtZWFu cy4gSSByZWFkIGl0IGFzIHNheWluZyB0aGF0DQo+IGludGVyZmFjZXMgQiBhbmQgQyBhcyBzaG93 biBvbiBGaWd1cmUgNSBhcmUgaW4gc2NvcGUgZm9yIGFuIEFDVE4NCj4gd29ya2luZyBncm91cCwg YnV0IGFsbCBvdGhlciBpbnRlcmZhY2VzIHNob3duIG9uIHRoZSBmaWd1cmUgYXJlIG5vdCBpbg0K PiBzY29wZS4gSSBiZWxpZXZlIHRoaXMgaXMgY29uc2lzdGVudCB3aXRoIFNlY3Rpb24gNi4xLjEg b2YgdGhlIGRyYWZ0Lg0KPg0KPiBDYW4geSdhbGwgY29uZmlybSB0aGF0IHRoaXMgaXMgeW91ciB1 bmRlcnN0YW5kaW5nIGFuZCB3aGF0IHlvdSB3YW50IHRvDQo+IHdvcmsgb24gYW5kIGV4Y2x1ZGUu DQo+DQo+IFRoYW5rcywNCj4gQWRyaWFuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEFDVE4gbWFpbGluZyBsaXN0DQo+IEFDVE5AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY3RuDQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFDVE4gbWFp bGluZyBsaXN0DQo+IEFDVE5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY3RuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ DQo+IEVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRl IGEgc3UNCj4gZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmls ZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkNCj4gZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBl cnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzDQo+IHVzdGVkLiBlbCBkZXN0aW5h dGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsDQo+IHV0 aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVk ZSBlc3Rhcg0KPiBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRl LiBTaSBoYSByZWNpYmlkbyBlc3RlDQo+IG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1 ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBw cm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KPg0KPiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kDQo+IGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsDQo+ IG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMg bm90IHRoZQ0KPiBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sDQo+IGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLg0KPiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuDQo+IFBsZWFz ZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCj4NCj4gRXN0 YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1 DQo+IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEg b3UgY29uZmlkZW5jaWFsIGUgw6kNCj4gcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBl bnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhDQo+IHNlbmhvcmlhIG8gZGVzdGlu YXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsDQo+IHV0 aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBv ZGUgZXN0YXIgcHJvaWJpZGENCj4gZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4g U2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLA0KPiByb2dhbW9zLWxoZSBxdWUgbm9z IG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUNCj4gcHJvY2Vk YSBhIHN1YSBkZXN0cnVpw6fDo28NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gQUNUTiBtYWlsaW5nIGxpc3QNCj4gQUNUTkBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjdG4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQUNUTiBtYWlsaW5nIGxpc3QN Cj4gQUNUTkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FjdG4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWpl IHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFy aW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNp YWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVz dGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90 aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9v IGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQg ZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBw b3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUg cG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRo aXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcg b2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxl YXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3Rh IG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUg ZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBj b25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRl IGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGlu ZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBk aXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9p YmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEg bWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlh dGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K From nobody Wed Oct 1 14:30:41 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 61AC51A87A0 for ; Wed, 1 Oct 2014 14:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 BPjYOVYRndNd for ; Wed, 1 Oct 2014 14:30:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18C31A8785 for ; Wed, 1 Oct 2014 14:30:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s91LUZcu004526 for ; Wed, 1 Oct 2014 22:30:35 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s91LUYq6004511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Oct 2014 22:30:35 +0100 From: "Adrian Farrel" To: Date: Wed, 1 Oct 2014 22:30:30 +0100 Message-ID: <05a601cfddbe$ed404290$c7c0c7b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/dvoWVlq06fmtAQTm+5s7d1ArLlw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20990.002 X-TM-AS-Result: No--8.650-10.0-31-10 X-imss-scan-details: No--8.650-10.0-31-10 X-TMASE-MatchedRID: wLt3kJ89u3SzfJHjQEw6opgGnz93PV93fKhbGg458tYBFRtyGdlCPYAK +rz+ag5s4FD3otNxTUMT5cyA1VC63SddkOzhns20W7gz/Gbgpl6imsR6hkcJArVO55U6WlFG079 j1EwNbJSt0M0aWIRkrC9r+L3LjrGVAM0/G7XUdeO8coKUcaOOvcyZqgcnwGktcVdapPIqr6jaCW ywau8mxrcB9zXNR8lBT+iqlK6IZ42ceiJYn/DsxvnCl+sgkNd7GWAN/II9wcSHwGEm+CpYGcRko eJ3OFRcFazsH9aUpcaRk6XtYogiarQ/aqQZTRfKC24oEZ6SpSkj80Za3RRg8FMeiU+gmSJ7zXfU SK+hAnvhDY97cGEJ2LIKiND6b8/4KCLLs5ecoDY= Archived-At: http://mailarchive.ietf.org/arch/msg/actn/wrbzLOfVWY0R8_MxjXC2IClQVbE Subject: [Actn] ACTN BoF approved for IETF-91 X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 21:30:40 -0000 Hi, The IESG and IAB met today to discuss all of the BoF proposals, and we have approved ACTN meeting at IETF-91. The meeting will be chaired by Young Lee and Daniele Ceccarelli (thanks!) and Dan King will provide admin and secretarial support. Erik Nordmark has agreed to provide help as IAB BoF Shepherd. This is good news, but now the real work starts! We must not leave this until the BoF itself: we must get things moving soon. I will be working with Young and Daniele to help them deliver what I need to see coming out of the BoF. In the meantime, this mailing list needs to ramp up and start working on a number of issues... - Please re-read the proposed WG charter and say what you think about it. Please comment about good things and bad things. - Please look at the very rough agenda on the BoF wiki and let the chairs know (on this list) about things you think should be discussed as well. - If you are an author of one of the ACTN drafts, please look at it to see what needs to be updated. Is it consistent with the most recent version of the framework? Did you pick up all of the comments made in Toronto? - Please review some of the top-level documents (framework, problem statement) and comment on the list. - Are there other I-Ds needed? What could you contribute? Thanks, Adrian From nobody Tue Oct 7 07:45:44 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 F163F1ACDC7 for ; Tue, 7 Oct 2014 07:45:39 -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 kt17On0kymQK for ; Tue, 7 Oct 2014 07:45:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8B71ACDB1 for ; Tue, 7 Oct 2014 07:45:35 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-5a-5433fc8dfb7a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 14.CC.21334.D8CF3345; Tue, 7 Oct 2014 16:45:33 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.79]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 16:45:33 +0200 From: Daniele Ceccarelli To: "actn@ietf.org" Thread-Topic: New Non-WG Mailing List: Rtg-yang-coord Thread-Index: Ac/iPUtd9S3uH8FqQtmB+Z6raktFvQ== Date: Tue, 7 Oct 2014 14:45:33 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812799CF8@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvjW7vH+MQgxcNBhZbei6wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48H3Y4wFRzgrbtz7yN7A2MrRxcjBISFgIrFhpV0XIyeQKSZx 4d56ti5GLg4hgaOMEge+NzFCOIsYJSZt+sIO0sAmYCXx5JAPSIOIgLLE4sN/2EBsYaA5X5Ys YQYpEREwlZj2MweiRE/i6faDYCUsAioSHff62UFsXgFfiUXTGsDijAKyEhN2L2IEsZkFxCVu PZnPBHGPgMSSPeeZIWxRiZeP/7FCnKwosbxfDqJcR2LB7k9sELa2xLKFr5khxgtKnJz5hGUC o/AsJFNnIWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECg/vglt+6OxhX v3Y8xCjAwajEw6vgaRwixJpYVlyZe4hRmoNFSZx30bl5wUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoY6+4onG/f7/r17NSWi5+CGTpym97bqh/8tMKy5dzb1s7JF40vV2d1bL4qzcIn3cl3 xPX2h4R9d7Z3Ld0uXXNnSc/BlIWm7s/tmg/q/j1Ymxf01K/XMW974HylpsWnyyYFxqqfztmp bnX/xq6brBlaUzvLGhZobFoqoX992+ebL6zyHmcI7OdfosRSnJFoqMVcVJwIAI0w2AhPAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/pKZF9tvvjH6E3zmohnjiqpIBy5U Subject: [Actn] FW: New Non-WG Mailing List: Rtg-yang-coord 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: Tue, 07 Oct 2014 14:45:40 -0000 FYI -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IE= TF Secretariat Sent: Monday, October 06, 2014 6:33 PM To: IETF Announcement List Cc: jhaas@juniper.net; jeff.tantsura@ericsson.com; rtg-yang-coord@ietf.org Subject: New Non-WG Mailing List: Rtg-yang-coord=20 A new IETF non-working group email list has been created. List address: rtg-yang-coord@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-yang-coord/ To subscribe: https://www.ietf.org/mailman/listinfo/rtg-yang-coord Purpose: The rtg-yang-coord mailing list will provide a forum for coordination of th= e development of YANG models being worked on for Routing, in order to provi= de a consistent view to the NMS. The intended participants are people activ= e in Routing working groups and interested in the associated YANG models, a= nd YANG experts assisting with Routing YANG models. While this list will he= lp with the synchronization, WGs with responsibility for core routing proto= cols are expected to also be responsible for the development of YANG models= for those protocols.=20 For additional information, please contact the list administrators. From nobody Wed Oct 8 05:33:54 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 0AF031A033C for ; Wed, 8 Oct 2014 05:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 b9pP8n5cebdV for ; Wed, 8 Oct 2014 05:33:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C513A1A033B for ; Wed, 8 Oct 2014 05:33:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 407BC4BFF8D2E; Wed, 8 Oct 2014 12:33:44 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s98CXjUw005193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 14:33:47 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.228]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 14:33:46 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: "actn@ietf.org" , Daniele Ceccarelli , Leeyoung , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1w== Date: Wed, 8 Oct 2014 12:33:45 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F486D545764FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/Uik9AIHeDaH1WHlRYsynElhHE2s Cc: "Varma, Eve L \(Eve\)" , "BELOTTI, SERGIO \(SERGIO\)" Subject: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 08 Oct 2014 12:33:53 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F486D545764FR711WXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 Page 30 : It is Interface C not B , between VNC and PNC Thanks Sergio --_000_B9FEE68CE3A78C41A2B3C67549A96F486D545764FR711WXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daniele , Young and all auth= ors,

 

I read you Framework draft and = I have some comments on that. Most are editorial , other questions for clar= ifications.

 

General question: in the draft = the concept of VNC is in the view of hierarchical level of controllers or l= inked to the multi-domain aspect that compel to provide to the customer a s= ingle virtualized network even if composed by real multi-domain multi-technology subnetworks? I mean, the “virt= ualizer function” provided by VNC, in case of a single domain context= could be inside directly the PNC , correct?

 

Section 2 , page 4: =

abstraction does not imply auto= matically virtualization,while virtualization implies to have surely a cert= ain form of abstraction. I would suggest to consider good definition contai= ned into ONF SDN architecture document chapter 2.3 Conventions about abstraction and virtualization. A good defin= ition can help all the reading.

 

Section 5: It seems to me you m= ixed here aspects that are more related to policy like admission control &n= bsp;and guarantee of client isolation with real computational issue like Co= mputing time , path constrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager

 

Section 6.1 : while it is clear= the scope of the different control interface presented in figure 5, I̵= 7;m a bit confused as to what I/F E is – data plane interface to prov= ider physical network? Or is the intention to provide what can be the underlying model of resources allocated to a customer from= network provider controller, and the mapping to real physical resources ? = Nor clear to me the intention

 

Section 6.1, always figure= 5: If a report of potential NW topology between a VNC and a CNC can be que= ried , the arrow in the drawn has to be bidirectional I guess

Figure 8 Section 6.4,page 28= : “PCA abstracts the physical network topology into an abstracted top= ology” Looking at the description of VNC components in 6.2.2 it is th= e resource manager devoting to provide abstract topology. Does not exist any PCA component.

 

Figure 8 SEction 6.4, : In= the picture there is no phase 7, and there are 2 phase 8=

Page 30 : It is Interface = C not B , between VNC and PNC

 

Thanks

 

Sergio

 

 

 

--_000_B9FEE68CE3A78C41A2B3C67549A96F486D545764FR711WXCHMBA05z_-- From nobody Wed Oct 8 08:34:55 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 A03501A6F15 for ; Wed, 8 Oct 2014 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 zYY6J48hNwxP for ; Wed, 8 Oct 2014 08:34:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BA51A6F6F for ; Wed, 8 Oct 2014 08:34:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKI56257; Wed, 08 Oct 2014 15:34:44 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Oct 2014 16:34:43 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 8 Oct 2014 08:34:35 -0700 From: Leeyoung To: "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQ Date: Wed, 8 Oct 2014 15:34:34 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.207] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C3C87Bdfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/03FE8eex925DwZjyajsgGkUSgog Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 08 Oct 2014 15:34:53 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3C87Bdfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; diego@tid.es; luyuanf@gmai= l.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. Thanks Sergio --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3C87Bdfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; diego@tid.es; luyua= nf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

Thanks

 

Sergio

 

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C3C87Bdfweml706chm_-- From nobody Wed Oct 8 11:06:13 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 508B31ACD8F for ; Wed, 8 Oct 2014 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 b5eNUrM8SeHr for ; Wed, 8 Oct 2014 11:06:08 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9EA1A702A for ; Wed, 8 Oct 2014 11:06:07 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so9685501igq.4 for ; Wed, 08 Oct 2014 11:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bSM9nWGsz359gz1ZsNTW3uKPDDhn9vIGnHVnaeFQI80=; b=Mz6HzkVDFjSZcDpLzhrbGH2i9rKwrzi1N54fshJx2iBaBs9bVIIgNG/Et0cdgJZfjQ qy6YtgyYsqIEHJrBw88/qva/xMkJW9UIwYg8d9Q4k82G6bGV1R2iKKui/vBzaP4TKp0N crPlt6QnxXA1+ZU7KqfD6q3YzArhUt8mFlhMubzzt8SEYfv4MxhbGJDrIkILYgpDXOFG gHhd1feEs0mt9aZFCcaPMk9E5tDSOi4UoL9W3hVJnUZZq8z3W+2XNQZGD9OtP/sCJbLM FZHfhAcPbeodlcnn42BPrJ4f3Lv0xO3nPHxuF1sT4Eqi2Zu3ZFnwNhbB21yga57hkY1/ 6TmA== MIME-Version: 1.0 X-Received: by 10.50.85.38 with SMTP id e6mr44755848igz.5.1412791567146; Wed, 08 Oct 2014 11:06:07 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Wed, 8 Oct 2014 11:06:07 -0700 (PDT) Date: Wed, 8 Oct 2014 23:36:07 +0530 X-Google-Sender-Auth: Jqd_O6D6hJDqiZ0Je63D959X6as Message-ID: From: Dhruv Dhody To: "actn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/mHUZ5R_4lHzxo8AgyRhyK6SmQBo Subject: [Actn] Comments on draft-ceccarelli-actn-framework-03 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, 08 Oct 2014 18:06:10 -0000 (1) Sec 1. Terminology - We should state that the following terms are defined in this document. - We should also state which terms are borrowed from 4655 and 5440 - PCE, PCC, PCEP etc (2) Sec 2. Introduction OLD: This implies that at least the following transport networks are in scope of the discussion of this draft: L1 optical networks (e.g., OTN and WDM), MPLS-TP, MPLS-TE, as well as other emerging connection-oriented networks such as Segment Routing (SR). NEW: This implies that at least the following transport networks are in scope of the discussion of this draft: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, Och/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior. Reason: to align with charter discussion. (3) Usage of the term 'virtual network element'; here it means generic element that could be a virtual node/link - The level of virtual control given to the customers can vary from a tunnel connecting two end- points to virtual network elements that consist of a set of virtual nodes and virtual links in a mesh network topology. Later, it is also used to mean only virtual nodes at - The level of topology abstraction is expressed in terms of the number of virtual network elements (VNEs) and virtual links (VLs). Also it is used for Virtual Network Embedding in section 5. This usage should be made uniform. (4) In section 3.1. Customers, it can be clearly stated that we are dealing with the case of "advanced customers" only in ACTN. (5) In section 6.2.1. Customer Network Controller, it should be figure 6 and not figure 5 that shows an example physical network topology. (6) In section 6.2.2. Virtual Network Controller, s/consumer controller/customer controller/ (7) In section 6.2.3. Physical Network Controller, it says - PCE: This is the stateful PCE performing the path computation over the physical topology and that provides the vConnection agent with the network topology. is network topology correct? Or should it be network paths (LSPs)? Or both? Note that in the previous section it says - vConnection Agent: This module is in charge of mapping VN setup commands into network provisioning requests to the PNC. which has no mention of network topology. Do you mean to suggest that the PCE needs to communicate raw or abstract topology to VNC as well? PCE does not expose such a interface right now. Also note that in figure 8, vConnection Agent doesn't talk to PCE? (8) In section 6.3. Abstracted Topology Illustration, it should be figure 6 instead figure 2 is mentioned. (9) In section 6.4. Workflows of ACTN Control Modules for Virtual Network Service, it should be figure 8 instead figure 5 is mentioned. Nits: - Suggest to follow the new RFC style guide [1] with respect to ordering of sections etc. - Expand on first use OTN, WDM, MPLS-TP, MPLS-TE, PCE, TE, TDM.... - Reference to problem statement ID in section 3 is displayed as - [REF probl stat] - s/ONC OAM handler/PNC OAM handler [page 21] Regards, Dhruv [1]: http://www.rfc-editor.org/rfc/rfc7322.txt From nobody Wed Oct 8 12:49:57 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 087011A019B for ; Wed, 8 Oct 2014 12:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IoypdqOb58uu for ; Wed, 8 Oct 2014 12:49:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106121A026A for ; Wed, 8 Oct 2014 12:49:45 -0700 (PDT) Received: from BL2PR03MB372.namprd03.prod.outlook.com (10.141.89.15) by BL2PR03MB369.namprd03.prod.outlook.com (10.141.89.12) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 19:49:21 +0000 Received: from BL2PR03MB372.namprd03.prod.outlook.com ([10.141.89.15]) by BL2PR03MB372.namprd03.prod.outlook.com ([10.141.89.15]) with mapi id 15.00.1044.008; Wed, 8 Oct 2014 19:49:22 +0000 From: Luyuan Fang To: Dhruv Dhody , "actn@ietf.org" Thread-Topic: [Actn] Comments on draft-ceccarelli-actn-framework-03 Thread-Index: AQHP4yKOkwFq/0PUr02Xo10Td0UkCpwmmZOA Date: Wed, 8 Oct 2014 19:49:21 +0000 Message-ID: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.70.160.102] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB369; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(189002)(164054003)(377454003)(92566001)(80022003)(76176999)(85306004)(105586002)(106356001)(107046002)(95666004)(107886001)(40100002)(20776003)(64706001)(31966008)(122556002)(86362001)(74316001)(66066001)(33646002)(2501002)(46102003)(97736003)(50986999)(2656002)(4396001)(21056001)(120916001)(19300405004)(101416001)(19580395003)(15202345003)(87936001)(85852003)(54356999)(106116001)(99396003)(99286002)(86612001)(15975445006)(76576001)(76482002)(230783001)(19580405001)(108616004)(24736002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB369; H:BL2PR03MB372.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/actn/k1GvV91lZUFJa103pZ8EKupjaGI Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 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, 08 Oct 2014 19:49:56 -0000 Hi Dhruv, Appreciate for your feedback, very good comments, we should update the draf= t to align. And I'm good to replace the old text with the new text that you suggested i= n Sec 2. Introduction, it is better. Thanks, Luyuan -----Original Message----- From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Wednesday, October 8, 2014 2:06 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-03 (1) Sec 1. Terminology - We should state that the following terms are defined in this document. - We should also state which terms are borrowed from 4655 and 5440 - PCE, P= CC, PCEP etc (2) Sec 2. Introduction OLD: This implies that at least the following transport networks are in scope of the discussion of this draft: L1 optical networks (e.g., OTN and WDM), MPLS-TP, MPLS-TE, as well as other emerging connection-oriented networks such as Segment Routing (SR). NEW: This implies that at least the following transport networks are in scope of the discussion of this draft: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, Och/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior. Reason: to align with charter discussion. (3) Usage of the term 'virtual network element'; here it means generic elem= ent that could be a virtual node/link - The level of virtual control given to the customers can vary from a tunnel connecting two end- points to virtual network elements that consist of a set of virtual nodes and virtual links in a mesh network topology. Later, it is also used to mean only virtual nodes at - The level of topology abstraction is expressed in terms of the number of virtual network elements (VNEs) and virtual links (VLs). Also it is used for Virtual Network Embedding in section 5. This usage should be made uniform. (4) In section 3.1. Customers, it can be clearly stated that we are dealing= with the case of "advanced customers" only in ACTN. (5) In section 6.2.1. Customer Network Controller, it should be figure 6 and not figure 5 that shows an example physical network topology. (6) In section 6.2.2. Virtual Network Controller, s/consumer controller/cus= tomer controller/ (7) In section 6.2.3. Physical Network Controller, it says - PCE: This is the stateful PCE performing the path computation over the physical topology and that provides the vConnection agent with the network topology. is network topology correct? Or should it be network paths (LSPs)? Or both? Note that in the previous section it says - vConnection Agent: This module is in charge of mapping VN setup commands into network provisioning requests to the PNC. which has no mention of network topology. Do you mean to suggest that the PCE needs to communicate raw or abstract to= pology to VNC as well? PCE does not expose such a interface right now. Also note that in figure 8, vConnection Agent doesn't talk to PCE? (8) In section 6.3. Abstracted Topology Illustration, it should be figure 6= instead figure 2 is mentioned. (9) In section 6.4. Workflows of ACTN Control Modules for Virtual Network S= ervice, it should be figure 8 instead figure 5 is mentioned. Nits: - Suggest to follow the new RFC style guide [1] with respect to ordering of= sections etc. - Expand on first use OTN, WDM, MPLS-TP, MPLS-TE, PCE, TE, TDM.... - Reference to problem statement ID in section 3 is displayed as - [REF pro= bl stat] - s/ONC OAM handler/PNC OAM handler [page 21] Regards, Dhruv [1]: http://www.rfc-editor.org/rfc/rfc7322.txt _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn From nobody Thu Oct 9 02:59:00 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 B13561ACD16 for ; Thu, 9 Oct 2014 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 ykbd1eVlxdJD for ; Thu, 9 Oct 2014 02:58:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3711ACD25 for ; Thu, 9 Oct 2014 02:58:52 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 912258E56A921; Thu, 9 Oct 2014 09:58:47 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s999wmig030890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 11:58:48 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.228]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 11:58:48 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Leeyoung , "actn@ietf.org" , "Daniele Ceccarelli" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMA= Date: Thu, 9 Oct 2014 09:58:48 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F486D545C16FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/SJQgxUNP-9eTVhO0dbs6Qq4-n2Y Cc: "BELOTTI, SERGIO \(SERGIO\)" , "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 09:58:57 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F486D545C16FR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.= es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_B9FEE68CE3A78C41A2B3C67549A96F486D545C16FR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

thanks = a lot for reply , please see in line just some further clarification

&n= bsp;

Regards=

Sergio<= o:p>

&n= bsp;

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; die= go@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Serg= io,

&n= bsp;

Thanks = for your feedback on the framework document. Please see in-line for my comm= ent.

&n= bsp;

Regards= ,

Young

&n= bsp;

From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all auth= ors,

 

I read you Framework draft and = I have some comments on that. Most are editorial , other questions for clar= ifications.

 

General question: in the draft = the concept of VNC is in the view of hierarchical level of controllers or l= inked to the multi-domain aspect that compel to provide to the customer a s= ingle virtualized network even if composed by real multi-domain multi-technology subnetworks? I mean, the “virt= ualizer function” provided by VNC, in case of a single domain context= could be inside directly the PNC , correct?

 

YOUNG>> Yes. That is the = correct view of VNC. For a single domain context, the VNC can be integrated= with PNC. But we need to factor in other scenarios such as 1) VNC vendor m= ay be different from PNC vendor or 2) VNC is a software function that operator may want to operate as its control. I= n my opinion, even for a single domain, I think there is benefit to define = this interface as a standard interface.

 

Section 2 , page 4: =

abstraction does not imply auto= matically virtualization,while virtualization implies to have surely a cert= ain form of abstraction. I would suggest to consider good definition contai= ned into ONF SDN architecture document chapter 2.3 Conventions about abstraction and virtualization. A good defin= ition can help all the reading.

 

YOUNG>> Agree. We will lo= ok into the mentioned document if the usage of terms are aligned with this = document. If not, we will clarify the terminology more clearly.

 

Section 5: It seems to me you m= ixed here aspects that are more related to policy like admission control &n= bsp;and guarantee of client isolation with real computational issue like Co= mputing time , path constrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager.

 

YOUNG>> Indeed. In Sectio= n 5, we will put some notes on the aspect of real-time related from non rea= l time aspect. VNM is not to be mixed with Virtual Network Manager. Here VN= M is an algorithm which is known as Virtual Network Mapping which is a software module that converts client requests i= nto actual networks. Virtual Network Manager is ABNO in my understanding is= a developed concept from VNTM. But Dan King and I will look at this more c= arefully on this aspect what Virtual Network Manager is doing.

&n= bsp;

SB>&= gt;> If I understood form Adrian and Daniel ABNO draft the concept, VNTM= is strictly related to planning function so I this it is very import point= in the context of PNC , I would say

 

Section 6.1 : while it is clear= the scope of the different control interface presented in figure 5, I̵= 7;m a bit confused as to what I/F E is – data plane interface to prov= ider physical network? Or is the intention to provide what can be the underlying model of resources allocated to a customer from= network provider controller, and the mapping to real physical resources ? = Nor clear to me the intention

 

YOUNG>> Interface E is no= t what ACTN will focus on. It simply shows  an underlying model of res= ources allocated to a customer from network provider controller, and the ma= pping to real physical resources.

&n= bsp;

SB>&= gt;> So if I interpreted correctly your answer is more an internal inter= face to PNC , the figure is misleading since it seems like a DP interface .=

 

Section 6.1, always figure= 5: If a report of potential NW topology between a VNC and a CNC can be que= ried , the arrow in the drawn has to be bidirectional I guess

YOUNG>> Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28= : “PCA abstracts the physical network topology into an abstracted top= ology” Looking at the description of VNC components in 6.2.2 it is th= e resource manager devoting to provide abstract topology. Does not exist any PCA component.

 

Y= OUNG>> Sorry for inconsistency. The intention was the PCA is the same= as the Resource Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In= the picture there is no phase 7, and there are 2 phase 8=

YOUNG>> Thanks. Good catch!

Page 30 : It is Interface = C not B , between VNC and PNC

YOUNG>> If you are ref= erring to Section 7.3 where:

   Interfaces= should also be scalable as a large amount of data needs<= /p>

   to be transport= ed across customers to virtual network controllers

   and across virt= ual network controllers and physical network

   controllers.

 

I think this implies both in= terfaces B and C although primarily between VNC-PNC.

&n= bsp;

SB>&= gt;> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , = on Interface interaction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C=

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_B9FEE68CE3A78C41A2B3C67549A96F486D545C16FR711WXCHMBA05z_-- From nobody Thu Oct 9 05:47:52 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 8161C1ACE44 for ; Thu, 9 Oct 2014 05:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 Jlody0GjkfTE for ; Thu, 9 Oct 2014 05:47:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2CF1ACE32 for ; Thu, 9 Oct 2014 05:47:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKJ41856; Thu, 09 Oct 2014 12:47:42 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Oct 2014 13:47:41 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 05:47:31 -0700 From: Leeyoung To: "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAABd/BMA== Date: Thu, 9 Oct 2014 12:47:30 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3CC74@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.86] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CC74dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/WTdbSlHx1btstkhZBIcT33ZMuLQ Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 12:47:50 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CC74dfweml706chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio, Thank you also for providing more comments. Please see in-line for my comme= nt with YOUNG 2>> Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Thursday, October 09, 2014 4:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmai= l.com Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.= es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say YOUNG2>> OK. I think you meant VNTM is a management entity (off-line). Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . YOUNG2>> I am sorry for the confusion. It is actually a mapping from virtua= l network to physical network, which I think a DP interface. Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C YOUNG2>> Yes, you are right. It was a typo. Will correct. Thanks Sergio Thanks Sergio --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CC74dfweml706chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sergio,<= /span>

 

Thank you also for pro= viding more comments. Please see in-line for my comment with YOUNG 2>>= ;

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]
Sent: Thursday, October 09, 2014 4:59 AM
To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyua= nf@gmail.com
Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; die= go@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

YOUNG2>> OK. I t= hink you meant VNTM is a management entity (off-line).

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

YOUNG2>> I am so= rry for the confusion. It is actually a mapping from virtual network to phy= sical network, which I think a DP interface.

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

YOUNG2>> Yes, yo= u are right. It was a typo. Will correct.

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CC74dfweml706chm_-- From nobody Thu Oct 9 11:48:28 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 AF8F21A1A6F for ; Thu, 9 Oct 2014 11:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 fBlQPZ36Tsqe for ; Thu, 9 Oct 2014 11:48:13 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC50A1A0356 for ; Thu, 9 Oct 2014 11:48:12 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s99Ilw9F017095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 14:47:58 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 9 Oct 2014 14:47:58 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Thu, 9 Oct 2014 14:47:57 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Thu, 9 Oct 2014 14:47:57 -0400 From: Igor Bryskin To: "BELOTTI, SERGIO (SERGIO)" , Leeyoung , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEA== Date: Thu, 9 Oct 2014 18:47:56 +0000 Message-ID: <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_874e9d7ce46c40608a6fd9221985fec1ATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-09_07:2014-10-09,2014-10-09,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/BtQ2_KmzAg5ERe1PhEQ9edTElAk Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 18:48:18 -0000 --_000_874e9d7ce46c40608a6fd9221985fec1ATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmai= l.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.= es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_874e9d7ce46c40608a6fd9221985fec1ATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyua= nf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; die= go@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_874e9d7ce46c40608a6fd9221985fec1ATLSRVMBX1advaopticalco_-- From nobody Thu Oct 9 12:24:34 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 9DBDC1A1B8F for ; Thu, 9 Oct 2014 12:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8zvXVOO_db4r for ; Thu, 9 Oct 2014 12:24:28 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::681]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A38C1A1A5C for ; Thu, 9 Oct 2014 12:24:27 -0700 (PDT) Received: from DB4PR04MB508.eurprd04.prod.outlook.com (10.141.239.156) by DB4PR04MB507.eurprd04.prod.outlook.com (10.141.239.149) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 9 Oct 2014 19:20:39 +0000 Received: from DB4PR04MB508.eurprd04.prod.outlook.com ([10.141.239.156]) by DB4PR04MB508.eurprd04.prod.outlook.com ([10.141.239.156]) with mapi id 15.00.1044.008; Thu, 9 Oct 2014 19:20:40 +0000 From: "Doolan, Paul (Coriant - US/Irving)" To: Igor Bryskin Thread-Topic: [Actn] draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAACqd4A Date: Thu, 9 Oct 2014 19:20:39 +0000 Message-ID: <27936621-9D19-4FC6-804C-60C90E397DEF@coriant.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [32.210.21.102] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB507; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(189002)(24454002)(377454003)(80022003)(36756003)(33656002)(54356999)(19625215002)(106356001)(76176999)(16601075003)(87936001)(95666004)(120916001)(122556002)(40100002)(92726001)(105586002)(230783001)(4396001)(110136001)(85306004)(93886004)(85852003)(97736003)(107046002)(15202345003)(86362001)(16236675004)(92566001)(20776003)(66066001)(76482002)(64706001)(2656002)(19617315012)(50986999)(46102003)(101416001)(31966008)(15975445006)(21056001)(19580405001)(19580395003)(99396003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB507; H:DB4PR04MB508.eurprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_279366219D194FC6804C60C90E397DEFcoriantcom_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com Archived-At: http://mailarchive.ietf.org/arch/msg/actn/gm2M8e1Be4K3D3YeldwgMPgIkOQ Cc: "actn@ietf.org" , "Varma, Eve L \(Eve\)" , "luyuanf@gmail.com" , Leeyoung , "diego@tid.es" , Daniele Ceccarelli , "BELOTTI, SERGIO \(SERGIO\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 19:24:32 -0000 --_000_279366219D194FC6804C60C90E397DEFcoriantcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Igor, Because I agree wholeheartedly with the sentiments expressed in your 4th pa= ra I'll ignore your omission of Coriant in the one above it;-) I think you nicely capture the practical realities of the matter at the opt= ical layer and I've heard similar views expressed in other places as well. = I hope some of those people will add to this conversation. thanks, pd On Oct 9, 2014, at 2:47 PM, Igor Bryskin > wrote: Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behal= f Of BELOTTI, SERGIO (SERGIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the =93virtualize= r function=94 provided by VNC, in case of a single domain context could be = inside directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I=92m a bit confused as to what I/F E is =96 data = plane interface to provider physical network? Or is the intention to provid= e what can be the underlying model of resources allocated to a customer fro= m network provider controller, and the mapping to real physical resources ?= Nor clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: =93PCA abstracts the physical network topolog= y into an abstracted topology=94 Looking at the description of VNC componen= ts in 6.2.2 it is the resource manager devoting to provide abstract topolog= y. Does not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn --_000_279366219D194FC6804C60C90E397DEFcoriantcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hello Igor,

Because I agree wholeheartedly with the sentiments expressed in your 4= th para I'll ignore your omission of Coriant in the one above it;-)

I think you nicely capture the practical realities of the matter at th= e optical layer and I've heard similar views expressed in other places as w= ell. I hope some of those people will add to this conversation.

thanks,
pd

On Oct 9, 2014, at 2:47 PM, Igor Bryskin <IBryskin@advaoptical.com>
 wrote:

Hi Yo= ung,

 = ;

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

 = ;

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

 = ;

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

 = ;

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

 = ;

Cheer= s,

Igor =

 = ;

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the =93virtualizer function=94 provi= ded by VNC, in case of a single domain context could be inside directly the= PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I=92m a bit confused as to = what I/F E is =96 data plane interface to provider physical network? Or is = the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: =93PCA abstracts th= e physical network topology into an abstracted topology=94 Looking at the d= escription of VNC components in 6.2.2 it is the resource manager devoting t= o provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

_______________________________________________
ACTN mailing list
ACTN@ietf.org
https://www.ietf.org/mailman/listinfo/actn

--_000_279366219D194FC6804C60C90E397DEFcoriantcom_-- From nobody Thu Oct 9 13:32:12 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 5E6BC1A873E for ; Thu, 9 Oct 2014 13:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 Be_Ux02mHH-P for ; Thu, 9 Oct 2014 13:32:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502681A8737 for ; Thu, 9 Oct 2014 13:32:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNM16105; Thu, 09 Oct 2014 20:32:02 +0000 (GMT) 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, 9 Oct 2014 21:32:01 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 13:31:50 -0700 From: Leeyoung To: Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , "Daniele Ceccarelli" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75A Date: Thu, 9 Oct 2014 20:31:49 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.218] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CF36dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/ScI-1uhcqTSgvV_LqcUL1uwZiYU Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 20:32:12 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CF36dfweml706chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; = diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmai= l.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.= es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CF36dfweml706chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Cecca= relli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyua= nf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; die= go@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CF36dfweml706chm_-- From nobody Thu Oct 9 13:53:48 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 39E001A8822 for ; Thu, 9 Oct 2014 13:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 lwZR2fycnNtk for ; Thu, 9 Oct 2014 13:53:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51541A876B for ; Thu, 9 Oct 2014 13:53:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKJ73150; Thu, 09 Oct 2014 20:53:32 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Oct 2014 21:53:31 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 13:53:20 -0700 From: Leeyoung To: Leeyoung , Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAGxRYA= Date: Thu, 9 Oct 2014 20:53:19 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.218] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/TryO3qQ7H-ywdL_XAsADx0grp78 Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 20:53:44 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2dfweml706chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry Igor for misspelling your name, no joke here. Take my apology! From: Leeyoung Sent: Thursday, October 09, 2014 3:32 PM To: 'Igor Bryskin'; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccar= elli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; = diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmai= l.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.= es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2dfweml706chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry Igor for misspel= ling your name, no joke here. Take my apology!

 

From: Leeyoung
Sent: Thursday, October 09, 2014 3:32 PM
To: 'Igor Bryskin'; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele= Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Cecca= relli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyua= nf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; die= go@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2dfweml706chm_-- From nobody Thu Oct 9 13:58:19 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 0B1761A8823 for ; Thu, 9 Oct 2014 13:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 v0_DkLIT3Adt for ; Thu, 9 Oct 2014 13:58:09 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 024F41A87C5 for ; Thu, 9 Oct 2014 13:58:09 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1XcKmh-0000EZ-59; Thu, 09 Oct 2014 21:58:03 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 21:58:02 +0100 From: "King, Daniel" To: Leeyoung , Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYA= Date: Thu, 9 Oct 2014 20:58:02 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A3236F248EX0MB2lancsloca_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/I2n6ggPkjn8xlibfOIwxXCSjdzs Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 20:58:18 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A3236F248EX0MB2lancsloca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarel= li; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_65174429B5AF4C45BD0798810EC48E0A3236F248EX0MB2lancsloca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All, including “Ignor” ;-)

 

Typical dichotomy between what operators want and what vendors are act= ually willing to provide, group consensus will eventually help resolve that= . Either way, the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the = protocol work) on the interfaces which are in scope, namely:

 

1. The CNC-VNC Interface (CVI)

- Create, modify and delete virtual network service instances

- Resource model

 

2. The VNC-PNC Interface (VPI)

- Mapping of physical and virtual resources

- Requests: path, provision, modify and restore

 

As Young suggests, if the VNC received physical topology info it would= be performing the role of the Physical Network Controller (PNC), which is = obviously a (somehow) required function, but the interface (direct provisioning of the actual physical network) is = out of scope for ACTN.

 

Br, Dan.

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele C= eccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Igno= r,

&n= bsp;

Thank y= ou for providing your comment that pauses us to think more and understand o= n the same level. I think your comment will contribute to crystallize the s= cope of work here.

&n= bsp;

First o= f all, I think there was a misunderstanding here. First, your assumption on= VNC receiving actual underlying topology is incorrect. If VNC were to have= actually topology (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect h= as been discussed by email threads Daniele started a few weeks ago. Check t= he archive on that. The reason this is out of scope is that PNC multi-domai= n issue is no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those= areas. What VNC receives from each PNC (domain controller) is an abstracte= d topology with varying degrees from actual underlying topology. The reason= why we distinguish the term VNC from PNC.

&n= bsp;

What ca= n be defined on VNC-PNC is a vertical signaling coordination from VNC to ea= ch PNC. As long as the detailed path computation and signaling within a dom= ain are completely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path co= mputation is based on what is exposed from PNCs to VNC. The actual topology= information details is kept by PNCs and the PNCs expose abstracted topolog= y that can hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of v= irtual links (which may be concatenated actual links) can be exposed for di= versity routing calculation at the VNC. This is very different from exposin= g the actual TE topology. You can view this as two level of path computation. VNC first computes an end-to-e= nd path (using whatever constraint information it has), then coordinates wi= th each PNC (telling the border nodes information), then each PNC computes = the domain specific path. When a PNC cannot provide a path segment in its domain, then this needs to be sig= naled to VNC so that the VNC would arrange an alternate path segment to be = able to find a feasible end-to-end path.  I would say this is a “= ;two-phase” signaling and path computation. The point is that there must be some level of hiding on abstract topology = exposure from PNC to VNC and proprietary characteristics of optical devices= need to be dealt only with the corresponding PNC.

&n= bsp;

Regardi= ng the term PNC vs. ANC, I wouldn’t concern too much about the termin= ology whichever works better. Thank you for your suggestion.

&n= bsp;

Lastly,= please check the use-cases written by operators in the below links that co= nsistently say they need a standard interface that can coordinate their mul= ti-domain issues.

&n= bsp;

http= s://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/

https://datatracker.ietf.org/doc/draft-klee-actn-connectivity= -multi-vendor-domains/

ht= tps://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/<= /o:p>

ht= tps://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/<= /o:p>

ht= tps://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/<= /o:p>

&n= bsp;

Regards= ,

Young

&n= bsp;

Thanks,=

Young

&n= bsp;

&n= bsp;

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Young,

 

I believe having the same instance of VNC talking to different ve= ndor domain PNCs is an extremely  idealistic view.

 

=3D=3D=E8 BTW I find PNC is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a= . a Hypervisor) is managing abstract topologies, and to be able do that, it= talks to a ANC- a controller which has an access and manages actual provid= er network).

 

One reason for this is that VNC needs to understand underlying ac= tual topology, for example, to ensure that two abstract TE links are SRLG d= isjoint as requested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendo= r and contains a great variety of proprietary extensions, failing to unders= tand which leads to producing unprovisionable service paths. Do you really = believe that a single VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to = ask all optical providers to switch to WSON :=3D).

 

This is not to say that you cannot build a hierarchy of VNCs, but= in this case North VNC plays role of a client network controller wrt to So= uth VNC, that is, uses the same X interface.

IHMO whenever a VNC has to talk to a ANC, it does so in a proprie= tary way, i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing= the same north bound interface to potentially the same client (e.g.TFK).

IHMO interface X is the only interface that the ACTN can work on.=

 

Cheers,

Igor

 

From: ACTN [mailto:actn-boun= ces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks = a lot for reply , please see in line just some further clarification

&n= bsp;

Regards=

Sergio<= o:p>

&n= bsp;

 = ;

 = ;

From: Leeyoung [mail= to:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Serg= io,

&n= bsp;

Thanks = for your feedback on the framework document. Please see in-line for my comm= ent.

&n= bsp;

Regards= ,

Young

&n= bsp;

From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all auth= ors,

 

I read you Framework draft and = I have some comments on that. Most are editorial , other questions for clar= ifications.

 

General question: in the draft = the concept of VNC is in the view of hierarchical level of controllers or l= inked to the multi-domain aspect that compel to provide to the customer a s= ingle virtualized network even if composed by real multi-domain multi-technology subnetworks? I mean, the “virt= ualizer function” provided by VNC, in case of a single domain context= could be inside directly the PNC , correct?

 

YOUNG>> Yes. That is the = correct view of VNC. For a single domain context, the VNC can be integrated= with PNC. But we need to factor in other scenarios such as 1) VNC vendor m= ay be different from PNC vendor or 2) VNC is a software function that operator may want to operate as its control. I= n my opinion, even for a single domain, I think there is benefit to define = this interface as a standard interface.

 

Section 2 , page 4: =

abstraction does not imply auto= matically virtualization,while virtualization implies to have surely a cert= ain form of abstraction. I would suggest to consider good definition contai= ned into ONF SDN architecture document chapter 2.3 Conventions about abstraction and virtualization. A good defin= ition can help all the reading.

 

YOUNG>> Agree. We will lo= ok into the mentioned document if the usage of terms are aligned with this = document. If not, we will clarify the terminology more clearly.

 

Section 5: It seems to me you m= ixed here aspects that are more related to policy like admission control &n= bsp;and guarantee of client isolation with real computational issue like Co= mputing time , path constrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager.

 

YOUNG>> Indeed. In Sectio= n 5, we will put some notes on the aspect of real-time related from non rea= l time aspect. VNM is not to be mixed with Virtual Network Manager. Here VN= M is an algorithm which is known as Virtual Network Mapping which is a software module that converts client requests i= nto actual networks. Virtual Network Manager is ABNO in my understanding is= a developed concept from VNTM. But Dan King and I will look at this more c= arefully on this aspect what Virtual Network Manager is doing.

&n= bsp;

SB>&= gt;> If I understood form Adrian and Daniel ABNO draft the concept, VNTM= is strictly related to planning function so I this it is very import point= in the context of PNC , I would say

 

Section 6.1 : while it is clear= the scope of the different control interface presented in figure 5, I̵= 7;m a bit confused as to what I/F E is – data plane interface to prov= ider physical network? Or is the intention to provide what can be the underlying model of resources allocated to a customer from= network provider controller, and the mapping to real physical resources ? = Nor clear to me the intention

 

YOUNG>> Interface E is no= t what ACTN will focus on. It simply shows  an underlying model of res= ources allocated to a customer from network provider controller, and the ma= pping to real physical resources.

&n= bsp;

SB>&= gt;> So if I interpreted correctly your answer is more an internal inter= face to PNC , the figure is misleading since it seems like a DP interface .=

 

Section 6.1, always figure= 5: If a report of potential NW topology between a VNC and a CNC can be que= ried , the arrow in the drawn has to be bidirectional I guess

YOUNG>> Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28= : “PCA abstracts the physical network topology into an abstracted top= ology” Looking at the description of VNC components in 6.2.2 it is th= e resource manager devoting to provide abstract topology. Does not exist any PCA component.

 

Y= OUNG>> Sorry for inconsistency. The intention was the PCA is the same= as the Resource Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In= the picture there is no phase 7, and there are 2 phase 8=

YOUNG>> Thanks. Good catch!

Page 30 : It is Interface = C not B , between VNC and PNC

YOUNG>> If you are ref= erring to Section 7.3 where:

   Interfaces= should also be scalable as a large amount of data needs<= /p>

   to be transport= ed across customers to virtual network controllers

   and across virt= ual network controllers and physical network

   controllers.

 

I think this implies both in= terfaces B and C although primarily between VNC-PNC.

&n= bsp;

SB>&= gt;> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , = on Interface interaction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C=

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_65174429B5AF4C45BD0798810EC48E0A3236F248EX0MB2lancsloca_-- From nobody Thu Oct 9 14:14:51 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 EEF0A1A882C for ; Thu, 9 Oct 2014 14:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SSXS1u99CT_9 for ; Thu, 9 Oct 2014 14:14:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592521A8863 for ; Thu, 9 Oct 2014 14:14:40 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 9 Oct 2014 21:14:15 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1049.012; Thu, 9 Oct 2014 21:14:15 +0000 From: John E Drake To: Leeyoung , Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAGxRYAAALkB0A== Date: Thu, 9 Oct 2014 21:14:14 +0000 Message-ID: <9d0ce8ecae1145f1b777960f18f7ce83@BLUPR05MB562.namprd05.prod.outlook.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3CFC2@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB561; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(189002)(377454003)(106356001)(97736003)(15202345003)(101416001)(230783001)(108616004)(19625215002)(2501002)(105586002)(31966008)(33646002)(85306004)(76176999)(50986999)(19617315012)(93886004)(54356999)(107046002)(95666004)(2201001)(20776003)(99286002)(92566001)(46102003)(80022003)(76576001)(21056001)(16236675004)(120916001)(99396003)(19580395003)(2656002)(87936001)(86362001)(4396001)(76482002)(85852003)(64706001)(66066001)(19580405001)(19300405004)(74316001)(122556002)(19609705001)(15975445006)(40100002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9d0ce8ecae1145f1b777960f18f7ce83BLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/actn/EvKACMCtOeOp6Fe_x6LqaYYh-ys Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 09 Oct 2014 21:14:49 -0000 --_000_9d0ce8ecae1145f1b777960f18f7ce83BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's actually spelled Ignore 8-> Yours Irrespectively, John From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, October 09, 2014 1:53 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniel= e Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Sorry Igor for misspelling your name, no joke here. Take my apology! From: Leeyoung Sent: Thursday, October 09, 2014 3:32 PM To: 'Igor Bryskin'; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmai= l.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_9d0ce8ecae1145f1b777960f18f7ce83BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It’s actually sp= elled Ignore 8->

 

Yours Irrespectively,<= o:p>

 

John=

 

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of Leeyoung
Sent: Thursday, October 09, 2014 1:53 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org;= Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Sorry Igor for misspel= ling your name, no joke here. Take my apology!

 

From: Leeyoung
Sent: Thursday, October 09, 2014 3:32 PM
To: 'Igor Bryskin'; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_9d0ce8ecae1145f1b777960f18f7ce83BLUPR05MB562namprd05pro_-- From nobody Thu Oct 9 18:16:23 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 E87F21AD04E for ; Thu, 9 Oct 2014 18:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 B0NLN8wQoJL8 for ; Thu, 9 Oct 2014 18:15:55 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49711AD048 for ; Thu, 9 Oct 2014 18:15:54 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9A1FiYO032271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 21:15:44 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 9 Oct 2014 21:15:44 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Thu, 9 Oct 2014 21:15:44 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Thu, 9 Oct 2014 21:15:44 -0400 From: Igor Bryskin To: "King, Daniel" , Leeyoung , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , Daniele Ceccarelli , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYA== Date: Fri, 10 Oct 2014 01:15:43 +0000 Message-ID: <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_58713f40bbb24e379d6dc56ea85af0afATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-10_02:2014-10-10,2014-10-10,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/xGOREmLROvRNLynHMhKuWlyIvfc Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 10 Oct 2014 01:16:11 -0000 --_000_58713f40bbb24e379d6dc56ea85af0afATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Young and Dan, It does not matter how you call me, and as John is helpfully applying, you = can ignore what I am saying. But let me explain in some more details what I= meant. Suppose we have a client (such as TFK) of a multi-domain transport network,= who wants to provision and manipulate e2e transport services the way he wa= nts it (i.e. applying his policies). What would such client need? 1. An access to a unified network TE topology that could be understood = and used by the client's path computer to select service e2e paths. How doe= s the client get such a topology? The necessary overlay topology comprises = abstract topologies presented for the client by each of the transport domai= ns + inter-domain TE links. Hence we are talking about interface #1 (and da= ta model #1) between a provider hypervisor/VNC and the client controller to= expose in a unified abstract way its topology on per client/tenant basis= . Furthermore, the client controller can use this interface in the opposite= direction to modify the said abstract topology (subject to the provider's = approval), because the client is the only guy who knows how the abstract t= opology exposed to him should look like to be useful (e.g. which and how th= e abstract links should be disjoint from each other, how many of them shoul= d be provided, their attributes, desired recovery capabilities, etc,). This= knowledge is supposed to come from the client's network planning. 2. A way to provision/modify/delete e2e services with the use of so com= puted e2e paths. The client's controller does that by chopping the paths in= to per-domain segments and instructs respective domain VNCs/Hypervisors to = set up/manipulate service respective connection segments. Hence we are talk= ing about interface #2 (data model #2) for the service segment manipulation= ; 3. A way to monitor, troubleshoot, carry out maintenance of the active = e2e services. This would require interface #3 (data model #3) between the c= lient's controller and domains VNCs/Hypervisors for this purpose. So, we are talking 3 Yang models with required modifications to neither Net= conf/Restconf, nor To any other management, routing or signaling protocol. Now I have a couple of questions to you: 1. In this example, what else (in addition to these three models) the c= lient such as TFK in your opinion would need? 2. What else the network providers and their vendors such as ADVA or CI= EN would need? 3. What is the importance of a construct such as PNC? My answer to 3. "Is not important at all, irrelevant" for the following rea= sons: a) What happens beyond the VNC/Hypervisor in the provider network is co= mpletely proprietary. b) There could be numerous ways as to how the provider network is manag= ed. Examples: centralized PNC (as you call it), ADVA style GMPLS based netw= ork intelligence, CIEN style PNNI based control plane, etc. Why is that of = ACTN's business? Cheers, Igor From: King, Daniel [mailto:d.king@lancaster.ac.uk] Sent: Thursday, October 09, 2014 4:58 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniel= e Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarel= li; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_58713f40bbb24e379d6dc56ea85af0afATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Young= and Dan,

=  

It do= es not matter how you call me, and as John is helpfully applying, you can i= gnore what I am saying. But let me explain in some more details what I mean= t.

=  

Suppo= se we have a client (such as TFK) of a multi-domain transport network, who = wants to provision and manipulate e2e transport services the way he wants i= t (i.e. applying his policies). What would such client need?

=  

1.     An access to a unified network TE topology that could be understood and = used by the client’s path computer to select service e2e paths. How d= oes the client get such a topology? The necessary overlay topology comprises abstract topologies presented for the= client by each of the transport domains + inter-domain TE links. Hence= we are talking about interface #1 (and data model #1) between a provider h= ypervisor/VNC and the client controller to expose in a unified abstract  way  its topology on per client= /tenant basis. Furthermore, the client controller can use this interface in= the opposite direction to modify the said abstract topology (subject to th= e provider’s  approval), because the client is the only guy who knows how the abstract topology exposed to him should = look like to be useful (e.g. which and how the abstract links should be dis= joint from each other, how many of them should be provided, their attribute= s, desired recovery capabilities, etc,). This knowledge is supposed to come from the client’s network = planning.

2.     A way to provision/modify/delete e2e services with the use of so compute= d e2e paths. The client’s controller does that by chopping the paths = into per-domain segments and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection= segments. Hence we are talking about interface #2 (data model #2) for the = service segment manipulation;

3.     A way to monitor, troubleshoot, carry out maintenance of the active e2e = services. This would require interface #3 (data model #3) between the clien= t’s controller and domains VNCs/Hypervisors for this purpose.

=  

So, w= e are talking 3 Yang models with required modifications to neither Netconf/= Restconf, nor   

 = ;To any other management, routing or signaling protocol.<= /p>

=  

Now I= have a couple of questions to you:

1.     In this example, what else (in addition to these three models) the clien= t such as TFK in your opinion would need?

2.     What else the network providers and their vendors such as ADVA or CIEN w= ould need?

3.     What is the importance of a construct such as PNC?

 

My an= swer to 3. “Is not important at all, irrelevant” for the follow= ing reasons:

a)     What happens beyond the VNC/Hypervisor in the provider network is comple= tely proprietary.

b)     There could be numerous ways as to how the provider network is managed. = Examples: centralized PNC (as you call it), ADVA style GMPLS based network = intelligence, CIEN style PNNI based control plane, etc. Why is that of ACTN’s business?

=  

Cheer= s,

Igor<= o:p>

=  

From: King, Daniel [mailto:d.king@lancaster.a= c.uk]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org;= Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi All,= including “Ignor” ;-)

&n= bsp;

Typical= dichotomy between what operators want and what vendors are actually willin= g to provide, group consensus will eventually help resolve that. Either way= , the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work)= on the interfaces which are in scope, namely:

&n= bsp;

1. The = CNC-VNC Interface (CVI)

- Creat= e, modify and delete virtual network service instances

- Resou= rce model

&n= bsp;

2. The = VNC-PNC Interface (VPI)

- Mappi= ng of physical and virtual resources

- Reque= sts: path, provision, modify and restore

&n= bsp;

As Youn= g suggests, if the VNC received physical topology info it would be performi= ng the role of the Physical Network Controller (PNC), which is obviously a = (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for A= CTN.

&n= bsp;

Br, Dan= .

 

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele C= eccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_58713f40bbb24e379d6dc56ea85af0afATLSRVMBX1advaopticalco_-- From nobody Fri Oct 10 10:25: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 9EC031A8FD6 for ; Fri, 10 Oct 2014 10:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jvC3mERAcMld for ; Fri, 10 Oct 2014 10:24:50 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0DA1A8822 for ; Fri, 10 Oct 2014 10:24:46 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-10-5438165c529a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.3C.04387.C5618345; Fri, 10 Oct 2014 19:24:44 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.79]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 19:24:44 +0200 From: Daniele Ceccarelli To: Igor Bryskin , "King, Daniel" , Leeyoung , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2g Date: Fri, 10 Oct 2014 17:24:43 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.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.149] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481279D3AEESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM+JvjW6MmEWIwdLVKhZbei6wWbxYF2yx ctJddoulTU8YLU71tDNaTJvnarF693kmi2Wbf7M7cHicXfCH1aP12V5Wj52z7rJ7tBx5y+qx ZMlPJo9TB9I9nvzdwhzAHsVlk5Kak1mWWqRvl8CV8WTPQ8aCljvMFVtPLGNtYFw5i7mLkZND QsBE4t3eg6wQtpjEhXvr2boYuTiEBI4ySuxo6maEcBYzSmxe8hHI4eBgE7CSeHLIByQuIrCU SWLWiUZWkDizgLnEnePJIIOEBWwkNmxdyQ5iiwjYSsy6+5AJwo6SOPHvBNhiFgFViRnfdoPF eQV8Jd7NWgq16zWzxKnza1hAEpwCPhJTDuxlBLEZBWQlJuxeBGYzC4hL3HoynwniagGJJXvO Q30jKvHy8T+ob5Qk1h7ezgJRny9x5tQGZohlghInZz5hmcAoOgvJqFlIymYhKYOI60ncmDqF DcLWlli28DUzhK0rMePfIRZk8QWM7KsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAqP74Jbf VjsYDz53PMQowMGoxMO7wNY8RIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MHYr/XMV2in/8SGz9PwVxvd+xH7Ue73rqkjUdI6zVaaVetPUq7qiF80q/J3+ wdGSQUZ0y/q/NvahOjtPfZwb67+wWIm3T8163qEFBTtP53qnNSmpMR5LeXpmnWi6kNUklrtP W0s8vVVF5pm7PhQ2tZnp/fajYWZ12razB522xvraGPgtqN1jpMRSnJFoqMVcVJwIAJZF2inP AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/60vPJ16F5MpYQZNgphm7gr9ROFc Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 10 Oct 2014 17:25:01 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481279D3AEESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, What do you mean by client here? The one that is the document is called "se= rvice provider" or the one that is called "client" ? From what you send I t= end to think you are talking about the service provider, but I might be wro= ng, please correct me. I don't think the client of the multi-domain network wants to have a so det= ailed view of the network, he does not care about domains, inter domain lin= ks or whatever, I would say he only cares about a given amount of Gbps from= A to B with a given max delay and probably some diversity parameters. On the other side, the one that cares about all of the issues you listed is= the service provider (as per actual document terminology). However also th= e service provider does not go into physical impairment details. He cares a= bout connectivity between the borders of the domains, inter domain links. H= ow such connectivity is provisioned/managed is the network provider busines= s. The network provides might be using GMPLS, NMS and ONF controller with O= pen Flow or whatever to control the network. Maybe calling it PNC is confus= ing? The PNC can be any of the things I've listed and much more. Hence the interfaces to be considered are two, not three (as Dan said) I th= ink this replies to questions 1 and 3. Just to add something regarding 2, I= would say that they need just a single entry point to the network control = (could be a small piece of code running on top of the PCE of your GMPLS dom= ain), which acts as an interface between the VNC and the control plane of y= our network and performs: "- Mapping of physical and virtual resources" and= "Requests: path, provision, modify and restore". Cheers Daniele From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 03:16 To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniel= e Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Young and Dan, It does not matter how you call me, and as John is helpfully applying, you = can ignore what I am saying. But let me explain in some more details what I= meant. Suppose we have a client (such as TFK) of a multi-domain transport network,= who wants to provision and manipulate e2e transport services the way he wa= nts it (i.e. applying his policies). What would such client need? 1. An access to a unified network TE topology that could be understood = and used by the client's path computer to select service e2e paths. How doe= s the client get such a topology? The necessary overlay topology comprises = abstract topologies presented for the client by each of the transport domai= ns + inter-domain TE links. Hence we are talking about interface #1 (and da= ta model #1) between a provider hypervisor/VNC and the client controller to= expose in a unified abstract way its topology on per client/tenant basis= . Furthermore, the client controller can use this interface in the opposite= direction to modify the said abstract topology (subject to the provider's = approval), because the client is the only guy who knows how the abstract t= opology exposed to him should look like to be useful (e.g. which and how th= e abstract links should be disjoint from each other, how many of them shoul= d be provided, their attributes, desired recovery capabilities, etc,). This= knowledge is supposed to come from the client's network planning. 2. A way to provision/modify/delete e2e services with the use of so com= puted e2e paths. The client's controller does that by chopping the paths in= to per-domain segments and instructs respective domain VNCs/Hypervisors to = set up/manipulate service respective connection segments. Hence we are talk= ing about interface #2 (data model #2) for the service segment manipulation= ; 3. A way to monitor, troubleshoot, carry out maintenance of the active = e2e services. This would require interface #3 (data model #3) between the c= lient's controller and domains VNCs/Hypervisors for this purpose. So, we are talking 3 Yang models with required modifications to neither Net= conf/Restconf, nor To any other management, routing or signaling protocol. Now I have a couple of questions to you: 1. In this example, what else (in addition to these three models) the c= lient such as TFK in your opinion would need? 2. What else the network providers and their vendors such as ADVA or CI= EN would need? 3. What is the importance of a construct such as PNC? My answer to 3. "Is not important at all, irrelevant" for the following rea= sons: a) What happens beyond the VNC/Hypervisor in the provider network is co= mpletely proprietary. b) There could be numerous ways as to how the provider network is manag= ed. Examples: centralized PNC (as you call it), ADVA style GMPLS based netw= ork intelligence, CIEN style PNNI based control plane, etc. Why is that of = ACTN's business? Cheers, Igor From: King, Daniel [mailto:d.king@lancaster.ac.uk] Sent: Thursday, October 09, 2014 4:58 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.= com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_4A1562797D64E44993C5CBF38CF1BE481279D3AEESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

What do you mean by cl= ient here? The one that is the document is called “service provider&#= 8221; or the one that is called “client” ? From what you send I= tend to think you are talking about the service provider, but I might be wrong, please correct me.

 

I don’t think th= e client of the multi-domain network wants to have a so detailed view of th= e network, he does not care about domains, inter domain links or whatever, = I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably some diversity par= ameters.

 

On the other side, the= one that cares about all of the issues you listed is the service provider = (as per actual document terminology). However also the service provider doe= s not go into physical impairment details. He cares about connectivity between the borders of the domains, inter doma= in links. How such connectivity is provisioned/managed is the network provi= der business. The network provides might be using GMPLS, NMS and ONF contro= ller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing? The PNC can be = any of the things I’ve listed and much more.

 

Hence the interfaces t= o be considered are two, not three (as Dan said) I think this replies to qu= estions 1 and 3. Just to add something regarding 2, I would say that they n= eed just a single entry point to the network control (could be a small piece of code running on top of the PCE = of your GMPLS domain), which acts as an interface between the VNC and the c= ontrol plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests: path, provision, m= odify and restore”.

&n= bsp;

Cheers<= o:p>

Daniele=

&n= bsp;

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: venerd=EC 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org;= Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Young= and Dan,

=  

It do= es not matter how you call me, and as John is helpfully applying, you can i= gnore what I am saying. But let me explain in some more details what I mean= t.

=  

Suppo= se we have a client (such as TFK) of a multi-domain transport network, who = wants to provision and manipulate e2e transport services the way he wants i= t (i.e. applying his policies). What would such client need?

=  

1. = ;    An access to a unifie= d network TE topology that could be understood and used by the client’= ;s path computer to select service e2e paths. How does the client get such = a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of the tran= sport domains + inter-domain TE links. Hence we are talking about inter= face #1 (and data model #1) between a provider hypervisor/VNC and the clien= t controller to expose in a unified abstract  way  its topology on per client/tenant basis. Furtherm= ore, the client controller can use this interface in the opposite direction= to modify the said abstract topology (subject to the provider’s &nbs= p;approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be useful (e.= g. which and how the abstract links should be disjoint from each other, how= many of them should be provided, their attributes, desired recovery capabi= lities, etc,). This knowledge is supposed to come from the client’s network planning.

2. = ;    A way to provision/mo= dify/delete e2e services with the use of so computed e2e paths. The client&= #8217;s controller does that by chopping the paths into per-domain segments= and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segments. Hence we are = talking about interface #2 (data model #2) for the service segment manipula= tion;

3. = ;    A way to monitor, tro= ubleshoot, carry out maintenance of the active e2e services. This would req= uire interface #3 (data model #3) between the client’s controller and= domains VNCs/Hypervisors for this purpose.

=  

So, w= e are talking 3 Yang models with required modifications to neither Netconf/= Restconf, nor   

 = ;To any other management, routing or signaling protocol.<= /p>

=  

Now I= have a couple of questions to you:

1. = ;    In this example, what= else (in addition to these three models) the client such as TFK in your op= inion would need?

2. = ;    What else the network= providers and their vendors such as ADVA or CIEN would need?

3. = ;    What is the importanc= e of a construct such as PNC?

 

My an= swer to 3. “Is not important at all, irrelevant” for the follow= ing reasons:

a) = ;    What happens beyond t= he VNC/Hypervisor in the provider network is completely proprietary.

b) = ;    There could be numero= us ways as to how the provider network is managed. Examples: centralized PN= C (as you call it), ADVA style GMPLS based network intelligence, CIEN style= PNNI based control plane, etc. Why is that of ACTN’s business?

=  

Cheer= s,

Igor<= o:p>

=  

From: King, Daniel [mailto:d.king@lancaster.ac.uk]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi All,= including “Ignor” ;-)

&n= bsp;

Typical= dichotomy between what operators want and what vendors are actually willin= g to provide, group consensus will eventually help resolve that. Either way= , the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work)= on the interfaces which are in scope, namely:

&n= bsp;

1. The = CNC-VNC Interface (CVI)

- Creat= e, modify and delete virtual network service instances

- Resou= rce model

&n= bsp;

2. The = VNC-PNC Interface (VPI)

- Mappi= ng of physical and virtual resources

- Reque= sts: path, provision, modify and restore

&n= bsp;

As Youn= g suggests, if the VNC received physical topology info it would be performi= ng the role of the Physical Network Controller (PNC), which is obviously a = (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for A= CTN.

&n= bsp;

Br, Dan= .

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_4A1562797D64E44993C5CBF38CF1BE481279D3AEESESSMB301erics_-- From nobody Fri Oct 10 10:25:12 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 DBA481A8822 for ; Fri, 10 Oct 2014 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 JAyMrEaGo2fJ for ; Fri, 10 Oct 2014 10:24:54 -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 EDDF81A8932 for ; Fri, 10 Oct 2014 10:24:49 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-d7-5438165f38df Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.E8.24955.F5618345; Fri, 10 Oct 2014 19:24:47 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.79]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 19:24:47 +0200 From: Daniele Ceccarelli To: "Doolan, Paul (Coriant - US/Irving)" , "Igor Bryskin" Thread-Topic: [Actn] draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAACqd4AACdZZ0A= Date: Fri, 10 Oct 2014 17:24:46 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481279D3BE@ESESSMB301.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <27936621-9D19-4FC6-804C-60C90E397DEF@coriant.com> In-Reply-To: <27936621-9D19-4FC6-804C-60C90E397DEF@coriant.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.149] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481279D3BEESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM+JvjW68mEWIwZV2bYstPRfYLFZOustu sbTpCaPFqZ52Rotp81wtVu8+z2Rx+vMrdotlm3+zO3B4nF3wh9Wj9dleVo/z3/aweuycdZfd o+XIW1aPJUt+Mnk8+buFOYA9issmJTUnsyy1SN8ugSuju/EBc8H5X4wVe3b8ZGtg7L7O2MXI ySEhYCJx6/V6NghbTOLCPRCbi0NI4CijxLfJ35ggnMWMEo87ZgN1cHCwCVhJPDnkA9IgIpAv 8W3eGnaQGmaBNiaJ1uaHzCAJYQFnid4Vq1ggilwk9jXuYQXpFRHwk2j7wQoSZhFQlTj69SrY Yl4BX4l/Z3qgdj1kkvhw+ykLSD2ngL3E3ecyIDWMArISE3YvAjuaWUBc4taT+UwQRwtILNlz nhnCFpV4+fgfK4StJLH28HYWiPp8iUfPm5khdglKnJz5hGUCo+gsJKNmISmbhaQMIq4ncWPq FDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiM74Nb fqvuYLz8xvEQowAHoxIP7wJb8xAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgtii8q zUktPsTIxMEp1cAY7RHyZsrWlL+nVqufnvZ8y47tZ+3d7qx3PTDz1Slz8/gP35Yla/+VN33L /PEG2zOr5a8EG3NC6uo/NLXnMoRdq1ytbnC8gOETp8HqpTFf77lv2ffy3uL2Tw/jV7sGP+BN kjDblsslVev9femhD/KRRcem6fZl1e2vmH5iYe/eN+c4FrQbffutq8RSnJFoqMVcVJwIAO6V IGLQAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/eHgzpSo1HtzhQUjDPvJ5uVqrODY Cc: "diego@tid.es" , "Varma, Eve L \(Eve\)" , "luyuanf@gmail.com" , Leeyoung , "actn@ietf.org" , "BELOTTI, SERGIO \(SERGIO\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 10 Oct 2014 17:25:03 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481279D3BEESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, The idea, at least speaking on behalf of Daniele and not of all the authors= , is to hide such complexity to the service provider and the client. The service provider (VNC level) asks the network provider to provide conne= ctivity between two points with given characteristics. If we want to export= all the ingredients for autonomously performing and end to end path comput= ation...then I agree with Igor: we will never succeed. It would also be an = exercise of multi domain routing (reinventing the wheel) as we would just u= se an NBI to export routing information instead of using inter domain routi= ng. BR Daniele From: Doolan, Paul (Coriant - US/Irving) [mailto:paul.doolan@coriant.com] Sent: gioved=EC 9 ottobre 2014 21:21 To: Igor Bryskin Cc: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; = diego@tid.es; luyuanf@gmail.com; Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hello Igor, Because I agree wholeheartedly with the sentiments expressed in your 4th pa= ra I'll ignore your omission of Coriant in the one above it;-) I think you nicely capture the practical realities of the matter at the opt= ical layer and I've heard similar views expressed in other places as well. = I hope some of those people will add to this conversation. thanks, pd On Oct 9, 2014, at 2:47 PM, Igor Bryskin > wrote: Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behal= f Of BELOTTI, SERGIO (SERGIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn --_000_4A1562797D64E44993C5CBF38CF1BE481279D3BEESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

The idea, at least spe= aking on behalf of Daniele and not of all the authors, is to hide such comp= lexity to the service provider and the client.

 

The service provider (= VNC level) asks the network provider to provide connectivity between two po= ints with given characteristics. If we want to export all the ingredients f= or autonomously performing and end to end path computation…then I agree with Igor: we will never succeed. = It would also be an exercise of multi domain routing (reinventing the wheel= ) as we would just use an NBI to export routing information instead of usin= g inter domain routing.

 

BR
Daniele

 

 

From: Doolan, = Paul (Coriant - US/Irving) [mailto:paul.doolan@coriant.com]
Sent: gioved=EC 9 ottobre 2014 21:21
To: Igor Bryskin
Cc: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Cecca= relli; diego@tid.es; luyuanf@gmail.com; Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hello Igor,

 

Because I agree wholeheartedly with the sentiments e= xpressed in your 4th para I'll ignore your omission of Coriant in the one a= bove it;-)

 

I think you nicely capture the practical realities o= f the matter at the optical layer and I've heard similar views expressed in= other places as well. I hope some of those people will add to this convers= ation.

 

thanks,

pd

 

On Oct 9, 2014, at 2:47 PM, Igor Bryskin <IBryskin@advaoptical.com><= /o:p>

 wrote:



Hi Yo= ung,

 = ;

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

 = ;

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

 = ;

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

 = ;

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

 = ;

Cheer= s,

Igor =

 = ;

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= /span>

 

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Sergio,=

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments=

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

____________________________________= ___________
ACTN mailing list
ACTN@ietf.org
https://www.ietf.org= /mailman/listinfo/actn

 

--_000_4A1562797D64E44993C5CBF38CF1BE481279D3BEESESSMB301erics_-- From nobody Fri Oct 10 13:37:54 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 3C4EF1AD0AA for ; Fri, 10 Oct 2014 13:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 7sx_iCM8GUrf for ; Fri, 10 Oct 2014 13:37:31 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB511AD070 for ; Fri, 10 Oct 2014 13:37:31 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9AKbJqc007827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 16:37:19 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 10 Oct 2014 16:37:19 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Fri, 10 Oct 2014 16:37:18 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Fri, 10 Oct 2014 16:37:18 -0400 From: Igor Bryskin To: Daniele Ceccarelli , "King, Daniel" , Leeyoung , "BELOTTI, SERGIO (SERGIO)" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CA= Date: Fri, 10 Oct 2014 20:37:18 +0000 Message-ID: <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_4003c11315234da8944051d37e30c796ATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-10_08:2014-10-10,2014-10-10,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/1jov0phNbl-DD-Vhe6gcntdBUyQ Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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, 10 Oct 2014 20:37:48 -0000 --_000_4003c11315234da8944051d37e30c796ATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniele, Please, see in line. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 10, 2014 1:25 PM To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ie= tf.org; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Igor, What do you mean by client here? The one that is the document is called "se= rvice provider" or the one that is called "client" ? From what you send I t= end to think you are talking about the service provider, but I might be wro= ng, please correct me. IB>> By client I mean the client of a transport domain, the one who speaks = Netconf/Restconf to the transport domain. The guy who speaks from the other= end (i.e. on behalf of the transport service provider) is the transport d= omain's Hypervisor. I don't think the client of the multi-domain network wants to have a so det= ailed view of the network, he does not care about domains, inter domain lin= ks or whatever, I would say he only cares about a given amount of Gbps from= A to B with a given max delay and probably some diversity parameters. IB>> Again, by client I mean multi-domain network controller (e.g. Telefoni= ca SDN controller), not the client using services of the multi-domain netwo= rk (i.e. not the Telefonica clients). Such client uses the transport domai= ns for a reason. "a given amount of Gbps from A to B" is too loose and litt= le for the client to do the network planning. IMO the client needs to *plan= * the abstract topologies provided by the transport domains the same or sim= ilar way as he would plan his own actual topology. On the other side, the one that cares about all of the issues you listed is= the service provider (as per actual document terminology). However also th= e service provider does not go into physical impairment details. He cares a= bout connectivity between the borders of the domains, inter domain links. H= ow such connectivity is provisioned/managed is the network provider busines= s. The network provides might be using GMPLS, NMS and ONF controller with O= pen Flow or whatever to control the network. Maybe calling it PNC is confus= ing? The PNC can be any of the things I've listed and much more. IB>> In this case my client is your service provider ;=3D). You architectur= ally separate client from the service provider, because you probably believ= e that it is possible to standardize the interface between the two. I disag= ree with that and don't think ACTN should work on this. In the context of A= CTN I see only two constructs: Transport domain controller (transport servi= ce provider) and Transport client controller (transport service user). Hence the interfaces to be considered are two, not three (as Dan said) I th= ink this replies to questions 1 and 3. Just to add something regarding 2, I= would say that they need just a single entry point to the network control = (could be a small piece of code running on top of the PCE of your GMPLS dom= ain), which acts as an interface between the VNC and the control plane of y= our network and performs: "- Mapping of physical and virtual resources" and= "Requests: path, provision, modify and restore". IB>> As I said, this is the task of the transport domain Hypervisor, whose = role is, essentially, to translate back and forth abstract <=3D> actual top= ology elements and service requests/responses containing the abstract/actua= l topology paths. I think that the north/south interface between the transp= ort domain Hypervisor and the entity representing the client of the transpo= rt domain (no matter how you call it) is the only interface ACTN can work o= n with the hope to produce something useful. Cheers Daniele From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 03:16 To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Young and Dan, It does not matter how you call me, and as John is helpfully applying, you = can ignore what I am saying. But let me explain in some more details what I= meant. Suppose we have a client (such as TFK) of a multi-domain transport network,= who wants to provision and manipulate e2e transport services the way he wa= nts it (i.e. applying his policies). What would such client need? 1. An access to a unified network TE topology that could be understood = and used by the client's path computer to select service e2e paths. How doe= s the client get such a topology? The necessary overlay topology comprises = abstract topologies presented for the client by each of the transport domai= ns + inter-domain TE links. Hence we are talking about interface #1 (and da= ta model #1) between a provider hypervisor/VNC and the client controller to= expose in a unified abstract way its topology on per client/tenant basis= . Furthermore, the client controller can use this interface in the opposite= direction to modify the said abstract topology (subject to the provider's = approval), because the client is the only guy who knows how the abstract t= opology exposed to him should look like to be useful (e.g. which and how th= e abstract links should be disjoint from each other, how many of them shoul= d be provided, their attributes, desired recovery capabilities, etc,). This= knowledge is supposed to come from the client's network planning. 2. A way to provision/modify/delete e2e services with the use of so com= puted e2e paths. The client's controller does that by chopping the paths in= to per-domain segments and instructs respective domain VNCs/Hypervisors to = set up/manipulate service respective connection segments. Hence we are talk= ing about interface #2 (data model #2) for the service segment manipulation= ; 3. A way to monitor, troubleshoot, carry out maintenance of the active = e2e services. This would require interface #3 (data model #3) between the c= lient's controller and domains VNCs/Hypervisors for this purpose. So, we are talking 3 Yang models with required modifications to neither Net= conf/Restconf, nor To any other management, routing or signaling protocol. Now I have a couple of questions to you: 1. In this example, what else (in addition to these three models) the c= lient such as TFK in your opinion would need? 2. What else the network providers and their vendors such as ADVA or CI= EN would need? 3. What is the importance of a construct such as PNC? My answer to 3. "Is not important at all, irrelevant" for the following rea= sons: a) What happens beyond the VNC/Hypervisor in the provider network is co= mpletely proprietary. b) There could be numerous ways as to how the provider network is manag= ed. Examples: centralized PNC (as you call it), ADVA style GMPLS based netw= ork intelligence, CIEN style PNNI based control plane, etc. Why is that of = ACTN's business? Cheers, Igor From: King, Daniel [mailto:d.king@lancaster.ac.uk] Sent: Thursday, October 09, 2014 4:58 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.= com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_4003c11315234da8944051d37e30c796ATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Da= niele,

Pleas= e, see in line.

Igor<= o:p>

=  

From: Daniele Ceccarelli [mailto:daniele.cecc= arelli@ericsson.com]
Sent: Friday, October 10, 2014 1:25 PM
To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); = actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Igor,

 

What do you mean by cl= ient here? The one that is the document is called “service provider&#= 8221; or the one that is called “client” ? From what you send I= tend to think you are talking about the service provider, but I might be wrong, please correct me.

=  

IB>= ;> By client I mean the client of a transport domain, the one who speaks= Netconf/Restconf to the transport domain. The guy who speaks from the othe= r end (i.e. on behalf of the transport service provider)  is the transport domain’s Hypervisor.

 

I don’t think th= e client of the multi-domain network wants to have a so detailed view of th= e network, he does not care about domains, inter domain links or whatever, = I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably some diversity par= ameters.

=  

IB>= ;> Again, by client I mean multi-domain network controller (e.g. Telefon= ica SDN controller), not the client using services of the multi-domain netw= ork (i.e. not the Telefonica clients). Such client uses  the transport domains for a reason. “a given amount of Gbps from A to B” is too lo= ose and little for the client to do the network planning. IMO the client ne= eds to *plan* the abstract topologies provided by the transport domains the same or similar way as he would plan his own = actual topology.=

 

On the other side, the= one that cares about all of the issues you listed is the service provider = (as per actual document terminology). However also the service provider doe= s not go into physical impairment details. He cares about connectivity between the borders of the domains, inter doma= in links. How such connectivity is provisioned/managed is the network provi= der business. The network provides might be using GMPLS, NMS and ONF contro= ller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing? The PNC can be = any of the things I’ve listed and much more.

=  

IB>= ;> In this case my client is your service provider ;=3D). You architectu= rally separate client from the service provider, because you probably belie= ve that it is possible to standardize the interface between the two. I disagree with that and don’t think ACTN should wo= rk on this. In the context of ACTN I see only two constructs: Transport dom= ain controller (transport service provider) and  Transport client cont= roller (transport service user).

 

Hence the interfaces t= o be considered are two, not three (as Dan said) I think this replies to qu= estions 1 and 3. Just to add something regarding 2, I would say that they n= eed just a single entry point to the network control (could be a small piece of code running on top of the PCE = of your GMPLS domain), which acts as an interface between the VNC and the c= ontrol plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests: path, provision, m= odify and restore”.

 

IB>> As I said, this is the task of the transport domain Hy= pervisor, whose role is, essentially, to translate back and forth abstract =F3 actual topology elements and service requests/responses conta= ining the abstract/actual topology paths. I think that the north/south interface between the transport domain Hyperv= isor and the entity representing the client of the transport domain (no mat= ter how you call it) is the only interface ACTN can work on with the hope t= o produce something useful.

&n= bsp;

Cheers<= o:p>

Daniele=

&n= bsp;

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: venerd=EC 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Young= and Dan,

=  

It do= es not matter how you call me, and as John is helpfully applying, you can i= gnore what I am saying. But let me explain in some more details what I mean= t.

=  

Suppo= se we have a client (such as TFK) of a multi-domain transport network, who = wants to provision and manipulate e2e transport services the way he wants i= t (i.e. applying his policies). What would such client need?

=  

1. =     An access to a unifie= d network TE topology that could be understood and used by the client’= ;s path computer to select service e2e paths. How does the client get such = a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of the tran= sport domains + inter-domain TE links. Hence we are talking about inter= face #1 (and data model #1) between a provider hypervisor/VNC and the clien= t controller to expose in a unified abstract  way  its topology on per client/tenant basis. Furtherm= ore, the client controller can use this interface in the opposite direction= to modify the said abstract topology (subject to the provider’s &nbs= p;approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be useful (e.= g. which and how the abstract links should be disjoint from each other, how= many of them should be provided, their attributes, desired recovery capabi= lities, etc,). This knowledge is supposed to come from the client’s network planning.

2. =     A way to provision/mo= dify/delete e2e services with the use of so computed e2e paths. The client&= #8217;s controller does that by chopping the paths into per-domain segments= and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segments. Hence we are = talking about interface #2 (data model #2) for the service segment manipula= tion;

3. =     A way to monitor, tro= ubleshoot, carry out maintenance of the active e2e services. This would req= uire interface #3 (data model #3) between the client’s controller and= domains VNCs/Hypervisors for this purpose.

=  

So, w= e are talking 3 Yang models with required modifications to neither Netconf/= Restconf, nor   

 = ;To any other management, routing or signaling protocol.<= /p>

=  

Now I= have a couple of questions to you:

1. =     In this example, what= else (in addition to these three models) the client such as TFK in your op= inion would need?

2. =     What else the network= providers and their vendors such as ADVA or CIEN would need?

3. =     What is the importanc= e of a construct such as PNC?

 

My an= swer to 3. “Is not important at all, irrelevant” for the follow= ing reasons:

a) =     What happens beyond t= he VNC/Hypervisor in the provider network is completely proprietary.

b) =     There could be numero= us ways as to how the provider network is managed. Examples: centralized PN= C (as you call it), ADVA style GMPLS based network intelligence, CIEN style= PNNI based control plane, etc. Why is that of ACTN’s business?

=  

Cheer= s,

Igor<= o:p>

=  

From: King, Daniel [mailto:d.king@lancaster.ac.uk]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi All,= including “Ignor” ;-)

&n= bsp;

Typical= dichotomy between what operators want and what vendors are actually willin= g to provide, group consensus will eventually help resolve that. Either way= , the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work)= on the interfaces which are in scope, namely:

&n= bsp;

1. The = CNC-VNC Interface (CVI)

- Creat= e, modify and delete virtual network service instances

- Resou= rce model

&n= bsp;

2. The = VNC-PNC Interface (VPI)

- Mappi= ng of physical and virtual resources

- Reque= sts: path, provision, modify and restore

&n= bsp;

As Youn= g suggests, if the VNC received physical topology info it would be performi= ng the role of the Physical Network Controller (PNC), which is obviously a = (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for A= CTN.

&n= bsp;

Br, Dan= .

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_4003c11315234da8944051d37e30c796ATLSRVMBX1advaopticalco_-- From nobody Sat Oct 11 17:35:59 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 BE41B1A00B7 for ; Sat, 11 Oct 2014 17:35:57 -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 LrUMM9Hh4n6X for ; Sat, 11 Oct 2014 17:35:56 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E58F1A007D for ; Sat, 11 Oct 2014 17:35:54 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn15so6814906igb.15 for ; Sat, 11 Oct 2014 17:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R/LeG/KY/9xdPxjGx8ueTh28figbYFOVDmpc5WwBAok=; b=n3llkvgFkqts68jjwpuwoIvKeboXq1gwhb6VMu+H6hJHSNdQdCEKDk9vj1ZDemqzM2 BPsnXSSJPAfeB4pVxqLOIcnt37o2wvsydw/bBoJZInxqbCfEmsZSM4mEv+z4HlF2MpvG Y2hQjnOtREm7IcJG4Rx/UkaKW873jf6ifPpDywhvaC2NZfoxx5wLCGXl0aQsZeMsTogp tGfL/h3O/cZzzXSkbKOWwzJK965EKh66RiQ61j2iPm3HBzT24ZxuTF/k2FFui7mggEMK 8YjaavqYuvNapZmf649EqPx3rm4SfRrFFzIFnAxIwl5CUsdFeX0h0yAia0ihV8pwQfXg vhfQ== MIME-Version: 1.0 X-Received: by 10.42.188.14 with SMTP id cy14mr26100825icb.52.1413074153857; Sat, 11 Oct 2014 17:35:53 -0700 (PDT) Received: by 10.50.155.134 with HTTP; Sat, 11 Oct 2014 17:35:53 -0700 (PDT) Date: Sat, 11 Oct 2014 19:35:53 -0500 Message-ID: From: Young Lee To: actn@ietf.org Content-Type: multipart/alternative; boundary=20cf301fb8f9fb68e405052ef6dd Archived-At: http://mailarchive.ietf.org/arch/msg/actn/mDQ9VHr4RHyKhFtDTpTXOlCp9ZU Subject: [Actn] ACTN BoF 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: Sun, 12 Oct 2014 00:35:58 -0000 --20cf301fb8f9fb68e405052ef6dd Content-Type: text/plain; charset=UTF-8 Hi All, Here's IETF 91 Preliminary Agenda: https://datatracker.ietf.org/meeting/91/agenda.html ACTN BoF is scheduled from 15:20 to 17:20, November 11 (Tuesday) at Coral 3. Best Regards, Young --20cf301fb8f9fb68e405052ef6dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

Here's IETF 91 P= reliminary Agenda: https://datatracker.ietf.org/meeting/91/agenda.html
<= br>
ACTN BoF is scheduled from 15:20 to 17:20, November 11 (Tuesd= ay) at Coral 3.

Best Regards,
Young


--20cf301fb8f9fb68e405052ef6dd-- From nobody Mon Oct 13 06:15:56 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 D7F031A8A79 for ; Mon, 13 Oct 2014 06:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 fxfoBPdb7Zw0 for ; Mon, 13 Oct 2014 06:15:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA501A8A75 for ; Mon, 13 Oct 2014 06:15:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 41AADE8B183E3; Mon, 13 Oct 2014 13:15:36 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9DDFRdZ004319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 15:15:34 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.228]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 15:15:22 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin , Daniele Ceccarelli , "King, Daniel" , Leeyoung , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYA== Date: Mon, 13 Oct 2014 13:15:21 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F486D546A08FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/4KgRZVtMASzTzzTVEZGua7XZyb8 Cc: "BELOTTI, SERGIO \(SERGIO\)" , "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Mon, 13 Oct 2014 13:15:53 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F486D546A08FR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Please, see in line Regards Sergio From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 22:37 To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); a= ctn@ietf.org; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele, Please, see in line. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 10, 2014 1:25 PM To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ie= tf.org; diego@tid.es; luyuanf@gm= ail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Igor, What do you mean by client here? The one that is the document is called "se= rvice provider" or the one that is called "client" ? From what you send I t= end to think you are talking about the service provider, but I might be wro= ng, please correct me. IB>> By client I mean the client of a transport domain, the one who speaks = Netconf/Restconf to the transport domain. The guy who speaks from the other= end (i.e. on behalf of the transport service provider) is the transport d= omain's Hypervisor. SB>>> It is clear what you intend here, even if word client it seems to me = more related to application than to a service provider. Moreover I would av= oid in this phase to mention any reference to protocol implementation (e.g.= Netconf/Restconf) : I think we are in the phase to understand architecture= , what are the relevant interfaces, and what information is exchanged over = the reference points/interfaces. I guess this is clearly stated also in the= charter of BoF. At an appropriate time - certainly not now - the next ste= p is to check with other SDOs on the availability of relevant core/technolo= gy specific/application specific information model "fragments", and then fi= nally proceed on the path of pruning/refactoring and mapping to REST/JSON, = Netconf/YANG, and any other possible data modeling and configuration protoc= ol existing. This is my understanding of the BoF scope . I don't think the client of the multi-domain network wants to have a so det= ailed view of the network, he does not care about domains, inter domain lin= ks or whatever, I would say he only cares about a given amount of Gbps from= A to B with a given max delay and probably some diversity parameters. IB>> Again, by client I mean multi-domain network controller (e.g. Telefoni= ca SDN controller), not the client using services of the multi-domain netwo= rk (i.e. not the Telefonica clients). Such client uses the transport domai= ns for a reason. "a given amount of Gbps from A to B" is too loose and litt= le for the client to do the network planning. IMO the client needs to *plan= * the abstract topologies provided by the transport domains the same or sim= ilar way as he would plan his own actual topology. SB>>> yes, sure, in you view of "client" , this is the service provider Dan= iele is talking, so an abstract view of what is the real transport network = is considered at this level. As I said to Young, in my previous mail, in th= e case of a single domain scenario VNC and PNC could also coincide but in c= ase of a multi-domain scenarios the scope is to provide to application laye= r a single virtualized view of the underline multi domain network. On the other side, the one that cares about all of the issues you listed is= the service provider (as per actual document terminology). However also th= e service provider does not go into physical impairment details. He cares a= bout connectivity between the borders of the domains, inter domain links. H= ow such connectivity is provisioned/managed is the network provider busines= s. The network provides might be using GMPLS, NMS and ONF controller with O= pen Flow or whatever to control the network. Maybe calling it PNC is confus= ing? The PNC can be any of the things I've listed and much more. IB>> In this case my client is your service provider ;=3D). You architectur= ally separate client from the service provider, because you probably believ= e that it is possible to standardize the interface between the two. I disag= ree with that and don't think ACTN should work on this. In the context of A= CTN I see only two constructs: Transport domain controller (transport servi= ce provider) and Transport client controller (transport service user). SB>>> ACTN here is not reinventing the wheel , in other SDO SDN specific is= considered the application layer , and the interface between AL and SDN c= ontroller (in this case the VNC of ACTN) . This interface permit to any cli= ent to directly impact to his own services and his own "virtualized" resour= ces . Hence the interfaces to be considered are two, not three (as Dan said) I th= ink this replies to questions 1 and 3. Just to add something regarding 2, I= would say that they need just a single entry point to the network control = (could be a small piece of code running on top of the PCE of your GMPLS dom= ain), which acts as an interface between the VNC and the control plane of y= our network and performs: "- Mapping of physical and virtual resources" and= "Requests: path, provision, modify and restore". IB>> As I said, this is the task of the transport domain Hypervisor, whose = role is, essentially, to translate back and forth abstract <=3D> actual top= ology elements and service requests/responses containing the abstract/actua= l topology paths. I think that the north/south interface between the transp= ort domain Hypervisor and the entity representing the client of the transpo= rt domain (no matter how you call it) is the only interface ACTN can work o= n with the hope to produce something useful. Cheers Daniele From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 03:16 To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Young and Dan, It does not matter how you call me, and as John is helpfully applying, you = can ignore what I am saying. But let me explain in some more details what I= meant. Suppose we have a client (such as TFK) of a multi-domain transport network,= who wants to provision and manipulate e2e transport services the way he wa= nts it (i.e. applying his policies). What would such client need? 1. An access to a unified network TE topology that could be understood = and used by the client's path computer to select service e2e paths. How doe= s the client get such a topology? The necessary overlay topology comprises = abstract topologies presented for the client by each of the transport domai= ns + inter-domain TE links. Hence we are talking about interface #1 (and da= ta model #1) between a provider hypervisor/VNC and the client controller to= expose in a unified abstract way its topology on per client/tenant basis= . Furthermore, the client controller can use this interface in the opposite= direction to modify the said abstract topology (subject to the provider's = approval), because the client is the only guy who knows how the abstract t= opology exposed to him should look like to be useful (e.g. which and how th= e abstract links should be disjoint from each other, how many of them shoul= d be provided, their attributes, desired recovery capabilities, etc,). This= knowledge is supposed to come from the client's network planning. 2. A way to provision/modify/delete e2e services with the use of so com= puted e2e paths. The client's controller does that by chopping the paths in= to per-domain segments and instructs respective domain VNCs/Hypervisors to = set up/manipulate service respective connection segments. Hence we are talk= ing about interface #2 (data model #2) for the service segment manipulation= ; 3. A way to monitor, troubleshoot, carry out maintenance of the active = e2e services. This would require interface #3 (data model #3) between the c= lient's controller and domains VNCs/Hypervisors for this purpose. So, we are talking 3 Yang models with required modifications to neither Net= conf/Restconf, nor To any other management, routing or signaling protocol. Now I have a couple of questions to you: 1. In this example, what else (in addition to these three models) the c= lient such as TFK in your opinion would need? 2. What else the network providers and their vendors such as ADVA or CI= EN would need? 3. What is the importance of a construct such as PNC? My answer to 3. "Is not important at all, irrelevant" for the following rea= sons: a) What happens beyond the VNC/Hypervisor in the provider network is co= mpletely proprietary. b) There could be numerous ways as to how the provider network is manag= ed. Examples: centralized PNC (as you call it), ADVA style GMPLS based netw= ork intelligence, CIEN style PNNI based control plane, etc. Why is that of = ACTN's business? Cheers, Igor From: King, Daniel [mailto:d.king@lancaster.ac.uk] Sent: Thursday, October 09, 2014 4:58 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.= com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_B9FEE68CE3A78C41A2B3C67549A96F486D546A08FR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

Please, see in line

 

Regards

Sergio

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: venerd=EC 10 ottobre 2014 22:37
To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SER= GIO); actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Daniele,

Please, see in line.

Igor

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Friday, October 10, 2014 1:25 PM
To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); = actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Igor= ,

&n= bsp;

What do= you mean by client here? The one that is the document is called “ser= vice provider” or the one that is called “client” ? From = what you send I tend to think you are talking about the service provider, but I might be wrong, please correct me.

 

IB>> By client I mean the client of a transport domain, the= one who speaks Netconf/Restconf to the transport domain. The guy who speak= s from the other end (i.e. on behalf of the transport service provider)  is the transport domain’s Hypervis= or.

&n= bsp;

SB>&= gt;> It is clear what you intend here, even if word client it seems to m= e more related to application than to a service provider. Moreover I would = avoid in this phase to mention any reference to protocol implementation (e.g. Netconf/Restconf) : I think we are in the ph= ase to understand architecture, what are the relevant i= nterfaces, and what information is exchanged over the reference points/inte= rfaces. I guess this is clearly stated also in the charter of BoF. &nb= sp;At an appropriate time – certainly not now – the next step is to check with other SDOs on the availability of r= elevant core/technology specific/application specific information model = 220;fragments”, and then finally proceed on the path of pruning/refac= toring and mapping to REST/JSON, Netconf/YANG, and any other possible data modeling and configuration protocol existing. = This is my understanding  of the BoF scope .

&n= bsp;

I don&#= 8217;t think the client of the multi-domain network wants to have a so deta= iled view of the network, he does not care about domains, inter domain link= s or whatever, I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably som= e diversity parameters.

 

IB>> Again, by client I mean multi-domain network controlle= r (e.g. Telefonica SDN controller), not the client using services of the mu= lti-domain network (i.e. not the Telefonica clients). Such client uses  the transport domains for a reason. ̶= 0;a given amount of Gbp= s from A to B” is too loose and little for the client to do the netwo= rk planning. IMO the client needs to *plan* the abstract topologies provided by the transport domains the same or similar = way as he would plan his own actual topology.

&n= bsp;

SB>&= gt;> yes, sure, in you view of “client” , this is the servic= e provider Daniele is talking, so an abstract view of what is the real tran= sport network is considered at this level. As I said to Young, in my previous mail, in the case of a single domain scenario VNC and PNC c= ould also coincide but in case of a multi-domain scenarios the scope is to = provide to application layer a single virtualized view of the underline mul= ti domain network.

&n= bsp;

On the = other side, the one that cares about all of the issues you listed is the se= rvice provider (as per actual document terminology). However also the servi= ce provider does not go into physical impairment details. He cares about connectivity between the borders of the= domains, inter domain links. How such connectivity is provisioned/managed = is the network provider business. The network provides might be using GMPLS= , NMS and ONF controller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing= ? The PNC can be any of the things I’ve listed and much more.

 

IB>> In this case my client is your service provider ;=3D).= You architecturally separate client from the service provider, because you= probably believe that it is possible to standardize the interface between the two. I disagree with that and don’t think = ACTN should work on this. In the context of ACTN I see only two constructs:= Transport domain controller (transport service provider) and  Transpo= rt client controller (transport service user).

&n= bsp;

SB>&= gt;> ACTN here is not reinventing the wheel , in other SDO SDN specific = is considered  the application layer , and the interface between AL an= d SDN controller (in this case the VNC of ACTN) . This interface permit to any client to directly impact to his own services and = his own “virtualized” resources .

&n= bsp;

&n= bsp;

Hence t= he interfaces to be considered are two, not three (as Dan said) I think thi= s replies to questions 1 and 3. Just to add something regarding 2, I would = say that they need just a single entry point to the network control (could be a small piece of code running on to= p of the PCE of your GMPLS domain), which acts as an interface between the = VNC and the control plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests= : path, provision, modify and restore”.

 

IB>> As I said, this is the task of the transport domain Hy= pervisor, whose role is, essentially, to translate back and forth abstract =F3 actual topology elements and service requests/responses conta= ining the abstract/actual topology paths. I think that the north/south interface between the transport domain Hyperv= isor and the entity representing the client of the transport domain (no mat= ter how you call it) is the only interface ACTN can work on with the hope t= o produce something useful.

&n= bsp;

Cheers<= o:p>

Daniele=

&n= bsp;

&n= bsp;

&n= bsp;

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: venerd=EC 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Young and Dan,

 

It does not matter how you call me, and as John is helpfully appl= ying, you can ignore what I am saying. But let me explain in some more deta= ils what I meant.

 

Suppose we have a client (such as TFK) of a multi-domain transpor= t network, who wants to provision and manipulate e2e transport services the= way he wants it (i.e. applying his policies). What would such client need?

 

1.     An acc= ess to a unified network TE topology that could be understood and used by t= he client’s path computer to select service e2e paths. How does the c= lient get such a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of= the transport domains + inter-domain TE links. Hence we are talking ab= out interface #1 (and data model #1) between a provider hypervisor/VNC and = the client controller to expose in a unified abstract  way  its topology on per client/tenant basis. = Furthermore, the client controller can use this interface in the opposite d= irection to modify the said abstract topology (subject to the provider̵= 7;s  approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be = useful (e.g. which and how the abstract links should be disjoint from each = other, how many of them should be provided, their attributes, desired recov= ery capabilities, etc,). This knowledge is supposed to come from the client’s network planning.

2.     A way = to provision/modify/delete e2e services with the use of so computed e2e pat= hs. The client’s controller does that by chopping the paths into per-= domain segments and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segmen= ts. Hence we are talking about interface #2 (data model #2) for the service= segment manipulation;

3.     A way = to monitor, troubleshoot, carry out maintenance of the active e2e services.= This would require interface #3 (data model #3) between the client’s= controller and domains VNCs/Hypervisors for this purpose.

 

So, we are talking 3 Yang models with required modifications to n= either Netconf/Restconf, nor   

 To any other management, routing or signaling protocol.

 

Now I have a couple of questions to you:

1.     In thi= s example, what else (in addition to these three models) the client such as= TFK in your opinion would need?

2.     What e= lse the network providers and their vendors such as ADVA or CIEN would need= ?

3.     What i= s the importance of a construct such as PNC?

 

My answer to 3. “Is not important at all, irrelevant”= for the following reasons:

a)     What h= appens beyond the VNC/Hypervisor in the provider network is completely prop= rietary.

b)     There = could be numerous ways as to how the provider network is managed. Examples:= centralized PNC (as you call it), ADVA style GMPLS based network intellige= nce, CIEN style PNNI based control plane, etc. Why is that of ACTN’s business?

 

Cheers,

Igor

 

From: King, Daniel [mailto:= d.king@lancaster.ac.uk]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi All,= including “Ignor” ;-)

&n= bsp;

Typical= dichotomy between what operators want and what vendors are actually willin= g to provide, group consensus will eventually help resolve that. Either way= , the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work)= on the interfaces which are in scope, namely:

&n= bsp;

1. The = CNC-VNC Interface (CVI)

- Creat= e, modify and delete virtual network service instances

- Resou= rce model

&n= bsp;

2. The = VNC-PNC Interface (VPI)

- Mappi= ng of physical and virtual resources

- Reque= sts: path, provision, modify and restore

&n= bsp;

As Youn= g suggests, if the VNC received physical topology info it would be performi= ng the role of the Physical Network Controller (PNC), which is obviously a = (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for A= CTN.

&n= bsp;

Br, Dan= .

 

From: ACTN [mailto:actn-boun= ces@ietf.org] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Igno= r,

&n= bsp;

Thank y= ou for providing your comment that pauses us to think more and understand o= n the same level. I think your comment will contribute to crystallize the s= cope of work here.

&n= bsp;

First o= f all, I think there was a misunderstanding here. First, your assumption on= VNC receiving actual underlying topology is incorrect. If VNC were to have= actually topology (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect h= as been discussed by email threads Daniele started a few weeks ago. Check t= he archive on that. The reason this is out of scope is that PNC multi-domai= n issue is no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those= areas. What VNC receives from each PNC (domain controller) is an abstracte= d topology with varying degrees from actual underlying topology. The reason= why we distinguish the term VNC from PNC.

&n= bsp;

What ca= n be defined on VNC-PNC is a vertical signaling coordination from VNC to ea= ch PNC. As long as the detailed path computation and signaling within a dom= ain are completely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path co= mputation is based on what is exposed from PNCs to VNC. The actual topology= information details is kept by PNCs and the PNCs expose abstracted topolog= y that can hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of v= irtual links (which may be concatenated actual links) can be exposed for di= versity routing calculation at the VNC. This is very different from exposin= g the actual TE topology. You can view this as two level of path computation. VNC first computes an end-to-e= nd path (using whatever constraint information it has), then coordinates wi= th each PNC (telling the border nodes information), then each PNC computes = the domain specific path. When a PNC cannot provide a path segment in its domain, then this needs to be sig= naled to VNC so that the VNC would arrange an alternate path segment to be = able to find a feasible end-to-end path.  I would say this is a “= ;two-phase” signaling and path computation. The point is that there must be some level of hiding on abstract topology = exposure from PNC to VNC and proprietary characteristics of optical devices= need to be dealt only with the corresponding PNC.

&n= bsp;

Regardi= ng the term PNC vs. ANC, I wouldn’t concern too much about the termin= ology whichever works better. Thank you for your suggestion.

&n= bsp;

Lastly,= please check the use-cases written by operators in the below links that co= nsistently say they need a standard interface that can coordinate their mul= ti-domain issues.

&n= bsp;

http= s://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/

https://datatracker.ietf.org/doc/draft-klee-actn-connectivity= -multi-vendor-domains/

ht= tps://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/<= /o:p>

ht= tps://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/<= /o:p>

ht= tps://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/<= /o:p>

&n= bsp;

Regards= ,

Young

&n= bsp;

Thanks,=

Young

&n= bsp;

&n= bsp;

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Young,

 

I believe having the same instance of VNC talking to different ve= ndor domain PNCs is an extremely  idealistic view.

 

=3D=3D=E8 BTW I find PNC is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a= . a Hypervisor) is managing abstract topologies, and to be able do that, it= talks to a ANC- a controller which has an access and manages actual provid= er network).

 

One reason for this is that VNC needs to understand underlying ac= tual topology, for example, to ensure that two abstract TE links are SRLG d= isjoint as requested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendo= r and contains a great variety of proprietary extensions, failing to unders= tand which leads to producing unprovisionable service paths. Do you really = believe that a single VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to = ask all optical providers to switch to WSON :=3D).

 

This is not to say that you cannot build a hierarchy of VNCs, but= in this case North VNC plays role of a client network controller wrt to So= uth VNC, that is, uses the same X interface.

IHMO whenever a VNC has to talk to a ANC, it does so in a proprie= tary way, i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing= the same north bound interface to potentially the same client (e.g.TFK).

IHMO interface X is the only interface that the ACTN can work on.=

 

Cheers,

Igor

 

From: ACTN [mailto:actn-boun= ces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,

 

thanks = a lot for reply , please see in line just some further clarification

&n= bsp;

Regards=

Sergio<= o:p>

&n= bsp;

 

 

From: Leeyoung [mail= to:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Serg= io,

&n= bsp;

Thanks = for your feedback on the framework document. Please see in-line for my comm= ent.

&n= bsp;

Regards= ,

Young

&n= bsp;

From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all auth= ors,

 

I read you Framework draft and = I have some comments on that. Most are editorial , other questions for clar= ifications.

 

General question: in the draft = the concept of VNC is in the view of hierarchical level of controllers or l= inked to the multi-domain aspect that compel to provide to the customer a s= ingle virtualized network even if composed by real multi-domain multi-technology subnetworks? I mean, the “virt= ualizer function” provided by VNC, in case of a single domain context= could be inside directly the PNC , correct?

 

YOUNG>> Yes. That is the = correct view of VNC. For a single domain context, the VNC can be integrated= with PNC. But we need to factor in other scenarios such as 1) VNC vendor m= ay be different from PNC vendor or 2) VNC is a software function that operator may want to operate as its control. I= n my opinion, even for a single domain, I think there is benefit to define = this interface as a standard interface.

 

Section 2 , page 4: =

abstraction does not imply auto= matically virtualization,while virtualization implies to have surely a cert= ain form of abstraction. I would suggest to consider good definition contai= ned into ONF SDN architecture document chapter 2.3 Conventions about abstraction and virtualization. A good defin= ition can help all the reading.

 

YOUNG>> Agree. We will lo= ok into the mentioned document if the usage of terms are aligned with this = document. If not, we will clarify the terminology more clearly.

 

Section 5: It seems to me you m= ixed here aspects that are more related to policy like admission control &n= bsp;and guarantee of client isolation with real computational issue like Co= mputing time , path constrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager.

 

YOUNG>> Indeed. In Sectio= n 5, we will put some notes on the aspect of real-time related from non rea= l time aspect. VNM is not to be mixed with Virtual Network Manager. Here VN= M is an algorithm which is known as Virtual Network Mapping which is a software module that converts client requests i= nto actual networks. Virtual Network Manager is ABNO in my understanding is= a developed concept from VNTM. But Dan King and I will look at this more c= arefully on this aspect what Virtual Network Manager is doing.

&n= bsp;

SB>&= gt;> If I understood form Adrian and Daniel ABNO draft the concept, VNTM= is strictly related to planning function so I this it is very import point= in the context of PNC , I would say

 

Section 6.1 : while it is clear= the scope of the different control interface presented in figure 5, I̵= 7;m a bit confused as to what I/F E is – data plane interface to prov= ider physical network? Or is the intention to provide what can be the underlying model of resources allocated to a customer from= network provider controller, and the mapping to real physical resources ? = Nor clear to me the intention

 

YOUNG>> Interface E is no= t what ACTN will focus on. It simply shows  an underlying model of res= ources allocated to a customer from network provider controller, and the ma= pping to real physical resources.

&n= bsp;

SB>&= gt;> So if I interpreted correctly your answer is more an internal inter= face to PNC , the figure is misleading since it seems like a DP interface .=

 

Section 6.1, always figure= 5: If a report of potential NW topology between a VNC and a CNC can be que= ried , the arrow in the drawn has to be bidirectional I guess

YOUNG>> Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28= : “PCA abstracts the physical network topology into an abstracted top= ology” Looking at the description of VNC components in 6.2.2 it is th= e resource manager devoting to provide abstract topology. Does not exist any PCA component.

 

Y= OUNG>> Sorry for inconsistency. The intention was the PCA is the same= as the Resource Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In= the picture there is no phase 7, and there are 2 phase 8=

YOUNG>> Thanks. Good catch!

Page 30 : It is Interface = C not B , between VNC and PNC

YOUNG>> If you are ref= erring to Section 7.3 where:

   Interfaces= should also be scalable as a large amount of data needs<= /p>

   to be transport= ed across customers to virtual network controllers

   and across virt= ual network controllers and physical network

   controllers.

 

I think this implies both in= terfaces B and C although primarily between VNC-PNC.

&n= bsp;

SB>&= gt;> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , = on Interface interaction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C=

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_B9FEE68CE3A78C41A2B3C67549A96F486D546A08FR711WXCHMBA05z_-- From nobody Mon Oct 13 07:18:02 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 760AF1A004C for ; Mon, 13 Oct 2014 07:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 wDZ4nqy4Udh6 for ; Mon, 13 Oct 2014 07:17:40 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747681A0010 for ; Mon, 13 Oct 2014 07:17:39 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9DEHRCl007483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 10:17:27 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 13 Oct 2014 10:17:27 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Mon, 13 Oct 2014 10:17:27 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Mon, 13 Oct 2014 10:17:27 -0400 From: Igor Bryskin To: "BELOTTI, SERGIO (SERGIO)" , "Daniele Ceccarelli" , "King, Daniel" , Leeyoung , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQ Date: Mon, 13 Oct 2014 14:17:26 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_d5d45bdf6c444d1e8bf68c6edfeebc7bATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-13_02:2014-10-13,2014-10-13,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/Bqc0LXawF2qFxdX0rg3PTIfFoXI Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Mon, 13 Oct 2014 14:17:51 -0000 --_000_d5d45bdf6c444d1e8bf68c6edfeebc7bATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio, A couple of comments in line. Cheers, Igor From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Monday, October 13, 2014 9:15 AM To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; actn@ietf.org= ; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Igor, Please, see in line Regards Sergio From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 22:37 To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); a= ctn@ietf.org; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele, Please, see in line. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 10, 2014 1:25 PM To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ie= tf.org; diego@tid.es; luyuanf@gm= ail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Igor, What do you mean by client here? The one that is the document is called "se= rvice provider" or the one that is called "client" ? From what you send I t= end to think you are talking about the service provider, but I might be wro= ng, please correct me. IB>> By client I mean the client of a transport domain, the one who speaks = Netconf/Restconf to the transport domain. The guy who speaks from the other= end (i.e. on behalf of the transport service provider) is the transport d= omain's Hypervisor. SB>>> It is clear what you intend here, even if word client it seems to me = more related to application than to a service provider. IB>> I am talking about the interface between transport domain server and = transport domain client. I would argue that the very same interface can be = used between a multi-domain provider (e.g. Telefonika) and its clients. Not= all such clients are dumb, as Daniele claims, and only care about "a given= amount of Gbps from A to B". It is easy to envision that some of the clien= ts would want from Telefonica a couple of SRLG-disjoint abstract links, so = that the clients can have a say in the placement of their services across = the Telefonika network. Three points here: a) The client will be able to configure fully or partially the abstrac= t topology he wants the network to present to him; b) The said abstract topology could be as simple (e.g. a single abstra= ct node) or as complex (e.g. N abstract nodes interconnected by M abstract = links) as the client wants it to be (subject to the provider's approval) c) The abstract topology presented to the client is completely decoupl= ed from the provider's actual topology. Therefore the same interface/set of models can be used between any transpor= t network provider and its client. Furthermore, the interface can be used i= n the hierarchical way, that is, a client of a transport domain can serve i= ts own clients using the same interface as it uses to talk to its own provi= der(s) Moreover I would avoid in this phase to mention any reference to protocol i= mplementation (e.g. Netconf/Restconf) : I think we are in the phase to unde= rstand architecture, what are the relevant interfaces, and what information= is exchanged over the reference points/interfaces. I guess this is clearly= stated also in the charter of BoF. IB>> Agree. I used Netconf/Restconf as an example to make it clear what int= erface I was talking about. At an appropriate time - certainly not now - the next step is to check wit= h other SDOs on the availability of relevant core/technology specific/appli= cation specific information model "fragments", and then finally proceed on = the path of pruning/refactoring and mapping to REST/JSON, Netconf/YANG, and= any other possible data modeling and configuration protocol existing. This= is my understanding of the BoF scope . I don't think the client of the multi-domain network wants to have a so det= ailed view of the network, he does not care about domains, inter domain lin= ks or whatever, I would say he only cares about a given amount of Gbps from= A to B with a given max delay and probably some diversity parameters. IB>> Again, by client I mean multi-domain network controller (e.g. Telefoni= ca SDN controller), not the client using services of the multi-domain netwo= rk (i.e. not the Telefonica clients). Such client uses the transport domai= ns for a reason. "a given amount of Gbps from A to B" is too loose and litt= le for the client to do the network planning. IMO the client needs to *plan= * the abstract topologies provided by the transport domains the same or sim= ilar way as he would plan his own actual topology. SB>>> yes, sure, in you view of "client" , this is the service provider Dan= iele is talking, so an abstract view of what is the real transport network = is considered at this level. As I said to Young, in my previous mail, in th= e case of a single domain scenario VNC and PNC could also coincide but in c= ase of a multi-domain scenarios the scope is to provide to application laye= r a single virtualized view of the underline multi domain network. On the other side, the one that cares about all of the issues you listed is= the service provider (as per actual document terminology). However also th= e service provider does not go into physical impairment details. He cares a= bout connectivity between the borders of the domains, inter domain links. H= ow such connectivity is provisioned/managed is the network provider busines= s. The network provides might be using GMPLS, NMS and ONF controller with O= pen Flow or whatever to control the network. Maybe calling it PNC is confus= ing? The PNC can be any of the things I've listed and much more. IB>> In this case my client is your service provider ;=3D). You architectur= ally separate client from the service provider, because you probably believ= e that it is possible to standardize the interface between the two. I disag= ree with that and don't think ACTN should work on this. In the context of A= CTN I see only two constructs: Transport domain controller (transport servi= ce provider) and Transport client controller (transport service user). SB>>> ACTN here is not reinventing the wheel , in other SDO SDN specific is= considered the application layer , and the interface between AL and SDN c= ontroller (in this case the VNC of ACTN) . This interface permit to any cli= ent to directly impact to his own services and his own "virtualized" resour= ces . Hence the interfaces to be considered are two, not three (as Dan said) I th= ink this replies to questions 1 and 3. Just to add something regarding 2, I= would say that they need just a single entry point to the network control = (could be a small piece of code running on top of the PCE of your GMPLS dom= ain), which acts as an interface between the VNC and the control plane of y= our network and performs: "- Mapping of physical and virtual resources" and= "Requests: path, provision, modify and restore". IB>> As I said, this is the task of the transport domain Hypervisor, whose = role is, essentially, to translate back and forth abstract <=3D> actual top= ology elements and service requests/responses containing the abstract/actua= l topology paths. I think that the north/south interface between the transp= ort domain Hypervisor and the entity representing the client of the transpo= rt domain (no matter how you call it) is the only interface ACTN can work o= n with the hope to produce something useful. Cheers Daniele From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 03:16 To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Young and Dan, It does not matter how you call me, and as John is helpfully applying, you = can ignore what I am saying. But let me explain in some more details what I= meant. Suppose we have a client (such as TFK) of a multi-domain transport network,= who wants to provision and manipulate e2e transport services the way he wa= nts it (i.e. applying his policies). What would such client need? 1. An access to a unified network TE topology that could be understood = and used by the client's path computer to select service e2e paths. How doe= s the client get such a topology? The necessary overlay topology comprises = abstract topologies presented for the client by each of the transport domai= ns + inter-domain TE links. Hence we are talking about interface #1 (and da= ta model #1) between a provider hypervisor/VNC and the client controller to= expose in a unified abstract way its topology on per client/tenant basis= . Furthermore, the client controller can use this interface in the opposite= direction to modify the said abstract topology (subject to the provider's = approval), because the client is the only guy who knows how the abstract t= opology exposed to him should look like to be useful (e.g. which and how th= e abstract links should be disjoint from each other, how many of them shoul= d be provided, their attributes, desired recovery capabilities, etc,). This= knowledge is supposed to come from the client's network planning. 2. A way to provision/modify/delete e2e services with the use of so com= puted e2e paths. The client's controller does that by chopping the paths in= to per-domain segments and instructs respective domain VNCs/Hypervisors to = set up/manipulate service respective connection segments. Hence we are talk= ing about interface #2 (data model #2) for the service segment manipulation= ; 3. A way to monitor, troubleshoot, carry out maintenance of the active = e2e services. This would require interface #3 (data model #3) between the c= lient's controller and domains VNCs/Hypervisors for this purpose. So, we are talking 3 Yang models with required modifications to neither Net= conf/Restconf, nor To any other management, routing or signaling protocol. Now I have a couple of questions to you: 1. In this example, what else (in addition to these three models) the c= lient such as TFK in your opinion would need? 2. What else the network providers and their vendors such as ADVA or CI= EN would need? 3. What is the importance of a construct such as PNC? My answer to 3. "Is not important at all, irrelevant" for the following rea= sons: a) What happens beyond the VNC/Hypervisor in the provider network is co= mpletely proprietary. b) There could be numerous ways as to how the provider network is manag= ed. Examples: centralized PNC (as you call it), ADVA style GMPLS based netw= ork intelligence, CIEN style PNNI based control plane, etc. Why is that of = ACTN's business? Cheers, Igor From: King, Daniel [mailto:d.king@lancaster.ac.uk] Sent: Thursday, October 09, 2014 4:58 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.= com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_d5d45bdf6c444d1e8bf68c6edfeebc7bATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Se= rgio,

A cou= ple of comments in line.

=  

Cheer= s,

Igor<= o:p>

=  

From: BELOTTI, SERGIO (SERGIO) [mailto:sergio= .belotti@alcatel-lucent.com]
Sent: Monday, October 13, 2014 9:15 AM
To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; actn@i= etf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Igor,

 = ;

Please, se= e in line

 = ;

Regards

Sergio

 = ;

 = ;

From: Igor Bryskin [m= ailto:IBryskin@advaoptical.com]
Sent: venerd=EC 10 ottobre 2014 22:37
To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SER= GIO); actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Da= niele,

Pleas= e, see in line.

Igor<= o:p>

=  

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Friday, October 10, 2014 1:25 PM
To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); = actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Igor,

 

What do you mean by cl= ient here? The one that is the document is called “service provider&#= 8221; or the one that is called “client” ? From what you send I= tend to think you are talking about the service provider, but I might be wrong, please correct me.

=  

IB>= ;> By client I mean the client of a transport domain, the one who speaks= Netconf/Restconf to the transport domain. The guy who speaks from the othe= r end (i.e. on behalf of the transport service provider)  is the transport domain’s Hypervisor.

 

SB>>> It is c= lear what you intend here, even if word client it seems to me more related = to application than to a service provider.

=  

IB>>= ; I am talking about the interface between transport domain server and = ; transport domain client. I would argue that the very same interface can b= e used between a multi-domain provider (e.g. Telefonika) and its clients. Not all such clients are dumb, as Daniele claims, and onl= y care about “a given amount of Gbps from A to B”. It is easy to env= ision that some of the clients would want from Telefonica a couple of SRLG-= disjoint abstract links, so that the clients can have a say in the placement of their  services across the Telefonika = network. Three points here:

a) =      T= he client will be able to configure fully or partially the abstract topolog= y he wants the network to present to him;

b) =      T= he said abstract topology could be as simple (e.g. a single abstract node) = or as complex (e.g. N abstract nodes interconnected by M abstract links) as= the client wants it to be (subject to the provider’s approval)

c) =      T= he abstract topology presented to the client is completely decoupled from t= he provider’s actual topology.

&nbs= p;

Therefore= the same interface/set of models can be used between any transport network= provider and its client. Furthermore, the interface can be used in the hie= rarchical way, that is, a client of a transport domain can serve its own clients using the same interface as i= t uses to talk to its own provider(s)

&nbs= p;

Moreover I would avoid= in this phase to mention any reference to protocol implementation (e.g. Ne= tconf/Restconf) : I think we are in the phase to understand architecture, w= hat are the relevant interfaces, and what information is exchanged over the reference points/interfaces. I= guess this is clearly stated also in the charter of BoF.

=  

IB>>= ; Agree. I used Netconf/Restconf as an example to make it clear what interf= ace I was talking about.

&nbs= p;

 At an appropriat= e time – certainly not now – the next step is to check with oth= er SDOs on the availability of relevant core/technology specific/applicatio= n specific information model “fragments”, and then finally proceed on the path of pruning/refactoring and mapping to REST/JSON, Netco= nf/YANG, and any other possible data modeling and configuration protocol ex= isting. This is my understanding  of the BoF scope .=

 

I don’t think th= e client of the multi-domain network wants to have a so detailed view of th= e network, he does not care about domains, inter domain links or whatever, = I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably some diversity par= ameters.

=  

IB>= ;> Again, by client I mean multi-domain network controller (e.g. Telefon= ica SDN controller), not the client using services of the multi-domain netw= ork (i.e. not the Telefonica clients). Such client uses  the transport domains for a reason. “a given amount of Gbps from A to B” is too lo= ose and little for the client to do the network planning. IMO the client ne= eds to *plan* the abstract topologies provided by the transport domains the same or similar way as he would plan his own = actual topology.

 

SB>>> yes, su= re, in you view of “client” , this is the service provider Dani= ele is talking, so an abstract view of what is the real transport network i= s considered at this level. As I said to Young, in my previous mail, in the case of a single domain scenario VNC and PNC could also coinc= ide but in case of a multi-domain scenarios the scope is to provide to appl= ication layer a single virtualized view of the underline multi domain netwo= rk.

 

On the other side, the= one that cares about all of the issues you listed is the service provider = (as per actual document terminology). However also the service provider doe= s not go into physical impairment details. He cares about connectivity between the borders of the domains, inter doma= in links. How such connectivity is provisioned/managed is the network provi= der business. The network provides might be using GMPLS, NMS and ONF contro= ller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing? The PNC can be = any of the things I’ve listed and much more.

=  

IB>= ;> In this case my client is your service provider ;=3D). You architectu= rally separate client from the service provider, because you probably belie= ve that it is possible to standardize the interface between the two. I disagree with that and don’t think ACTN should wo= rk on this. In the context of ACTN I see only two constructs: Transport dom= ain controller (transport service provider) and  Transport client cont= roller (transport service user).

 

SB>>> ACTN he= re is not reinventing the wheel , in other SDO SDN specific is considered &= nbsp;the application layer , and the interface between AL and SDN controlle= r (in this case the VNC of ACTN) . This interface permit to any client to directly impact to his own services and his own &#= 8220;virtualized” resources .

 

 

Hence the interfaces t= o be considered are two, not three (as Dan said) I think this replies to qu= estions 1 and 3. Just to add something regarding 2, I would say that they n= eed just a single entry point to the network control (could be a small piece of code running on top of the PCE = of your GMPLS domain), which acts as an interface between the VNC and the c= ontrol plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests: path, provision, m= odify and restore”.

 

IB>> As I said, this is the task of the transport domain Hy= pervisor, whose role is, essentially, to translate back and forth abstract =F3 actual topology elements and service requests/responses conta= ining the abstract/actual topology paths. I think that the north/south interface between the transport domain Hyperv= isor and the entity representing the client of the transport domain (no mat= ter how you call it) is the only interface ACTN can work on with the hope t= o produce something useful.

&n= bsp;

Cheers<= o:p>

Daniele=

&n= bsp;

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: venerd=EC 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Young= and Dan,

=  

It do= es not matter how you call me, and as John is helpfully applying, you can i= gnore what I am saying. But let me explain in some more details what I mean= t.

=  

Suppo= se we have a client (such as TFK) of a multi-domain transport network, who = wants to provision and manipulate e2e transport services the way he wants i= t (i.e. applying his policies). What would such client need?

=  

1. =     An access to a unifie= d network TE topology that could be understood and used by the client’= ;s path computer to select service e2e paths. How does the client get such = a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of the tran= sport domains + inter-domain TE links. Hence we are talking about inter= face #1 (and data model #1) between a provider hypervisor/VNC and the clien= t controller to expose in a unified abstract  way  its topology on per client/tenant basis. Furtherm= ore, the client controller can use this interface in the opposite direction= to modify the said abstract topology (subject to the provider’s &nbs= p;approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be useful (e.= g. which and how the abstract links should be disjoint from each other, how= many of them should be provided, their attributes, desired recovery capabi= lities, etc,). This knowledge is supposed to come from the client’s network planning.

2. =     A way to provision/mo= dify/delete e2e services with the use of so computed e2e paths. The client&= #8217;s controller does that by chopping the paths into per-domain segments= and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segments. Hence we are = talking about interface #2 (data model #2) for the service segment manipula= tion;

3. =     A way to monitor, tro= ubleshoot, carry out maintenance of the active e2e services. This would req= uire interface #3 (data model #3) between the client’s controller and= domains VNCs/Hypervisors for this purpose.

=  

So, w= e are talking 3 Yang models with required modifications to neither Netconf/= Restconf, nor   

 = ;To any other management, routing or signaling protocol.<= /p>

=  

Now I= have a couple of questions to you:

1. =     In this example, what= else (in addition to these three models) the client such as TFK in your op= inion would need?

2. =     What else the network= providers and their vendors such as ADVA or CIEN would need?

3. =     What is the importanc= e of a construct such as PNC?

 

My an= swer to 3. “Is not important at all, irrelevant” for the follow= ing reasons:

a) =     What happens beyond t= he VNC/Hypervisor in the provider network is completely proprietary.

b) =     There could be numero= us ways as to how the provider network is managed. Examples: centralized PN= C (as you call it), ADVA style GMPLS based network intelligence, CIEN style= PNNI based control plane, etc. Why is that of ACTN’s business?

=  

Cheer= s,

Igor<= o:p>

=  

From: King, Daniel [mailto:d.king@lancaster.ac.uk]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi All,= including “Ignor” ;-)

&n= bsp;

Typical= dichotomy between what operators want and what vendors are actually willin= g to provide, group consensus will eventually help resolve that. Either way= , the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work)= on the interfaces which are in scope, namely:

&n= bsp;

1. The = CNC-VNC Interface (CVI)

- Creat= e, modify and delete virtual network service instances

- Resou= rce model

&n= bsp;

2. The = VNC-PNC Interface (VPI)

- Mappi= ng of physical and virtual resources

- Reque= sts: path, provision, modify and restore

&n= bsp;

As Youn= g suggests, if the VNC received physical topology info it would be performi= ng the role of the Physical Network Controller (PNC), which is obviously a = (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for A= CTN.

&n= bsp;

Br, Dan= .

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_d5d45bdf6c444d1e8bf68c6edfeebc7bATLSRVMBX1advaopticalco_-- From nobody Mon Oct 13 14:12:46 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 D5BC91A0041 for ; Mon, 13 Oct 2014 14:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 f3U9aTZo9WpD for ; Mon, 13 Oct 2014 14:12:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79461A005C for ; Mon, 13 Oct 2014 14:12:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP43413; Mon, 13 Oct 2014 21:12:24 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Oct 2014 22:12:22 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 13 Oct 2014 14:12:11 -0700 From: Leeyoung To: Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" , Daniele Ceccarelli , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GA= Date: Mon, 13 Oct 2014 21:12:10 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.247] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C3DB7Edfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/h37NPbJJxxuWeKh58vn_00HT2VE Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Mon, 13 Oct 2014 21:12:43 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3DB7Edfweml706chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, After all we are agreeing with the interfaces of ACTN interest are Interfac= e B and C, right? IB>> I am talking about the interface between transport domain server and = transport domain client. I would argue that the very same interface can be = used between a multi-domain provider (e.g. Telefonika) and its clients. Not= all such clients are dumb, as Daniele claims, and only care about "a given= amount of Gbps from A to B". It is easy to envision that some of the clien= ts would want from Telefonica a couple of SRLG-disjoint abstract links, so = that the clients can have a say in the placement of their services across = the Telefonika network. Three points here: a) The client will be able to configure fully or partially the abstrac= t topology he wants the network to present to him; b) The said abstract topology could be as simple (e.g. a single abstra= ct node) or as complex (e.g. N abstract nodes interconnected by M abstract = links) as the client wants it to be (subject to the provider's approval) c) The abstract topology presented to the client is completely decoupl= ed from the provider's actual topology. Therefore the same interface/set of models can be used between any transpor= t network provider and its client. Furthermore, the interface can be used i= n the hierarchical way, that is, a client of a transport domain can serve i= ts own clients using the same interface as it uses to talk to its own provi= der(s) Here I would like to give you a little clearer picture on multi-domain issu= es. +----------------+ +---------------+ +--------------+ | Customer 1 | | Customer 2 | ... | Customer M | +----------------+ +---------------+ +--------------+ \ | / \ | / Interface B \ | / \ | / +----------------------+ | VNC Multi-domain | E2E abstract | Coordination | topology creation +----------------------+ / | \ Interface C / | \ Network Topology / | \ (abstract) / | \ +------------------+ +------------------+ +------------------+ | Network Domain 1 | | Network Domain 2 | .. | Network Domain N | +------------------+ +------------------+ +------------------+ Vendor X Vendor Y Vendor Z What is sitting above "VNC" (that coordinates over multi-domain controllers= ) can be an internal service organization (of the same operator) or service= providers (different operators, forming carriers of carrier). The control = entity of these entities is referred to as Customer Network control (CNC). = The VNC -CNC interface (Interface B) has different requirements than the VN= C-PNC interface (Interface C). Topology abstraction is just one of the requ= irements and in multi-domain case, the VNC is performing multi-domain coord= ination function. VNC needs to have a standard interface that enable commun= ications with different kinds of domain network control/management control = (which is referred to as PNC, you call ANC). Each domain has its own ways o= f controlling its network, which ACTN is not touching those at all. Whateve= r the choices of vendor control regime will continue to be employed (GMPLS/= ASON, PNNI, NMS, OpenFlow, etc.). For this multi-domain coordination function assumed by VNC should be operat= ed on an abstract level. We don't want to inject the same level of actual n= etwork topology (e.g., TED) as the domain controller operates its physical/= actual networks. Is this agreeable? You said above this in c) The abstract = topology presented to the client is completely decoupled from the provider'= s actual topology. Now the VNC (multi-domain coordinator) needs to coordinate signaling across= multi-domain controllers (in terms of the sequence of the end-to-end path = across multiple domains). This is a new element I believe ACTN will have to= develop. This interface C (VNC-PNC) is very different from Interface B (CN= C-VNC). There are other differences (please see Section 6.5 of the framewor= k document). But I agree with you that from an abstract topology standpoin= t, similar model works for Interfaces B and C as you said b) The said= abstract topology could be as simple (e.g. a single abstract node) or as c= omplex (e.g. N abstract nodes interconnected by M abstract links) as the cl= ient wants it to be (subject to the provider's approval). Best regards, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, October 13, 2014 9:17 AM To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; Leeyoung; a= ctn@ietf.org; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, A couple of comments in line. Cheers, Igor From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Monday, October 13, 2014 9:15 AM To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; actn@ietf.org= ; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Igor, Please, see in line Regards Sergio From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 22:37 To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); a= ctn@ietf.org; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele, Please, see in line. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 10, 2014 1:25 PM To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ie= tf.org; diego@tid.es; luyuanf@gm= ail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Igor, What do you mean by client here? The one that is the document is called "se= rvice provider" or the one that is called "client" ? From what you send I t= end to think you are talking about the service provider, but I might be wro= ng, please correct me. IB>> By client I mean the client of a transport domain, the one who speaks = Netconf/Restconf to the transport domain. The guy who speaks from the other= end (i.e. on behalf of the transport service provider) is the transport d= omain's Hypervisor. SB>>> It is clear what you intend here, even if word client it seems to me = more related to application than to a service provider. IB>> I am talking about the interface between transport domain server and = transport domain client. I would argue that the very same interface can be = used between a multi-domain provider (e.g. Telefonika) and its clients. Not= all such clients are dumb, as Daniele claims, and only care about "a given= amount of Gbps from A to B". It is easy to envision that some of the clien= ts would want from Telefonica a couple of SRLG-disjoint abstract links, so = that the clients can have a say in the placement of their services across = the Telefonika network. Three points here: a) The client will be able to configure fully or partially the abstrac= t topology he wants the network to present to him; b) The said abstract topology could be as simple (e.g. a single abstra= ct node) or as complex (e.g. N abstract nodes interconnected by M abstract = links) as the client wants it to be (subject to the provider's approval) c) The abstract topology presented to the client is completely decoupl= ed from the provider's actual topology. Therefore the same interface/set of models can be used between any transpor= t network provider and its client. Furthermore, the interface can be used i= n the hierarchical way, that is, a client of a transport domain can serve i= ts own clients using the same interface as it uses to talk to its own provi= der(s) Moreover I would avoid in this phase to mention any reference to protocol i= mplementation (e.g. Netconf/Restconf) : I think we are in the phase to unde= rstand architecture, what are the relevant interfaces, and what information= is exchanged over the reference points/interfaces. I guess this is clearly= stated also in the charter of BoF. IB>> Agree. I used Netconf/Restconf as an example to make it clear what int= erface I was talking about. At an appropriate time - certainly not now - the next step is to check wit= h other SDOs on the availability of relevant core/technology specific/appli= cation specific information model "fragments", and then finally proceed on = the path of pruning/refactoring and mapping to REST/JSON, Netconf/YANG, and= any other possible data modeling and configuration protocol existing. This= is my understanding of the BoF scope . I don't think the client of the multi-domain network wants to have a so det= ailed view of the network, he does not care about domains, inter domain lin= ks or whatever, I would say he only cares about a given amount of Gbps from= A to B with a given max delay and probably some diversity parameters. IB>> Again, by client I mean multi-domain network controller (e.g. Telefoni= ca SDN controller), not the client using services of the multi-domain netwo= rk (i.e. not the Telefonica clients). Such client uses the transport domai= ns for a reason. "a given amount of Gbps from A to B" is too loose and litt= le for the client to do the network planning. IMO the client needs to *plan= * the abstract topologies provided by the transport domains the same or sim= ilar way as he would plan his own actual topology. SB>>> yes, sure, in you view of "client" , this is the service provider Dan= iele is talking, so an abstract view of what is the real transport network = is considered at this level. As I said to Young, in my previous mail, in th= e case of a single domain scenario VNC and PNC could also coincide but in c= ase of a multi-domain scenarios the scope is to provide to application laye= r a single virtualized view of the underline multi domain network. On the other side, the one that cares about all of the issues you listed is= the service provider (as per actual document terminology). However also th= e service provider does not go into physical impairment details. He cares a= bout connectivity between the borders of the domains, inter domain links. H= ow such connectivity is provisioned/managed is the network provider busines= s. The network provides might be using GMPLS, NMS and ONF controller with O= pen Flow or whatever to control the network. Maybe calling it PNC is confus= ing? The PNC can be any of the things I've listed and much more. IB>> In this case my client is your service provider ;=3D). You architectur= ally separate client from the service provider, because you probably believ= e that it is possible to standardize the interface between the two. I disag= ree with that and don't think ACTN should work on this. In the context of A= CTN I see only two constructs: Transport domain controller (transport servi= ce provider) and Transport client controller (transport service user). SB>>> ACTN here is not reinventing the wheel , in other SDO SDN specific is= considered the application layer , and the interface between AL and SDN c= ontroller (in this case the VNC of ACTN) . This interface permit to any cli= ent to directly impact to his own services and his own "virtualized" resour= ces . Hence the interfaces to be considered are two, not three (as Dan said) I th= ink this replies to questions 1 and 3. Just to add something regarding 2, I= would say that they need just a single entry point to the network control = (could be a small piece of code running on top of the PCE of your GMPLS dom= ain), which acts as an interface between the VNC and the control plane of y= our network and performs: "- Mapping of physical and virtual resources" and= "Requests: path, provision, modify and restore". IB>> As I said, this is the task of the transport domain Hypervisor, whose = role is, essentially, to translate back and forth abstract <=3D> actual top= ology elements and service requests/responses containing the abstract/actua= l topology paths. I think that the north/south interface between the transp= ort domain Hypervisor and the entity representing the client of the transpo= rt domain (no matter how you call it) is the only interface ACTN can work o= n with the hope to produce something useful. Cheers Daniele From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: venerd=EC 10 ottobre 2014 03:16 To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Young and Dan, It does not matter how you call me, and as John is helpfully applying, you = can ignore what I am saying. But let me explain in some more details what I= meant. Suppose we have a client (such as TFK) of a multi-domain transport network,= who wants to provision and manipulate e2e transport services the way he wa= nts it (i.e. applying his policies). What would such client need? 1. An access to a unified network TE topology that could be understood = and used by the client's path computer to select service e2e paths. How doe= s the client get such a topology? The necessary overlay topology comprises = abstract topologies presented for the client by each of the transport domai= ns + inter-domain TE links. Hence we are talking about interface #1 (and da= ta model #1) between a provider hypervisor/VNC and the client controller to= expose in a unified abstract way its topology on per client/tenant basis= . Furthermore, the client controller can use this interface in the opposite= direction to modify the said abstract topology (subject to the provider's = approval), because the client is the only guy who knows how the abstract t= opology exposed to him should look like to be useful (e.g. which and how th= e abstract links should be disjoint from each other, how many of them shoul= d be provided, their attributes, desired recovery capabilities, etc,). This= knowledge is supposed to come from the client's network planning. 2. A way to provision/modify/delete e2e services with the use of so com= puted e2e paths. The client's controller does that by chopping the paths in= to per-domain segments and instructs respective domain VNCs/Hypervisors to = set up/manipulate service respective connection segments. Hence we are talk= ing about interface #2 (data model #2) for the service segment manipulation= ; 3. A way to monitor, troubleshoot, carry out maintenance of the active = e2e services. This would require interface #3 (data model #3) between the c= lient's controller and domains VNCs/Hypervisors for this purpose. So, we are talking 3 Yang models with required modifications to neither Net= conf/Restconf, nor To any other management, routing or signaling protocol. Now I have a couple of questions to you: 1. In this example, what else (in addition to these three models) the c= lient such as TFK in your opinion would need? 2. What else the network providers and their vendors such as ADVA or CI= EN would need? 3. What is the importance of a construct such as PNC? My answer to 3. "Is not important at all, irrelevant" for the following rea= sons: a) What happens beyond the VNC/Hypervisor in the provider network is co= mpletely proprietary. b) There could be numerous ways as to how the provider network is manag= ed. Examples: centralized PNC (as you call it), ADVA style GMPLS based netw= ork intelligence, CIEN style PNNI based control plane, etc. Why is that of = ACTN's business? Cheers, Igor From: King, Daniel [mailto:d.king@lancaster.ac.uk] Sent: Thursday, October 09, 2014 4:58 PM To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyu= anf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi All, including "Ignor" ;-) Typical dichotomy between what operators want and what vendors are actually= willing to provide, group consensus will eventually help resolve that. Eit= her way, the latest version of the Framework I-D is trying to focus ACTN di= scussion and scope (i.e., the protocol work) on the interfaces which are in= scope, namely: 1. The CNC-VNC Interface (CVI) - Create, modify and delete virtual network service instances - Resource model 2. The VNC-PNC Interface (VPI) - Mapping of physical and virtual resources - Requests: path, provision, modify and restore As Young suggests, if the VNC received physical topology info it would be p= erforming the role of the Physical Network Controller (PNC), which is obvio= usly a (somehow) required function, but the interface (direct provisioning = of the actual physical network) is out of scope for ACTN. Br, Dan. From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 09 October 2014 21:32 To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.= com Cc: Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Ignor, Thank you for providing your comment that pauses us to think more and under= stand on the same level. I think your comment will contribute to crystalliz= e the scope of work here. First of all, I think there was a misunderstanding here. First, your assump= tion on VNC receiving actual underlying topology is incorrect. If VNC were = to have actually topology (e.g. TED) of a network, this would be called a P= NC and this is out of scope of ACTN. This aspect has been discussed by emai= l threads Daniele started a few weeks ago. Check the archive on that. The r= eason this is out of scope is that PNC multi-domain issue is no different f= rom today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not st= ep on those areas. What VNC receives from each PNC (domain controller) is a= n abstracted topology with varying degrees from actual underlying topology.= The reason why we distinguish the term VNC from PNC. What can be defined on VNC-PNC is a vertical signaling coordination from VN= C to each PNC. As long as the detailed path computation and signaling withi= n a domain are completely up to the domain PNC. VNC is not to be operated o= n the same level as PNC. Its end-to-end path computation is based on what i= s exposed from PNCs to VNC. The actual topology information details is kept= by PNCs and the PNCs expose abstracted topology that can hide the exact de= tails while exposing a minimum level of constraints. For instance, the SRLG= of virtual links (which may be concatenated actual links) can be exposed f= or diversity routing calculation at the VNC. This is very different from ex= posing the actual TE topology. You can view this as two level of path compu= tation. VNC first computes an end-to-end path (using whatever constraint in= formation it has), then coordinates with each PNC (telling the border nodes= information), then each PNC computes the domain specific path. When a PNC = cannot provide a path segment in its domain, then this needs to be signaled= to VNC so that the VNC would arrange an alternate path segment to be able = to find a feasible end-to-end path. I would say this is a "two-phase" sign= aling and path computation. The point is that there must be some level of h= iding on abstract topology exposure from PNC to VNC and proprietary charact= eristics of optical devices need to be dealt only with the corresponding PN= C. Regarding the term PNC vs. ANC, I wouldn't concern too much about the termi= nology whichever works better. Thank you for your suggestion. Lastly, please check the use-cases written by operators in the below links = that consistently say they need a standard interface that can coordinate th= eir multi-domain issues. https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ Regards, Young Thanks, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, October 09, 2014 1:48 PM To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org= ; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com<= mailto:luyuanf@gmail.com> Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Young, I believe having the same instance of VNC talking to different vendor domai= n PNCs is an extremely idealistic view. =3D=3D=3D=3D> BTW I find PNC is a bad term, I like much better Actual Netwo= rk Controller (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topolo= gies, and to be able do that, it talks to a ANC- a controller which has an = access and manages actual provider network). One reason for this is that VNC needs to understand underlying actual topol= ogy, for example, to ensure that two abstract TE links are SRLG disjoint as= requested. Actual topology semantics (especially in WDM layer) is very dif= ferent from vendor to vendor and contains a great variety of proprietary ex= tensions, failing to understand which leads to producing unprovisionable se= rvice paths. Do you really believe that a single VNC can talk in the same w= ay to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optica= l providers to switch to WSON :=3D). This is not to say that you cannot build a hierarchy of VNCs, but in this c= ase North VNC plays role of a client network controller wrt to South VNC, t= hat is, uses the same X interface. IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, = i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same = north bound interface to potentially the same client (e.g.TFK). IHMO interface X is the only interface that the ACTN can work on. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SER= GIO) Sent: Thursday, October 09, 2014 5:59 AM To: Leeyoung; actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments Hi Young, thanks a lot for reply , please see in line just some further clarification Regards Sergio From: Leeyoung [mailto:leeyoung@huawei.com] Sent: mercoled=EC 8 ottobre 2014 17:35 To: BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele = Ceccarelli; diego@tid.es; luyuanf@gmail.com Cc: Varma, Eve L (Eve) Subject: RE: draft-ceccarelli-actn-framework-03.txt comments Hi Sergio, Thanks for your feedback on the framework document. Please see in-line for = my comment. Regards, Young From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, October 08, 2014 7:34 AM To: actn@ietf.org; Daniele Ceccarelli; Leeyoung; dieg= o@tid.es; luyuanf@gmail.com Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: draft-ceccarelli-actn-framework-03.txt comments Hi Daniele , Young and all authors, I read you Framework draft and I have some comments on that. Most are edito= rial , other questions for clarifications. General question: in the draft the concept of VNC is in the view of hierarc= hical level of controllers or linked to the multi-domain aspect that compel= to provide to the customer a single virtualized network even if composed b= y real multi-domain multi-technology subnetworks? I mean, the "virtualizer = function" provided by VNC, in case of a single domain context could be insi= de directly the PNC , correct? YOUNG>> Yes. That is the correct view of VNC. For a single domain context, = the VNC can be integrated with PNC. But we need to factor in other scenario= s such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a sof= tware function that operator may want to operate as its control. In my opin= ion, even for a single domain, I think there is benefit to define this inte= rface as a standard interface. Section 2 , page 4: abstraction does not imply automatically virtualization,while virtualizatio= n implies to have surely a certain form of abstraction. I would suggest to = consider good definition contained into ONF SDN architecture document chapt= er 2.3 Conventions about abstraction and virtualization. A good definition = can help all the reading. YOUNG>> Agree. We will look into the mentioned document if the usage of ter= ms are aligned with this document. If not, we will clarify the terminology = more clearly. Section 5: It seems to me you mixed here aspects that are more related to p= olicy like admission control and guarantee of client isolation with real c= omputational issue like Computing time , path constrains or re-optimization= process. Moreover the term VNM for Virtual network mapping is a bit mislea= ding since this term in already used e.g. in ABNO architecture for Virtual = Network Manager. YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-= time related from non real time aspect. VNM is not to be mixed with Virtual= Network Manager. Here VNM is an algorithm which is known as Virtual Networ= k Mapping which is a software module that converts client requests into act= ual networks. Virtual Network Manager is ABNO in my understanding is a deve= loped concept from VNTM. But Dan King and I will look at this more carefull= y on this aspect what Virtual Network Manager is doing. SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM i= s strictly related to planning function so I this it is very import point i= n the context of PNC , I would say Section 6.1 : while it is clear the scope of the different control interfac= e presented in figure 5, I'm a bit confused as to what I/F E is - data plan= e interface to provider physical network? Or is the intention to provide wh= at can be the underlying model of resources allocated to a customer from ne= twork provider controller, and the mapping to real physical resources ? Nor= clear to me the intention YOUNG>> Interface E is not what ACTN will focus on. It simply shows an und= erlying model of resources allocated to a customer from network provider co= ntroller, and the mapping to real physical resources. SB>>> So if I interpreted correctly your answer is more an internal interfa= ce to PNC , the figure is misleading since it seems like a DP interface . Section 6.1, always figure 5: If a report of potential NW topology between = a VNC and a CNC can be queried , the arrow in the drawn has to be bidirecti= onal I guess YOUNG>> Yes, You are right. It will be fixed. Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology = into an abstracted topology" Looking at the description of VNC components i= n 6.2.2 it is the resource manager devoting to provide abstract topology. D= oes not exist any PCA component. YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as t= he Resource Manager in VNC. Will make the term consistent. Good catch! Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2= phase 8 YOUNG>> Thanks. Good catch! Page 30 : It is Interface C not B , between VNC and PNC YOUNG>> If you are referring to Section 7.3 where: Interfaces should also be scalable as a large amount of data needs to be transported across customers to virtual network controllers and across virtual network controllers and physical network controllers. I think this implies both interfaces B and C although primarily between VNC= -PNC. SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on= Interface interaction, after point 6, is indicated Interface B as interfac= e between VNC and PNC, figure 5 says it is I/F C Thanks Sergio Thanks Sergio --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3DB7Edfweml706chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

After all we are agree= ing with the interfaces of ACTN interest are Interface B and C, right?

 

IB>>= ; I am talking about the interface between transport domain server and = ; transport domain client. I would argue that the very same interface can b= e used between a multi-domain provider (e.g. Telefonika) and its clients. Not all such clients are dumb, as Daniele claims, and onl= y care about “a given amount of Gbps= from A to B”. It is easy to envision that some of the clients would = want from Telefonica a couple of SRLG-disjoint abstract links, so that the clients can have a say in the placement of the= ir  services across the Telefonika network. Three points here:

a)      The client will be able t= o configure fully or partially the abstract topology he wants the network t= o present to him;

b)      The said abstract topolog= y could be as simple (e.g. a single abstract node) or as complex (e.g. N ab= stract nodes interconnected by M abstract links) as the client wants it to = be (subject to the provider’s approval)

c)      The abstract topology pre= sented to the client is completely decoupled from the provider’s actu= al topology.

&nbs= p;

Therefore= the same interface/set of models can be used between any transport network= provider and its client. Furthermore, the interface can be used in the hie= rarchical way, that is, a client of a transport domain can serve its own clients using the same interface as i= t uses to talk to its own provider(s)

 

Here I would like to g= ive you a little clearer picture on multi-domain issues.

 

   +----------------+   +----= -----------+      +--------------+

   |   Customer 1   | &nbs= p; |   Customer 2  |  ... | Customer M   |

   +----------------+   +----= -----------+      +--------------+

          &= nbsp;        \    &n= bsp;        |    &nb= sp;         /

          &= nbsp;         \   &n= bsp;        |    &nb= sp;        /  

       Interface B &n= bsp; \           | &= nbsp;          /  &n= bsp;

          &= nbsp;           \&nb= sp;         |   &nbs= p;       /    

          &= nbsp;           += ;----------------------+

          &= nbsp;           |  &= nbsp;VNC Multi-domain   | E2E abstract

          &= nbsp;           | &n= bsp;    Coordination    | topology creation

          &= nbsp;           +----= ------------------+

          &= nbsp;            /&n= bsp;        |    &nb= sp;       \

        Interface C &= nbsp; /          |  =            \  Networ= k Topology

          &= nbsp;          /  &n= bsp;        |    &nb= sp;         \ (abstract)=

           =          /   &n= bsp;        |    &nb= sp;          \

   +------------------+   +--= ----------------+    +------------------+

   | Network Domain 1 |   | Network Domai= n 2 | .. | Network Domain N |

   +------------------+   +--= ----------------+    +------------------+

        Vendor X &nbs= p;            &= nbsp;  Vendor Y         &= nbsp;     Vendor Z

 

 

What is sitting above = “VNC” (that coordinates over multi-domain controllers) can be a= n internal service organization (of the same operator) or service providers= (different operators, forming carriers of carrier). The control entity of these entities is referred to as Customer Network co= ntrol (CNC). The VNC –CNC interface (Interface B) has different requi= rements than the VNC-PNC interface (Interface C). Topology abstraction is j= ust one of the requirements and in multi-domain case, the VNC is performing multi-domain coordination function. VNC needs = to have a standard interface that enable communications with different kind= s of domain network control/management control (which is referred to as PNC= , you call ANC). Each domain has its own ways of controlling its network, which ACTN is not touching those = at all. Whatever the choices of vendor control regime will continue to be e= mployed (GMPLS/ASON, PNNI, NMS, OpenFlow, etc.).

 

For this multi-domain = coordination function assumed by VNC should be operated on an abstract leve= l. We don’t want to inject the same level of actual network topology = (e.g., TED) as the domain controller operates its physical/actual networks. Is this agreeable? You said above this in c)= The abstract topology presented = to the client is completely decoupled from the provider’s actual topo= logy.

 

Now the VNC (multi-dom= ain coordinator) needs to coordinate signaling across multi-domain controll= ers (in terms of the sequence of the end-to-end path across multiple domain= s). This is a new element I believe ACTN will have to develop. This interface C (VNC-PNC) is very different fr= om Interface B (CNC-VNC). There are other differences (please see Section 6= .5 of the framework document).  But I agree with you that from an abst= ract topology standpoint, similar model works for Interfaces B and C as you said  b)      The said abstract topolog= y could be as simple (e.g. a single abstract node) or as complex (e.g. N ab= stract nodes interconnected by M abstract links) as the client wants it to = be (subject to the provider’s approval).

&nbs= p;

Best regards,

Young

 

 

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Monday, October 13, 2014 9:17 AM
To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; Leey= oung; actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Se= rgio,

A cou= ple of comments in line.

=  

Cheer= s,

Igor<= o:p>

=  

From: BELOTTI, SERGIO (SERGIO) [mailto:sergio= .belotti@alcatel-lucent.com]
Sent: Monday, October 13, 2014 9:15 AM
To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; actn@i= etf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Igor,

 = ;

Please, se= e in line

 = ;

Regards

Sergio

 = ;

 = ;

From: Igor Bryskin [m= ailto:IBryskin@advaoptical.com]
Sent: venerd=EC 10 ottobre 2014 22:37
To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SER= GIO); actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Da= niele,

Pleas= e, see in line.

Igor<= o:p>

=  

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Friday, October 10, 2014 1:25 PM
To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); = actn@ietf.org; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Igor,

 

What do you mean by cl= ient here? The one that is the document is called “service provider&#= 8221; or the one that is called “client” ? From what you send I= tend to think you are talking about the service provider, but I might be wrong, please correct me.

=  

IB>= ;> By client I mean the client of a transport domain, the one who speaks= Netconf/Restconf to the transport domain. The guy who speaks from the othe= r end (i.e. on behalf of the transport service provider)  is the transport domain’s Hypervisor.

 

SB>>> It is c= lear what you intend here, even if word client it seems to me more related = to application than to a service provider.

=  

IB>>= ; I am talking about the interface between transport domain server and = ; transport domain client. I would argue that the very same interface can b= e used between a multi-domain provider (e.g. Telefonika) and its clients. Not all such clients are dumb, as Daniele claims, and onl= y care about “a given amount of Gbps= from A to B”. It is easy to envision that some of the clients would = want from Telefonica a couple of SRLG-disjoint abstract links, so that the clients can have a say in the placement of the= ir  services across the Telefonika network. Three points here:

a)      The client will be able t= o configure fully or partially the abstract topology he wants the network t= o present to him;

b)      The said abstract topolog= y could be as simple (e.g. a single abstract node) or as complex (e.g. N ab= stract nodes interconnected by M abstract links) as the client wants it to = be (subject to the provider’s approval)

c)      The abstract topology pre= sented to the client is completely decoupled from the provider’s actu= al topology.

&nbs= p;

Therefore= the same interface/set of models can be used between any transport network= provider and its client. Furthermore, the interface can be used in the hie= rarchical way, that is, a client of a transport domain can serve its own clients using the same interface as i= t uses to talk to its own provider(s)

&nbs= p;

Moreover I would avoid= in this phase to mention any reference to protocol implementation (e.g. Ne= tconf/Restconf) : I think we are in the phase to understand architecture, w= hat are the relevant interfaces, and what information is exchanged over the reference points/interfaces. I= guess this is clearly stated also in the charter of BoF.

=  

IB>>= ; Agree. I used Netconf/Restconf as an example to make it clear what interf= ace I was talking about.

&nbs= p;

 At an appropriat= e time – certainly not now – the next step is to check with oth= er SDOs on the availability of relevant core/technology specific/applicatio= n specific information model “fragments”, and then finally proceed on the path of pruning/refactoring and mapping to REST/JSON, Netco= nf/YANG, and any other possible data modeling and configuration protocol ex= isting. This is my understanding  of the BoF scope .=

 

I don’t think th= e client of the multi-domain network wants to have a so detailed view of th= e network, he does not care about domains, inter domain links or whatever, = I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably some diversity par= ameters.

=  

IB>= ;> Again, by client I mean multi-domain network controller (e.g. Telefon= ica SDN controller), not the client using services of the multi-domain netw= ork (i.e. not the Telefonica clients). Such client uses  the transport domains for a reason. “a given amount of Gbps from A to B” is too lo= ose and little for the client to do the network planning. IMO the client ne= eds to *plan* the abstract topologies provided by the transport domains the same or similar way as he would plan his own = actual topology.

 

SB>>> yes, su= re, in you view of “client” , this is the service provider Dani= ele is talking, so an abstract view of what is the real transport network i= s considered at this level. As I said to Young, in my previous mail, in the case of a single domain scenario VNC and PNC could also coinc= ide but in case of a multi-domain scenarios the scope is to provide to appl= ication layer a single virtualized view of the underline multi domain netwo= rk.

 

On the other side, the= one that cares about all of the issues you listed is the service provider = (as per actual document terminology). However also the service provider doe= s not go into physical impairment details. He cares about connectivity between the borders of the domains, inter doma= in links. How such connectivity is provisioned/managed is the network provi= der business. The network provides might be using GMPLS, NMS and ONF contro= ller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing? The PNC can be = any of the things I’ve listed and much more.

=  

IB>= ;> In this case my client is your service provider ;=3D). You architectu= rally separate client from the service provider, because you probably belie= ve that it is possible to standardize the interface between the two. I disagree with that and don’t think ACTN should wo= rk on this. In the context of ACTN I see only two constructs: Transport dom= ain controller (transport service provider) and  Transport client cont= roller (transport service user).

 

SB>>> ACTN he= re is not reinventing the wheel , in other SDO SDN specific is considered &= nbsp;the application layer , and the interface between AL and SDN controlle= r (in this case the VNC of ACTN) . This interface permit to any client to directly impact to his own services and his own &#= 8220;virtualized” resources .

 

 

Hence the interfaces t= o be considered are two, not three (as Dan said) I think this replies to qu= estions 1 and 3. Just to add something regarding 2, I would say that they n= eed just a single entry point to the network control (could be a small piece of code running on top of the PCE = of your GMPLS domain), which acts as an interface between the VNC and the c= ontrol plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests: path, provision, m= odify and restore”.

 

IB>> As I said, this is the task of the transport domain Hy= pervisor, whose role is, essentially, to translate back and forth abstract =F3 actual topology elements and service requests/responses conta= ining the abstract/actual topology paths. I think that the north/south interface between the transport domain Hyperv= isor and the entity representing the client of the transport domain (no mat= ter how you call it) is the only interface ACTN can work on with the hope t= o produce something useful.

&n= bsp;

Cheers<= o:p>

Daniele=

&n= bsp;

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: venerd=EC 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Young= and Dan,

=  

It do= es not matter how you call me, and as John is helpfully applying, you can i= gnore what I am saying. But let me explain in some more details what I mean= t.

=  

Suppo= se we have a client (such as TFK) of a multi-domain transport network, who = wants to provision and manipulate e2e transport services the way he wants i= t (i.e. applying his policies). What would such client need?

=  

1. =     An access to a unifie= d network TE topology that could be understood and used by the client’= ;s path computer to select service e2e paths. How does the client get such = a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of the tran= sport domains + inter-domain TE links. Hence we are talking about inter= face #1 (and data model #1) between a provider hypervisor/VNC and the clien= t controller to expose in a unified abstract  way  its topology on per client/tenant basis. Furtherm= ore, the client controller can use this interface in the opposite direction= to modify the said abstract topology (subject to the provider’s &nbs= p;approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be useful (e.= g. which and how the abstract links should be disjoint from each other, how= many of them should be provided, their attributes, desired recovery capabi= lities, etc,). This knowledge is supposed to come from the client’s network planning.

2. =     A way to provision/mo= dify/delete e2e services with the use of so computed e2e paths. The client&= #8217;s controller does that by chopping the paths into per-domain segments= and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segments. Hence we are = talking about interface #2 (data model #2) for the service segment manipula= tion;

3. =     A way to monitor, tro= ubleshoot, carry out maintenance of the active e2e services. This would req= uire interface #3 (data model #3) between the client’s controller and= domains VNCs/Hypervisors for this purpose.

=  

So, w= e are talking 3 Yang models with required modifications to neither Netconf/= Restconf, nor   

 = ;To any other management, routing or signaling protocol.<= /p>

=  

Now I= have a couple of questions to you:

1. =     In this example, what= else (in addition to these three models) the client such as TFK in your op= inion would need?

2. =     What else the network= providers and their vendors such as ADVA or CIEN would need?

3. =     What is the importanc= e of a construct such as PNC?

 

My an= swer to 3. “Is not important at all, irrelevant” for the follow= ing reasons:

a) =     What happens beyond t= he VNC/Hypervisor in the provider network is completely proprietary.

b) =     There could be numero= us ways as to how the provider network is managed. Examples: centralized PN= C (as you call it), ADVA style GMPLS based network intelligence, CIEN style= PNNI based control plane, etc. Why is that of ACTN’s business?

=  

Cheer= s,

Igor<= o:p>

=  

From: King, Daniel [mailto:d.king@lancaster.ac.uk]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi All,= including “Ignor” ;-)

&n= bsp;

Typical= dichotomy between what operators want and what vendors are actually willin= g to provide, group consensus will eventually help resolve that. Either way= , the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work)= on the interfaces which are in scope, namely:

&n= bsp;

1. The = CNC-VNC Interface (CVI)

- Creat= e, modify and delete virtual network service instances

- Resou= rce model

&n= bsp;

2. The = VNC-PNC Interface (VPI)

- Mappi= ng of physical and virtual resources

- Reque= sts: path, provision, modify and restore

&n= bsp;

As Youn= g suggests, if the VNC received physical topology info it would be performi= ng the role of the Physical Network Controller (PNC), which is obviously a = (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for A= CTN.

&n= bsp;

Br, Dan= .

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); actn@ietf.org; Daniele Ceccarelli; dieg= o@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Ignor,

 

Thank you for providin= g your comment that pauses us to think more and understand on the same leve= l. I think your comment will contribute to crystallize the scope of work he= re.

 

First of all, I think = there was a misunderstanding here. First, your assumption on VNC receiving = actual underlying topology is incorrect. If VNC were to have actually topol= ogy (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been dis= cussed by email threads Daniele started a few weeks ago. Check the archive = on that. The reason this is out of scope is that PNC multi-domain issue is = no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. Wh= at VNC receives from each PNC (domain controller) is an abstracted topology= with varying degrees from actual underlying topology. The reason why we di= stinguish the term VNC from PNC.

 

What can be defined on= VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long= as the detailed path computation and signaling within a domain are complet= ely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation i= s based on what is exposed from PNCs to VNC. The actual topology informatio= n details is kept by PNCs and the PNCs expose abstracted topology that can = hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (w= hich may be concatenated actual links) can be exposed for diversity routing= calculation at the VNC. This is very different from exposing the actual TE= topology. You can view this as two level of path computation. VNC first computes an end-to-end path (usin= g whatever constraint information it has), then coordinates with each PNC (= telling the border nodes information), then each PNC computes the domain sp= ecific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so tha= t the VNC would arrange an alternate path segment to be able to find a feas= ible end-to-end path.  I would say this is a “two-phase” s= ignaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC = to VNC and proprietary characteristics of optical devices need to be dealt = only with the corresponding PNC.

 

Regarding the term PNC= vs. ANC, I wouldn’t concern too much about the terminology whichever= works better. Thank you for your suggestion.

 

Lastly, please check t= he use-cases written by operators in the below links that consistently say = they need a standard interface that can coordinate their multi-domain issue= s.

 

https://datatracker= .ietf.org/doc/draft-fang-actn-multidomain-dci/

h= ttps://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-d= omains/

https://datatrack= er.ietf.org/doc/draft-kumaki-actn-multitenant-vno/

https://datatrack= er.ietf.org/doc/draft-lopez-actn-vno-multidomains/

https://datatrack= er.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

Regards,

Young

 

Thanks,

Young

 

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; actn@ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Yo= ung,

=  

I bel= ieve having the same instance of VNC talking to different vendor domain PNC= s is an extremely  idealistic view.

=  

=3D= =3D=E8 BTW I find PN= C is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract top= ologies, and to be able do that, it talks to a ANC- a controller which has = an access and manages actual provider network).

=  

One r= eason for this is that VNC needs to understand underlying actual topology, = for example, to ensure that two abstract TE links are SRLG disjoint as requ= ested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great= variety of proprietary extensions, failing to understand which leads to pr= oducing unprovisionable service paths. Do you really believe that a single = VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical pro= viders to switch to WSON :=3D).

=  

This = is not to say that you cannot build a hierarchy of VNCs, but in this case N= orth VNC plays role of a client network controller wrt to South VNC, that i= s, uses the same X interface.

IHMO = whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. = ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north= bound interface to potentially the same client (e.g.TFK).

IHMO = interface X is the only interface that the ACTN can work on.

=  

Cheer= s,

Igor =

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; actn@ietf.org; Da= niele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments<= o:p>

 

Hi Young,<= o:p>

 = ;

thanks a lot for reply= , please see in line just some further clarification

 

Regards

Sergio

 

 = ;

 = ;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: mercoled=EC 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); actn@= ietf.org; Daniele Ceccarelli; diego@tid.es; luyuanf@gmail.com
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

 

Hi Sergio,<= /span>

 

Thanks for your feedba= ck on the framework document. Please see in-line for my comment.=

 

Regards,

Young

 

From: BELOTTI,= SERGIO (SERGIO) [mail= to:sergio.belotti@alcatel-lucent.com]
Sent: Wednesday, October 08, 2014 7:34 AM
To: actn@ietf.org; Daniele Cecc= arelli; Leeyoung; diego@tid.es; luyuanf@gmail.com
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments<= /span>

 

Hi Daniele , Young and all authors,

 

I read you Framework draft and I have some comments = on that. Most are editorial , other questions for clarifications.

 

General question: in the draft the concept of VNC is= in the view of hierarchical level of controllers or linked to the multi-do= main aspect that compel to provide to the customer a single virtualized net= work even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function̶= 1; provided by VNC, in case of a single domain context could be inside dire= ctly the PNC , correct?

 

YOUNG>> Yes. That is the correct view of VNC. = For a single domain context, the VNC can be integrated with PNC. But we nee= d to factor in other scenarios such as 1) VNC vendor may be different from = PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for = a single domain, I think there is benefit to define this interface as a sta= ndard interface.

 

Section 2 , page 4:

abstraction does not imply automatically virtualizat= ion,while virtualization implies to have surely a certain form of abstracti= on. I would suggest to consider good definition contained into ONF SDN arch= itecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the r= eading.

 

YOUNG>> Agree. We will look into the mentioned= document if the usage of terms are aligned with this document. If not, we = will clarify the terminology more clearly.

 

Section 5: It seems to me you mixed here aspects tha= t are more related to policy like admission control  and guarantee of = client isolation with real computational issue like Computing time , path c= onstrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this te= rm in already used e.g. in ABNO architecture for Virtual Network Manager.

 

YOUNG>> Indeed. In Section 5, we will put some= notes on the aspect of real-time related from non real time aspect. VNM is= not to be mixed with Virtual Network Manager. Here VNM is an algorithm whi= ch is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. V= irtual Network Manager is ABNO in my understanding is a developed concept f= rom VNTM. But Dan King and I will look at this more carefully on this aspec= t what Virtual Network Manager is doing.

 

SB>>> If I un= derstood form Adrian and Daniel ABNO draft the concept, VNTM is strictly re= lated to planning function so I this it is very import point in the context= of PNC , I would say

 

Section 6.1 : while it is clear the scope of the dif= ferent control interface presented in figure 5, I’m a bit confused as= to what I/F E is – data plane interface to provider physical network= ? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provide= r controller, and the mapping to real physical resources ? Nor clear to me = the intention

 

YOUNG>> Interface E is not what ACTN will focu= s on. It simply shows  an underlying model of resources allocated to a= customer from network provider controller, and the mapping to real physica= l resources.

 

SB>>> So if I= interpreted correctly your answer is more an internal interface to PNC , t= he figure is misleading since it seems like a DP interface .

 

Section 6.1, always figure 5: If a report of po= tential NW topology between a VNC and a CNC can be queried , the arrow in t= he drawn has to be bidirectional I guess

YOUNG>> = Yes, You are right. It will be fixed.

Figure 8 Section 6.4,page 28: “PCA abstract= s the physical network topology into an abstracted topology” Looking = at the description of VNC components in 6.2.2 it is the resource manager de= voting to provide abstract topology. Does not exist any PCA component.

 

YOUNG>> So= rry for inconsistency. The intention was the PCA is the same as the Resourc= e Manager in VNC. Will make the term consistent. Good catch!

 

Figure 8 SEction 6.4, : In the picture there is= no phase 7, and there are 2 phase 8

YOUNG>> = Thanks. Good catch!

Page 30 : It is Interface C not B , between VNC= and PNC

YOUNG>> If you are referring to Section 7.3= where:

   Interfaces should also be scala= ble as a large amount of data needs

   to be transported across customers t= o virtual network controllers

   and across virtual network controlle= rs and physical network

   controllers.

 

I think this implies both interfaces B and C alth= ough primarily between VNC-PNC.

 

SB>>> Sorry Y= oung, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface in= teraction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

 

Thanks

 

Sergio

 

 

Thanks

Sergio

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C3DB7Edfweml706chm_-- From nobody Mon Oct 13 17:01: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 1C4F31A1A57 for ; Mon, 13 Oct 2014 17:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 9syOFsH13Q58 for ; Mon, 13 Oct 2014 17:01:06 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2481A1A4B for ; Mon, 13 Oct 2014 17:01:06 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9E00vRj026920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 20:00:57 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 13 Oct 2014 20:00:56 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Mon, 13 Oct 2014 20:00:56 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Mon, 13 Oct 2014 20:00:56 -0400 From: Igor Bryskin To: Leeyoung , "BELOTTI, SERGIO (SERGIO)" , Daniele Ceccarelli , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9A== Date: Tue, 14 Oct 2014 00:00:55 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-14_01:2014-10-13,2014-10-13,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/xXuJ-fGnjsZNlvOGoEJOHKrGBk0 Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 00:01:12 -0000 DQpZb3VuZywNCg0KDQo9PT2ht0FmdGVyIGFsbCB3ZSBhcmUgYWdyZWVpbmcgd2l0aCB0aGUgaW50 ZXJmYWNlcyBvZiBBQ1ROIGludGVyZXN0IGFyZSBJbnRlcmZhY2UgQiBhbmQgQywgcmlnaHQ/DQoN CklCobdOby4gSSBhbSBzYXlpbmcgdGhhdCBpbnRlcmZhY2UgQiBhbmQgQyBhcmUgZXhhY3RseSB0 aGUgc2FtZSBpbnRlcmZhY2VzLiBGb3IgZXhhbXBsZSwgb24gdGhlIHBpY3R1cmUgTmV0d29yayBk b21haW4gMSBpbiBvcmRlciB0byBwcm92aWRlIHRoZSBhYnN0cmFjdCB0b3BvbG9neSB0byB0aGUg bXVsdGktdmVuZG9yIFZOQywgbWF5IHVzZSBmdWxseSBvciBwYXJ0aWFsbHkgYWJzdHJhY3QgdG9w b2xvZ2llcyBwcm92aWRlZCBieSBvbmUgb3IgbW9yZSBsb3dlciB0aWVyIHRyYW5zcG9ydCBkb21h aW5zLg0KTGlrZXdpc2UsIEN1c3RvbWVyIDEgb24gdGhlIHBpY3R1cmUgbWF5IHVzZSBhbiBhYnN0 cmFjdCB0b3BvbG9neSBwcm92aWRlZCBieSANCk11bHRpLWRvbWFpbiBuZXR3b3JrICh0aGUgVk5D IG9uIHRoZSBwaWN0dXJlIGlzIHBhcnQgb2YpLg0KSW4gb3RoZXIgd29yZHMsIHRoZSBzYW1lIGlu dGVyZmFjZSBDIGFuZCB0aGUgc2FtZSBzZXQgb2YgbW9kZWxzLCBjb3VsZCBiZSB1c2VkICBoaWVy YXJjaGljYWxseS4gDQoNCklnb3INCg0KSUI+PiBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIGludGVy ZmFjZSBiZXR3ZWVuIHRyYW5zcG9ydCBkb21haW4gc2VydmVyIGFuZCAgdHJhbnNwb3J0IGRvbWFp biBjbGllbnQuIEkgd291bGQgYXJndWUgdGhhdCB0aGUgdmVyeSBzYW1lIGludGVyZmFjZSBjYW4g YmUgdXNlZCBiZXR3ZWVuIGEgbXVsdGktZG9tYWluIHByb3ZpZGVyIChlLmcuIFRlbGVmb25pa2Ep IGFuZCBpdHMgY2xpZW50cy4gTm90IGFsbCBzdWNoIGNsaWVudHMgYXJlIGR1bWIsIGFzIERhbmll bGUgY2xhaW1zLCBhbmQgb25seSBjYXJlIGFib3V0IKGwYSBnaXZlbiBhbW91bnQgb2YgR2JwcyBm cm9tIEEgdG8gQqGxLiBJdCBpcyBlYXN5IHRvIGVudmlzaW9uIHRoYXQgc29tZSBvZiB0aGUgY2xp ZW50cyB3b3VsZCB3YW50IGZyb20gVGVsZWZvbmljYSBhIGNvdXBsZSBvZiBTUkxHLWRpc2pvaW50 IGFic3RyYWN0IGxpbmtzLCBzbyB0aGF0IHRoZSBjbGllbnRzIGNhbiBoYXZlIGEgc2F5IGluIHRo ZSBwbGFjZW1lbnQgb2YgdGhlaXIgIHNlcnZpY2VzIGFjcm9zcyB0aGUgVGVsZWZvbmlrYSBuZXR3 b3JrLiBUaHJlZSBwb2ludHMgaGVyZToNCg0KYSkgICAgICBUaGUgY2xpZW50IHdpbGwgYmUgYWJs ZSB0byBjb25maWd1cmUgZnVsbHkgb3IgcGFydGlhbGx5IHRoZSBhYnN0cmFjdCB0b3BvbG9neSBo ZSB3YW50cyB0aGUgbmV0d29yayB0byBwcmVzZW50IHRvIGhpbTsNCg0KYikgICAgICBUaGUgc2Fp ZCBhYnN0cmFjdCB0b3BvbG9neSBjb3VsZCBiZSBhcyBzaW1wbGUgKGUuZy4gYSBzaW5nbGUgYWJz dHJhY3Qgbm9kZSkgb3IgYXMgY29tcGxleCAoZS5nLiBOIGFic3RyYWN0IG5vZGVzIGludGVyY29u bmVjdGVkIGJ5IE0gYWJzdHJhY3QgbGlua3MpIGFzIHRoZSBjbGllbnQgd2FudHMgaXQgdG8gYmUg KHN1YmplY3QgdG8gdGhlIHByb3ZpZGVyoa9zIGFwcHJvdmFsKQ0KDQpjKSAgICAgIFRoZSBhYnN0 cmFjdCB0b3BvbG9neSBwcmVzZW50ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IGRlY291 cGxlZCBmcm9tIHRoZSBwcm92aWRlcqGvcyBhY3R1YWwgdG9wb2xvZ3kuDQoNClRoZXJlZm9yZSB0 aGUgc2FtZSBpbnRlcmZhY2Uvc2V0IG9mIG1vZGVscyBjYW4gYmUgdXNlZCBiZXR3ZWVuIGFueSB0 cmFuc3BvcnQgbmV0d29yayBwcm92aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhlcm1vcmUsIHRo ZSBpbnRlcmZhY2UgY2FuIGJlIHVzZWQgaW4gdGhlIGhpZXJhcmNoaWNhbCB3YXksIHRoYXQgaXMs IGEgY2xpZW50IG9mIGEgdHJhbnNwb3J0IGRvbWFpbiBjYW4gc2VydmUgaXRzIG93biBjbGllbnRz IHVzaW5nIHRoZSBzYW1lIGludGVyZmFjZSBhcyBpdCB1c2VzIHRvIHRhbGsgdG8gaXRzIG93biBw cm92aWRlcihzKQ0KDQpIZXJlIEkgd291bGQgbGlrZSB0byBnaXZlIHlvdSBhIGxpdHRsZSBjbGVh cmVyIHBpY3R1cmUgb24gbXVsdGktZG9tYWluIGlzc3Vlcy4NCg0KICAgKy0tLS0tLS0tLS0tLS0t LS0rICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0rDQogICB8ICAgQ3Vz dG9tZXIgMSAgIHwgICB8ICAgQ3VzdG9tZXIgMiAgfCAgLi4uIHwgQ3VzdG9tZXIgTSAgIHwNCiAg ICstLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgLw0K ICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgfCAgICAgICAgICAgICAvDQogICAgICAg SW50ZXJmYWNlIEIgICBcICAgICAgICAgICB8ICAgICAgICAgICAgLw0KICAgICAgICAgICAgICAg ICAgICAgIFwgICAgICAgICAgfCAgICAgICAgICAgLw0KICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwgICBWTkMgTXVs dGktZG9tYWluICAgfCBFMkUgYWJzdHJhY3QNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg Q29vcmRpbmF0aW9uICAgIHwgdG9wb2xvZ3kgY3JlYXRpb24NCiAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgLyAgICAg ICAgIHwgICAgICAgICAgICBcDQogICAgICAgIEludGVyZmFjZSBDICAgLyAgICAgICAgICB8ICAg ICAgICAgICAgIFwgIE5ldHdvcmsgVG9wb2xvZ3kNCiAgICAgICAgICAgICAgICAgICAgIC8gICAg ICAgICAgIHwgICAgICAgICAgICAgIFwgKGFic3RyYWN0KQ0KICAgICAgICAgICAgICAgICAgICAv ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIFwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAg Ky0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgTmV0d29y ayBEb21haW4gMSB8ICAgfCBOZXR3b3JrIERvbWFpbiAyIHwgLi4gfCBOZXR3b3JrIERvbWFpbiBO IHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgVmVuZG9yIFggICAgICAgICAgICAgICAgIFZlbmRv ciBZICAgICAgICAgICAgICAgVmVuZG9yIFoNCg0KDQpXaGF0IGlzIHNpdHRpbmcgYWJvdmUgobBW TkOhsSAodGhhdCBjb29yZGluYXRlcyBvdmVyIG11bHRpLWRvbWFpbiBjb250cm9sbGVycykgY2Fu IGJlIGFuIGludGVybmFsIHNlcnZpY2Ugb3JnYW5pemF0aW9uIChvZiB0aGUgc2FtZSBvcGVyYXRv cikgb3Igc2VydmljZSBwcm92aWRlcnMgKGRpZmZlcmVudCBvcGVyYXRvcnMsIGZvcm1pbmcgY2Fy cmllcnMgb2YgY2FycmllcikuIFRoZSBjb250cm9sIGVudGl0eSBvZiB0aGVzZSBlbnRpdGllcyBp cyByZWZlcnJlZCB0byBhcyBDdXN0b21lciBOZXR3b3JrIGNvbnRyb2wgKENOQykuIFRoZSBWTkMg qENDTkMgaW50ZXJmYWNlIChJbnRlcmZhY2UgQikgaGFzIGRpZmZlcmVudCByZXF1aXJlbWVudHMg dGhhbiB0aGUgVk5DLVBOQyBpbnRlcmZhY2UgKEludGVyZmFjZSBDKS4gVG9wb2xvZ3kgYWJzdHJh Y3Rpb24gaXMganVzdCBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyBhbmQgaW4gbXVsdGktZG9tYWlu IGNhc2UsIHRoZSBWTkMgaXMgcGVyZm9ybWluZyBtdWx0aS1kb21haW4gY29vcmRpbmF0aW9uIGZ1 bmN0aW9uLiBWTkMgbmVlZHMgdG8gaGF2ZSBhIHN0YW5kYXJkIGludGVyZmFjZSB0aGF0IGVuYWJs ZSBjb21tdW5pY2F0aW9ucyB3aXRoIGRpZmZlcmVudCBraW5kcyBvZiBkb21haW4gbmV0d29yayBj b250cm9sL21hbmFnZW1lbnQgY29udHJvbCAod2hpY2ggaXMgcmVmZXJyZWQgdG8gYXMgUE5DLCB5 b3UgY2FsbCBBTkMpLiBFYWNoIGRvbWFpbiBoYXMgaXRzIG93biB3YXlzIG9mIGNvbnRyb2xsaW5n IGl0cyBuZXR3b3JrLCB3aGljaCBBQ1ROIGlzIG5vdCB0b3VjaGluZyB0aG9zZSBhdCBhbGwuIFdo YXRldmVyIHRoZSBjaG9pY2VzIG9mIHZlbmRvciBjb250cm9sIHJlZ2ltZSB3aWxsIGNvbnRpbnVl IHRvIGJlIGVtcGxveWVkIChHTVBMUy9BU09OLCBQTk5JLCBOTVMsIE9wZW5GbG93LCBldGMuKS4N Cg0KRm9yIHRoaXMgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBhc3N1bWVkIGJ5 IFZOQyBzaG91bGQgYmUgb3BlcmF0ZWQgb24gYW4gYWJzdHJhY3QgbGV2ZWwuIFdlIGRvbqGvdCB3 YW50IHRvIGluamVjdCB0aGUgc2FtZSBsZXZlbCBvZiBhY3R1YWwgbmV0d29yayB0b3BvbG9neSAo ZS5nLiwgVEVEKSBhcyB0aGUgZG9tYWluIGNvbnRyb2xsZXIgb3BlcmF0ZXMgaXRzIHBoeXNpY2Fs L2FjdHVhbCBuZXR3b3Jrcy4gSXMgdGhpcyBhZ3JlZWFibGU/IFlvdSBzYWlkIGFib3ZlIHRoaXMg aW4gYykgVGhlIGFic3RyYWN0IHRvcG9sb2d5IHByZXNlbnRlZCB0byB0aGUgY2xpZW50IGlzIGNv bXBsZXRlbHkgZGVjb3VwbGVkIGZyb20gdGhlIHByb3ZpZGVyoa9zIGFjdHVhbCB0b3BvbG9neS4N Cg0KTm93IHRoZSBWTkMgKG11bHRpLWRvbWFpbiBjb29yZGluYXRvcikgbmVlZHMgdG8gY29vcmRp bmF0ZSBzaWduYWxpbmcgYWNyb3NzIG11bHRpLWRvbWFpbiBjb250cm9sbGVycyAoaW4gdGVybXMg b2YgdGhlIHNlcXVlbmNlIG9mIHRoZSBlbmQtdG8tZW5kIHBhdGggYWNyb3NzIG11bHRpcGxlIGRv bWFpbnMpLiBUaGlzIGlzIGEgbmV3IGVsZW1lbnQgSSBiZWxpZXZlIEFDVE4gd2lsbCBoYXZlIHRv IGRldmVsb3AuIFRoaXMgaW50ZXJmYWNlIEMgKFZOQy1QTkMpIGlzIHZlcnkgZGlmZmVyZW50IGZy b20gSW50ZXJmYWNlIEIgKENOQy1WTkMpLiBUaGVyZSBhcmUgb3RoZXIgZGlmZmVyZW5jZXMgKHBs ZWFzZSBzZWUgU2VjdGlvbiA2LjUgb2YgdGhlIGZyYW1ld29yayBkb2N1bWVudCkuICBCdXQgSSBh Z3JlZSB3aXRoIHlvdSB0aGF0IGZyb20gYW4gYWJzdHJhY3QgdG9wb2xvZ3kgc3RhbmRwb2ludCwg c2ltaWxhciBtb2RlbCB3b3JrcyBmb3IgSW50ZXJmYWNlcyBCIGFuZCBDIGFzIHlvdSBzYWlkICBi KSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNpbXBsZSAoZS5n LiBhIHNpbmdsZSBhYnN0cmFjdCBub2RlKSBvciBhcyBjb21wbGV4IChlLmcuIE4gYWJzdHJhY3Qg bm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBhYnN0cmFjdCBsaW5rcykgYXMgdGhlIGNsaWVudCB3 YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXKhr3MgYXBwcm92YWwpLg0KDQpC ZXN0IHJlZ2FyZHMsDQpZb3VuZw0KDQoNCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJ QnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQg OToxNyBBTQ0KVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSBDZWNjYXJlbGxp OyBLaW5nLCBEYW5pZWw7IExlZXlvdW5nOyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1 eXVhbmZAZ21haWwuY29tDQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJh ZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgU2VyZ2lv LA0KQSBjb3VwbGUgb2YgY29tbWVudHMgaW4gbGluZS4NCg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9t OiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgW21haWx0bzpzZXJnaW8uYmVsb3R0aUBhbGNhdGVs LWx1Y2VudC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQgOToxNSBBTQ0KVG86 IElnb3IgQnJ5c2tpbjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IExlZXlvdW5n OyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29tDQpDYzogVmFy bWEsIEV2ZSBMIChFdmUpOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykNClN1YmplY3Q6IFJFOiBk cmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBJZ29y LA0KDQpQbGVhc2UsIHNlZSBpbiBsaW5lDQoNClJlZ2FyZHMNClNlcmdpbw0KDQoNCkZyb206IEln b3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IHZlbmVy ZKisIDEwIG90dG9icmUgMjAxNCAyMjozNw0KVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywg RGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3Jn PG1haWx0bzphY3RuQGlldGYub3JnPjsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+ OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEs IEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29y ay0wMy50eHQgY29tbWVudHMNCg0KSGkgRGFuaWVsZSwNClBsZWFzZSwgc2VlIGluIGxpbmUuDQpJ Z29yDQoNCkZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxs aUBlcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTAsIDIwMTQgMToyNSBQTQ0K VG86IElnb3IgQnJ5c2tpbjsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lP IChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgZGllZ29AdGlk LmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFu ZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQt Y2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgSWdvciwNCg0K V2hhdCBkbyB5b3UgbWVhbiBieSBjbGllbnQgaGVyZT8gVGhlIG9uZSB0aGF0IGlzIHRoZSBkb2N1 bWVudCBpcyBjYWxsZWQgobBzZXJ2aWNlIHByb3ZpZGVyobEgb3IgdGhlIG9uZSB0aGF0IGlzIGNh bGxlZCChsGNsaWVudKGxID8gRnJvbSB3aGF0IHlvdSBzZW5kIEkgdGVuZCB0byB0aGluayB5b3Ug YXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNlcnZpY2UgcHJvdmlkZXIsIGJ1dCBJIG1pZ2h0IGJlIHdy b25nLCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KSUI+PiBCeSBjbGllbnQgSSBtZWFuIHRoZSBjbGll bnQgb2YgYSB0cmFuc3BvcnQgZG9tYWluLCB0aGUgb25lIHdobyBzcGVha3MgTmV0Y29uZi9SZXN0 Y29uZiB0byB0aGUgdHJhbnNwb3J0IGRvbWFpbi4gVGhlIGd1eSB3aG8gc3BlYWtzIGZyb20gdGhl IG90aGVyIGVuZCAoaS5lLiBvbiBiZWhhbGYgb2YgdGhlIHRyYW5zcG9ydCBzZXJ2aWNlIHByb3Zp ZGVyKSAgaXMgdGhlIHRyYW5zcG9ydCBkb21haW6hr3MgSHlwZXJ2aXNvci4NCg0KU0I+Pj4gSXQg aXMgY2xlYXIgd2hhdCB5b3UgaW50ZW5kIGhlcmUsIGV2ZW4gaWYgd29yZCBjbGllbnQgaXQgc2Vl bXMgdG8gbWUgbW9yZSByZWxhdGVkIHRvIGFwcGxpY2F0aW9uIHRoYW4gdG8gYSBzZXJ2aWNlIHBy b3ZpZGVyLg0KDQpJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4g dHJhbnNwb3J0IGRvbWFpbiBzZXJ2ZXIgYW5kICB0cmFuc3BvcnQgZG9tYWluIGNsaWVudC4gSSB3 b3VsZCBhcmd1ZSB0aGF0IHRoZSB2ZXJ5IHNhbWUgaW50ZXJmYWNlIGNhbiBiZSB1c2VkIGJldHdl ZW4gYSBtdWx0aS1kb21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkgYW5kIGl0cyBjbGll bnRzLiBOb3QgYWxsIHN1Y2ggY2xpZW50cyBhcmUgZHVtYiwgYXMgRGFuaWVsZSBjbGFpbXMsIGFu ZCBvbmx5IGNhcmUgYWJvdXQgobBhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBCobEu IEl0IGlzIGVhc3kgdG8gZW52aXNpb24gdGhhdCBzb21lIG9mIHRoZSBjbGllbnRzIHdvdWxkIHdh bnQgZnJvbSBUZWxlZm9uaWNhIGEgY291cGxlIG9mIFNSTEctZGlzam9pbnQgYWJzdHJhY3QgbGlu a3MsIHNvIHRoYXQgdGhlIGNsaWVudHMgY2FuIGhhdmUgYSBzYXkgaW4gdGhlIHBsYWNlbWVudCBv ZiB0aGVpciAgc2VydmljZXMgYWNyb3NzIHRoZSBUZWxlZm9uaWthIG5ldHdvcmsuIFRocmVlIHBv aW50cyBoZXJlOg0KDQphKSAgICAgIFRoZSBjbGllbnQgd2lsbCBiZSBhYmxlIHRvIGNvbmZpZ3Vy ZSBmdWxseSBvciBwYXJ0aWFsbHkgdGhlIGFic3RyYWN0IHRvcG9sb2d5IGhlIHdhbnRzIHRoZSBu ZXR3b3JrIHRvIHByZXNlbnQgdG8gaGltOw0KDQpiKSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRv cG9sb2d5IGNvdWxkIGJlIGFzIHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdCBub2RlKSBv ciBhcyBjb21wbGV4IChlLmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBh YnN0cmFjdCBsaW5rcykgYXMgdGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0 aGUgcHJvdmlkZXKhr3MgYXBwcm92YWwpDQoNCmMpICAgICAgVGhlIGFic3RyYWN0IHRvcG9sb2d5 IHByZXNlbnRlZCB0byB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVkIGZyb20gdGhl IHByb3ZpZGVyoa9zIGFjdHVhbCB0b3BvbG9neS4NCg0KVGhlcmVmb3JlIHRoZSBzYW1lIGludGVy ZmFjZS9zZXQgb2YgbW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55IHRyYW5zcG9ydCBuZXR3 b3JrIHByb3ZpZGVyIGFuZCBpdHMgY2xpZW50LiBGdXJ0aGVybW9yZSwgdGhlIGludGVyZmFjZSBj YW4gYmUgdXNlZCBpbiB0aGUgaGllcmFyY2hpY2FsIHdheSwgdGhhdCBpcywgYSBjbGllbnQgb2Yg YSB0cmFuc3BvcnQgZG9tYWluIGNhbiBzZXJ2ZSBpdHMgb3duIGNsaWVudHMgdXNpbmcgdGhlIHNh bWUgaW50ZXJmYWNlIGFzIGl0IHVzZXMgdG8gdGFsayB0byBpdHMgb3duIHByb3ZpZGVyKHMpDQoN Ck1vcmVvdmVyIEkgd291bGQgYXZvaWQgaW4gdGhpcyBwaGFzZSB0byBtZW50aW9uIGFueSByZWZl cmVuY2UgdG8gcHJvdG9jb2wgaW1wbGVtZW50YXRpb24gKGUuZy4gTmV0Y29uZi9SZXN0Y29uZikg OiBJIHRoaW5rIHdlIGFyZSBpbiB0aGUgcGhhc2UgdG8gdW5kZXJzdGFuZCBhcmNoaXRlY3R1cmUs IHdoYXQgYXJlIHRoZSByZWxldmFudCBpbnRlcmZhY2VzLCBhbmQgd2hhdCBpbmZvcm1hdGlvbiBp cyBleGNoYW5nZWQgb3ZlciB0aGUgcmVmZXJlbmNlIHBvaW50cy9pbnRlcmZhY2VzLiBJIGd1ZXNz IHRoaXMgaXMgY2xlYXJseSBzdGF0ZWQgYWxzbyBpbiB0aGUgY2hhcnRlciBvZiBCb0YuDQoNCklC Pj4gQWdyZWUuIEkgdXNlZCBOZXRjb25mL1Jlc3Rjb25mIGFzIGFuIGV4YW1wbGUgdG8gbWFrZSBp dCBjbGVhciB3aGF0IGludGVyZmFjZSBJIHdhcyB0YWxraW5nIGFib3V0Lg0KDQogQXQgYW4gYXBw cm9wcmlhdGUgdGltZSCoQyBjZXJ0YWlubHkgbm90IG5vdyCoQyB0aGUgbmV4dCBzdGVwIGlzIHRv IGNoZWNrIHdpdGggb3RoZXIgU0RPcyBvbiB0aGUgYXZhaWxhYmlsaXR5IG9mIHJlbGV2YW50IGNv cmUvdGVjaG5vbG9neSBzcGVjaWZpYy9hcHBsaWNhdGlvbiBzcGVjaWZpYyBpbmZvcm1hdGlvbiBt b2RlbCChsGZyYWdtZW50c6GxLCBhbmQgdGhlbiBmaW5hbGx5IHByb2NlZWQgb24gdGhlIHBhdGgg b2YgcHJ1bmluZy9yZWZhY3RvcmluZyBhbmQgbWFwcGluZyB0byBSRVNUL0pTT04sIE5ldGNvbmYv WUFORywgYW5kIGFueSBvdGhlciBwb3NzaWJsZSBkYXRhIG1vZGVsaW5nIGFuZCBjb25maWd1cmF0 aW9uIHByb3RvY29sIGV4aXN0aW5nLiBUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgIG9mIHRoZSBC b0Ygc2NvcGUgLg0KDQpJIGRvbqGvdCB0aGluayB0aGUgY2xpZW50IG9mIHRoZSBtdWx0aS1kb21h aW4gbmV0d29yayB3YW50cyB0byBoYXZlIGEgc28gZGV0YWlsZWQgdmlldyBvZiB0aGUgbmV0d29y aywgaGUgZG9lcyBub3QgY2FyZSBhYm91dCBkb21haW5zLCBpbnRlciBkb21haW4gbGlua3Mgb3Ig d2hhdGV2ZXIsIEkgd291bGQgc2F5IGhlIG9ubHkgY2FyZXMgYWJvdXQgYSBnaXZlbiBhbW91bnQg b2YgR2JwcyBmcm9tIEEgdG8gQiB3aXRoIGEgZ2l2ZW4gbWF4IGRlbGF5IGFuZCBwcm9iYWJseSBz b21lIGRpdmVyc2l0eSBwYXJhbWV0ZXJzLg0KDQpJQj4+IEFnYWluLCBieSBjbGllbnQgSSBtZWFu IG11bHRpLWRvbWFpbiBuZXR3b3JrIGNvbnRyb2xsZXIgKGUuZy4gVGVsZWZvbmljYSBTRE4gY29u dHJvbGxlciksIG5vdCB0aGUgY2xpZW50IHVzaW5nIHNlcnZpY2VzIG9mIHRoZSBtdWx0aS1kb21h aW4gbmV0d29yayAoaS5lLiBub3QgdGhlIFRlbGVmb25pY2EgY2xpZW50cykuIFN1Y2ggY2xpZW50 IHVzZXMgIHRoZSB0cmFuc3BvcnQgZG9tYWlucyBmb3IgYSByZWFzb24uIKGwYSBnaXZlbiBhbW91 bnQgb2YgR2JwcyBmcm9tIEEgdG8gQqGxIGlzIHRvbyBsb29zZSBhbmQgbGl0dGxlIGZvciB0aGUg Y2xpZW50IHRvIGRvIHRoZSBuZXR3b3JrIHBsYW5uaW5nLiBJTU8gdGhlIGNsaWVudCBuZWVkcyB0 byAqcGxhbiogdGhlIGFic3RyYWN0IHRvcG9sb2dpZXMgcHJvdmlkZWQgYnkgdGhlIHRyYW5zcG9y dCBkb21haW5zIHRoZSBzYW1lIG9yIHNpbWlsYXIgd2F5IGFzIGhlIHdvdWxkIHBsYW4gaGlzIG93 biBhY3R1YWwgdG9wb2xvZ3kuDQoNClNCPj4+IHllcywgc3VyZSwgaW4geW91IHZpZXcgb2YgobBj bGllbnShsSAsIHRoaXMgaXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIgRGFuaWVsZSBpcyB0YWxraW5n LCBzbyBhbiBhYnN0cmFjdCB2aWV3IG9mIHdoYXQgaXMgdGhlIHJlYWwgdHJhbnNwb3J0IG5ldHdv cmsgaXMgY29uc2lkZXJlZCBhdCB0aGlzIGxldmVsLiBBcyBJIHNhaWQgdG8gWW91bmcsIGluIG15 IHByZXZpb3VzIG1haWwsIGluIHRoZSBjYXNlIG9mIGEgc2luZ2xlIGRvbWFpbiBzY2VuYXJpbyBW TkMgYW5kIFBOQyBjb3VsZCBhbHNvIGNvaW5jaWRlIGJ1dCBpbiBjYXNlIG9mIGEgbXVsdGktZG9t YWluIHNjZW5hcmlvcyB0aGUgc2NvcGUgaXMgdG8gcHJvdmlkZSB0byBhcHBsaWNhdGlvbiBsYXll ciBhIHNpbmdsZSB2aXJ0dWFsaXplZCB2aWV3IG9mIHRoZSB1bmRlcmxpbmUgbXVsdGkgZG9tYWlu IG5ldHdvcmsuDQoNCk9uIHRoZSBvdGhlciBzaWRlLCB0aGUgb25lIHRoYXQgY2FyZXMgYWJvdXQg YWxsIG9mIHRoZSBpc3N1ZXMgeW91IGxpc3RlZCBpcyB0aGUgc2VydmljZSBwcm92aWRlciAoYXMg cGVyIGFjdHVhbCBkb2N1bWVudCB0ZXJtaW5vbG9neSkuIEhvd2V2ZXIgYWxzbyB0aGUgc2Vydmlj ZSBwcm92aWRlciBkb2VzIG5vdCBnbyBpbnRvIHBoeXNpY2FsIGltcGFpcm1lbnQgZGV0YWlscy4g SGUgY2FyZXMgYWJvdXQgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhlIGJvcmRlcnMgb2YgdGhlIGRv bWFpbnMsIGludGVyIGRvbWFpbiBsaW5rcy4gSG93IHN1Y2ggY29ubmVjdGl2aXR5IGlzIHByb3Zp c2lvbmVkL21hbmFnZWQgaXMgdGhlIG5ldHdvcmsgcHJvdmlkZXIgYnVzaW5lc3MuIFRoZSBuZXR3 b3JrIHByb3ZpZGVzIG1pZ2h0IGJlIHVzaW5nIEdNUExTLCBOTVMgYW5kIE9ORiBjb250cm9sbGVy IHdpdGggT3BlbiBGbG93IG9yIHdoYXRldmVyIHRvIGNvbnRyb2wgdGhlIG5ldHdvcmsuIE1heWJl IGNhbGxpbmcgaXQgUE5DIGlzIGNvbmZ1c2luZz8gVGhlIFBOQyBjYW4gYmUgYW55IG9mIHRoZSB0 aGluZ3MgSaGvdmUgbGlzdGVkIGFuZCBtdWNoIG1vcmUuDQoNCklCPj4gSW4gdGhpcyBjYXNlIG15 IGNsaWVudCBpcyB5b3VyIHNlcnZpY2UgcHJvdmlkZXIgOz0pLiBZb3UgYXJjaGl0ZWN0dXJhbGx5 IHNlcGFyYXRlIGNsaWVudCBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLCBiZWNhdXNlIHlvdSBw cm9iYWJseSBiZWxpZXZlIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gc3RhbmRhcmRpemUgdGhlIGlu dGVyZmFjZSBiZXR3ZWVuIHRoZSB0d28uIEkgZGlzYWdyZWUgd2l0aCB0aGF0IGFuZCBkb26hr3Qg dGhpbmsgQUNUTiBzaG91bGQgd29yayBvbiB0aGlzLiBJbiB0aGUgY29udGV4dCBvZiBBQ1ROIEkg c2VlIG9ubHkgdHdvIGNvbnN0cnVjdHM6IFRyYW5zcG9ydCBkb21haW4gY29udHJvbGxlciAodHJh bnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpIGFuZCAgVHJhbnNwb3J0IGNsaWVudCBjb250cm9sbGVy ICh0cmFuc3BvcnQgc2VydmljZSB1c2VyKS4NCg0KU0I+Pj4gQUNUTiBoZXJlIGlzIG5vdCByZWlu dmVudGluZyB0aGUgd2hlZWwgLCBpbiBvdGhlciBTRE8gU0ROIHNwZWNpZmljIGlzIGNvbnNpZGVy ZWQgIHRoZSBhcHBsaWNhdGlvbiBsYXllciAsIGFuZCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gQUwg YW5kIFNETiBjb250cm9sbGVyIChpbiB0aGlzIGNhc2UgdGhlIFZOQyBvZiBBQ1ROKSAuIFRoaXMg aW50ZXJmYWNlIHBlcm1pdCB0byBhbnkgY2xpZW50IHRvIGRpcmVjdGx5IGltcGFjdCB0byBoaXMg b3duIHNlcnZpY2VzIGFuZCBoaXMgb3duIKGwdmlydHVhbGl6ZWShsSByZXNvdXJjZXMgLg0KDQoN CkhlbmNlIHRoZSBpbnRlcmZhY2VzIHRvIGJlIGNvbnNpZGVyZWQgYXJlIHR3bywgbm90IHRocmVl IChhcyBEYW4gc2FpZCkgSSB0aGluayB0aGlzIHJlcGxpZXMgdG8gcXVlc3Rpb25zIDEgYW5kIDMu IEp1c3QgdG8gYWRkIHNvbWV0aGluZyByZWdhcmRpbmcgMiwgSSB3b3VsZCBzYXkgdGhhdCB0aGV5 IG5lZWQganVzdCBhIHNpbmdsZSBlbnRyeSBwb2ludCB0byB0aGUgbmV0d29yayBjb250cm9sIChj b3VsZCBiZSBhIHNtYWxsIHBpZWNlIG9mIGNvZGUgcnVubmluZyBvbiB0b3Agb2YgdGhlIFBDRSBv ZiB5b3VyIEdNUExTIGRvbWFpbiksIHdoaWNoIGFjdHMgYXMgYW4gaW50ZXJmYWNlIGJldHdlZW4g dGhlIFZOQyBhbmQgdGhlIGNvbnRyb2wgcGxhbmUgb2YgeW91ciBuZXR3b3JrIGFuZCBwZXJmb3Jt czogobAtIE1hcHBpbmcgb2YgcGh5c2ljYWwgYW5kIHZpcnR1YWwgcmVzb3VyY2VzobEgYW5kICCh sFJlcXVlc3RzOiBwYXRoLCBwcm92aXNpb24sIG1vZGlmeSBhbmQgcmVzdG9yZaGxLg0KDQpJQj4+ IEFzIEkgc2FpZCwgdGhpcyBpcyB0aGUgdGFzayBvZiB0aGUgdHJhbnNwb3J0IGRvbWFpbiBIeXBl cnZpc29yLCB3aG9zZSByb2xlIGlzLCBlc3NlbnRpYWxseSwgdG8gdHJhbnNsYXRlIGJhY2sgYW5k IGZvcnRoIGFic3RyYWN0IDw9PiBhY3R1YWwgdG9wb2xvZ3kgZWxlbWVudHMgYW5kIHNlcnZpY2Ug cmVxdWVzdHMvcmVzcG9uc2VzIGNvbnRhaW5pbmcgdGhlIGFic3RyYWN0L2FjdHVhbCB0b3BvbG9n eSBwYXRocy4gSSB0aGluayB0aGF0IHRoZSBub3J0aC9zb3V0aCBpbnRlcmZhY2UgYmV0d2VlbiB0 aGUgdHJhbnNwb3J0IGRvbWFpbiBIeXBlcnZpc29yIGFuZCB0aGUgZW50aXR5IHJlcHJlc2VudGlu ZyB0aGUgY2xpZW50IG9mIHRoZSB0cmFuc3BvcnQgZG9tYWluIChubyBtYXR0ZXIgaG93IHlvdSBj YWxsIGl0KSBpcyB0aGUgb25seSBpbnRlcmZhY2UgQUNUTiBjYW4gd29yayBvbiB3aXRoIHRoZSBo b3BlIHRvIHByb2R1Y2Ugc29tZXRoaW5nIHVzZWZ1bC4NCg0KQ2hlZXJzDQpEYW5pZWxlDQoNCg0K DQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpT ZW50OiB2ZW5lcmSorCAxMCBvdHRvYnJlIDIwMTQgMDM6MTYNClRvOiBLaW5nLCBEYW5pZWw7IExl ZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFj dG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxtYWlsdG86ZGll Z29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0K Q2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCllvdW5nIGFuZCBEYW4sDQoNCkl0IGRvZXMg bm90IG1hdHRlciBob3cgeW91IGNhbGwgbWUsIGFuZCBhcyBKb2huIGlzIGhlbHBmdWxseSBhcHBs eWluZywgeW91IGNhbiBpZ25vcmUgd2hhdCBJIGFtIHNheWluZy4gQnV0IGxldCBtZSBleHBsYWlu IGluIHNvbWUgbW9yZSBkZXRhaWxzIHdoYXQgSSBtZWFudC4NCg0KU3VwcG9zZSB3ZSBoYXZlIGEg Y2xpZW50IChzdWNoIGFzIFRGSykgb2YgYSBtdWx0aS1kb21haW4gdHJhbnNwb3J0IG5ldHdvcmss IHdobyB3YW50cyB0byBwcm92aXNpb24gYW5kIG1hbmlwdWxhdGUgZTJlIHRyYW5zcG9ydCBzZXJ2 aWNlcyB0aGUgd2F5IGhlIHdhbnRzIGl0IChpLmUuIGFwcGx5aW5nIGhpcyBwb2xpY2llcykuIFdo YXQgd291bGQgc3VjaCBjbGllbnQgbmVlZD8NCg0KDQoxLiAgICAgQW4gYWNjZXNzIHRvIGEgdW5p ZmllZCBuZXR3b3JrIFRFIHRvcG9sb2d5IHRoYXQgY291bGQgYmUgdW5kZXJzdG9vZCBhbmQgdXNl ZCBieSB0aGUgY2xpZW50oa9zIHBhdGggY29tcHV0ZXIgdG8gc2VsZWN0IHNlcnZpY2UgZTJlIHBh dGhzLiBIb3cgZG9lcyB0aGUgY2xpZW50IGdldCBzdWNoIGEgdG9wb2xvZ3k/IFRoZSBuZWNlc3Nh cnkgb3ZlcmxheSB0b3BvbG9neSBjb21wcmlzZXMgYWJzdHJhY3QgdG9wb2xvZ2llcyBwcmVzZW50 ZWQgZm9yIHRoZSBjbGllbnQgYnkgZWFjaCBvZiB0aGUgdHJhbnNwb3J0IGRvbWFpbnMgKyBpbnRl ci1kb21haW4gVEUgbGlua3MuIEhlbmNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGludGVyZmFjZSAj MSAoYW5kIGRhdGEgbW9kZWwgIzEpIGJldHdlZW4gYSBwcm92aWRlciBoeXBlcnZpc29yL1ZOQyBh bmQgdGhlIGNsaWVudCBjb250cm9sbGVyIHRvIGV4cG9zZSBpbiBhIHVuaWZpZWQgYWJzdHJhY3Qg IHdheSAgaXRzIHRvcG9sb2d5IG9uIHBlciBjbGllbnQvdGVuYW50IGJhc2lzLiBGdXJ0aGVybW9y ZSwgdGhlIGNsaWVudCBjb250cm9sbGVyIGNhbiB1c2UgdGhpcyBpbnRlcmZhY2UgaW4gdGhlIG9w cG9zaXRlIGRpcmVjdGlvbiB0byBtb2RpZnkgdGhlIHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kgKHN1 YmplY3QgdG8gdGhlIHByb3ZpZGVyoa9zICBhcHByb3ZhbCksIGJlY2F1c2UgdGhlIGNsaWVudCBp cyB0aGUgb25seSBndXkgd2hvIGtub3dzIGhvdyB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgZXhwb3Nl ZCB0byBoaW0gc2hvdWxkIGxvb2sgbGlrZSB0byBiZSB1c2VmdWwgKGUuZy4gd2hpY2ggYW5kIGhv dyB0aGUgYWJzdHJhY3QgbGlua3Mgc2hvdWxkIGJlIGRpc2pvaW50IGZyb20gZWFjaCBvdGhlciwg aG93IG1hbnkgb2YgdGhlbSBzaG91bGQgYmUgcHJvdmlkZWQsIHRoZWlyIGF0dHJpYnV0ZXMsIGRl c2lyZWQgcmVjb3ZlcnkgY2FwYWJpbGl0aWVzLCBldGMsKS4gVGhpcyBrbm93bGVkZ2UgaXMgc3Vw cG9zZWQgdG8gY29tZSBmcm9tIHRoZSBjbGllbnShr3MgbmV0d29yayBwbGFubmluZy4NCg0KMi4g ICAgIEEgd2F5IHRvIHByb3Zpc2lvbi9tb2RpZnkvZGVsZXRlIGUyZSBzZXJ2aWNlcyB3aXRoIHRo ZSB1c2Ugb2Ygc28gY29tcHV0ZWQgZTJlIHBhdGhzLiBUaGUgY2xpZW50oa9zIGNvbnRyb2xsZXIg ZG9lcyB0aGF0IGJ5IGNob3BwaW5nIHRoZSBwYXRocyBpbnRvIHBlci1kb21haW4gc2VnbWVudHMg YW5kIGluc3RydWN0cyByZXNwZWN0aXZlIGRvbWFpbiBWTkNzL0h5cGVydmlzb3JzIHRvIHNldCB1 cC9tYW5pcHVsYXRlIHNlcnZpY2UgcmVzcGVjdGl2ZSBjb25uZWN0aW9uIHNlZ21lbnRzLiBIZW5j ZSB3ZSBhcmUgdGFsa2luZyBhYm91dCBpbnRlcmZhY2UgIzIgKGRhdGEgbW9kZWwgIzIpIGZvciB0 aGUgc2VydmljZSBzZWdtZW50IG1hbmlwdWxhdGlvbjsNCg0KMy4gICAgIEEgd2F5IHRvIG1vbml0 b3IsIHRyb3VibGVzaG9vdCwgY2Fycnkgb3V0IG1haW50ZW5hbmNlIG9mIHRoZSBhY3RpdmUgZTJl IHNlcnZpY2VzLiBUaGlzIHdvdWxkIHJlcXVpcmUgaW50ZXJmYWNlICMzIChkYXRhIG1vZGVsICMz KSBiZXR3ZWVuIHRoZSBjbGllbnShr3MgY29udHJvbGxlciBhbmQgZG9tYWlucyBWTkNzL0h5cGVy dmlzb3JzIGZvciB0aGlzIHB1cnBvc2UuDQoNClNvLCB3ZSBhcmUgdGFsa2luZyAzIFlhbmcgbW9k ZWxzIHdpdGggcmVxdWlyZWQgbW9kaWZpY2F0aW9ucyB0byBuZWl0aGVyIE5ldGNvbmYvUmVzdGNv bmYsIG5vcg0KIFRvIGFueSBvdGhlciBtYW5hZ2VtZW50LCByb3V0aW5nIG9yIHNpZ25hbGluZyBw cm90b2NvbC4NCg0KTm93IEkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgdG8geW91Og0KDQox LiAgICAgSW4gdGhpcyBleGFtcGxlLCB3aGF0IGVsc2UgKGluIGFkZGl0aW9uIHRvIHRoZXNlIHRo cmVlIG1vZGVscykgdGhlIGNsaWVudCBzdWNoIGFzIFRGSyBpbiB5b3VyIG9waW5pb24gd291bGQg bmVlZD8NCg0KMi4gICAgIFdoYXQgZWxzZSB0aGUgbmV0d29yayBwcm92aWRlcnMgYW5kIHRoZWly IHZlbmRvcnMgc3VjaCBhcyBBRFZBIG9yIENJRU4gd291bGQgbmVlZD8NCg0KMy4gICAgIFdoYXQg aXMgdGhlIGltcG9ydGFuY2Ugb2YgYSBjb25zdHJ1Y3Qgc3VjaCBhcyBQTkM/DQoNCg0KTXkgYW5z d2VyIHRvIDMuIKGwSXMgbm90IGltcG9ydGFudCBhdCBhbGwsIGlycmVsZXZhbnShsSBmb3IgdGhl IGZvbGxvd2luZyByZWFzb25zOg0KDQphKSAgICAgV2hhdCBoYXBwZW5zIGJleW9uZCB0aGUgVk5D L0h5cGVydmlzb3IgaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgaXMgY29tcGxldGVseSBwcm9wcmll dGFyeS4NCg0KYikgICAgIFRoZXJlIGNvdWxkIGJlIG51bWVyb3VzIHdheXMgYXMgdG8gaG93IHRo ZSBwcm92aWRlciBuZXR3b3JrIGlzIG1hbmFnZWQuIEV4YW1wbGVzOiBjZW50cmFsaXplZCBQTkMg KGFzIHlvdSBjYWxsIGl0KSwgQURWQSBzdHlsZSBHTVBMUyBiYXNlZCBuZXR3b3JrIGludGVsbGln ZW5jZSwgQ0lFTiBzdHlsZSBQTk5JIGJhc2VkIGNvbnRyb2wgcGxhbmUsIGV0Yy4gV2h5IGlzIHRo YXQgb2YgQUNUTqGvcyBidXNpbmVzcz8NCg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9tOiBLaW5nLCBE YW5pZWwgW21haWx0bzpkLmtpbmdAbGFuY2FzdGVyLmFjLnVrXQ0KU2VudDogVGh1cnNkYXksIE9j dG9iZXIgMDksIDIwMTQgNDo1OCBQTQ0KVG86IExlZXlvdW5nOyBJZ29yIEJyeXNraW47IEJFTE9U VEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47 IERhbmllbGUgQ2VjY2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBs dXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2 ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0w My50eHQgY29tbWVudHMNCg0KSGkgQWxsLCBpbmNsdWRpbmcgobBJZ25vcqGxIDstKQ0KDQpUeXBp Y2FsIGRpY2hvdG9teSBiZXR3ZWVuIHdoYXQgb3BlcmF0b3JzIHdhbnQgYW5kIHdoYXQgdmVuZG9y cyBhcmUgYWN0dWFsbHkgd2lsbGluZyB0byBwcm92aWRlLCBncm91cCBjb25zZW5zdXMgd2lsbCBl dmVudHVhbGx5IGhlbHAgcmVzb2x2ZSB0aGF0LiBFaXRoZXIgd2F5LCB0aGUgbGF0ZXN0IHZlcnNp b24gb2YgdGhlIEZyYW1ld29yayBJLUQgaXMgdHJ5aW5nIHRvIGZvY3VzIEFDVE4gZGlzY3Vzc2lv biBhbmQgc2NvcGUgKGkuZS4sIHRoZSBwcm90b2NvbCB3b3JrKSBvbiB0aGUgaW50ZXJmYWNlcyB3 aGljaCBhcmUgaW4gc2NvcGUsIG5hbWVseToNCg0KMS4gVGhlIENOQy1WTkMgSW50ZXJmYWNlIChD VkkpDQotIENyZWF0ZSwgbW9kaWZ5IGFuZCBkZWxldGUgdmlydHVhbCBuZXR3b3JrIHNlcnZpY2Ug aW5zdGFuY2VzDQotIFJlc291cmNlIG1vZGVsDQoNCjIuIFRoZSBWTkMtUE5DIEludGVyZmFjZSAo VlBJKQ0KLSBNYXBwaW5nIG9mIHBoeXNpY2FsIGFuZCB2aXJ0dWFsIHJlc291cmNlcw0KLSBSZXF1 ZXN0czogcGF0aCwgcHJvdmlzaW9uLCBtb2RpZnkgYW5kIHJlc3RvcmUNCg0KQXMgWW91bmcgc3Vn Z2VzdHMsIGlmIHRoZSBWTkMgcmVjZWl2ZWQgcGh5c2ljYWwgdG9wb2xvZ3kgaW5mbyBpdCB3b3Vs ZCBiZSBwZXJmb3JtaW5nIHRoZSByb2xlIG9mIHRoZSBQaHlzaWNhbCBOZXR3b3JrIENvbnRyb2xs ZXIgKFBOQyksIHdoaWNoIGlzIG9idmlvdXNseSBhIChzb21laG93KSByZXF1aXJlZCBmdW5jdGlv biwgYnV0IHRoZSBpbnRlcmZhY2UgKGRpcmVjdCBwcm92aXNpb25pbmcgb2YgdGhlIGFjdHVhbCBw aHlzaWNhbCBuZXR3b3JrKSBpcyBvdXQgb2Ygc2NvcGUgZm9yIEFDVE4uDQoNCkJyLCBEYW4uDQoN CkZyb206IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBM ZWV5b3VuZw0KU2VudDogMDkgT2N0b2JlciAyMDE0IDIxOjMyDQpUbzogSWdvciBCcnlza2luOyBC RUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5v cmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVz PjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KQ2M6IFZhcm1h LCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUmU6IFtBY3RuXSBkcmFmdC1jZWNjYXJlbGxpLWFjdG4t ZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBJZ25vciwNCg0KVGhhbmsgeW91IGZvciBw cm92aWRpbmcgeW91ciBjb21tZW50IHRoYXQgcGF1c2VzIHVzIHRvIHRoaW5rIG1vcmUgYW5kIHVu ZGVyc3RhbmQgb24gdGhlIHNhbWUgbGV2ZWwuIEkgdGhpbmsgeW91ciBjb21tZW50IHdpbGwgY29u dHJpYnV0ZSB0byBjcnlzdGFsbGl6ZSB0aGUgc2NvcGUgb2Ygd29yayBoZXJlLg0KDQpGaXJzdCBv ZiBhbGwsIEkgdGhpbmsgdGhlcmUgd2FzIGEgbWlzdW5kZXJzdGFuZGluZyBoZXJlLiBGaXJzdCwg eW91ciBhc3N1bXB0aW9uIG9uIFZOQyByZWNlaXZpbmcgYWN0dWFsIHVuZGVybHlpbmcgdG9wb2xv Z3kgaXMgaW5jb3JyZWN0LiBJZiBWTkMgd2VyZSB0byBoYXZlIGFjdHVhbGx5IHRvcG9sb2d5IChl LmcuIFRFRCkgb2YgYSBuZXR3b3JrLCB0aGlzIHdvdWxkIGJlIGNhbGxlZCBhIFBOQyBhbmQgdGhp cyBpcyBvdXQgb2Ygc2NvcGUgb2YgQUNUTi4gVGhpcyBhc3BlY3QgaGFzIGJlZW4gZGlzY3Vzc2Vk IGJ5IGVtYWlsIHRocmVhZHMgRGFuaWVsZSBzdGFydGVkIGEgZmV3IHdlZWtzIGFnby4gQ2hlY2sg dGhlIGFyY2hpdmUgb24gdGhhdC4gVGhlIHJlYXNvbiB0aGlzIGlzIG91dCBvZiBzY29wZSBpcyB0 aGF0IFBOQyBtdWx0aS1kb21haW4gaXNzdWUgaXMgbm8gZGlmZmVyZW50IGZyb20gdG9kYXmhr3Mg R01QTFMvUENFIGlzc3VlLCBlc3BlY2lhbGx5IGluIGxpZ2h0IG9mIEgtUENFLiBBQ1ROIGRvZXMg bm90IHN0ZXAgb24gdGhvc2UgYXJlYXMuIFdoYXQgVk5DIHJlY2VpdmVzIGZyb20gZWFjaCBQTkMg KGRvbWFpbiBjb250cm9sbGVyKSBpcyBhbiBhYnN0cmFjdGVkIHRvcG9sb2d5IHdpdGggdmFyeWlu ZyBkZWdyZWVzIGZyb20gYWN0dWFsIHVuZGVybHlpbmcgdG9wb2xvZ3kuIFRoZSByZWFzb24gd2h5 IHdlIGRpc3Rpbmd1aXNoIHRoZSB0ZXJtIFZOQyBmcm9tIFBOQy4NCg0KV2hhdCBjYW4gYmUgZGVm aW5lZCBvbiBWTkMtUE5DIGlzIGEgdmVydGljYWwgc2lnbmFsaW5nIGNvb3JkaW5hdGlvbiBmcm9t IFZOQyB0byBlYWNoIFBOQy4gQXMgbG9uZyBhcyB0aGUgZGV0YWlsZWQgcGF0aCBjb21wdXRhdGlv biBhbmQgc2lnbmFsaW5nIHdpdGhpbiBhIGRvbWFpbiBhcmUgY29tcGxldGVseSB1cCB0byB0aGUg ZG9tYWluIFBOQy4gVk5DIGlzIG5vdCB0byBiZSBvcGVyYXRlZCBvbiB0aGUgc2FtZSBsZXZlbCBh cyBQTkMuIEl0cyBlbmQtdG8tZW5kIHBhdGggY29tcHV0YXRpb24gaXMgYmFzZWQgb24gd2hhdCBp cyBleHBvc2VkIGZyb20gUE5DcyB0byBWTkMuIFRoZSBhY3R1YWwgdG9wb2xvZ3kgaW5mb3JtYXRp b24gZGV0YWlscyBpcyBrZXB0IGJ5IFBOQ3MgYW5kIHRoZSBQTkNzIGV4cG9zZSBhYnN0cmFjdGVk IHRvcG9sb2d5IHRoYXQgY2FuIGhpZGUgdGhlIGV4YWN0IGRldGFpbHMgd2hpbGUgZXhwb3Npbmcg YSBtaW5pbXVtIGxldmVsIG9mIGNvbnN0cmFpbnRzLiBGb3IgaW5zdGFuY2UsIHRoZSBTUkxHIG9m IHZpcnR1YWwgbGlua3MgKHdoaWNoIG1heSBiZSBjb25jYXRlbmF0ZWQgYWN0dWFsIGxpbmtzKSBj YW4gYmUgZXhwb3NlZCBmb3IgZGl2ZXJzaXR5IHJvdXRpbmcgY2FsY3VsYXRpb24gYXQgdGhlIFZO Qy4gVGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGV4cG9zaW5nIHRoZSBhY3R1YWwgVEUgdG9w b2xvZ3kuIFlvdSBjYW4gdmlldyB0aGlzIGFzIHR3byBsZXZlbCBvZiBwYXRoIGNvbXB1dGF0aW9u LiBWTkMgZmlyc3QgY29tcHV0ZXMgYW4gZW5kLXRvLWVuZCBwYXRoICh1c2luZyB3aGF0ZXZlciBj b25zdHJhaW50IGluZm9ybWF0aW9uIGl0IGhhcyksIHRoZW4gY29vcmRpbmF0ZXMgd2l0aCBlYWNo IFBOQyAodGVsbGluZyB0aGUgYm9yZGVyIG5vZGVzIGluZm9ybWF0aW9uKSwgdGhlbiBlYWNoIFBO QyBjb21wdXRlcyB0aGUgZG9tYWluIHNwZWNpZmljIHBhdGguIFdoZW4gYSBQTkMgY2Fubm90IHBy b3ZpZGUgYSBwYXRoIHNlZ21lbnQgaW4gaXRzIGRvbWFpbiwgdGhlbiB0aGlzIG5lZWRzIHRvIGJl IHNpZ25hbGVkIHRvIFZOQyBzbyB0aGF0IHRoZSBWTkMgd291bGQgYXJyYW5nZSBhbiBhbHRlcm5h dGUgcGF0aCBzZWdtZW50IHRvIGJlIGFibGUgdG8gZmluZCBhIGZlYXNpYmxlIGVuZC10by1lbmQg cGF0aC4gIEkgd291bGQgc2F5IHRoaXMgaXMgYSChsHR3by1waGFzZaGxIHNpZ25hbGluZyBhbmQg cGF0aCBjb21wdXRhdGlvbi4gVGhlIHBvaW50IGlzIHRoYXQgdGhlcmUgbXVzdCBiZSBzb21lIGxl dmVsIG9mIGhpZGluZyBvbiBhYnN0cmFjdCB0b3BvbG9neSBleHBvc3VyZSBmcm9tIFBOQyB0byBW TkMgYW5kIHByb3ByaWV0YXJ5IGNoYXJhY3RlcmlzdGljcyBvZiBvcHRpY2FsIGRldmljZXMgbmVl ZCB0byBiZSBkZWFsdCBvbmx5IHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgUE5DLg0KDQpSZWdhcmRp bmcgdGhlIHRlcm0gUE5DIHZzLiBBTkMsIEkgd291bGRuoa90IGNvbmNlcm4gdG9vIG11Y2ggYWJv dXQgdGhlIHRlcm1pbm9sb2d5IHdoaWNoZXZlciB3b3JrcyBiZXR0ZXIuIFRoYW5rIHlvdSBmb3Ig eW91ciBzdWdnZXN0aW9uLg0KDQpMYXN0bHksIHBsZWFzZSBjaGVjayB0aGUgdXNlLWNhc2VzIHdy aXR0ZW4gYnkgb3BlcmF0b3JzIGluIHRoZSBiZWxvdyBsaW5rcyB0aGF0IGNvbnNpc3RlbnRseSBz YXkgdGhleSBuZWVkIGEgc3RhbmRhcmQgaW50ZXJmYWNlIHRoYXQgY2FuIGNvb3JkaW5hdGUgdGhl aXIgbXVsdGktZG9tYWluIGlzc3Vlcy4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmFuZy1hY3RuLW11bHRpZG9tYWluLWRjaS8NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWtsZWUtYWN0bi1jb25uZWN0aXZpdHktbXVsdGktdmVuZG9yLWRv bWFpbnMvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdW1ha2ktYWN0 bi1tdWx0aXRlbmFudC12bm8vDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1sb3Blei1hY3RuLXZuby1tdWx0aWRvbWFpbnMvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1zaGluLWFjdG4tbXZuby1tdWx0aS1kb21haW4vDQoNClJlZ2FyZHMsDQpZ b3VuZw0KDQpUaGFua3MsDQpZb3VuZw0KDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklC cnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0 IDE6NDggUE0NClRvOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IExlZXlvdW5nOyBhY3RuQGll dGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBkaWVnb0B0 aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1 YW5mQGdtYWlsLmNvbT4NCkNjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFm dC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBZb3VuZywN Cg0KSSBiZWxpZXZlIGhhdmluZyB0aGUgc2FtZSBpbnN0YW5jZSBvZiBWTkMgdGFsa2luZyB0byBk aWZmZXJlbnQgdmVuZG9yIGRvbWFpbiBQTkNzIGlzIGFuIGV4dHJlbWVseSAgaWRlYWxpc3RpYyB2 aWV3Lg0KDQo9PT09PiBCVFcgSSBmaW5kIFBOQyBpcyBhIGJhZCB0ZXJtLCBJIGxpa2UgbXVjaCBi ZXR0ZXIgQWN0dWFsIE5ldHdvcmsgQ29udHJvbGxlciAgKEFOQykuIFZOQyAoYS5rLmEuIGEgSHlw ZXJ2aXNvcikgaXMgbWFuYWdpbmcgYWJzdHJhY3QgdG9wb2xvZ2llcywgYW5kIHRvIGJlIGFibGUg ZG8gdGhhdCwgaXQgdGFsa3MgdG8gYSBBTkMtIGEgY29udHJvbGxlciB3aGljaCBoYXMgYW4gYWNj ZXNzIGFuZCBtYW5hZ2VzIGFjdHVhbCBwcm92aWRlciBuZXR3b3JrKS4NCg0KT25lIHJlYXNvbiBm b3IgdGhpcyBpcyB0aGF0IFZOQyBuZWVkcyB0byB1bmRlcnN0YW5kIHVuZGVybHlpbmcgYWN0dWFs IHRvcG9sb2d5LCBmb3IgZXhhbXBsZSwgdG8gZW5zdXJlIHRoYXQgdHdvIGFic3RyYWN0IFRFIGxp bmtzIGFyZSBTUkxHIGRpc2pvaW50IGFzIHJlcXVlc3RlZC4gQWN0dWFsIHRvcG9sb2d5IHNlbWFu dGljcyAoZXNwZWNpYWxseSBpbiBXRE0gbGF5ZXIpIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gdmVu ZG9yIHRvIHZlbmRvciBhbmQgY29udGFpbnMgYSBncmVhdCB2YXJpZXR5IG9mIHByb3ByaWV0YXJ5 IGV4dGVuc2lvbnMsIGZhaWxpbmcgdG8gdW5kZXJzdGFuZCB3aGljaCBsZWFkcyB0byBwcm9kdWNp bmcgdW5wcm92aXNpb25hYmxlIHNlcnZpY2UgcGF0aHMuIERvIHlvdSByZWFsbHkgYmVsaWV2ZSB0 aGF0IGEgc2luZ2xlIFZOQyBjYW4gdGFsayBpbiB0aGUgc2FtZSB3YXkgdG8gQURWQSwgSU5GTiwg QUxVIGFuZCBIdWF3ZWkgQU5Dcz8gVGhpcyBpcyBlcXVpdmFsZW50IHRvIGFzayBhbGwgb3B0aWNh bCBwcm92aWRlcnMgdG8gc3dpdGNoIHRvIFdTT04gOj0pLg0KDQpUaGlzIGlzIG5vdCB0byBzYXkg dGhhdCB5b3UgY2Fubm90IGJ1aWxkIGEgaGllcmFyY2h5IG9mIFZOQ3MsIGJ1dCBpbiB0aGlzIGNh c2UgTm9ydGggVk5DIHBsYXlzIHJvbGUgb2YgYSBjbGllbnQgbmV0d29yayBjb250cm9sbGVyIHdy dCB0byBTb3V0aCBWTkMsIHRoYXQgaXMsIHVzZXMgdGhlIHNhbWUgWCBpbnRlcmZhY2UuDQpJSE1P IHdoZW5ldmVyIGEgVk5DIGhhcyB0byB0YWxrIHRvIGEgQU5DLCBpdCBkb2VzIHNvIGluIGEgcHJv cHJpZXRhcnkgd2F5LCBpLmUuIEFEVkEsIElORk4sIEFMVSBhbmQgSHVhd2VpIHdpbGwgaGF2ZSB0 aGVpciBvd24gVk5DcyBleHBvc2luZyB0aGUgc2FtZSBub3J0aCBib3VuZCBpbnRlcmZhY2UgdG8g cG90ZW50aWFsbHkgdGhlIHNhbWUgY2xpZW50IChlLmcuVEZLKS4NCklITU8gaW50ZXJmYWNlIFgg aXMgdGhlIG9ubHkgaW50ZXJmYWNlIHRoYXQgdGhlIEFDVE4gY2FuIHdvcmsgb24uDQoNCkNoZWVy cywNCklnb3INCg0KRnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKQ0KU2VudDogVGh1cnNkYXksIE9jdG9i ZXIgMDksIDIwMTQgNTo1OSBBTQ0KVG86IExlZXlvdW5nOyBhY3RuQGlldGYub3JnPG1haWx0bzph Y3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBkaWVnb0B0aWQuZXM8bWFpbHRvOmRp ZWdvQHRpZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4N CkNjOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVj dDogUmU6IFtBY3RuXSBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21t ZW50cw0KDQpIaSBZb3VuZywNCg0KdGhhbmtzIGEgbG90IGZvciByZXBseSAsIHBsZWFzZSBzZWUg aW4gbGluZSBqdXN0IHNvbWUgZnVydGhlciBjbGFyaWZpY2F0aW9uDQoNClJlZ2FyZHMNClNlcmdp bw0KDQoNCg0KRnJvbTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXQ0KU2Vu dDogbWVyY29sZWSorCA4IG90dG9icmUgMjAxNCAxNzozNQ0KVG86IEJFTE9UVEksIFNFUkdJTyAo U0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2Vj Y2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWls LmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpT dWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVu dHMNCg0KSGkgU2VyZ2lvLA0KDQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2sgb24gdGhlIGZyYW1l d29yayBkb2N1bWVudC4gUGxlYXNlIHNlZSBpbi1saW5lIGZvciBteSBjb21tZW50Lg0KDQpSZWdh cmRzLA0KWW91bmcNCg0KRnJvbTogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIFttYWlsdG86c2Vy Z2lvLmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVy IDA4LCAyMDE0IDc6MzQgQU0NClRvOiBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3Jn PjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBMZWV5b3VuZzsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVn b0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpD YzogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6 IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIERh bmllbGUgLCBZb3VuZyBhbmQgYWxsIGF1dGhvcnMsDQoNCkkgcmVhZCB5b3UgRnJhbWV3b3JrIGRy YWZ0IGFuZCBJIGhhdmUgc29tZSBjb21tZW50cyBvbiB0aGF0LiBNb3N0IGFyZSBlZGl0b3JpYWwg LCBvdGhlciBxdWVzdGlvbnMgZm9yIGNsYXJpZmljYXRpb25zLg0KDQpHZW5lcmFsIHF1ZXN0aW9u OiBpbiB0aGUgZHJhZnQgdGhlIGNvbmNlcHQgb2YgVk5DIGlzIGluIHRoZSB2aWV3IG9mIGhpZXJh cmNoaWNhbCBsZXZlbCBvZiBjb250cm9sbGVycyBvciBsaW5rZWQgdG8gdGhlIG11bHRpLWRvbWFp biBhc3BlY3QgdGhhdCBjb21wZWwgdG8gcHJvdmlkZSB0byB0aGUgY3VzdG9tZXIgYSBzaW5nbGUg dmlydHVhbGl6ZWQgbmV0d29yayBldmVuIGlmIGNvbXBvc2VkIGJ5IHJlYWwgbXVsdGktZG9tYWlu IG11bHRpLXRlY2hub2xvZ3kgc3VibmV0d29ya3M/IEkgbWVhbiwgdGhlIKGwdmlydHVhbGl6ZXIg ZnVuY3Rpb26hsSBwcm92aWRlZCBieSBWTkMsIGluIGNhc2Ugb2YgYSBzaW5nbGUgZG9tYWluIGNv bnRleHQgY291bGQgYmUgaW5zaWRlIGRpcmVjdGx5IHRoZSBQTkMgLCBjb3JyZWN0Pw0KDQpZT1VO Rz4+IFllcy4gVGhhdCBpcyB0aGUgY29ycmVjdCB2aWV3IG9mIFZOQy4gRm9yIGEgc2luZ2xlIGRv bWFpbiBjb250ZXh0LCB0aGUgVk5DIGNhbiBiZSBpbnRlZ3JhdGVkIHdpdGggUE5DLiBCdXQgd2Ug bmVlZCB0byBmYWN0b3IgaW4gb3RoZXIgc2NlbmFyaW9zIHN1Y2ggYXMgMSkgVk5DIHZlbmRvciBt YXkgYmUgZGlmZmVyZW50IGZyb20gUE5DIHZlbmRvciBvciAyKSBWTkMgaXMgYSBzb2Z0d2FyZSBm dW5jdGlvbiB0aGF0IG9wZXJhdG9yIG1heSB3YW50IHRvIG9wZXJhdGUgYXMgaXRzIGNvbnRyb2wu IEluIG15IG9waW5pb24sIGV2ZW4gZm9yIGEgc2luZ2xlIGRvbWFpbiwgSSB0aGluayB0aGVyZSBp cyBiZW5lZml0IHRvIGRlZmluZSB0aGlzIGludGVyZmFjZSBhcyBhIHN0YW5kYXJkIGludGVyZmFj ZS4NCg0KU2VjdGlvbiAyICwgcGFnZSA0Og0KYWJzdHJhY3Rpb24gZG9lcyBub3QgaW1wbHkgYXV0 b21hdGljYWxseSB2aXJ0dWFsaXphdGlvbix3aGlsZSB2aXJ0dWFsaXphdGlvbiBpbXBsaWVzIHRv IGhhdmUgc3VyZWx5IGEgY2VydGFpbiBmb3JtIG9mIGFic3RyYWN0aW9uLiBJIHdvdWxkIHN1Z2dl c3QgdG8gY29uc2lkZXIgZ29vZCBkZWZpbml0aW9uIGNvbnRhaW5lZCBpbnRvIE9ORiBTRE4gYXJj aGl0ZWN0dXJlIGRvY3VtZW50IGNoYXB0ZXIgMi4zIENvbnZlbnRpb25zIGFib3V0IGFic3RyYWN0 aW9uIGFuZCB2aXJ0dWFsaXphdGlvbi4gQSBnb29kIGRlZmluaXRpb24gY2FuIGhlbHAgYWxsIHRo ZSByZWFkaW5nLg0KDQpZT1VORz4+IEFncmVlLiBXZSB3aWxsIGxvb2sgaW50byB0aGUgbWVudGlv bmVkIGRvY3VtZW50IGlmIHRoZSB1c2FnZSBvZiB0ZXJtcyBhcmUgYWxpZ25lZCB3aXRoIHRoaXMg ZG9jdW1lbnQuIElmIG5vdCwgd2Ugd2lsbCBjbGFyaWZ5IHRoZSB0ZXJtaW5vbG9neSBtb3JlIGNs ZWFybHkuDQoNClNlY3Rpb24gNTogSXQgc2VlbXMgdG8gbWUgeW91IG1peGVkIGhlcmUgYXNwZWN0 cyB0aGF0IGFyZSBtb3JlIHJlbGF0ZWQgdG8gcG9saWN5IGxpa2UgYWRtaXNzaW9uIGNvbnRyb2wg IGFuZCBndWFyYW50ZWUgb2YgY2xpZW50IGlzb2xhdGlvbiB3aXRoIHJlYWwgY29tcHV0YXRpb25h bCBpc3N1ZSBsaWtlIENvbXB1dGluZyB0aW1lICwgcGF0aCBjb25zdHJhaW5zIG9yIHJlLW9wdGlt aXphdGlvbiBwcm9jZXNzLiBNb3Jlb3ZlciB0aGUgdGVybSBWTk0gZm9yIFZpcnR1YWwgbmV0d29y ayBtYXBwaW5nIGlzIGEgYml0IG1pc2xlYWRpbmcgc2luY2UgdGhpcyB0ZXJtIGluIGFscmVhZHkg dXNlZCBlLmcuIGluIEFCTk8gYXJjaGl0ZWN0dXJlIGZvciBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdl ci4NCg0KWU9VTkc+PiBJbmRlZWQuIEluIFNlY3Rpb24gNSwgd2Ugd2lsbCBwdXQgc29tZSBub3Rl cyBvbiB0aGUgYXNwZWN0IG9mIHJlYWwtdGltZSByZWxhdGVkIGZyb20gbm9uIHJlYWwgdGltZSBh c3BlY3QuIFZOTSBpcyBub3QgdG8gYmUgbWl4ZWQgd2l0aCBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdl ci4gSGVyZSBWTk0gaXMgYW4gYWxnb3JpdGhtIHdoaWNoIGlzIGtub3duIGFzIFZpcnR1YWwgTmV0 d29yayBNYXBwaW5nIHdoaWNoIGlzIGEgc29mdHdhcmUgbW9kdWxlIHRoYXQgY29udmVydHMgY2xp ZW50IHJlcXVlc3RzIGludG8gYWN0dWFsIG5ldHdvcmtzLiBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdl ciBpcyBBQk5PIGluIG15IHVuZGVyc3RhbmRpbmcgaXMgYSBkZXZlbG9wZWQgY29uY2VwdCBmcm9t IFZOVE0uIEJ1dCBEYW4gS2luZyBhbmQgSSB3aWxsIGxvb2sgYXQgdGhpcyBtb3JlIGNhcmVmdWxs eSBvbiB0aGlzIGFzcGVjdCB3aGF0IFZpcnR1YWwgTmV0d29yayBNYW5hZ2VyIGlzIGRvaW5nLg0K DQpTQj4+PiBJZiBJIHVuZGVyc3Rvb2QgZm9ybSBBZHJpYW4gYW5kIERhbmllbCBBQk5PIGRyYWZ0 IHRoZSBjb25jZXB0LCBWTlRNIGlzIHN0cmljdGx5IHJlbGF0ZWQgdG8gcGxhbm5pbmcgZnVuY3Rp b24gc28gSSB0aGlzIGl0IGlzIHZlcnkgaW1wb3J0IHBvaW50IGluIHRoZSBjb250ZXh0IG9mIFBO QyAsIEkgd291bGQgc2F5DQoNClNlY3Rpb24gNi4xIDogd2hpbGUgaXQgaXMgY2xlYXIgdGhlIHNj b3BlIG9mIHRoZSBkaWZmZXJlbnQgY29udHJvbCBpbnRlcmZhY2UgcHJlc2VudGVkIGluIGZpZ3Vy ZSA1LCBJoa9tIGEgYml0IGNvbmZ1c2VkIGFzIHRvIHdoYXQgSS9GIEUgaXMgqEMgZGF0YSBwbGFu ZSBpbnRlcmZhY2UgdG8gcHJvdmlkZXIgcGh5c2ljYWwgbmV0d29yaz8gT3IgaXMgdGhlIGludGVu dGlvbiB0byBwcm92aWRlIHdoYXQgY2FuIGJlIHRoZSB1bmRlcmx5aW5nIG1vZGVsIG9mIHJlc291 cmNlcyBhbGxvY2F0ZWQgdG8gYSBjdXN0b21lciBmcm9tIG5ldHdvcmsgcHJvdmlkZXIgY29udHJv bGxlciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwgcGh5c2ljYWwgcmVzb3VyY2VzID8gTm9yIGNs ZWFyIHRvIG1lIHRoZSBpbnRlbnRpb24NCg0KWU9VTkc+PiBJbnRlcmZhY2UgRSBpcyBub3Qgd2hh dCBBQ1ROIHdpbGwgZm9jdXMgb24uIEl0IHNpbXBseSBzaG93cyAgYW4gdW5kZXJseWluZyBtb2Rl bCBvZiByZXNvdXJjZXMgYWxsb2NhdGVkIHRvIGEgY3VzdG9tZXIgZnJvbSBuZXR3b3JrIHByb3Zp ZGVyIGNvbnRyb2xsZXIsIGFuZCB0aGUgbWFwcGluZyB0byByZWFsIHBoeXNpY2FsIHJlc291cmNl cy4NCg0KU0I+Pj4gU28gaWYgSSBpbnRlcnByZXRlZCBjb3JyZWN0bHkgeW91ciBhbnN3ZXIgaXMg bW9yZSBhbiBpbnRlcm5hbCBpbnRlcmZhY2UgdG8gUE5DICwgdGhlIGZpZ3VyZSBpcyBtaXNsZWFk aW5nIHNpbmNlIGl0IHNlZW1zIGxpa2UgYSBEUCBpbnRlcmZhY2UgLg0KDQoNClNlY3Rpb24gNi4x LCBhbHdheXMgZmlndXJlIDU6IElmIGEgcmVwb3J0IG9mIHBvdGVudGlhbCBOVyB0b3BvbG9neSBi ZXR3ZWVuIGEgVk5DIGFuZCBhIENOQyBjYW4gYmUgcXVlcmllZCAsIHRoZSBhcnJvdyBpbiB0aGUg ZHJhd24gaGFzIHRvIGJlIGJpZGlyZWN0aW9uYWwgSSBndWVzcw0KDQpZT1VORz4+IFllcywgWW91 IGFyZSByaWdodC4gSXQgd2lsbCBiZSBmaXhlZC4NCg0KRmlndXJlIDggU2VjdGlvbiA2LjQscGFn ZSAyODogobBQQ0EgYWJzdHJhY3RzIHRoZSBwaHlzaWNhbCBuZXR3b3JrIHRvcG9sb2d5IGludG8g YW4gYWJzdHJhY3RlZCB0b3BvbG9neaGxIExvb2tpbmcgYXQgdGhlIGRlc2NyaXB0aW9uIG9mIFZO QyBjb21wb25lbnRzIGluIDYuMi4yIGl0IGlzIHRoZSByZXNvdXJjZSBtYW5hZ2VyIGRldm90aW5n IHRvIHByb3ZpZGUgYWJzdHJhY3QgdG9wb2xvZ3kuIERvZXMgbm90IGV4aXN0IGFueSBQQ0EgY29t cG9uZW50Lg0KDQoNCg0KWU9VTkc+PiBTb3JyeSBmb3IgaW5jb25zaXN0ZW5jeS4gVGhlIGludGVu dGlvbiB3YXMgdGhlIFBDQSBpcyB0aGUgc2FtZSBhcyB0aGUgUmVzb3VyY2UgTWFuYWdlciBpbiBW TkMuIFdpbGwgbWFrZSB0aGUgdGVybSBjb25zaXN0ZW50LiBHb29kIGNhdGNoIQ0KDQoNCg0KRmln dXJlIDggU0VjdGlvbiA2LjQsIDogSW4gdGhlIHBpY3R1cmUgdGhlcmUgaXMgbm8gcGhhc2UgNywg YW5kIHRoZXJlIGFyZSAyIHBoYXNlIDgNCg0KWU9VTkc+PiBUaGFua3MuIEdvb2QgY2F0Y2ghDQoN ClBhZ2UgMzAgOiBJdCBpcyBJbnRlcmZhY2UgQyBub3QgQiAsIGJldHdlZW4gVk5DIGFuZCBQTkMN Cg0KWU9VTkc+PiBJZiB5b3UgYXJlIHJlZmVycmluZyB0byBTZWN0aW9uIDcuMyB3aGVyZToNCg0K ICAgSW50ZXJmYWNlcyBzaG91bGQgYWxzbyBiZSBzY2FsYWJsZSBhcyBhIGxhcmdlIGFtb3VudCBv ZiBkYXRhIG5lZWRzDQoNCiAgIHRvIGJlIHRyYW5zcG9ydGVkIGFjcm9zcyBjdXN0b21lcnMgdG8g dmlydHVhbCBuZXR3b3JrIGNvbnRyb2xsZXJzDQoNCiAgIGFuZCBhY3Jvc3MgdmlydHVhbCBuZXR3 b3JrIGNvbnRyb2xsZXJzIGFuZCBwaHlzaWNhbCBuZXR3b3JrDQoNCiAgIGNvbnRyb2xsZXJzLg0K DQoNCg0KSSB0aGluayB0aGlzIGltcGxpZXMgYm90aCBpbnRlcmZhY2VzIEIgYW5kIEMgYWx0aG91 Z2ggcHJpbWFyaWx5IGJldHdlZW4gVk5DLVBOQy4NCg0KDQoNClNCPj4+IFNvcnJ5IFlvdW5nLCBp aXQgaXMgbm90IHJlZmVycmVkIHRvIDcuMyAsIGJ1dCBpbiB0aGUgY2hhcHRlciA2LDUgLCBvbiBJ bnRlcmZhY2UgaW50ZXJhY3Rpb24sIGFmdGVyIHBvaW50IDYsIGlzIGluZGljYXRlZCBJbnRlcmZh Y2UgQiBhcyBpbnRlcmZhY2UgYmV0d2VlbiBWTkMgYW5kIFBOQywgZmlndXJlIDUgc2F5cyBpdCBp cyBJL0YgQw0KDQoNClRoYW5rcw0KDQpTZXJnaW8NCg0KDQpUaGFua3MNClNlcmdpbw0K From nobody Tue Oct 14 02:38:47 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 F3C6B1A7002 for ; Tue, 14 Oct 2014 02:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 bwHH2GE7P5T5 for ; Tue, 14 Oct 2014 02:38:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCEC1A7000 for ; Tue, 14 Oct 2014 02:38:39 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3809CA4EF2E3E; Tue, 14 Oct 2014 09:38:35 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9E9cGqT011002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 11:38:35 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.228]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 11:38:29 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin , Leeyoung , Daniele Ceccarelli , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAUUWIA Date: Tue, 14 Oct 2014 09:38:28 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/luOZbb5IGri8DJaLRjhZHFOBQgc Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 09:38:46 -0000 SGkgSWdvciwNCg0KIiBJQuOAi05vLiBJIGFtIHNheWluZyB0aGF0IGludGVyZmFjZSBCIGFuZCBD IGFyZSBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMuIEZvciBleGFtcGxlLCBvbiB0aGUgcGlj dHVyZSBOZXR3b3JrIGRvbWFpbiAxIGluIG9yZGVyIHRvIHByb3ZpZGUgdGhlIGFic3RyYWN0IHRv cG9sb2d5IHRvIHRoZSBtdWx0aS12ZW5kb3IgVk5DLCBtYXkgdXNlIGZ1bGx5IG9yIHBhcnRpYWxs eSBhYnN0cmFjdCB0b3BvbG9naWVzIHByb3ZpZGVkIGJ5IG9uZSBvciBtb3JlIGxvd2VyIHRpZXIg dHJhbnNwb3J0IGRvbWFpbnMuDQpMaWtld2lzZSwgQ3VzdG9tZXIgMSBvbiB0aGUgcGljdHVyZSBt YXkgdXNlIGFuIGFic3RyYWN0IHRvcG9sb2d5IHByb3ZpZGVkIGJ5IE11bHRpLWRvbWFpbiBuZXR3 b3JrICh0aGUgVk5DIG9uIHRoZSBwaWN0dXJlIGlzIHBhcnQgb2YpLg0KSW4gb3RoZXIgd29yZHMs IHRoZSBzYW1lIGludGVyZmFjZSBDIGFuZCB0aGUgc2FtZSBzZXQgb2YgbW9kZWxzLCBjb3VsZCBi ZSB1c2VkICBoaWVyYXJjaGljYWxseS4gDQoNCklnb3IiDQoNCkkgdGVuZCB0byBkaXNhZ3JlZSBo ZXJlLiBXaGF0IHRoYXQgY2FuIGJlIGRpc2N1c3NlZCBpbiBteSB2aWV3IGl0IGlzIHRoZSBuZWVk IG9yIG5vdCBvZiBpbnRlcmZhY2UgQy4gV2hhdCBWTkMgaXMgZ29pbmcgdG8gcHJvdmlkZSBpcyBh IGRvdWJsZSBmdW5jdGlvbiBvZiB2aXJ0dWFsaXplciBvZiB0aGUgbmV0d29yayB0b3dhcmRzIGNs aWVudCBhcHBsaWNhdGlvbiBsZXZlbCBhbmQgb3JjaGVzdHJhdGlvbiwgZHVlIHRvIHRoZSBuZWVk IHRvIHNwYW4gbXVsdGlwbGUgKHZpcnR1YWwpTkVzIG9yIG11bHRpcGxlIG5ldHdvcmsgZG9tYWlu IC4gSWYgd2UgaW1tbWFnaW5lIHRvIGVuY29tcGFzcyB0aGVzZSBmdW5jdGlvbmFsbHkgaW50byBv bmx5IG9uZSBTRE4gY29udHJvbGxlciAsIG1hbmFnaW5nIGFsbCB2aXJ0dWFsIG5ldHdvcmsgeW91 IHdvdWxkIG5vdCB1c2UgYW5vdGhlciBpbnRlcmZhY2UgYmV0d2VlbiBWTkMgYW5kIFBOQy4NCkJ1 dCBoZXJlIFlvdW5nIHB1dCBjb3JyZWN0bHkgc29tZSBwcm9ibGVtcyBhbmQgaXQgaXMgdGhlIGNv cnJlY3QgdGltZSBJIHRoaW5rIHRvIGNvbnNpZGVyIGFsbCB0aGUgYXNwZWN0cy4NCkJ1dCB0b3dh cmRzIGNsaWVudCBhcHBsaWNhdGlvbiB0aGVyZSBpcyBhbm90aGVyIGxldmVsIG9mIGFic3RyYWN0 aW9uLCBhIHJlYWwgdmlydHVhbGl6YXRpb24gKHRvIGNsaWVudCkgb2YgcmVzb3VyY2VzIHdpdGgg ZGlmZmVyZW50IGdyYW51bGFyaXR5IGFuZCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHNldCBvZiBp bmZvcm1hdGlvbiBuZWVkZWQgdG8gdGhlIGxvd2VyIGxldmVsIG9mIGNvbnRyb2xsZXIsIGFzIHdl bGwgZXhwbGFpbmVkIGJ5IFlvdW5nLg0KSXQgY2FuIGRlYmF0ZSBpZiBhbm90aGVyIHNlcGFyYXRl IGVudGl0eSBhcyBWTkMgY2FuIGJlICwgaW4gdGhpcyBhcmNoaXRlY3R1cmUsIHRoZSBnb29kIGNo b2ljZSwgYnV0IEkgZG8gbm90IGhhdmUgcHJlY2x1c2lvbiBvbiB0aGF0LiANCkkgaW5zdGVhZCBz aGFyZSB5b3VyIHNlbnRlbmNlIGFib3V0IGhpZXJhcmNoaWNhbCBsZXZlbCBvZiBjb250cm9sbGVy LiANCg0KVGhhbmtzDQoNClJlZ2FyZHMNClNlcmdpbw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBBQ1ROIFttYWlsdG86YWN0bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSWdvciBCcnlza2luDQpTZW50OiBtYXJ0ZWTDrCAxNCBvdHRvYnJlIDIwMTQgMDI6MDEN ClRvOiBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBEYW5pZWxlIENlY2NhcmVs bGk7IEtpbmcsIERhbmllbDsgYWN0bkBpZXRmLm9yZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdt YWlsLmNvbQ0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUmU6IFtBY3RuXSBkcmFm dC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQoNCllvdW5nLA0K DQoNCj09PeOAi0FmdGVyIGFsbCB3ZSBhcmUgYWdyZWVpbmcgd2l0aCB0aGUgaW50ZXJmYWNlcyBv ZiBBQ1ROIGludGVyZXN0IGFyZSBJbnRlcmZhY2UgQiBhbmQgQywgcmlnaHQ/DQoNCklC44CLTm8u IEkgYW0gc2F5aW5nIHRoYXQgaW50ZXJmYWNlIEIgYW5kIEMgYXJlIGV4YWN0bHkgdGhlIHNhbWUg aW50ZXJmYWNlcy4gRm9yIGV4YW1wbGUsIG9uIHRoZSBwaWN0dXJlIE5ldHdvcmsgZG9tYWluIDEg aW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgdG8gdGhlIG11bHRpLXZl bmRvciBWTkMsIG1heSB1c2UgZnVsbHkgb3IgcGFydGlhbGx5IGFic3RyYWN0IHRvcG9sb2dpZXMg cHJvdmlkZWQgYnkgb25lIG9yIG1vcmUgbG93ZXIgdGllciB0cmFuc3BvcnQgZG9tYWlucy4NCkxp a2V3aXNlLCBDdXN0b21lciAxIG9uIHRoZSBwaWN0dXJlIG1heSB1c2UgYW4gYWJzdHJhY3QgdG9w b2xvZ3kgcHJvdmlkZWQgYnkgTXVsdGktZG9tYWluIG5ldHdvcmsgKHRoZSBWTkMgb24gdGhlIHBp Y3R1cmUgaXMgcGFydCBvZikuDQpJbiBvdGhlciB3b3JkcywgdGhlIHNhbWUgaW50ZXJmYWNlIEMg YW5kIHRoZSBzYW1lIHNldCBvZiBtb2RlbHMsIGNvdWxkIGJlIHVzZWQgIGhpZXJhcmNoaWNhbGx5 LiANCg0KSWdvcg0KDQpJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdl ZW4gdHJhbnNwb3J0IGRvbWFpbiBzZXJ2ZXIgYW5kICB0cmFuc3BvcnQgZG9tYWluIGNsaWVudC4g SSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSB2ZXJ5IHNhbWUgaW50ZXJmYWNlIGNhbiBiZSB1c2VkIGJl dHdlZW4gYSBtdWx0aS1kb21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkgYW5kIGl0cyBj bGllbnRzLiBOb3QgYWxsIHN1Y2ggY2xpZW50cyBhcmUgZHVtYiwgYXMgRGFuaWVsZSBjbGFpbXMs IGFuZCBvbmx5IGNhcmUgYWJvdXQg4oCcYSBnaXZlbiBhbW91bnQgb2YgR2JwcyBmcm9tIEEgdG8g QuKAnS4gSXQgaXMgZWFzeSB0byBlbnZpc2lvbiB0aGF0IHNvbWUgb2YgdGhlIGNsaWVudHMgd291 bGQgd2FudCBmcm9tIFRlbGVmb25pY2EgYSBjb3VwbGUgb2YgU1JMRy1kaXNqb2ludCBhYnN0cmFj dCBsaW5rcywgc28gdGhhdCB0aGUgY2xpZW50cyBjYW4gaGF2ZSBhIHNheSBpbiB0aGUgcGxhY2Vt ZW50IG9mIHRoZWlyICBzZXJ2aWNlcyBhY3Jvc3MgdGhlIFRlbGVmb25pa2EgbmV0d29yay4gVGhy ZWUgcG9pbnRzIGhlcmU6DQoNCmEpICAgICAgVGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gY29u ZmlndXJlIGZ1bGx5IG9yIHBhcnRpYWxseSB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgaGUgd2FudHMg dGhlIG5ldHdvcmsgdG8gcHJlc2VudCB0byBoaW07DQoNCmIpICAgICAgVGhlIHNhaWQgYWJzdHJh Y3QgdG9wb2xvZ3kgY291bGQgYmUgYXMgc2ltcGxlIChlLmcuIGEgc2luZ2xlIGFic3RyYWN0IG5v ZGUpIG9yIGFzIGNvbXBsZXggKGUuZy4gTiBhYnN0cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBi eSBNIGFic3RyYWN0IGxpbmtzKSBhcyB0aGUgY2xpZW50IHdhbnRzIGl0IHRvIGJlIChzdWJqZWN0 IHRvIHRoZSBwcm92aWRlcuKAmXMgYXBwcm92YWwpDQoNCmMpICAgICAgVGhlIGFic3RyYWN0IHRv cG9sb2d5IHByZXNlbnRlZCB0byB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVkIGZy b20gdGhlIHByb3ZpZGVy4oCZcyBhY3R1YWwgdG9wb2xvZ3kuDQoNClRoZXJlZm9yZSB0aGUgc2Ft ZSBpbnRlcmZhY2Uvc2V0IG9mIG1vZGVscyBjYW4gYmUgdXNlZCBiZXR3ZWVuIGFueSB0cmFuc3Bv cnQgbmV0d29yayBwcm92aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhlcm1vcmUsIHRoZSBpbnRl cmZhY2UgY2FuIGJlIHVzZWQgaW4gdGhlIGhpZXJhcmNoaWNhbCB3YXksIHRoYXQgaXMsIGEgY2xp ZW50IG9mIGEgdHJhbnNwb3J0IGRvbWFpbiBjYW4gc2VydmUgaXRzIG93biBjbGllbnRzIHVzaW5n IHRoZSBzYW1lIGludGVyZmFjZSBhcyBpdCB1c2VzIHRvIHRhbGsgdG8gaXRzIG93biBwcm92aWRl cihzKQ0KDQpIZXJlIEkgd291bGQgbGlrZSB0byBnaXZlIHlvdSBhIGxpdHRsZSBjbGVhcmVyIHBp Y3R1cmUgb24gbXVsdGktZG9tYWluIGlzc3Vlcy4NCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0rICAg Ky0tLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0rDQogICB8ICAgQ3VzdG9tZXIg MSAgIHwgICB8ICAgQ3VzdG9tZXIgMiAgfCAgLi4uIHwgQ3VzdG9tZXIgTSAgIHwNCiAgICstLS0t LS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0tKw0K ICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgLw0KICAgICAg ICAgICAgICAgICAgICBcICAgICAgICAgICAgfCAgICAgICAgICAgICAvDQogICAgICAgSW50ZXJm YWNlIEIgICBcICAgICAgICAgICB8ICAgICAgICAgICAgLw0KICAgICAgICAgICAgICAgICAgICAg IFwgICAgICAgICAgfCAgICAgICAgICAgLw0KICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwgICBWTkMgTXVsdGktZG9t YWluICAgfCBFMkUgYWJzdHJhY3QNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgQ29vcmRp bmF0aW9uICAgIHwgdG9wb2xvZ3kgY3JlYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgIHwg ICAgICAgICAgICBcDQogICAgICAgIEludGVyZmFjZSBDICAgLyAgICAgICAgICB8ICAgICAgICAg ICAgIFwgIE5ldHdvcmsgVG9wb2xvZ3kNCiAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAg IHwgICAgICAgICAgICAgIFwgKGFic3RyYWN0KQ0KICAgICAgICAgICAgICAgICAgICAvICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIFwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgKy0tLS0t LS0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgTmV0d29yayBEb21h aW4gMSB8ICAgfCBOZXR3b3JrIERvbWFpbiAyIHwgLi4gfCBOZXR3b3JrIERvbWFpbiBOIHwNCiAg ICstLS0tLS0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgICAgICAgVmVuZG9yIFggICAgICAgICAgICAgICAgIFZlbmRvciBZICAg ICAgICAgICAgICAgVmVuZG9yIFoNCg0KDQpXaGF0IGlzIHNpdHRpbmcgYWJvdmUg4oCcVk5D4oCd ICh0aGF0IGNvb3JkaW5hdGVzIG92ZXIgbXVsdGktZG9tYWluIGNvbnRyb2xsZXJzKSBjYW4gYmUg YW4gaW50ZXJuYWwgc2VydmljZSBvcmdhbml6YXRpb24gKG9mIHRoZSBzYW1lIG9wZXJhdG9yKSBv ciBzZXJ2aWNlIHByb3ZpZGVycyAoZGlmZmVyZW50IG9wZXJhdG9ycywgZm9ybWluZyBjYXJyaWVy cyBvZiBjYXJyaWVyKS4gVGhlIGNvbnRyb2wgZW50aXR5IG9mIHRoZXNlIGVudGl0aWVzIGlzIHJl ZmVycmVkIHRvIGFzIEN1c3RvbWVyIE5ldHdvcmsgY29udHJvbCAoQ05DKS4gVGhlIFZOQyDigJND TkMgaW50ZXJmYWNlIChJbnRlcmZhY2UgQikgaGFzIGRpZmZlcmVudCByZXF1aXJlbWVudHMgdGhh biB0aGUgVk5DLVBOQyBpbnRlcmZhY2UgKEludGVyZmFjZSBDKS4gVG9wb2xvZ3kgYWJzdHJhY3Rp b24gaXMganVzdCBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyBhbmQgaW4gbXVsdGktZG9tYWluIGNh c2UsIHRoZSBWTkMgaXMgcGVyZm9ybWluZyBtdWx0aS1kb21haW4gY29vcmRpbmF0aW9uIGZ1bmN0 aW9uLiBWTkMgbmVlZHMgdG8gaGF2ZSBhIHN0YW5kYXJkIGludGVyZmFjZSB0aGF0IGVuYWJsZSBj b21tdW5pY2F0aW9ucyB3aXRoIGRpZmZlcmVudCBraW5kcyBvZiBkb21haW4gbmV0d29yayBjb250 cm9sL21hbmFnZW1lbnQgY29udHJvbCAod2hpY2ggaXMgcmVmZXJyZWQgdG8gYXMgUE5DLCB5b3Ug Y2FsbCBBTkMpLiBFYWNoIGRvbWFpbiBoYXMgaXRzIG93biB3YXlzIG9mIGNvbnRyb2xsaW5nIGl0 cyBuZXR3b3JrLCB3aGljaCBBQ1ROIGlzIG5vdCB0b3VjaGluZyB0aG9zZSBhdCBhbGwuIFdoYXRl dmVyIHRoZSBjaG9pY2VzIG9mIHZlbmRvciBjb250cm9sIHJlZ2ltZSB3aWxsIGNvbnRpbnVlIHRv IGJlIGVtcGxveWVkIChHTVBMUy9BU09OLCBQTk5JLCBOTVMsIE9wZW5GbG93LCBldGMuKS4NCg0K Rm9yIHRoaXMgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBhc3N1bWVkIGJ5IFZO QyBzaG91bGQgYmUgb3BlcmF0ZWQgb24gYW4gYWJzdHJhY3QgbGV2ZWwuIFdlIGRvbuKAmXQgd2Fu dCB0byBpbmplY3QgdGhlIHNhbWUgbGV2ZWwgb2YgYWN0dWFsIG5ldHdvcmsgdG9wb2xvZ3kgKGUu Zy4sIFRFRCkgYXMgdGhlIGRvbWFpbiBjb250cm9sbGVyIG9wZXJhdGVzIGl0cyBwaHlzaWNhbC9h Y3R1YWwgbmV0d29ya3MuIElzIHRoaXMgYWdyZWVhYmxlPyBZb3Ugc2FpZCBhYm92ZSB0aGlzIGlu IGMpIFRoZSBhYnN0cmFjdCB0b3BvbG9neSBwcmVzZW50ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21w bGV0ZWx5IGRlY291cGxlZCBmcm9tIHRoZSBwcm92aWRlcuKAmXMgYWN0dWFsIHRvcG9sb2d5Lg0K DQpOb3cgdGhlIFZOQyAobXVsdGktZG9tYWluIGNvb3JkaW5hdG9yKSBuZWVkcyB0byBjb29yZGlu YXRlIHNpZ25hbGluZyBhY3Jvc3MgbXVsdGktZG9tYWluIGNvbnRyb2xsZXJzIChpbiB0ZXJtcyBv ZiB0aGUgc2VxdWVuY2Ugb2YgdGhlIGVuZC10by1lbmQgcGF0aCBhY3Jvc3MgbXVsdGlwbGUgZG9t YWlucykuIFRoaXMgaXMgYSBuZXcgZWxlbWVudCBJIGJlbGlldmUgQUNUTiB3aWxsIGhhdmUgdG8g ZGV2ZWxvcC4gVGhpcyBpbnRlcmZhY2UgQyAoVk5DLVBOQykgaXMgdmVyeSBkaWZmZXJlbnQgZnJv bSBJbnRlcmZhY2UgQiAoQ05DLVZOQykuIFRoZXJlIGFyZSBvdGhlciBkaWZmZXJlbmNlcyAocGxl YXNlIHNlZSBTZWN0aW9uIDYuNSBvZiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50KS4gIEJ1dCBJIGFn cmVlIHdpdGggeW91IHRoYXQgZnJvbSBhbiBhYnN0cmFjdCB0b3BvbG9neSBzdGFuZHBvaW50LCBz aW1pbGFyIG1vZGVsIHdvcmtzIGZvciBJbnRlcmZhY2VzIEIgYW5kIEMgYXMgeW91IHNhaWQgIGIp ICAgICAgVGhlIHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kgY291bGQgYmUgYXMgc2ltcGxlIChlLmcu IGEgc2luZ2xlIGFic3RyYWN0IG5vZGUpIG9yIGFzIGNvbXBsZXggKGUuZy4gTiBhYnN0cmFjdCBu b2RlcyBpbnRlcmNvbm5lY3RlZCBieSBNIGFic3RyYWN0IGxpbmtzKSBhcyB0aGUgY2xpZW50IHdh bnRzIGl0IHRvIGJlIChzdWJqZWN0IHRvIHRoZSBwcm92aWRlcuKAmXMgYXBwcm92YWwpLg0KDQpC ZXN0IHJlZ2FyZHMsDQpZb3VuZw0KDQoNCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJ QnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQg OToxNyBBTQ0KVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSBDZWNjYXJlbGxp OyBLaW5nLCBEYW5pZWw7IExlZXlvdW5nOyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1 eXVhbmZAZ21haWwuY29tDQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJh ZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgU2VyZ2lv LA0KQSBjb3VwbGUgb2YgY29tbWVudHMgaW4gbGluZS4NCg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9t OiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgW21haWx0bzpzZXJnaW8uYmVsb3R0aUBhbGNhdGVs LWx1Y2VudC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQgOToxNSBBTQ0KVG86 IElnb3IgQnJ5c2tpbjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IExlZXlvdW5n OyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29tDQpDYzogVmFy bWEsIEV2ZSBMIChFdmUpOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykNClN1YmplY3Q6IFJFOiBk cmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBJZ29y LA0KDQpQbGVhc2UsIHNlZSBpbiBsaW5lDQoNClJlZ2FyZHMNClNlcmdpbw0KDQoNCkZyb206IEln b3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IHZlbmVy ZMOsIDEwIG90dG9icmUgMjAxNCAyMjozNw0KVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywg RGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3Jn PG1haWx0bzphY3RuQGlldGYub3JnPjsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+ OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEs IEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29y ay0wMy50eHQgY29tbWVudHMNCg0KSGkgRGFuaWVsZSwNClBsZWFzZSwgc2VlIGluIGxpbmUuDQpJ Z29yDQoNCkZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxs aUBlcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTAsIDIwMTQgMToyNSBQTQ0K VG86IElnb3IgQnJ5c2tpbjsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lP IChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgZGllZ29AdGlk LmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFu ZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQt Y2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgSWdvciwNCg0K V2hhdCBkbyB5b3UgbWVhbiBieSBjbGllbnQgaGVyZT8gVGhlIG9uZSB0aGF0IGlzIHRoZSBkb2N1 bWVudCBpcyBjYWxsZWQg4oCcc2VydmljZSBwcm92aWRlcuKAnSBvciB0aGUgb25lIHRoYXQgaXMg Y2FsbGVkIOKAnGNsaWVudOKAnSA/IEZyb20gd2hhdCB5b3Ugc2VuZCBJIHRlbmQgdG8gdGhpbmsg eW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyLCBidXQgSSBtaWdodCBi ZSB3cm9uZywgcGxlYXNlIGNvcnJlY3QgbWUuDQoNCklCPj4gQnkgY2xpZW50IEkgbWVhbiB0aGUg Y2xpZW50IG9mIGEgdHJhbnNwb3J0IGRvbWFpbiwgdGhlIG9uZSB3aG8gc3BlYWtzIE5ldGNvbmYv UmVzdGNvbmYgdG8gdGhlIHRyYW5zcG9ydCBkb21haW4uIFRoZSBndXkgd2hvIHNwZWFrcyBmcm9t IHRoZSBvdGhlciBlbmQgKGkuZS4gb24gYmVoYWxmIG9mIHRoZSB0cmFuc3BvcnQgc2VydmljZSBw cm92aWRlcikgIGlzIHRoZSB0cmFuc3BvcnQgZG9tYWlu4oCZcyBIeXBlcnZpc29yLg0KDQpTQj4+ PiBJdCBpcyBjbGVhciB3aGF0IHlvdSBpbnRlbmQgaGVyZSwgZXZlbiBpZiB3b3JkIGNsaWVudCBp dCBzZWVtcyB0byBtZSBtb3JlIHJlbGF0ZWQgdG8gYXBwbGljYXRpb24gdGhhbiB0byBhIHNlcnZp Y2UgcHJvdmlkZXIuDQoNCklCPj4gSSBhbSB0YWxraW5nIGFib3V0IHRoZSBpbnRlcmZhY2UgYmV0 d2VlbiB0cmFuc3BvcnQgZG9tYWluIHNlcnZlciBhbmQgIHRyYW5zcG9ydCBkb21haW4gY2xpZW50 LiBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHZlcnkgc2FtZSBpbnRlcmZhY2UgY2FuIGJlIHVzZWQg YmV0d2VlbiBhIG11bHRpLWRvbWFpbiBwcm92aWRlciAoZS5nLiBUZWxlZm9uaWthKSBhbmQgaXRz IGNsaWVudHMuIE5vdCBhbGwgc3VjaCBjbGllbnRzIGFyZSBkdW1iLCBhcyBEYW5pZWxlIGNsYWlt cywgYW5kIG9ubHkgY2FyZSBhYm91dCDigJxhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0 byBC4oCdLiBJdCBpcyBlYXN5IHRvIGVudmlzaW9uIHRoYXQgc29tZSBvZiB0aGUgY2xpZW50cyB3 b3VsZCB3YW50IGZyb20gVGVsZWZvbmljYSBhIGNvdXBsZSBvZiBTUkxHLWRpc2pvaW50IGFic3Ry YWN0IGxpbmtzLCBzbyB0aGF0IHRoZSBjbGllbnRzIGNhbiBoYXZlIGEgc2F5IGluIHRoZSBwbGFj ZW1lbnQgb2YgdGhlaXIgIHNlcnZpY2VzIGFjcm9zcyB0aGUgVGVsZWZvbmlrYSBuZXR3b3JrLiBU aHJlZSBwb2ludHMgaGVyZToNCg0KYSkgICAgICBUaGUgY2xpZW50IHdpbGwgYmUgYWJsZSB0byBj b25maWd1cmUgZnVsbHkgb3IgcGFydGlhbGx5IHRoZSBhYnN0cmFjdCB0b3BvbG9neSBoZSB3YW50 cyB0aGUgbmV0d29yayB0byBwcmVzZW50IHRvIGhpbTsNCg0KYikgICAgICBUaGUgc2FpZCBhYnN0 cmFjdCB0b3BvbG9neSBjb3VsZCBiZSBhcyBzaW1wbGUgKGUuZy4gYSBzaW5nbGUgYWJzdHJhY3Qg bm9kZSkgb3IgYXMgY29tcGxleCAoZS5nLiBOIGFic3RyYWN0IG5vZGVzIGludGVyY29ubmVjdGVk IGJ5IE0gYWJzdHJhY3QgbGlua3MpIGFzIHRoZSBjbGllbnQgd2FudHMgaXQgdG8gYmUgKHN1Ympl Y3QgdG8gdGhlIHByb3ZpZGVy4oCZcyBhcHByb3ZhbCkNCg0KYykgICAgICBUaGUgYWJzdHJhY3Qg dG9wb2xvZ3kgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQgaXMgY29tcGxldGVseSBkZWNvdXBsZWQg ZnJvbSB0aGUgcHJvdmlkZXLigJlzIGFjdHVhbCB0b3BvbG9neS4NCg0KVGhlcmVmb3JlIHRoZSBz YW1lIGludGVyZmFjZS9zZXQgb2YgbW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55IHRyYW5z cG9ydCBuZXR3b3JrIHByb3ZpZGVyIGFuZCBpdHMgY2xpZW50LiBGdXJ0aGVybW9yZSwgdGhlIGlu dGVyZmFjZSBjYW4gYmUgdXNlZCBpbiB0aGUgaGllcmFyY2hpY2FsIHdheSwgdGhhdCBpcywgYSBj bGllbnQgb2YgYSB0cmFuc3BvcnQgZG9tYWluIGNhbiBzZXJ2ZSBpdHMgb3duIGNsaWVudHMgdXNp bmcgdGhlIHNhbWUgaW50ZXJmYWNlIGFzIGl0IHVzZXMgdG8gdGFsayB0byBpdHMgb3duIHByb3Zp ZGVyKHMpDQoNCk1vcmVvdmVyIEkgd291bGQgYXZvaWQgaW4gdGhpcyBwaGFzZSB0byBtZW50aW9u IGFueSByZWZlcmVuY2UgdG8gcHJvdG9jb2wgaW1wbGVtZW50YXRpb24gKGUuZy4gTmV0Y29uZi9S ZXN0Y29uZikgOiBJIHRoaW5rIHdlIGFyZSBpbiB0aGUgcGhhc2UgdG8gdW5kZXJzdGFuZCBhcmNo aXRlY3R1cmUsIHdoYXQgYXJlIHRoZSByZWxldmFudCBpbnRlcmZhY2VzLCBhbmQgd2hhdCBpbmZv cm1hdGlvbiBpcyBleGNoYW5nZWQgb3ZlciB0aGUgcmVmZXJlbmNlIHBvaW50cy9pbnRlcmZhY2Vz LiBJIGd1ZXNzIHRoaXMgaXMgY2xlYXJseSBzdGF0ZWQgYWxzbyBpbiB0aGUgY2hhcnRlciBvZiBC b0YuDQoNCklCPj4gQWdyZWUuIEkgdXNlZCBOZXRjb25mL1Jlc3Rjb25mIGFzIGFuIGV4YW1wbGUg dG8gbWFrZSBpdCBjbGVhciB3aGF0IGludGVyZmFjZSBJIHdhcyB0YWxraW5nIGFib3V0Lg0KDQog QXQgYW4gYXBwcm9wcmlhdGUgdGltZSDigJMgY2VydGFpbmx5IG5vdCBub3cg4oCTIHRoZSBuZXh0 IHN0ZXAgaXMgdG8gY2hlY2sgd2l0aCBvdGhlciBTRE9zIG9uIHRoZSBhdmFpbGFiaWxpdHkgb2Yg cmVsZXZhbnQgY29yZS90ZWNobm9sb2d5IHNwZWNpZmljL2FwcGxpY2F0aW9uIHNwZWNpZmljIGlu Zm9ybWF0aW9uIG1vZGVsIOKAnGZyYWdtZW50c+KAnSwgYW5kIHRoZW4gZmluYWxseSBwcm9jZWVk IG9uIHRoZSBwYXRoIG9mIHBydW5pbmcvcmVmYWN0b3JpbmcgYW5kIG1hcHBpbmcgdG8gUkVTVC9K U09OLCBOZXRjb25mL1lBTkcsIGFuZCBhbnkgb3RoZXIgcG9zc2libGUgZGF0YSBtb2RlbGluZyBh bmQgY29uZmlndXJhdGlvbiBwcm90b2NvbCBleGlzdGluZy4gVGhpcyBpcyBteSB1bmRlcnN0YW5k aW5nICBvZiB0aGUgQm9GIHNjb3BlIC4NCg0KSSBkb27igJl0IHRoaW5rIHRoZSBjbGllbnQgb2Yg dGhlIG11bHRpLWRvbWFpbiBuZXR3b3JrIHdhbnRzIHRvIGhhdmUgYSBzbyBkZXRhaWxlZCB2aWV3 IG9mIHRoZSBuZXR3b3JrLCBoZSBkb2VzIG5vdCBjYXJlIGFib3V0IGRvbWFpbnMsIGludGVyIGRv bWFpbiBsaW5rcyBvciB3aGF0ZXZlciwgSSB3b3VsZCBzYXkgaGUgb25seSBjYXJlcyBhYm91dCBh IGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBCIHdpdGggYSBnaXZlbiBtYXggZGVsYXkg YW5kIHByb2JhYmx5IHNvbWUgZGl2ZXJzaXR5IHBhcmFtZXRlcnMuDQoNCklCPj4gQWdhaW4sIGJ5 IGNsaWVudCBJIG1lYW4gbXVsdGktZG9tYWluIG5ldHdvcmsgY29udHJvbGxlciAoZS5nLiBUZWxl Zm9uaWNhIFNETiBjb250cm9sbGVyKSwgbm90IHRoZSBjbGllbnQgdXNpbmcgc2VydmljZXMgb2Yg dGhlIG11bHRpLWRvbWFpbiBuZXR3b3JrIChpLmUuIG5vdCB0aGUgVGVsZWZvbmljYSBjbGllbnRz KS4gU3VjaCBjbGllbnQgdXNlcyAgdGhlIHRyYW5zcG9ydCBkb21haW5zIGZvciBhIHJlYXNvbi4g 4oCcYSBnaXZlbiBhbW91bnQgb2YgR2JwcyBmcm9tIEEgdG8gQuKAnSBpcyB0b28gbG9vc2UgYW5k IGxpdHRsZSBmb3IgdGhlIGNsaWVudCB0byBkbyB0aGUgbmV0d29yayBwbGFubmluZy4gSU1PIHRo ZSBjbGllbnQgbmVlZHMgdG8gKnBsYW4qIHRoZSBhYnN0cmFjdCB0b3BvbG9naWVzIHByb3ZpZGVk IGJ5IHRoZSB0cmFuc3BvcnQgZG9tYWlucyB0aGUgc2FtZSBvciBzaW1pbGFyIHdheSBhcyBoZSB3 b3VsZCBwbGFuIGhpcyBvd24gYWN0dWFsIHRvcG9sb2d5Lg0KDQpTQj4+PiB5ZXMsIHN1cmUsIGlu IHlvdSB2aWV3IG9mIOKAnGNsaWVudOKAnSAsIHRoaXMgaXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIg RGFuaWVsZSBpcyB0YWxraW5nLCBzbyBhbiBhYnN0cmFjdCB2aWV3IG9mIHdoYXQgaXMgdGhlIHJl YWwgdHJhbnNwb3J0IG5ldHdvcmsgaXMgY29uc2lkZXJlZCBhdCB0aGlzIGxldmVsLiBBcyBJIHNh aWQgdG8gWW91bmcsIGluIG15IHByZXZpb3VzIG1haWwsIGluIHRoZSBjYXNlIG9mIGEgc2luZ2xl IGRvbWFpbiBzY2VuYXJpbyBWTkMgYW5kIFBOQyBjb3VsZCBhbHNvIGNvaW5jaWRlIGJ1dCBpbiBj YXNlIG9mIGEgbXVsdGktZG9tYWluIHNjZW5hcmlvcyB0aGUgc2NvcGUgaXMgdG8gcHJvdmlkZSB0 byBhcHBsaWNhdGlvbiBsYXllciBhIHNpbmdsZSB2aXJ0dWFsaXplZCB2aWV3IG9mIHRoZSB1bmRl cmxpbmUgbXVsdGkgZG9tYWluIG5ldHdvcmsuDQoNCk9uIHRoZSBvdGhlciBzaWRlLCB0aGUgb25l IHRoYXQgY2FyZXMgYWJvdXQgYWxsIG9mIHRoZSBpc3N1ZXMgeW91IGxpc3RlZCBpcyB0aGUgc2Vy dmljZSBwcm92aWRlciAoYXMgcGVyIGFjdHVhbCBkb2N1bWVudCB0ZXJtaW5vbG9neSkuIEhvd2V2 ZXIgYWxzbyB0aGUgc2VydmljZSBwcm92aWRlciBkb2VzIG5vdCBnbyBpbnRvIHBoeXNpY2FsIGlt cGFpcm1lbnQgZGV0YWlscy4gSGUgY2FyZXMgYWJvdXQgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhl IGJvcmRlcnMgb2YgdGhlIGRvbWFpbnMsIGludGVyIGRvbWFpbiBsaW5rcy4gSG93IHN1Y2ggY29u bmVjdGl2aXR5IGlzIHByb3Zpc2lvbmVkL21hbmFnZWQgaXMgdGhlIG5ldHdvcmsgcHJvdmlkZXIg YnVzaW5lc3MuIFRoZSBuZXR3b3JrIHByb3ZpZGVzIG1pZ2h0IGJlIHVzaW5nIEdNUExTLCBOTVMg YW5kIE9ORiBjb250cm9sbGVyIHdpdGggT3BlbiBGbG93IG9yIHdoYXRldmVyIHRvIGNvbnRyb2wg dGhlIG5ldHdvcmsuIE1heWJlIGNhbGxpbmcgaXQgUE5DIGlzIGNvbmZ1c2luZz8gVGhlIFBOQyBj YW4gYmUgYW55IG9mIHRoZSB0aGluZ3MgSeKAmXZlIGxpc3RlZCBhbmQgbXVjaCBtb3JlLg0KDQpJ Qj4+IEluIHRoaXMgY2FzZSBteSBjbGllbnQgaXMgeW91ciBzZXJ2aWNlIHByb3ZpZGVyIDs9KS4g WW91IGFyY2hpdGVjdHVyYWxseSBzZXBhcmF0ZSBjbGllbnQgZnJvbSB0aGUgc2VydmljZSBwcm92 aWRlciwgYmVjYXVzZSB5b3UgcHJvYmFibHkgYmVsaWV2ZSB0aGF0IGl0IGlzIHBvc3NpYmxlIHRv IHN0YW5kYXJkaXplIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgdHdvLiBJIGRpc2FncmVlIHdp dGggdGhhdCBhbmQgZG9u4oCZdCB0aGluayBBQ1ROIHNob3VsZCB3b3JrIG9uIHRoaXMuIEluIHRo ZSBjb250ZXh0IG9mIEFDVE4gSSBzZWUgb25seSB0d28gY29uc3RydWN0czogVHJhbnNwb3J0IGRv bWFpbiBjb250cm9sbGVyICh0cmFuc3BvcnQgc2VydmljZSBwcm92aWRlcikgYW5kICBUcmFuc3Bv cnQgY2xpZW50IGNvbnRyb2xsZXIgKHRyYW5zcG9ydCBzZXJ2aWNlIHVzZXIpLg0KDQpTQj4+PiBB Q1ROIGhlcmUgaXMgbm90IHJlaW52ZW50aW5nIHRoZSB3aGVlbCAsIGluIG90aGVyIFNETyBTRE4g c3BlY2lmaWMgaXMgY29uc2lkZXJlZCAgdGhlIGFwcGxpY2F0aW9uIGxheWVyICwgYW5kIHRoZSBp bnRlcmZhY2UgYmV0d2VlbiBBTCBhbmQgU0ROIGNvbnRyb2xsZXIgKGluIHRoaXMgY2FzZSB0aGUg Vk5DIG9mIEFDVE4pIC4gVGhpcyBpbnRlcmZhY2UgcGVybWl0IHRvIGFueSBjbGllbnQgdG8gZGly ZWN0bHkgaW1wYWN0IHRvIGhpcyBvd24gc2VydmljZXMgYW5kIGhpcyBvd24g4oCcdmlydHVhbGl6 ZWTigJ0gcmVzb3VyY2VzIC4NCg0KDQpIZW5jZSB0aGUgaW50ZXJmYWNlcyB0byBiZSBjb25zaWRl cmVkIGFyZSB0d28sIG5vdCB0aHJlZSAoYXMgRGFuIHNhaWQpIEkgdGhpbmsgdGhpcyByZXBsaWVz IHRvIHF1ZXN0aW9ucyAxIGFuZCAzLiBKdXN0IHRvIGFkZCBzb21ldGhpbmcgcmVnYXJkaW5nIDIs IEkgd291bGQgc2F5IHRoYXQgdGhleSBuZWVkIGp1c3QgYSBzaW5nbGUgZW50cnkgcG9pbnQgdG8g dGhlIG5ldHdvcmsgY29udHJvbCAoY291bGQgYmUgYSBzbWFsbCBwaWVjZSBvZiBjb2RlIHJ1bm5p bmcgb24gdG9wIG9mIHRoZSBQQ0Ugb2YgeW91ciBHTVBMUyBkb21haW4pLCB3aGljaCBhY3RzIGFz IGFuIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBWTkMgYW5kIHRoZSBjb250cm9sIHBsYW5lIG9mIHlv dXIgbmV0d29yayBhbmQgcGVyZm9ybXM6IOKAnC0gTWFwcGluZyBvZiBwaHlzaWNhbCBhbmQgdmly dHVhbCByZXNvdXJjZXPigJ0gYW5kICDigJxSZXF1ZXN0czogcGF0aCwgcHJvdmlzaW9uLCBtb2Rp ZnkgYW5kIHJlc3RvcmXigJ0uDQoNCklCPj4gQXMgSSBzYWlkLCB0aGlzIGlzIHRoZSB0YXNrIG9m IHRoZSB0cmFuc3BvcnQgZG9tYWluIEh5cGVydmlzb3IsIHdob3NlIHJvbGUgaXMsIGVzc2VudGlh bGx5LCB0byB0cmFuc2xhdGUgYmFjayBhbmQgZm9ydGggYWJzdHJhY3QgPD0+IGFjdHVhbCB0b3Bv bG9neSBlbGVtZW50cyBhbmQgc2VydmljZSByZXF1ZXN0cy9yZXNwb25zZXMgY29udGFpbmluZyB0 aGUgYWJzdHJhY3QvYWN0dWFsIHRvcG9sb2d5IHBhdGhzLiBJIHRoaW5rIHRoYXQgdGhlIG5vcnRo L3NvdXRoIGludGVyZmFjZSBiZXR3ZWVuIHRoZSB0cmFuc3BvcnQgZG9tYWluIEh5cGVydmlzb3Ig YW5kIHRoZSBlbnRpdHkgcmVwcmVzZW50aW5nIHRoZSBjbGllbnQgb2YgdGhlIHRyYW5zcG9ydCBk b21haW4gKG5vIG1hdHRlciBob3cgeW91IGNhbGwgaXQpIGlzIHRoZSBvbmx5IGludGVyZmFjZSBB Q1ROIGNhbiB3b3JrIG9uIHdpdGggdGhlIGhvcGUgdG8gcHJvZHVjZSBzb21ldGhpbmcgdXNlZnVs Lg0KDQpDaGVlcnMNCkRhbmllbGUNCg0KDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklC cnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IHZlbmVyZMOsIDEwIG90dG9icmUgMjAxNCAw MzoxNg0KVG86IEtpbmcsIERhbmllbDsgTGVleW91bmc7IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lP KTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxs aTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxt YWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0 OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0K WW91bmcgYW5kIERhbiwNCg0KSXQgZG9lcyBub3QgbWF0dGVyIGhvdyB5b3UgY2FsbCBtZSwgYW5k IGFzIEpvaG4gaXMgaGVscGZ1bGx5IGFwcGx5aW5nLCB5b3UgY2FuIGlnbm9yZSB3aGF0IEkgYW0g c2F5aW5nLiBCdXQgbGV0IG1lIGV4cGxhaW4gaW4gc29tZSBtb3JlIGRldGFpbHMgd2hhdCBJIG1l YW50Lg0KDQpTdXBwb3NlIHdlIGhhdmUgYSBjbGllbnQgKHN1Y2ggYXMgVEZLKSBvZiBhIG11bHRp LWRvbWFpbiB0cmFuc3BvcnQgbmV0d29yaywgd2hvIHdhbnRzIHRvIHByb3Zpc2lvbiBhbmQgbWFu aXB1bGF0ZSBlMmUgdHJhbnNwb3J0IHNlcnZpY2VzIHRoZSB3YXkgaGUgd2FudHMgaXQgKGkuZS4g YXBwbHlpbmcgaGlzIHBvbGljaWVzKS4gV2hhdCB3b3VsZCBzdWNoIGNsaWVudCBuZWVkPw0KDQoN CjEuICAgICBBbiBhY2Nlc3MgdG8gYSB1bmlmaWVkIG5ldHdvcmsgVEUgdG9wb2xvZ3kgdGhhdCBj b3VsZCBiZSB1bmRlcnN0b29kIGFuZCB1c2VkIGJ5IHRoZSBjbGllbnTigJlzIHBhdGggY29tcHV0 ZXIgdG8gc2VsZWN0IHNlcnZpY2UgZTJlIHBhdGhzLiBIb3cgZG9lcyB0aGUgY2xpZW50IGdldCBz dWNoIGEgdG9wb2xvZ3k/IFRoZSBuZWNlc3Nhcnkgb3ZlcmxheSB0b3BvbG9neSBjb21wcmlzZXMg YWJzdHJhY3QgdG9wb2xvZ2llcyBwcmVzZW50ZWQgZm9yIHRoZSBjbGllbnQgYnkgZWFjaCBvZiB0 aGUgdHJhbnNwb3J0IGRvbWFpbnMgKyBpbnRlci1kb21haW4gVEUgbGlua3MuIEhlbmNlIHdlIGFy ZSB0YWxraW5nIGFib3V0IGludGVyZmFjZSAjMSAoYW5kIGRhdGEgbW9kZWwgIzEpIGJldHdlZW4g YSBwcm92aWRlciBoeXBlcnZpc29yL1ZOQyBhbmQgdGhlIGNsaWVudCBjb250cm9sbGVyIHRvIGV4 cG9zZSBpbiBhIHVuaWZpZWQgYWJzdHJhY3QgIHdheSAgaXRzIHRvcG9sb2d5IG9uIHBlciBjbGll bnQvdGVuYW50IGJhc2lzLiBGdXJ0aGVybW9yZSwgdGhlIGNsaWVudCBjb250cm9sbGVyIGNhbiB1 c2UgdGhpcyBpbnRlcmZhY2UgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiB0byBtb2RpZnkgdGhl IHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kgKHN1YmplY3QgdG8gdGhlIHByb3ZpZGVy4oCZcyAgYXBw cm92YWwpLCBiZWNhdXNlIHRoZSBjbGllbnQgaXMgdGhlIG9ubHkgZ3V5IHdobyBrbm93cyBob3cg dGhlIGFic3RyYWN0IHRvcG9sb2d5IGV4cG9zZWQgdG8gaGltIHNob3VsZCBsb29rIGxpa2UgdG8g YmUgdXNlZnVsIChlLmcuIHdoaWNoIGFuZCBob3cgdGhlIGFic3RyYWN0IGxpbmtzIHNob3VsZCBi ZSBkaXNqb2ludCBmcm9tIGVhY2ggb3RoZXIsIGhvdyBtYW55IG9mIHRoZW0gc2hvdWxkIGJlIHBy b3ZpZGVkLCB0aGVpciBhdHRyaWJ1dGVzLCBkZXNpcmVkIHJlY292ZXJ5IGNhcGFiaWxpdGllcywg ZXRjLCkuIFRoaXMga25vd2xlZGdlIGlzIHN1cHBvc2VkIHRvIGNvbWUgZnJvbSB0aGUgY2xpZW50 4oCZcyBuZXR3b3JrIHBsYW5uaW5nLg0KDQoyLiAgICAgQSB3YXkgdG8gcHJvdmlzaW9uL21vZGlm eS9kZWxldGUgZTJlIHNlcnZpY2VzIHdpdGggdGhlIHVzZSBvZiBzbyBjb21wdXRlZCBlMmUgcGF0 aHMuIFRoZSBjbGllbnTigJlzIGNvbnRyb2xsZXIgZG9lcyB0aGF0IGJ5IGNob3BwaW5nIHRoZSBw YXRocyBpbnRvIHBlci1kb21haW4gc2VnbWVudHMgYW5kIGluc3RydWN0cyByZXNwZWN0aXZlIGRv bWFpbiBWTkNzL0h5cGVydmlzb3JzIHRvIHNldCB1cC9tYW5pcHVsYXRlIHNlcnZpY2UgcmVzcGVj dGl2ZSBjb25uZWN0aW9uIHNlZ21lbnRzLiBIZW5jZSB3ZSBhcmUgdGFsa2luZyBhYm91dCBpbnRl cmZhY2UgIzIgKGRhdGEgbW9kZWwgIzIpIGZvciB0aGUgc2VydmljZSBzZWdtZW50IG1hbmlwdWxh dGlvbjsNCg0KMy4gICAgIEEgd2F5IHRvIG1vbml0b3IsIHRyb3VibGVzaG9vdCwgY2Fycnkgb3V0 IG1haW50ZW5hbmNlIG9mIHRoZSBhY3RpdmUgZTJlIHNlcnZpY2VzLiBUaGlzIHdvdWxkIHJlcXVp cmUgaW50ZXJmYWNlICMzIChkYXRhIG1vZGVsICMzKSBiZXR3ZWVuIHRoZSBjbGllbnTigJlzIGNv bnRyb2xsZXIgYW5kIGRvbWFpbnMgVk5Dcy9IeXBlcnZpc29ycyBmb3IgdGhpcyBwdXJwb3NlLg0K DQpTbywgd2UgYXJlIHRhbGtpbmcgMyBZYW5nIG1vZGVscyB3aXRoIHJlcXVpcmVkIG1vZGlmaWNh dGlvbnMgdG8gbmVpdGhlciBOZXRjb25mL1Jlc3Rjb25mLCBub3IgIFRvIGFueSBvdGhlciBtYW5h Z2VtZW50LCByb3V0aW5nIG9yIHNpZ25hbGluZyBwcm90b2NvbC4NCg0KTm93IEkgaGF2ZSBhIGNv dXBsZSBvZiBxdWVzdGlvbnMgdG8geW91Og0KDQoxLiAgICAgSW4gdGhpcyBleGFtcGxlLCB3aGF0 IGVsc2UgKGluIGFkZGl0aW9uIHRvIHRoZXNlIHRocmVlIG1vZGVscykgdGhlIGNsaWVudCBzdWNo IGFzIFRGSyBpbiB5b3VyIG9waW5pb24gd291bGQgbmVlZD8NCg0KMi4gICAgIFdoYXQgZWxzZSB0 aGUgbmV0d29yayBwcm92aWRlcnMgYW5kIHRoZWlyIHZlbmRvcnMgc3VjaCBhcyBBRFZBIG9yIENJ RU4gd291bGQgbmVlZD8NCg0KMy4gICAgIFdoYXQgaXMgdGhlIGltcG9ydGFuY2Ugb2YgYSBjb25z dHJ1Y3Qgc3VjaCBhcyBQTkM/DQoNCg0KTXkgYW5zd2VyIHRvIDMuIOKAnElzIG5vdCBpbXBvcnRh bnQgYXQgYWxsLCBpcnJlbGV2YW504oCdIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQoNCmEp ICAgICBXaGF0IGhhcHBlbnMgYmV5b25kIHRoZSBWTkMvSHlwZXJ2aXNvciBpbiB0aGUgcHJvdmlk ZXIgbmV0d29yayBpcyBjb21wbGV0ZWx5IHByb3ByaWV0YXJ5Lg0KDQpiKSAgICAgVGhlcmUgY291 bGQgYmUgbnVtZXJvdXMgd2F5cyBhcyB0byBob3cgdGhlIHByb3ZpZGVyIG5ldHdvcmsgaXMgbWFu YWdlZC4gRXhhbXBsZXM6IGNlbnRyYWxpemVkIFBOQyAoYXMgeW91IGNhbGwgaXQpLCBBRFZBIHN0 eWxlIEdNUExTIGJhc2VkIG5ldHdvcmsgaW50ZWxsaWdlbmNlLCBDSUVOIHN0eWxlIFBOTkkgYmFz ZWQgY29udHJvbCBwbGFuZSwgZXRjLiBXaHkgaXMgdGhhdCBvZiBBQ1RO4oCZcyBidXNpbmVzcz8N Cg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9tOiBLaW5nLCBEYW5pZWwgW21haWx0bzpkLmtpbmdAbGFu Y2FzdGVyLmFjLnVrXQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDksIDIwMTQgNDo1OCBQTQ0K VG86IExlZXlvdW5nOyBJZ29yIEJyeXNraW47IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0 bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgZGll Z29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86 bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTog ZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgQWxs LCBpbmNsdWRpbmcg4oCcSWdub3LigJ0gOy0pDQoNClR5cGljYWwgZGljaG90b215IGJldHdlZW4g d2hhdCBvcGVyYXRvcnMgd2FudCBhbmQgd2hhdCB2ZW5kb3JzIGFyZSBhY3R1YWxseSB3aWxsaW5n IHRvIHByb3ZpZGUsIGdyb3VwIGNvbnNlbnN1cyB3aWxsIGV2ZW50dWFsbHkgaGVscCByZXNvbHZl IHRoYXQuIEVpdGhlciB3YXksIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgRnJhbWV3b3JrIEkt RCBpcyB0cnlpbmcgdG8gZm9jdXMgQUNUTiBkaXNjdXNzaW9uIGFuZCBzY29wZSAoaS5lLiwgdGhl IHByb3RvY29sIHdvcmspIG9uIHRoZSBpbnRlcmZhY2VzIHdoaWNoIGFyZSBpbiBzY29wZSwgbmFt ZWx5Og0KDQoxLiBUaGUgQ05DLVZOQyBJbnRlcmZhY2UgKENWSSkNCi0gQ3JlYXRlLCBtb2RpZnkg YW5kIGRlbGV0ZSB2aXJ0dWFsIG5ldHdvcmsgc2VydmljZSBpbnN0YW5jZXMNCi0gUmVzb3VyY2Ug bW9kZWwNCg0KMi4gVGhlIFZOQy1QTkMgSW50ZXJmYWNlIChWUEkpDQotIE1hcHBpbmcgb2YgcGh5 c2ljYWwgYW5kIHZpcnR1YWwgcmVzb3VyY2VzDQotIFJlcXVlc3RzOiBwYXRoLCBwcm92aXNpb24s IG1vZGlmeSBhbmQgcmVzdG9yZQ0KDQpBcyBZb3VuZyBzdWdnZXN0cywgaWYgdGhlIFZOQyByZWNl aXZlZCBwaHlzaWNhbCB0b3BvbG9neSBpbmZvIGl0IHdvdWxkIGJlIHBlcmZvcm1pbmcgdGhlIHJv bGUgb2YgdGhlIFBoeXNpY2FsIE5ldHdvcmsgQ29udHJvbGxlciAoUE5DKSwgd2hpY2ggaXMgb2J2 aW91c2x5IGEgKHNvbWVob3cpIHJlcXVpcmVkIGZ1bmN0aW9uLCBidXQgdGhlIGludGVyZmFjZSAo ZGlyZWN0IHByb3Zpc2lvbmluZyBvZiB0aGUgYWN0dWFsIHBoeXNpY2FsIG5ldHdvcmspIGlzIG91 dCBvZiBzY29wZSBmb3IgQUNUTi4NCg0KQnIsIERhbi4NCg0KRnJvbTogQUNUTiBbbWFpbHRvOmFj dG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQpTZW50OiAwOSBPY3Rv YmVyIDIwMTQgMjE6MzINClRvOiBJZ29yIEJyeXNraW47IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lP KTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxs aTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxt YWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0 OiBSZTogW0FjdG5dIGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1l bnRzDQoNCkhpIElnbm9yLA0KDQpUaGFuayB5b3UgZm9yIHByb3ZpZGluZyB5b3VyIGNvbW1lbnQg dGhhdCBwYXVzZXMgdXMgdG8gdGhpbmsgbW9yZSBhbmQgdW5kZXJzdGFuZCBvbiB0aGUgc2FtZSBs ZXZlbC4gSSB0aGluayB5b3VyIGNvbW1lbnQgd2lsbCBjb250cmlidXRlIHRvIGNyeXN0YWxsaXpl IHRoZSBzY29wZSBvZiB3b3JrIGhlcmUuDQoNCkZpcnN0IG9mIGFsbCwgSSB0aGluayB0aGVyZSB3 YXMgYSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuIEZpcnN0LCB5b3VyIGFzc3VtcHRpb24gb24gVk5D IHJlY2VpdmluZyBhY3R1YWwgdW5kZXJseWluZyB0b3BvbG9neSBpcyBpbmNvcnJlY3QuIElmIFZO QyB3ZXJlIHRvIGhhdmUgYWN0dWFsbHkgdG9wb2xvZ3kgKGUuZy4gVEVEKSBvZiBhIG5ldHdvcmss IHRoaXMgd291bGQgYmUgY2FsbGVkIGEgUE5DIGFuZCB0aGlzIGlzIG91dCBvZiBzY29wZSBvZiBB Q1ROLiBUaGlzIGFzcGVjdCBoYXMgYmVlbiBkaXNjdXNzZWQgYnkgZW1haWwgdGhyZWFkcyBEYW5p ZWxlIHN0YXJ0ZWQgYSBmZXcgd2Vla3MgYWdvLiBDaGVjayB0aGUgYXJjaGl2ZSBvbiB0aGF0LiBU aGUgcmVhc29uIHRoaXMgaXMgb3V0IG9mIHNjb3BlIGlzIHRoYXQgUE5DIG11bHRpLWRvbWFpbiBp c3N1ZSBpcyBubyBkaWZmZXJlbnQgZnJvbSB0b2RheeKAmXMgR01QTFMvUENFIGlzc3VlLCBlc3Bl Y2lhbGx5IGluIGxpZ2h0IG9mIEgtUENFLiBBQ1ROIGRvZXMgbm90IHN0ZXAgb24gdGhvc2UgYXJl YXMuIFdoYXQgVk5DIHJlY2VpdmVzIGZyb20gZWFjaCBQTkMgKGRvbWFpbiBjb250cm9sbGVyKSBp cyBhbiBhYnN0cmFjdGVkIHRvcG9sb2d5IHdpdGggdmFyeWluZyBkZWdyZWVzIGZyb20gYWN0dWFs IHVuZGVybHlpbmcgdG9wb2xvZ3kuIFRoZSByZWFzb24gd2h5IHdlIGRpc3Rpbmd1aXNoIHRoZSB0 ZXJtIFZOQyBmcm9tIFBOQy4NCg0KV2hhdCBjYW4gYmUgZGVmaW5lZCBvbiBWTkMtUE5DIGlzIGEg dmVydGljYWwgc2lnbmFsaW5nIGNvb3JkaW5hdGlvbiBmcm9tIFZOQyB0byBlYWNoIFBOQy4gQXMg bG9uZyBhcyB0aGUgZGV0YWlsZWQgcGF0aCBjb21wdXRhdGlvbiBhbmQgc2lnbmFsaW5nIHdpdGhp biBhIGRvbWFpbiBhcmUgY29tcGxldGVseSB1cCB0byB0aGUgZG9tYWluIFBOQy4gVk5DIGlzIG5v dCB0byBiZSBvcGVyYXRlZCBvbiB0aGUgc2FtZSBsZXZlbCBhcyBQTkMuIEl0cyBlbmQtdG8tZW5k IHBhdGggY29tcHV0YXRpb24gaXMgYmFzZWQgb24gd2hhdCBpcyBleHBvc2VkIGZyb20gUE5DcyB0 byBWTkMuIFRoZSBhY3R1YWwgdG9wb2xvZ3kgaW5mb3JtYXRpb24gZGV0YWlscyBpcyBrZXB0IGJ5 IFBOQ3MgYW5kIHRoZSBQTkNzIGV4cG9zZSBhYnN0cmFjdGVkIHRvcG9sb2d5IHRoYXQgY2FuIGhp ZGUgdGhlIGV4YWN0IGRldGFpbHMgd2hpbGUgZXhwb3NpbmcgYSBtaW5pbXVtIGxldmVsIG9mIGNv bnN0cmFpbnRzLiBGb3IgaW5zdGFuY2UsIHRoZSBTUkxHIG9mIHZpcnR1YWwgbGlua3MgKHdoaWNo IG1heSBiZSBjb25jYXRlbmF0ZWQgYWN0dWFsIGxpbmtzKSBjYW4gYmUgZXhwb3NlZCBmb3IgZGl2 ZXJzaXR5IHJvdXRpbmcgY2FsY3VsYXRpb24gYXQgdGhlIFZOQy4gVGhpcyBpcyB2ZXJ5IGRpZmZl cmVudCBmcm9tIGV4cG9zaW5nIHRoZSBhY3R1YWwgVEUgdG9wb2xvZ3kuIFlvdSBjYW4gdmlldyB0 aGlzIGFzIHR3byBsZXZlbCBvZiBwYXRoIGNvbXB1dGF0aW9uLiBWTkMgZmlyc3QgY29tcHV0ZXMg YW4gZW5kLXRvLWVuZCBwYXRoICh1c2luZyB3aGF0ZXZlciBjb25zdHJhaW50IGluZm9ybWF0aW9u IGl0IGhhcyksIHRoZW4gY29vcmRpbmF0ZXMgd2l0aCBlYWNoIFBOQyAodGVsbGluZyB0aGUgYm9y ZGVyIG5vZGVzIGluZm9ybWF0aW9uKSwgdGhlbiBlYWNoIFBOQyBjb21wdXRlcyB0aGUgZG9tYWlu IHNwZWNpZmljIHBhdGguIFdoZW4gYSBQTkMgY2Fubm90IHByb3ZpZGUgYSBwYXRoIHNlZ21lbnQg aW4gaXRzIGRvbWFpbiwgdGhlbiB0aGlzIG5lZWRzIHRvIGJlIHNpZ25hbGVkIHRvIFZOQyBzbyB0 aGF0IHRoZSBWTkMgd291bGQgYXJyYW5nZSBhbiBhbHRlcm5hdGUgcGF0aCBzZWdtZW50IHRvIGJl IGFibGUgdG8gZmluZCBhIGZlYXNpYmxlIGVuZC10by1lbmQgcGF0aC4gIEkgd291bGQgc2F5IHRo aXMgaXMgYSDigJx0d28tcGhhc2XigJ0gc2lnbmFsaW5nIGFuZCBwYXRoIGNvbXB1dGF0aW9uLiBU aGUgcG9pbnQgaXMgdGhhdCB0aGVyZSBtdXN0IGJlIHNvbWUgbGV2ZWwgb2YgaGlkaW5nIG9uIGFi c3RyYWN0IHRvcG9sb2d5IGV4cG9zdXJlIGZyb20gUE5DIHRvIFZOQyBhbmQgcHJvcHJpZXRhcnkg Y2hhcmFjdGVyaXN0aWNzIG9mIG9wdGljYWwgZGV2aWNlcyBuZWVkIHRvIGJlIGRlYWx0IG9ubHkg d2l0aCB0aGUgY29ycmVzcG9uZGluZyBQTkMuDQoNClJlZ2FyZGluZyB0aGUgdGVybSBQTkMgdnMu IEFOQywgSSB3b3VsZG7igJl0IGNvbmNlcm4gdG9vIG11Y2ggYWJvdXQgdGhlIHRlcm1pbm9sb2d5 IHdoaWNoZXZlciB3b3JrcyBiZXR0ZXIuIFRoYW5rIHlvdSBmb3IgeW91ciBzdWdnZXN0aW9uLg0K DQpMYXN0bHksIHBsZWFzZSBjaGVjayB0aGUgdXNlLWNhc2VzIHdyaXR0ZW4gYnkgb3BlcmF0b3Jz IGluIHRoZSBiZWxvdyBsaW5rcyB0aGF0IGNvbnNpc3RlbnRseSBzYXkgdGhleSBuZWVkIGEgc3Rh bmRhcmQgaW50ZXJmYWNlIHRoYXQgY2FuIGNvb3JkaW5hdGUgdGhlaXIgbXVsdGktZG9tYWluIGlz c3Vlcy4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFuZy1hY3Ru LW11bHRpZG9tYWluLWRjaS8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWtsZWUtYWN0bi1jb25uZWN0aXZpdHktbXVsdGktdmVuZG9yLWRvbWFpbnMvDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdW1ha2ktYWN0bi1tdWx0aXRlbmFudC12bm8v DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb3Blei1hY3RuLXZuby1t dWx0aWRvbWFpbnMvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zaGlu LWFjdG4tbXZuby1tdWx0aS1kb21haW4vDQoNClJlZ2FyZHMsDQpZb3VuZw0KDQpUaGFua3MsDQpZ b3VuZw0KDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2Fs LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDE6NDggUE0NClRvOiBCRUxP VFRJLCBTRVJHSU8gKFNFUkdJTyk7IExlZXlvdW5nOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3Ru QGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdv QHRpZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNj OiBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4t ZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBZb3VuZywNCg0KSSBiZWxpZXZlIGhhdmlu ZyB0aGUgc2FtZSBpbnN0YW5jZSBvZiBWTkMgdGFsa2luZyB0byBkaWZmZXJlbnQgdmVuZG9yIGRv bWFpbiBQTkNzIGlzIGFuIGV4dHJlbWVseSAgaWRlYWxpc3RpYyB2aWV3Lg0KDQo9PT09PiBCVFcg SSBmaW5kIFBOQyBpcyBhIGJhZCB0ZXJtLCBJIGxpa2UgbXVjaCBiZXR0ZXIgQWN0dWFsIE5ldHdv cmsgQ29udHJvbGxlciAgKEFOQykuIFZOQyAoYS5rLmEuIGEgSHlwZXJ2aXNvcikgaXMgbWFuYWdp bmcgYWJzdHJhY3QgdG9wb2xvZ2llcywgYW5kIHRvIGJlIGFibGUgZG8gdGhhdCwgaXQgdGFsa3Mg dG8gYSBBTkMtIGEgY29udHJvbGxlciB3aGljaCBoYXMgYW4gYWNjZXNzIGFuZCBtYW5hZ2VzIGFj dHVhbCBwcm92aWRlciBuZXR3b3JrKS4NCg0KT25lIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0IFZO QyBuZWVkcyB0byB1bmRlcnN0YW5kIHVuZGVybHlpbmcgYWN0dWFsIHRvcG9sb2d5LCBmb3IgZXhh bXBsZSwgdG8gZW5zdXJlIHRoYXQgdHdvIGFic3RyYWN0IFRFIGxpbmtzIGFyZSBTUkxHIGRpc2pv aW50IGFzIHJlcXVlc3RlZC4gQWN0dWFsIHRvcG9sb2d5IHNlbWFudGljcyAoZXNwZWNpYWxseSBp biBXRE0gbGF5ZXIpIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gdmVuZG9yIHRvIHZlbmRvciBhbmQg Y29udGFpbnMgYSBncmVhdCB2YXJpZXR5IG9mIHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMsIGZhaWxp bmcgdG8gdW5kZXJzdGFuZCB3aGljaCBsZWFkcyB0byBwcm9kdWNpbmcgdW5wcm92aXNpb25hYmxl IHNlcnZpY2UgcGF0aHMuIERvIHlvdSByZWFsbHkgYmVsaWV2ZSB0aGF0IGEgc2luZ2xlIFZOQyBj YW4gdGFsayBpbiB0aGUgc2FtZSB3YXkgdG8gQURWQSwgSU5GTiwgQUxVIGFuZCBIdWF3ZWkgQU5D cz8gVGhpcyBpcyBlcXVpdmFsZW50IHRvIGFzayBhbGwgb3B0aWNhbCBwcm92aWRlcnMgdG8gc3dp dGNoIHRvIFdTT04gOj0pLg0KDQpUaGlzIGlzIG5vdCB0byBzYXkgdGhhdCB5b3UgY2Fubm90IGJ1 aWxkIGEgaGllcmFyY2h5IG9mIFZOQ3MsIGJ1dCBpbiB0aGlzIGNhc2UgTm9ydGggVk5DIHBsYXlz IHJvbGUgb2YgYSBjbGllbnQgbmV0d29yayBjb250cm9sbGVyIHdydCB0byBTb3V0aCBWTkMsIHRo YXQgaXMsIHVzZXMgdGhlIHNhbWUgWCBpbnRlcmZhY2UuDQpJSE1PIHdoZW5ldmVyIGEgVk5DIGhh cyB0byB0YWxrIHRvIGEgQU5DLCBpdCBkb2VzIHNvIGluIGEgcHJvcHJpZXRhcnkgd2F5LCBpLmUu IEFEVkEsIElORk4sIEFMVSBhbmQgSHVhd2VpIHdpbGwgaGF2ZSB0aGVpciBvd24gVk5DcyBleHBv c2luZyB0aGUgc2FtZSBub3J0aCBib3VuZCBpbnRlcmZhY2UgdG8gcG90ZW50aWFsbHkgdGhlIHNh bWUgY2xpZW50IChlLmcuVEZLKS4NCklITU8gaW50ZXJmYWNlIFggaXMgdGhlIG9ubHkgaW50ZXJm YWNlIHRoYXQgdGhlIEFDVE4gY2FuIHdvcmsgb24uDQoNCkNoZWVycywNCklnb3INCg0KRnJvbTog QUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJFTE9UVEks IFNFUkdJTyAoU0VSR0lPKQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDksIDIwMTQgNTo1OSBB TQ0KVG86IExlZXlvdW5nOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFu aWVsZSBDZWNjYXJlbGxpOyBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47IGx1eXVh bmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNjOiBCRUxPVFRJLCBTRVJH SU8gKFNFUkdJTyk7IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUmU6IFtBY3RuXSBkcmFm dC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBZb3VuZywN Cg0KdGhhbmtzIGEgbG90IGZvciByZXBseSAsIHBsZWFzZSBzZWUgaW4gbGluZSBqdXN0IHNvbWUg ZnVydGhlciBjbGFyaWZpY2F0aW9uDQoNClJlZ2FyZHMNClNlcmdpbw0KDQoNCg0KRnJvbTogTGVl eW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXQ0KU2VudDogbWVyY29sZWTDrCA4IG90 dG9icmUgMjAxNCAxNzozNQ0KVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0bkBpZXRm Lm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgZGllZ29AdGlk LmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFu ZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQt Y2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgU2VyZ2lvLA0K DQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2sgb24gdGhlIGZyYW1ld29yayBkb2N1bWVudC4gUGxl YXNlIHNlZSBpbi1saW5lIGZvciBteSBjb21tZW50Lg0KDQpSZWdhcmRzLA0KWW91bmcNCg0KRnJv bTogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIFttYWlsdG86c2VyZ2lvLmJlbG90dGlAYWxjYXRl bC1sdWNlbnQuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA4LCAyMDE0IDc6MzQgQU0N ClRvOiBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJl bGxpOyBMZWV5b3VuZzsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5m QGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogQkVMT1RUSSwgU0VSR0lP IChTRVJHSU8pOyBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IGRyYWZ0LWNlY2NhcmVsbGkt YWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIERhbmllbGUgLCBZb3VuZyBhbmQg YWxsIGF1dGhvcnMsDQoNCkkgcmVhZCB5b3UgRnJhbWV3b3JrIGRyYWZ0IGFuZCBJIGhhdmUgc29t ZSBjb21tZW50cyBvbiB0aGF0LiBNb3N0IGFyZSBlZGl0b3JpYWwgLCBvdGhlciBxdWVzdGlvbnMg Zm9yIGNsYXJpZmljYXRpb25zLg0KDQpHZW5lcmFsIHF1ZXN0aW9uOiBpbiB0aGUgZHJhZnQgdGhl IGNvbmNlcHQgb2YgVk5DIGlzIGluIHRoZSB2aWV3IG9mIGhpZXJhcmNoaWNhbCBsZXZlbCBvZiBj b250cm9sbGVycyBvciBsaW5rZWQgdG8gdGhlIG11bHRpLWRvbWFpbiBhc3BlY3QgdGhhdCBjb21w ZWwgdG8gcHJvdmlkZSB0byB0aGUgY3VzdG9tZXIgYSBzaW5nbGUgdmlydHVhbGl6ZWQgbmV0d29y ayBldmVuIGlmIGNvbXBvc2VkIGJ5IHJlYWwgbXVsdGktZG9tYWluIG11bHRpLXRlY2hub2xvZ3kg c3VibmV0d29ya3M/IEkgbWVhbiwgdGhlIOKAnHZpcnR1YWxpemVyIGZ1bmN0aW9u4oCdIHByb3Zp ZGVkIGJ5IFZOQywgaW4gY2FzZSBvZiBhIHNpbmdsZSBkb21haW4gY29udGV4dCBjb3VsZCBiZSBp bnNpZGUgZGlyZWN0bHkgdGhlIFBOQyAsIGNvcnJlY3Q/DQoNCllPVU5HPj4gWWVzLiBUaGF0IGlz IHRoZSBjb3JyZWN0IHZpZXcgb2YgVk5DLiBGb3IgYSBzaW5nbGUgZG9tYWluIGNvbnRleHQsIHRo ZSBWTkMgY2FuIGJlIGludGVncmF0ZWQgd2l0aCBQTkMuIEJ1dCB3ZSBuZWVkIHRvIGZhY3RvciBp biBvdGhlciBzY2VuYXJpb3Mgc3VjaCBhcyAxKSBWTkMgdmVuZG9yIG1heSBiZSBkaWZmZXJlbnQg ZnJvbSBQTkMgdmVuZG9yIG9yIDIpIFZOQyBpcyBhIHNvZnR3YXJlIGZ1bmN0aW9uIHRoYXQgb3Bl cmF0b3IgbWF5IHdhbnQgdG8gb3BlcmF0ZSBhcyBpdHMgY29udHJvbC4gSW4gbXkgb3Bpbmlvbiwg ZXZlbiBmb3IgYSBzaW5nbGUgZG9tYWluLCBJIHRoaW5rIHRoZXJlIGlzIGJlbmVmaXQgdG8gZGVm aW5lIHRoaXMgaW50ZXJmYWNlIGFzIGEgc3RhbmRhcmQgaW50ZXJmYWNlLg0KDQpTZWN0aW9uIDIg LCBwYWdlIDQ6DQphYnN0cmFjdGlvbiBkb2VzIG5vdCBpbXBseSBhdXRvbWF0aWNhbGx5IHZpcnR1 YWxpemF0aW9uLHdoaWxlIHZpcnR1YWxpemF0aW9uIGltcGxpZXMgdG8gaGF2ZSBzdXJlbHkgYSBj ZXJ0YWluIGZvcm0gb2YgYWJzdHJhY3Rpb24uIEkgd291bGQgc3VnZ2VzdCB0byBjb25zaWRlciBn b29kIGRlZmluaXRpb24gY29udGFpbmVkIGludG8gT05GIFNETiBhcmNoaXRlY3R1cmUgZG9jdW1l bnQgY2hhcHRlciAyLjMgQ29udmVudGlvbnMgYWJvdXQgYWJzdHJhY3Rpb24gYW5kIHZpcnR1YWxp emF0aW9uLiBBIGdvb2QgZGVmaW5pdGlvbiBjYW4gaGVscCBhbGwgdGhlIHJlYWRpbmcuDQoNCllP VU5HPj4gQWdyZWUuIFdlIHdpbGwgbG9vayBpbnRvIHRoZSBtZW50aW9uZWQgZG9jdW1lbnQgaWYg dGhlIHVzYWdlIG9mIHRlcm1zIGFyZSBhbGlnbmVkIHdpdGggdGhpcyBkb2N1bWVudC4gSWYgbm90 LCB3ZSB3aWxsIGNsYXJpZnkgdGhlIHRlcm1pbm9sb2d5IG1vcmUgY2xlYXJseS4NCg0KU2VjdGlv biA1OiBJdCBzZWVtcyB0byBtZSB5b3UgbWl4ZWQgaGVyZSBhc3BlY3RzIHRoYXQgYXJlIG1vcmUg cmVsYXRlZCB0byBwb2xpY3kgbGlrZSBhZG1pc3Npb24gY29udHJvbCAgYW5kIGd1YXJhbnRlZSBv ZiBjbGllbnQgaXNvbGF0aW9uIHdpdGggcmVhbCBjb21wdXRhdGlvbmFsIGlzc3VlIGxpa2UgQ29t cHV0aW5nIHRpbWUgLCBwYXRoIGNvbnN0cmFpbnMgb3IgcmUtb3B0aW1pemF0aW9uIHByb2Nlc3Mu IE1vcmVvdmVyIHRoZSB0ZXJtIFZOTSBmb3IgVmlydHVhbCBuZXR3b3JrIG1hcHBpbmcgaXMgYSBi aXQgbWlzbGVhZGluZyBzaW5jZSB0aGlzIHRlcm0gaW4gYWxyZWFkeSB1c2VkIGUuZy4gaW4gQUJO TyBhcmNoaXRlY3R1cmUgZm9yIFZpcnR1YWwgTmV0d29yayBNYW5hZ2VyLg0KDQpZT1VORz4+IElu ZGVlZC4gSW4gU2VjdGlvbiA1LCB3ZSB3aWxsIHB1dCBzb21lIG5vdGVzIG9uIHRoZSBhc3BlY3Qg b2YgcmVhbC10aW1lIHJlbGF0ZWQgZnJvbSBub24gcmVhbCB0aW1lIGFzcGVjdC4gVk5NIGlzIG5v dCB0byBiZSBtaXhlZCB3aXRoIFZpcnR1YWwgTmV0d29yayBNYW5hZ2VyLiBIZXJlIFZOTSBpcyBh biBhbGdvcml0aG0gd2hpY2ggaXMga25vd24gYXMgVmlydHVhbCBOZXR3b3JrIE1hcHBpbmcgd2hp Y2ggaXMgYSBzb2Z0d2FyZSBtb2R1bGUgdGhhdCBjb252ZXJ0cyBjbGllbnQgcmVxdWVzdHMgaW50 byBhY3R1YWwgbmV0d29ya3MuIFZpcnR1YWwgTmV0d29yayBNYW5hZ2VyIGlzIEFCTk8gaW4gbXkg dW5kZXJzdGFuZGluZyBpcyBhIGRldmVsb3BlZCBjb25jZXB0IGZyb20gVk5UTS4gQnV0IERhbiBL aW5nIGFuZCBJIHdpbGwgbG9vayBhdCB0aGlzIG1vcmUgY2FyZWZ1bGx5IG9uIHRoaXMgYXNwZWN0 IHdoYXQgVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIgaXMgZG9pbmcuDQoNClNCPj4+IElmIEkgdW5k ZXJzdG9vZCBmb3JtIEFkcmlhbiBhbmQgRGFuaWVsIEFCTk8gZHJhZnQgdGhlIGNvbmNlcHQsIA0K U0I+Pj4gVk5UTSBpcyBzdHJpY3RseSByZWxhdGVkIHRvIHBsYW5uaW5nIGZ1bmN0aW9uIHNvIEkg dGhpcyBpdCBpcyB2ZXJ5IA0KU0I+Pj4gaW1wb3J0IHBvaW50IGluIHRoZSBjb250ZXh0IG9mIFBO QyAsIEkgd291bGQgc2F5DQoNClNlY3Rpb24gNi4xIDogd2hpbGUgaXQgaXMgY2xlYXIgdGhlIHNj b3BlIG9mIHRoZSBkaWZmZXJlbnQgY29udHJvbCBpbnRlcmZhY2UgcHJlc2VudGVkIGluIGZpZ3Vy ZSA1LCBJ4oCZbSBhIGJpdCBjb25mdXNlZCBhcyB0byB3aGF0IEkvRiBFIGlzIOKAkyBkYXRhIHBs YW5lIGludGVyZmFjZSB0byBwcm92aWRlciBwaHlzaWNhbCBuZXR3b3JrPyBPciBpcyB0aGUgaW50 ZW50aW9uIHRvIHByb3ZpZGUgd2hhdCBjYW4gYmUgdGhlIHVuZGVybHlpbmcgbW9kZWwgb2YgcmVz b3VyY2VzIGFsbG9jYXRlZCB0byBhIGN1c3RvbWVyIGZyb20gbmV0d29yayBwcm92aWRlciBjb250 cm9sbGVyLCBhbmQgdGhlIG1hcHBpbmcgdG8gcmVhbCBwaHlzaWNhbCByZXNvdXJjZXMgPyBOb3Ig Y2xlYXIgdG8gbWUgdGhlIGludGVudGlvbg0KDQpZT1VORz4+IEludGVyZmFjZSBFIGlzIG5vdCB3 aGF0IEFDVE4gd2lsbCBmb2N1cyBvbi4gSXQgc2ltcGx5IHNob3dzICBhbiB1bmRlcmx5aW5nIG1v ZGVsIG9mIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gYSBjdXN0b21lciBmcm9tIG5ldHdvcmsgcHJv dmlkZXIgY29udHJvbGxlciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwgcGh5c2ljYWwgcmVzb3Vy Y2VzLg0KDQpTQj4+PiBTbyBpZiBJIGludGVycHJldGVkIGNvcnJlY3RseSB5b3VyIGFuc3dlciBp cyBtb3JlIGFuIGludGVybmFsIGludGVyZmFjZSB0byBQTkMgLCB0aGUgZmlndXJlIGlzIG1pc2xl YWRpbmcgc2luY2UgaXQgc2VlbXMgbGlrZSBhIERQIGludGVyZmFjZSAuDQoNCg0KU2VjdGlvbiA2 LjEsIGFsd2F5cyBmaWd1cmUgNTogSWYgYSByZXBvcnQgb2YgcG90ZW50aWFsIE5XIHRvcG9sb2d5 IGJldHdlZW4gYSBWTkMgYW5kIGEgQ05DIGNhbiBiZSBxdWVyaWVkICwgdGhlIGFycm93IGluIHRo ZSBkcmF3biBoYXMgdG8gYmUgYmlkaXJlY3Rpb25hbCBJIGd1ZXNzDQoNCllPVU5HPj4gWWVzLCBZ b3UgYXJlIHJpZ2h0LiBJdCB3aWxsIGJlIGZpeGVkLg0KDQpGaWd1cmUgOCBTZWN0aW9uIDYuNCxw YWdlIDI4OiDigJxQQ0EgYWJzdHJhY3RzIHRoZSBwaHlzaWNhbCBuZXR3b3JrIHRvcG9sb2d5IGlu dG8gYW4gYWJzdHJhY3RlZCB0b3BvbG9neeKAnSBMb29raW5nIGF0IHRoZSBkZXNjcmlwdGlvbiBv ZiBWTkMgY29tcG9uZW50cyBpbiA2LjIuMiBpdCBpcyB0aGUgcmVzb3VyY2UgbWFuYWdlciBkZXZv dGluZyB0byBwcm92aWRlIGFic3RyYWN0IHRvcG9sb2d5LiBEb2VzIG5vdCBleGlzdCBhbnkgUENB IGNvbXBvbmVudC4NCg0KDQoNCllPVU5HPj4gU29ycnkgZm9yIGluY29uc2lzdGVuY3kuIFRoZSBp bnRlbnRpb24gd2FzIHRoZSBQQ0EgaXMgdGhlIHNhbWUgYXMgdGhlIFJlc291cmNlIE1hbmFnZXIg aW4gVk5DLiBXaWxsIG1ha2UgdGhlIHRlcm0gY29uc2lzdGVudC4gR29vZCBjYXRjaCENCg0KDQoN CkZpZ3VyZSA4IFNFY3Rpb24gNi40LCA6IEluIHRoZSBwaWN0dXJlIHRoZXJlIGlzIG5vIHBoYXNl IDcsIGFuZCB0aGVyZSBhcmUgMiBwaGFzZSA4DQoNCllPVU5HPj4gVGhhbmtzLiBHb29kIGNhdGNo IQ0KDQpQYWdlIDMwIDogSXQgaXMgSW50ZXJmYWNlIEMgbm90IEIgLCBiZXR3ZWVuIFZOQyBhbmQg UE5DDQoNCllPVU5HPj4gSWYgeW91IGFyZSByZWZlcnJpbmcgdG8gU2VjdGlvbiA3LjMgd2hlcmU6 DQoNCiAgIEludGVyZmFjZXMgc2hvdWxkIGFsc28gYmUgc2NhbGFibGUgYXMgYSBsYXJnZSBhbW91 bnQgb2YgZGF0YSBuZWVkcw0KDQogICB0byBiZSB0cmFuc3BvcnRlZCBhY3Jvc3MgY3VzdG9tZXJz IHRvIHZpcnR1YWwgbmV0d29yayBjb250cm9sbGVycw0KDQogICBhbmQgYWNyb3NzIHZpcnR1YWwg bmV0d29yayBjb250cm9sbGVycyBhbmQgcGh5c2ljYWwgbmV0d29yaw0KDQogICBjb250cm9sbGVy cy4NCg0KDQoNCkkgdGhpbmsgdGhpcyBpbXBsaWVzIGJvdGggaW50ZXJmYWNlcyBCIGFuZCBDIGFs dGhvdWdoIHByaW1hcmlseSBiZXR3ZWVuIFZOQy1QTkMuDQoNCg0KDQpTQj4+PiBTb3JyeSBZb3Vu ZywgaWl0IGlzIG5vdCByZWZlcnJlZCB0byA3LjMgLCBidXQgaW4gdGhlIGNoYXB0ZXIgNiw1ICwg DQpTQj4+PiBvbiBJbnRlcmZhY2UgaW50ZXJhY3Rpb24sIGFmdGVyIHBvaW50IDYsIGlzIGluZGlj YXRlZCBJbnRlcmZhY2UgQiANClNCPj4+IGFzIGludGVyZmFjZSBiZXR3ZWVuIFZOQyBhbmQgUE5D LCBmaWd1cmUgNSBzYXlzIGl0IGlzIEkvRiBDDQoNCg0KVGhhbmtzDQoNClNlcmdpbw0KDQoNClRo YW5rcw0KU2VyZ2lvDQo= From nobody Tue Oct 14 03:27:38 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 2DEE11A7023 for ; Tue, 14 Oct 2014 03:27:36 -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 1BeBQszFlAix for ; Tue, 14 Oct 2014 03:27:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5C61A7008 for ; Tue, 14 Oct 2014 03:27:30 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-c0-543cfa90ba4d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.D0.04081.09AFC345; Tue, 14 Oct 2014 12:27:28 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.79]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 12:27:27 +0200 From: Daniele Ceccarelli To: "BELOTTI, SERGIO (SERGIO)" , "Igor Bryskin" , Leeyoung , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAUUWIAAAD4nwA= Date: Tue, 14 Oct 2014 10:27:27 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481279E6E8@ESESSMB301.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM+Jvje6EXzYhBj9eyVps6bnAZvFiXbDF ykl32S2WNj1htDjV085oMW2eq8Xq3eeZLJZt/s3uwOFxdsEfVo/WZ3tZPXbOusvu0XLkLavH kiU/mTxOHUj3ePJ3C3MAexSXTUpqTmZZapG+XQJXxrPVL5gL9v1mqui8voqtgfHBR6YuRk4O CQETiS+bLrJC2GISF+6tZ+ti5OIQEjjKKLH59y+whJDAYkaJaZtruxg5ONgErCSeHPIBqRER WMokcWbvUxaQOLOAucSd48kg5cICNhIbtq5kB7FFBGwlZt19yARR38UoMeP2LxaQBIuAqkTb uwuMIDavgK/E/E0gDSCLr7NLfPywAaybUyBW4sSls2CXMgrISkzYvQisgVlAXOLWk/lQHwhI LNlznhnCFpV4+fgfK8hBEgKKEsv75SBu05RYv0sfolNRYkr3Q3aItYISJ2c+YZnAKDYLydBZ CB2zkHTMQtKxgJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgnB7c8ttgB+PL546HGAU4 GJV4eBc024QIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG 5+nbNwbUc/yfOOPebBPLmebr9G2a333rj2rfZjznKWeG8/5P7YnCAg+WL/olq3dS3+TWh8PH 2o1VngjvtTg86fWyrnMM99blhZTKfuc9Z3Fpt9N2y+2tyUkZNhnZ9YXrVX60n88O4H0l1Su9 wHXWq18aprUTdUvO/LHhFN7L92vl1sP2jG3uSizFGYmGWsxFxYkAD/6n+rQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/actn/onaxFw8OTLWCjC-UxkujoNUaJl4 Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 10:27:36 -0000 SGkgSWdvciwNCg0KSSBkb24ndCB0aGluayB0aGF0IEIgYW5kIEMgYXJlIGdvaW5nIHRvIGJlIHRo ZSBzYW1lIGludGVyZmFjZSBlaXRoZXIuIA0KSnVzdCBsb3VkIHRoaW5raW5nLCBzb21lIGV4YW1w bGUgdGhhdCBjb21lIHRvIG15IG1pbmQgYXJlIGFzIGZvbGxvd3M6DQoNCjEuIE11bHRpIGRvbWFp bjogU3VwcG9zZSBUZWxlZm9uaWNhIGhhcyBpdHMgb3duIFZOQyAodGhlIHByZXZpb3VzIG1pc3Vu ZGVyc3RhbmRpbmcgd2FzIGR1ZSB0byB0aGUgZmFjdCB0aGF0IHlvdSBjYWxsIFRlbGVmb25pY2Eg YXMgdGhlIGNsaWVudCwgd2hpbGUgZm9yIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGluIHRoZSBkcmFm dCBUZWxlZm9uaWNhIGlzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGFuZCB0aGUgY2xpZW50IGlzIGUu Zy4gdGhlIGJhbmsgYXNraW5nIFRlbGVmb25pY2EgZm9yIGEgVlBOIGJldHdlZW4gMyBwb2ludHMp IHdoaWNoIHJ1bnMgb24gdG9wIG9mIDIgZG9tYWlucyB3aXRoIFBOQ3MgZnJvbSBkaWZmZXJlbnQg dmVuZG9ycy4gVGhlIFZOQyBpcyBhd2FyZSBvZiB0aGUgZmFjdCB0aGF0IHRoZXJlIGFyZSAzIGRv bWFpbnMgYmVsb3cgKGhlbmNlIEMgbXVzdCBiZSBkb21haW4gYXdhcmUpIHdoaWxlIHRoZXJlIGlz IG5vIG5lZWQgZm9yIHRoZSBiYW5rIHRvIGtub3cgdGhhdCBkaWZmZXJlbnQgZG9tYWlucyBhcmUg dXNlZCB0byBjb25uZWN0IGhpcyAzIHBvaW50cw0KDQoyLiBDbG91ZCArIFRyYW5zcG9ydDogQW4g aW50ZXJlc3RpbmcgdXNlIGNhc2UgaW4gbXkgb3BpbmlvbiBpcyB0aGUgcHJvdmlzaW9uaW5nIG9m IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGRhdGEgY2VudGVyIFggYW5kIFkuIFRoZXJlIHdvdWxkIGJl IGEgQ05DIChsZXQncyBjYWxsIGl0IGUuZy4gY2xvdWQgbmV0d29yayBjb250cm9sbGVyIGFzIGl0 IHdvdWxkIHByb2JhYmx5IGJlIHNvbWV0aGluZyBkaWZmZXJlbnQgZnJvbSBhIFBOQykgZm9yIGRh dGEgY2VudGVyIFgsIG9uZSBmb3IgZGF0YSBjZW50ZXIgWSBhbmQgb25lIG9yIG1vcmUgUE5DIGlu IHRoZSBtaWRkbGUuIFRoZSBWTkMgd291bGQgYmUgYW4gZW5hYmxlIGZvciBwcm92aWRpbmcgY29u bmVjdGl2aXR5IGJldHdlZW4gZGF0YSBjZW50ZXJzIG92ZXIgYSB0cmFuc3BvcnQgbmV0d29yay4g QWxzbyBpbiB0aGlzIGNhc2UgSSB0aGluayB0aGF0IGludGVyZmFjZXMgQiBhbmQgQyB3b3VsZCBi ZSBkaWZmZXJlbnQuDQoNCjMuIE9wdGljYWwgbXVsdGkgZG9tYWluOiBpdCBtaWdodCBiZSBwb3Nz aWJsZSB0aGF0IFRlbGVmb25pY2Egd2FudHMgdG8gaGF2ZSBhIHNldCBvZiBpbXBhaXJtZW50cyBm b3IgY29tcHV0aW5nIGVuZCB0byBlbmQgb3B0aWNhbCBwYXRocyAoaS5lLiBvcHRpY2FsIGltcGFp cm1lbnQgbm90IGxpbWl0ZWQgdG8gdGhlIFBOQyBkb21haW4pLiBJbiB0aGF0IGNhc2UgeW91IHdv dWxkIGhhdmUgdGhlbSB0aHJvdWdoIGludGVyZmFjZSBDIGJ1dCBub3QgQi4NCg0KTWF5YmUgd2Ug bWlnaHQgY29tZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IG9uZSBpbnRlcmZhY2UgaXMgYSBzdWJz ZXQgb2YgdGhlIG90aGVyIG9yIG1heWJlIHRoZXJlIGFyZSByZXF1aXJlbWVudHMgdGhhdCBsZWFk IHRvIGRlZmluaW5nIHRoZW0gYXMgc2VwYXJhdGUgaW50ZXJmYWNlcyB3aXRoIGp1c3QgYSBsaXR0 bGUgYml0IG9mIG92ZXJsYXAsIGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIGtlZXBpbmcgdGhlbSBz ZXBhcmF0ZS4NCkkgd291bGQgbGlrZSB0byBrbm93IGEgYml0IG1vcmUgYWJvdXQgcmVxdWlyZW1l bnRzIG9uIGludGVyZmFjZSBCIGFzIGl0IGNvdWxkIGJlIGFuIGludGVyZmFjZSB0b3dhcmRzIHRo ZSBjbGllbnQgY29udHJvbGxlciAod2hlcmUgY2xpZW50ID09IHRoZSBiYW5rKSBvciBkaXJlY3Rs eSBhbiBhcHBsaWNhdGlvbiAod2hpY2ggSSBndWVzcyBoYXMgZGlmZmVyZW50IHJlcXVpcmVtZW50 cyB0aGFuIHRoZSBvbmVzIHRvIGJlIHB1dCBvbiBpbnRmIEMpLg0KDQpCUg0KRGFuaWVsZQ0KDQoN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCRUxPVFRJLCBTRVJHSU8g KFNFUkdJTykgW21haWx0bzpzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb21dDQo+IFNl bnQ6IG1hcnRlZMOsIDE0IG90dG9icmUgMjAxNCAxMTozOA0KPiBUbzogSWdvciBCcnlza2luOyBM ZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IGFjdG5AaWV0Zi5vcmc7 DQo+IGRpZWdvQHRpZC5lczsgbHV5dWFuZkBnbWFpbC5jb20NCj4gQ2M6IFZhcm1hLCBFdmUgTCAo RXZlKQ0KPiBTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50 eHQgY29tbWVudHMNCj4gDQo+IEhpIElnb3IsDQo+IA0KPiAiIElC44CLTm8uIEkgYW0gc2F5aW5n IHRoYXQgaW50ZXJmYWNlIEIgYW5kIEMgYXJlIGV4YWN0bHkgdGhlIHNhbWUgaW50ZXJmYWNlcy4N Cj4gRm9yIGV4YW1wbGUsIG9uIHRoZSBwaWN0dXJlIE5ldHdvcmsgZG9tYWluIDEgaW4gb3JkZXIg dG8gcHJvdmlkZSB0aGUNCj4gYWJzdHJhY3QgdG9wb2xvZ3kgdG8gdGhlIG11bHRpLXZlbmRvciBW TkMsIG1heSB1c2UgZnVsbHkgb3IgcGFydGlhbGx5IGFic3RyYWN0DQo+IHRvcG9sb2dpZXMgcHJv dmlkZWQgYnkgb25lIG9yIG1vcmUgbG93ZXIgdGllciB0cmFuc3BvcnQgZG9tYWlucy4NCj4gTGlr ZXdpc2UsIEN1c3RvbWVyIDEgb24gdGhlIHBpY3R1cmUgbWF5IHVzZSBhbiBhYnN0cmFjdCB0b3Bv bG9neSBwcm92aWRlZA0KPiBieSBNdWx0aS1kb21haW4gbmV0d29yayAodGhlIFZOQyBvbiB0aGUg cGljdHVyZSBpcyBwYXJ0IG9mKS4NCj4gSW4gb3RoZXIgd29yZHMsIHRoZSBzYW1lIGludGVyZmFj ZSBDIGFuZCB0aGUgc2FtZSBzZXQgb2YgbW9kZWxzLCBjb3VsZCBiZQ0KPiB1c2VkICBoaWVyYXJj aGljYWxseS4NCj4gDQo+IElnb3IiDQo+IA0KPiBJIHRlbmQgdG8gZGlzYWdyZWUgaGVyZS4gV2hh dCB0aGF0IGNhbiBiZSBkaXNjdXNzZWQgaW4gbXkgdmlldyBpdCBpcyB0aGUgbmVlZA0KPiBvciBu b3Qgb2YgaW50ZXJmYWNlIEMuIFdoYXQgVk5DIGlzIGdvaW5nIHRvIHByb3ZpZGUgaXMgYSBkb3Vi bGUgZnVuY3Rpb24gb2YNCj4gdmlydHVhbGl6ZXIgb2YgdGhlIG5ldHdvcmsgdG93YXJkcyBjbGll bnQgYXBwbGljYXRpb24gbGV2ZWwgYW5kIG9yY2hlc3RyYXRpb24sDQo+IGR1ZSB0byB0aGUgbmVl ZCB0byBzcGFuIG11bHRpcGxlICh2aXJ0dWFsKU5FcyBvciBtdWx0aXBsZSBuZXR3b3JrIGRvbWFp biAuIElmDQo+IHdlIGltbW1hZ2luZSB0byBlbmNvbXBhc3MgdGhlc2UgZnVuY3Rpb25hbGx5IGlu dG8gb25seSBvbmUgU0ROIGNvbnRyb2xsZXINCj4gLCBtYW5hZ2luZyBhbGwgdmlydHVhbCBuZXR3 b3JrIHlvdSB3b3VsZCBub3QgdXNlIGFub3RoZXIgaW50ZXJmYWNlIGJldHdlZW4NCj4gVk5DIGFu ZCBQTkMuDQo+IEJ1dCBoZXJlIFlvdW5nIHB1dCBjb3JyZWN0bHkgc29tZSBwcm9ibGVtcyBhbmQg aXQgaXMgdGhlIGNvcnJlY3QgdGltZSBJIHRoaW5rDQo+IHRvIGNvbnNpZGVyIGFsbCB0aGUgYXNw ZWN0cy4NCj4gQnV0IHRvd2FyZHMgY2xpZW50IGFwcGxpY2F0aW9uIHRoZXJlIGlzIGFub3RoZXIg bGV2ZWwgb2YgYWJzdHJhY3Rpb24sIGEgcmVhbA0KPiB2aXJ0dWFsaXphdGlvbiAodG8gY2xpZW50 KSBvZiByZXNvdXJjZXMgd2l0aCBkaWZmZXJlbnQgZ3JhbnVsYXJpdHkgYW5kDQo+IGNoYXJhY3Rl cmlzdGljcyBvZiB0aGUgc2V0IG9mIGluZm9ybWF0aW9uIG5lZWRlZCB0byB0aGUgbG93ZXIgbGV2 ZWwgb2YNCj4gY29udHJvbGxlciwgYXMgd2VsbCBleHBsYWluZWQgYnkgWW91bmcuDQo+IEl0IGNh biBkZWJhdGUgaWYgYW5vdGhlciBzZXBhcmF0ZSBlbnRpdHkgYXMgVk5DIGNhbiBiZSAsIGluIHRo aXMgYXJjaGl0ZWN0dXJlLA0KPiB0aGUgZ29vZCBjaG9pY2UsIGJ1dCBJIGRvIG5vdCBoYXZlIHBy ZWNsdXNpb24gb24gdGhhdC4NCj4gSSBpbnN0ZWFkIHNoYXJlIHlvdXIgc2VudGVuY2UgYWJvdXQg aGllcmFyY2hpY2FsIGxldmVsIG9mIGNvbnRyb2xsZXIuDQo+IA0KPiBUaGFua3MNCj4gDQo+IFJl Z2FyZHMNCj4gU2VyZ2lvDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEln b3IgQnJ5c2tpbg0KPiBTZW50OiBtYXJ0ZWTDrCAxNCBvdHRvYnJlIDIwMTQgMDI6MDENCj4gVG86 IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IERhbmllbGUgQ2VjY2FyZWxsaTsg S2luZywgRGFuaWVsOw0KPiBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21h aWwuY29tDQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUmU6IFtBY3RuXSBk cmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KPiANCj4gDQo+ IFlvdW5nLA0KPiANCj4gDQo+ID09PeOAi0FmdGVyIGFsbCB3ZSBhcmUgYWdyZWVpbmcgd2l0aCB0 aGUgaW50ZXJmYWNlcyBvZiBBQ1ROIGludGVyZXN0IGFyZQ0KPiBJbnRlcmZhY2UgQiBhbmQgQywg cmlnaHQ/DQo+IA0KPiBJQuOAi05vLiBJIGFtIHNheWluZyB0aGF0IGludGVyZmFjZSBCIGFuZCBD IGFyZSBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMuDQo+IEZvciBleGFtcGxlLCBvbiB0aGUg cGljdHVyZSBOZXR3b3JrIGRvbWFpbiAxIGluIG9yZGVyIHRvIHByb3ZpZGUgdGhlDQo+IGFic3Ry YWN0IHRvcG9sb2d5IHRvIHRoZSBtdWx0aS12ZW5kb3IgVk5DLCBtYXkgdXNlIGZ1bGx5IG9yIHBh cnRpYWxseSBhYnN0cmFjdA0KPiB0b3BvbG9naWVzIHByb3ZpZGVkIGJ5IG9uZSBvciBtb3JlIGxv d2VyIHRpZXIgdHJhbnNwb3J0IGRvbWFpbnMuDQo+IExpa2V3aXNlLCBDdXN0b21lciAxIG9uIHRo ZSBwaWN0dXJlIG1heSB1c2UgYW4gYWJzdHJhY3QgdG9wb2xvZ3kgcHJvdmlkZWQNCj4gYnkgTXVs dGktZG9tYWluIG5ldHdvcmsgKHRoZSBWTkMgb24gdGhlIHBpY3R1cmUgaXMgcGFydCBvZikuDQo+ IEluIG90aGVyIHdvcmRzLCB0aGUgc2FtZSBpbnRlcmZhY2UgQyBhbmQgdGhlIHNhbWUgc2V0IG9m IG1vZGVscywgY291bGQgYmUNCj4gdXNlZCAgaGllcmFyY2hpY2FsbHkuDQo+IA0KPiBJZ29yDQo+ IA0KPiBJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdHJhbnNw b3J0IGRvbWFpbiBzZXJ2ZXIgYW5kDQo+IHRyYW5zcG9ydCBkb21haW4gY2xpZW50LiBJIHdvdWxk IGFyZ3VlIHRoYXQgdGhlIHZlcnkgc2FtZSBpbnRlcmZhY2UgY2FuIGJlDQo+IHVzZWQgYmV0d2Vl biBhIG11bHRpLWRvbWFpbiBwcm92aWRlciAoZS5nLiBUZWxlZm9uaWthKSBhbmQgaXRzIGNsaWVu dHMuIE5vdA0KPiBhbGwgc3VjaCBjbGllbnRzIGFyZSBkdW1iLCBhcyBEYW5pZWxlIGNsYWltcywg YW5kIG9ubHkgY2FyZSBhYm91dCDigJxhIGdpdmVuDQo+IGFtb3VudCBvZiBHYnBzIGZyb20gQSB0 byBC4oCdLiBJdCBpcyBlYXN5IHRvIGVudmlzaW9uIHRoYXQgc29tZSBvZiB0aGUgY2xpZW50cw0K PiB3b3VsZCB3YW50IGZyb20gVGVsZWZvbmljYSBhIGNvdXBsZSBvZiBTUkxHLWRpc2pvaW50IGFi c3RyYWN0IGxpbmtzLCBzbyB0aGF0DQo+IHRoZSBjbGllbnRzIGNhbiBoYXZlIGEgc2F5IGluIHRo ZSBwbGFjZW1lbnQgb2YgdGhlaXIgIHNlcnZpY2VzIGFjcm9zcyB0aGUNCj4gVGVsZWZvbmlrYSBu ZXR3b3JrLiBUaHJlZSBwb2ludHMgaGVyZToNCj4gDQo+IGEpICAgICAgVGhlIGNsaWVudCB3aWxs IGJlIGFibGUgdG8gY29uZmlndXJlIGZ1bGx5IG9yIHBhcnRpYWxseSB0aGUgYWJzdHJhY3QgdG9w b2xvZ3kNCj4gaGUgd2FudHMgdGhlIG5ldHdvcmsgdG8gcHJlc2VudCB0byBoaW07DQo+IA0KPiBi KSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNpbXBsZSAoZS5n LiBhIHNpbmdsZSBhYnN0cmFjdA0KPiBub2RlKSBvciBhcyBjb21wbGV4IChlLmcuIE4gYWJzdHJh Y3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBhYnN0cmFjdA0KPiBsaW5rcykgYXMgdGhlIGNs aWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXLigJlzIGFwcHJvdmFs KQ0KPiANCj4gYykgICAgICBUaGUgYWJzdHJhY3QgdG9wb2xvZ3kgcHJlc2VudGVkIHRvIHRoZSBj bGllbnQgaXMgY29tcGxldGVseSBkZWNvdXBsZWQNCj4gZnJvbSB0aGUgcHJvdmlkZXLigJlzIGFj dHVhbCB0b3BvbG9neS4NCj4gDQo+IFRoZXJlZm9yZSB0aGUgc2FtZSBpbnRlcmZhY2Uvc2V0IG9m IG1vZGVscyBjYW4gYmUgdXNlZCBiZXR3ZWVuIGFueQ0KPiB0cmFuc3BvcnQgbmV0d29yayBwcm92 aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhlcm1vcmUsIHRoZSBpbnRlcmZhY2UgY2FuIGJlDQo+ IHVzZWQgaW4gdGhlIGhpZXJhcmNoaWNhbCB3YXksIHRoYXQgaXMsIGEgY2xpZW50IG9mIGEgdHJh bnNwb3J0IGRvbWFpbiBjYW4gc2VydmUNCj4gaXRzIG93biBjbGllbnRzIHVzaW5nIHRoZSBzYW1l IGludGVyZmFjZSBhcyBpdCB1c2VzIHRvIHRhbGsgdG8gaXRzIG93bg0KPiBwcm92aWRlcihzKQ0K PiANCj4gSGVyZSBJIHdvdWxkIGxpa2UgdG8gZ2l2ZSB5b3UgYSBsaXR0bGUgY2xlYXJlciBwaWN0 dXJlIG9uIG11bHRpLWRvbWFpbiBpc3N1ZXMuDQo+IA0KPiAgICArLS0tLS0tLS0tLS0tLS0tLSsg ICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLSsNCj4gICAgfCAgIEN1c3Rv bWVyIDEgICB8ICAgfCAgIEN1c3RvbWVyIDIgIHwgIC4uLiB8IEN1c3RvbWVyIE0gICB8DQo+ICAg ICstLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0t LS0tKw0KPiAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAv DQo+ICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgIHwgICAgICAgICAgICAgLw0KPiAg ICAgICAgSW50ZXJmYWNlIEIgICBcICAgICAgICAgICB8ICAgICAgICAgICAgLw0KPiAgICAgICAg ICAgICAgICAgICAgICAgXCAgICAgICAgICB8ICAgICAgICAgICAvDQo+ICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAgICAgICAgICAgICAgICAg IHwgICBWTkMgTXVsdGktZG9tYWluICAgfCBFMkUgYWJzdHJhY3QNCj4gICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICBDb29yZGluYXRpb24gICAgfCB0b3BvbG9neSBjcmVhdGlvbg0KPiAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgLyAgICAgICAgIHwgICAgICAgICAgICBcDQo+ICAgICAgICAgSW50ZXJmYWNl IEMgICAvICAgICAgICAgIHwgICAgICAgICAgICAgXCAgTmV0d29yayBUb3BvbG9neQ0KPiAgICAg ICAgICAgICAgICAgICAgICAvICAgICAgICAgICB8ICAgICAgICAgICAgICBcIChhYnN0cmFjdCkN Cj4gICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgfCAgICAgICAgICAgICAgIFwNCj4g ICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICArLS0tLS0t LS0tLS0tLS0tLS0tKw0KPiAgICB8IE5ldHdvcmsgRG9tYWluIDEgfCAgIHwgTmV0d29yayBEb21h aW4gMiB8IC4uIHwgTmV0d29yayBEb21haW4gTiB8DQo+ICAgICstLS0tLS0tLS0tLS0tLS0tLS0r ICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAg ICBWZW5kb3IgWCAgICAgICAgICAgICAgICAgVmVuZG9yIFkgICAgICAgICAgICAgICBWZW5kb3Ig Wg0KPiANCj4gDQo+IFdoYXQgaXMgc2l0dGluZyBhYm92ZSDigJxWTkPigJ0gKHRoYXQgY29vcmRp bmF0ZXMgb3ZlciBtdWx0aS1kb21haW4gY29udHJvbGxlcnMpDQo+IGNhbiBiZSBhbiBpbnRlcm5h bCBzZXJ2aWNlIG9yZ2FuaXphdGlvbiAob2YgdGhlIHNhbWUgb3BlcmF0b3IpIG9yIHNlcnZpY2UN Cj4gcHJvdmlkZXJzIChkaWZmZXJlbnQgb3BlcmF0b3JzLCBmb3JtaW5nIGNhcnJpZXJzIG9mIGNh cnJpZXIpLiBUaGUgY29udHJvbCBlbnRpdHkNCj4gb2YgdGhlc2UgZW50aXRpZXMgaXMgcmVmZXJy ZWQgdG8gYXMgQ3VzdG9tZXIgTmV0d29yayBjb250cm9sIChDTkMpLiBUaGUgVk5DDQo+IOKAk0NO QyBpbnRlcmZhY2UgKEludGVyZmFjZSBCKSBoYXMgZGlmZmVyZW50IHJlcXVpcmVtZW50cyB0aGFu IHRoZSBWTkMtUE5DDQo+IGludGVyZmFjZSAoSW50ZXJmYWNlIEMpLiBUb3BvbG9neSBhYnN0cmFj dGlvbiBpcyBqdXN0IG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzDQo+IGFuZCBpbiBtdWx0aS1kb21h aW4gY2FzZSwgdGhlIFZOQyBpcyBwZXJmb3JtaW5nIG11bHRpLWRvbWFpbiBjb29yZGluYXRpb24N Cj4gZnVuY3Rpb24uIFZOQyBuZWVkcyB0byBoYXZlIGEgc3RhbmRhcmQgaW50ZXJmYWNlIHRoYXQg ZW5hYmxlDQo+IGNvbW11bmljYXRpb25zIHdpdGggZGlmZmVyZW50IGtpbmRzIG9mIGRvbWFpbiBu ZXR3b3JrDQo+IGNvbnRyb2wvbWFuYWdlbWVudCBjb250cm9sICh3aGljaCBpcyByZWZlcnJlZCB0 byBhcyBQTkMsIHlvdSBjYWxsIEFOQykuDQo+IEVhY2ggZG9tYWluIGhhcyBpdHMgb3duIHdheXMg b2YgY29udHJvbGxpbmcgaXRzIG5ldHdvcmssIHdoaWNoIEFDVE4gaXMgbm90DQo+IHRvdWNoaW5n IHRob3NlIGF0IGFsbC4gV2hhdGV2ZXIgdGhlIGNob2ljZXMgb2YgdmVuZG9yIGNvbnRyb2wgcmVn aW1lIHdpbGwNCj4gY29udGludWUgdG8gYmUgZW1wbG95ZWQgKEdNUExTL0FTT04sIFBOTkksIE5N UywgT3BlbkZsb3csIGV0Yy4pLg0KPiANCj4gRm9yIHRoaXMgbXVsdGktZG9tYWluIGNvb3JkaW5h dGlvbiBmdW5jdGlvbiBhc3N1bWVkIGJ5IFZOQyBzaG91bGQgYmUNCj4gb3BlcmF0ZWQgb24gYW4g YWJzdHJhY3QgbGV2ZWwuIFdlIGRvbuKAmXQgd2FudCB0byBpbmplY3QgdGhlIHNhbWUgbGV2ZWwg b2YNCj4gYWN0dWFsIG5ldHdvcmsgdG9wb2xvZ3kgKGUuZy4sIFRFRCkgYXMgdGhlIGRvbWFpbiBj b250cm9sbGVyIG9wZXJhdGVzIGl0cw0KPiBwaHlzaWNhbC9hY3R1YWwgbmV0d29ya3MuIElzIHRo aXMgYWdyZWVhYmxlPyBZb3Ugc2FpZCBhYm92ZSB0aGlzIGluIGMpIFRoZQ0KPiBhYnN0cmFjdCB0 b3BvbG9neSBwcmVzZW50ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IGRlY291cGxlZCBm cm9tIHRoZQ0KPiBwcm92aWRlcuKAmXMgYWN0dWFsIHRvcG9sb2d5Lg0KPiANCj4gTm93IHRoZSBW TkMgKG11bHRpLWRvbWFpbiBjb29yZGluYXRvcikgbmVlZHMgdG8gY29vcmRpbmF0ZSBzaWduYWxp bmcNCj4gYWNyb3NzIG11bHRpLWRvbWFpbiBjb250cm9sbGVycyAoaW4gdGVybXMgb2YgdGhlIHNl cXVlbmNlIG9mIHRoZSBlbmQtdG8tZW5kDQo+IHBhdGggYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMp LiBUaGlzIGlzIGEgbmV3IGVsZW1lbnQgSSBiZWxpZXZlIEFDVE4gd2lsbCBoYXZlDQo+IHRvIGRl dmVsb3AuIFRoaXMgaW50ZXJmYWNlIEMgKFZOQy1QTkMpIGlzIHZlcnkgZGlmZmVyZW50IGZyb20g SW50ZXJmYWNlIEINCj4gKENOQy1WTkMpLiBUaGVyZSBhcmUgb3RoZXIgZGlmZmVyZW5jZXMgKHBs ZWFzZSBzZWUgU2VjdGlvbiA2LjUgb2YgdGhlDQo+IGZyYW1ld29yayBkb2N1bWVudCkuICBCdXQg SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGZyb20gYW4gYWJzdHJhY3QgdG9wb2xvZ3kNCj4gc3RhbmRw b2ludCwgc2ltaWxhciBtb2RlbCB3b3JrcyBmb3IgSW50ZXJmYWNlcyBCIGFuZCBDIGFzIHlvdSBz YWlkICBiKSAgICAgIFRoZQ0KPiBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNp bXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdCBub2RlKSBvciBhcw0KPiBjb21wbGV4IChlLmcu IE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBhYnN0cmFjdCBsaW5rcykgYXMg dGhlDQo+IGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXLigJlz IGFwcHJvdmFsKS4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWW91bmcNCj4gDQo+IA0KPiANCj4g DQo+IEZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0N Cj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDk6MTcgQU0NCj4gVG86IEJFTE9UVEks IFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IExlZXlv dW5nOw0KPiBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29tDQo+ IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGkt YWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBTZXJnaW8sDQo+IEEgY291 cGxlIG9mIGNvbW1lbnRzIGluIGxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IElnb3INCj4gDQo+IEZy b206IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKSBbbWFpbHRvOnNlcmdpby5iZWxvdHRpQGFsY2F0 ZWwtbHVjZW50LmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDk6MTUgQU0N Cj4gVG86IElnb3IgQnJ5c2tpbjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IExl ZXlvdW5nOyBhY3RuQGlldGYub3JnOw0KPiBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29t DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSk7IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKQ0KPiBT dWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVu dHMNCj4gDQo+IEhpIElnb3IsDQo+IA0KPiBQbGVhc2UsIHNlZSBpbiBsaW5lDQo+IA0KPiBSZWdh cmRzDQo+IFNlcmdpbw0KPiANCj4gDQo+IEZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlz a2luQGFkdmFvcHRpY2FsLmNvbV0NCj4gU2VudDogdmVuZXJkw6wgMTAgb3R0b2JyZSAyMDE0IDIy OjM3DQo+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IEtpbmcsIERhbmllbDsgTGVleW91bmc7IEJF TE9UVEksIFNFUkdJTyAoU0VSR0lPKTsNCj4gYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRm Lm9yZz47IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFp bC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUp DQo+IFN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBj b21tZW50cw0KPiANCj4gSGkgRGFuaWVsZSwNCj4gUGxlYXNlLCBzZWUgaW4gbGluZS4NCj4gSWdv cg0KPiANCj4gRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNjYXJl bGxpQGVyaWNzc29uLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDEwLCAyMDE0IDE6MjUg UE0NCj4gVG86IElnb3IgQnJ5c2tpbjsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwg U0VSR0lPIChTRVJHSU8pOw0KPiBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsg ZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWlsLmNvbTxt YWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3Vi amVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRz DQo+IA0KPiBIaSBJZ29yLA0KPiANCj4gV2hhdCBkbyB5b3UgbWVhbiBieSBjbGllbnQgaGVyZT8g VGhlIG9uZSB0aGF0IGlzIHRoZSBkb2N1bWVudCBpcyBjYWxsZWQNCj4g4oCcc2VydmljZSBwcm92 aWRlcuKAnSBvciB0aGUgb25lIHRoYXQgaXMgY2FsbGVkIOKAnGNsaWVudOKAnSA/IEZyb20gd2hh dCB5b3Ugc2VuZCBJDQo+IHRlbmQgdG8gdGhpbmsgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBz ZXJ2aWNlIHByb3ZpZGVyLCBidXQgSSBtaWdodCBiZQ0KPiB3cm9uZywgcGxlYXNlIGNvcnJlY3Qg bWUuDQo+IA0KPiBJQj4+IEJ5IGNsaWVudCBJIG1lYW4gdGhlIGNsaWVudCBvZiBhIHRyYW5zcG9y dCBkb21haW4sIHRoZSBvbmUgd2hvIHNwZWFrcw0KPiBOZXRjb25mL1Jlc3Rjb25mIHRvIHRoZSB0 cmFuc3BvcnQgZG9tYWluLiBUaGUgZ3V5IHdobyBzcGVha3MgZnJvbSB0aGUNCj4gb3RoZXIgZW5k IChpLmUuIG9uIGJlaGFsZiBvZiB0aGUgdHJhbnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpICBpcyB0 aGUgdHJhbnNwb3J0DQo+IGRvbWFpbuKAmXMgSHlwZXJ2aXNvci4NCj4gDQo+IFNCPj4+IEl0IGlz IGNsZWFyIHdoYXQgeW91IGludGVuZCBoZXJlLCBldmVuIGlmIHdvcmQgY2xpZW50IGl0IHNlZW1z IHRvIG1lDQo+IG1vcmUgcmVsYXRlZCB0byBhcHBsaWNhdGlvbiB0aGFuIHRvIGEgc2VydmljZSBw cm92aWRlci4NCj4gDQo+IElCPj4gSSBhbSB0YWxraW5nIGFib3V0IHRoZSBpbnRlcmZhY2UgYmV0 d2VlbiB0cmFuc3BvcnQgZG9tYWluIHNlcnZlciBhbmQNCj4gdHJhbnNwb3J0IGRvbWFpbiBjbGll bnQuIEkgd291bGQgYXJndWUgdGhhdCB0aGUgdmVyeSBzYW1lIGludGVyZmFjZSBjYW4gYmUNCj4g dXNlZCBiZXR3ZWVuIGEgbXVsdGktZG9tYWluIHByb3ZpZGVyIChlLmcuIFRlbGVmb25pa2EpIGFu ZCBpdHMgY2xpZW50cy4gTm90DQo+IGFsbCBzdWNoIGNsaWVudHMgYXJlIGR1bWIsIGFzIERhbmll bGUgY2xhaW1zLCBhbmQgb25seSBjYXJlIGFib3V0IOKAnGEgZ2l2ZW4NCj4gYW1vdW50IG9mIEdi cHMgZnJvbSBBIHRvIELigJ0uIEl0IGlzIGVhc3kgdG8gZW52aXNpb24gdGhhdCBzb21lIG9mIHRo ZSBjbGllbnRzDQo+IHdvdWxkIHdhbnQgZnJvbSBUZWxlZm9uaWNhIGEgY291cGxlIG9mIFNSTEct ZGlzam9pbnQgYWJzdHJhY3QgbGlua3MsIHNvIHRoYXQNCj4gdGhlIGNsaWVudHMgY2FuIGhhdmUg YSBzYXkgaW4gdGhlIHBsYWNlbWVudCBvZiB0aGVpciAgc2VydmljZXMgYWNyb3NzIHRoZQ0KPiBU ZWxlZm9uaWthIG5ldHdvcmsuIFRocmVlIHBvaW50cyBoZXJlOg0KPiANCj4gYSkgICAgICBUaGUg Y2xpZW50IHdpbGwgYmUgYWJsZSB0byBjb25maWd1cmUgZnVsbHkgb3IgcGFydGlhbGx5IHRoZSBh YnN0cmFjdCB0b3BvbG9neQ0KPiBoZSB3YW50cyB0aGUgbmV0d29yayB0byBwcmVzZW50IHRvIGhp bTsNCj4gDQo+IGIpICAgICAgVGhlIHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kgY291bGQgYmUgYXMg c2ltcGxlIChlLmcuIGEgc2luZ2xlIGFic3RyYWN0DQo+IG5vZGUpIG9yIGFzIGNvbXBsZXggKGUu Zy4gTiBhYnN0cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBieSBNIGFic3RyYWN0DQo+IGxpbmtz KSBhcyB0aGUgY2xpZW50IHdhbnRzIGl0IHRvIGJlIChzdWJqZWN0IHRvIHRoZSBwcm92aWRlcuKA mXMgYXBwcm92YWwpDQo+IA0KPiBjKSAgICAgIFRoZSBhYnN0cmFjdCB0b3BvbG9neSBwcmVzZW50 ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IGRlY291cGxlZA0KPiBmcm9tIHRoZSBwcm92 aWRlcuKAmXMgYWN0dWFsIHRvcG9sb2d5Lg0KPiANCj4gVGhlcmVmb3JlIHRoZSBzYW1lIGludGVy ZmFjZS9zZXQgb2YgbW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55DQo+IHRyYW5zcG9ydCBu ZXR3b3JrIHByb3ZpZGVyIGFuZCBpdHMgY2xpZW50LiBGdXJ0aGVybW9yZSwgdGhlIGludGVyZmFj ZSBjYW4gYmUNCj4gdXNlZCBpbiB0aGUgaGllcmFyY2hpY2FsIHdheSwgdGhhdCBpcywgYSBjbGll bnQgb2YgYSB0cmFuc3BvcnQgZG9tYWluIGNhbiBzZXJ2ZQ0KPiBpdHMgb3duIGNsaWVudHMgdXNp bmcgdGhlIHNhbWUgaW50ZXJmYWNlIGFzIGl0IHVzZXMgdG8gdGFsayB0byBpdHMgb3duDQo+IHBy b3ZpZGVyKHMpDQo+IA0KPiBNb3Jlb3ZlciBJIHdvdWxkIGF2b2lkIGluIHRoaXMgcGhhc2UgdG8g bWVudGlvbiBhbnkgcmVmZXJlbmNlIHRvIHByb3RvY29sDQo+IGltcGxlbWVudGF0aW9uIChlLmcu IE5ldGNvbmYvUmVzdGNvbmYpIDogSSB0aGluayB3ZSBhcmUgaW4gdGhlIHBoYXNlIHRvDQo+IHVu ZGVyc3RhbmQgYXJjaGl0ZWN0dXJlLCB3aGF0IGFyZSB0aGUgcmVsZXZhbnQgaW50ZXJmYWNlcywg YW5kIHdoYXQNCj4gaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIG92ZXIgdGhlIHJlZmVyZW5jZSBw b2ludHMvaW50ZXJmYWNlcy4gSSBndWVzcyB0aGlzIGlzDQo+IGNsZWFybHkgc3RhdGVkIGFsc28g aW4gdGhlIGNoYXJ0ZXIgb2YgQm9GLg0KPiANCj4gSUI+PiBBZ3JlZS4gSSB1c2VkIE5ldGNvbmYv UmVzdGNvbmYgYXMgYW4gZXhhbXBsZSB0byBtYWtlIGl0IGNsZWFyIHdoYXQNCj4gaW50ZXJmYWNl IEkgd2FzIHRhbGtpbmcgYWJvdXQuDQo+IA0KPiAgQXQgYW4gYXBwcm9wcmlhdGUgdGltZSDigJMg Y2VydGFpbmx5IG5vdCBub3cg4oCTIHRoZSBuZXh0IHN0ZXAgaXMgdG8gY2hlY2sgd2l0aA0KPiBv dGhlciBTRE9zIG9uIHRoZSBhdmFpbGFiaWxpdHkgb2YgcmVsZXZhbnQgY29yZS90ZWNobm9sb2d5 DQo+IHNwZWNpZmljL2FwcGxpY2F0aW9uIHNwZWNpZmljIGluZm9ybWF0aW9uIG1vZGVsIOKAnGZy YWdtZW50c+KAnSwgYW5kIHRoZW4gZmluYWxseQ0KPiBwcm9jZWVkIG9uIHRoZSBwYXRoIG9mIHBy dW5pbmcvcmVmYWN0b3JpbmcgYW5kIG1hcHBpbmcgdG8gUkVTVC9KU09OLA0KPiBOZXRjb25mL1lB TkcsIGFuZCBhbnkgb3RoZXIgcG9zc2libGUgZGF0YSBtb2RlbGluZyBhbmQgY29uZmlndXJhdGlv bg0KPiBwcm90b2NvbCBleGlzdGluZy4gVGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nICBvZiB0aGUg Qm9GIHNjb3BlIC4NCj4gDQo+IEkgZG9u4oCZdCB0aGluayB0aGUgY2xpZW50IG9mIHRoZSBtdWx0 aS1kb21haW4gbmV0d29yayB3YW50cyB0byBoYXZlIGEgc28NCj4gZGV0YWlsZWQgdmlldyBvZiB0 aGUgbmV0d29yaywgaGUgZG9lcyBub3QgY2FyZSBhYm91dCBkb21haW5zLCBpbnRlciBkb21haW4N Cj4gbGlua3Mgb3Igd2hhdGV2ZXIsIEkgd291bGQgc2F5IGhlIG9ubHkgY2FyZXMgYWJvdXQgYSBn aXZlbiBhbW91bnQgb2YgR2Jwcw0KPiBmcm9tIEEgdG8gQiB3aXRoIGEgZ2l2ZW4gbWF4IGRlbGF5 IGFuZCBwcm9iYWJseSBzb21lIGRpdmVyc2l0eSBwYXJhbWV0ZXJzLg0KPiANCj4gSUI+PiBBZ2Fp biwgYnkgY2xpZW50IEkgbWVhbiBtdWx0aS1kb21haW4gbmV0d29yayBjb250cm9sbGVyIChlLmcu IFRlbGVmb25pY2ENCj4gU0ROIGNvbnRyb2xsZXIpLCBub3QgdGhlIGNsaWVudCB1c2luZyBzZXJ2 aWNlcyBvZiB0aGUgbXVsdGktZG9tYWluIG5ldHdvcmsNCj4gKGkuZS4gbm90IHRoZSBUZWxlZm9u aWNhIGNsaWVudHMpLiBTdWNoIGNsaWVudCB1c2VzICB0aGUgdHJhbnNwb3J0IGRvbWFpbnMgZm9y IGENCj4gcmVhc29uLiDigJxhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBC4oCdIGlz IHRvbyBsb29zZSBhbmQgbGl0dGxlIGZvciB0aGUNCj4gY2xpZW50IHRvIGRvIHRoZSBuZXR3b3Jr IHBsYW5uaW5nLiBJTU8gdGhlIGNsaWVudCBuZWVkcyB0byAqcGxhbiogdGhlDQo+IGFic3RyYWN0 IHRvcG9sb2dpZXMgcHJvdmlkZWQgYnkgdGhlIHRyYW5zcG9ydCBkb21haW5zIHRoZSBzYW1lIG9y IHNpbWlsYXINCj4gd2F5IGFzIGhlIHdvdWxkIHBsYW4gaGlzIG93biBhY3R1YWwgdG9wb2xvZ3ku DQo+IA0KPiBTQj4+PiB5ZXMsIHN1cmUsIGluIHlvdSB2aWV3IG9mIOKAnGNsaWVudOKAnSAsIHRo aXMgaXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIgRGFuaWVsZSBpcw0KPiB0YWxraW5nLCBzbyBhbiBh YnN0cmFjdCB2aWV3IG9mIHdoYXQgaXMgdGhlIHJlYWwgdHJhbnNwb3J0IG5ldHdvcmsgaXMNCj4g Y29uc2lkZXJlZCBhdCB0aGlzIGxldmVsLiBBcyBJIHNhaWQgdG8gWW91bmcsIGluIG15IHByZXZp b3VzIG1haWwsIGluIHRoZSBjYXNlIG9mDQo+IGEgc2luZ2xlIGRvbWFpbiBzY2VuYXJpbyBWTkMg YW5kIFBOQyBjb3VsZCBhbHNvIGNvaW5jaWRlIGJ1dCBpbiBjYXNlIG9mIGENCj4gbXVsdGktZG9t YWluIHNjZW5hcmlvcyB0aGUgc2NvcGUgaXMgdG8gcHJvdmlkZSB0byBhcHBsaWNhdGlvbiBsYXll ciBhIHNpbmdsZQ0KPiB2aXJ0dWFsaXplZCB2aWV3IG9mIHRoZSB1bmRlcmxpbmUgbXVsdGkgZG9t YWluIG5ldHdvcmsuDQo+IA0KPiBPbiB0aGUgb3RoZXIgc2lkZSwgdGhlIG9uZSB0aGF0IGNhcmVz IGFib3V0IGFsbCBvZiB0aGUgaXNzdWVzIHlvdSBsaXN0ZWQgaXMgdGhlDQo+IHNlcnZpY2UgcHJv dmlkZXIgKGFzIHBlciBhY3R1YWwgZG9jdW1lbnQgdGVybWlub2xvZ3kpLiBIb3dldmVyIGFsc28g dGhlDQo+IHNlcnZpY2UgcHJvdmlkZXIgZG9lcyBub3QgZ28gaW50byBwaHlzaWNhbCBpbXBhaXJt ZW50IGRldGFpbHMuIEhlIGNhcmVzIGFib3V0DQo+IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZSBi b3JkZXJzIG9mIHRoZSBkb21haW5zLCBpbnRlciBkb21haW4gbGlua3MuIEhvdw0KPiBzdWNoIGNv bm5lY3Rpdml0eSBpcyBwcm92aXNpb25lZC9tYW5hZ2VkIGlzIHRoZSBuZXR3b3JrIHByb3ZpZGVy IGJ1c2luZXNzLg0KPiBUaGUgbmV0d29yayBwcm92aWRlcyBtaWdodCBiZSB1c2luZyBHTVBMUywg Tk1TIGFuZCBPTkYgY29udHJvbGxlciB3aXRoDQo+IE9wZW4gRmxvdyBvciB3aGF0ZXZlciB0byBj b250cm9sIHRoZSBuZXR3b3JrLiBNYXliZSBjYWxsaW5nIGl0IFBOQyBpcw0KPiBjb25mdXNpbmc/ IFRoZSBQTkMgY2FuIGJlIGFueSBvZiB0aGUgdGhpbmdzIEnigJl2ZSBsaXN0ZWQgYW5kIG11Y2gg bW9yZS4NCj4gDQo+IElCPj4gSW4gdGhpcyBjYXNlIG15IGNsaWVudCBpcyB5b3VyIHNlcnZpY2Ug cHJvdmlkZXIgOz0pLiBZb3UgYXJjaGl0ZWN0dXJhbGx5DQo+IHNlcGFyYXRlIGNsaWVudCBmcm9t IHRoZSBzZXJ2aWNlIHByb3ZpZGVyLCBiZWNhdXNlIHlvdSBwcm9iYWJseSBiZWxpZXZlIHRoYXQN Cj4gaXQgaXMgcG9zc2libGUgdG8gc3RhbmRhcmRpemUgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRo ZSB0d28uIEkgZGlzYWdyZWUgd2l0aA0KPiB0aGF0IGFuZCBkb27igJl0IHRoaW5rIEFDVE4gc2hv dWxkIHdvcmsgb24gdGhpcy4gSW4gdGhlIGNvbnRleHQgb2YgQUNUTiBJIHNlZQ0KPiBvbmx5IHR3 byBjb25zdHJ1Y3RzOiBUcmFuc3BvcnQgZG9tYWluIGNvbnRyb2xsZXIgKHRyYW5zcG9ydCBzZXJ2 aWNlIHByb3ZpZGVyKQ0KPiBhbmQgIFRyYW5zcG9ydCBjbGllbnQgY29udHJvbGxlciAodHJhbnNw b3J0IHNlcnZpY2UgdXNlcikuDQo+IA0KPiBTQj4+PiBBQ1ROIGhlcmUgaXMgbm90IHJlaW52ZW50 aW5nIHRoZSB3aGVlbCAsIGluIG90aGVyIFNETyBTRE4gc3BlY2lmaWMgaXMNCj4gY29uc2lkZXJl ZCAgdGhlIGFwcGxpY2F0aW9uIGxheWVyICwgYW5kIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBBTCBh bmQgU0RODQo+IGNvbnRyb2xsZXIgKGluIHRoaXMgY2FzZSB0aGUgVk5DIG9mIEFDVE4pIC4gVGhp cyBpbnRlcmZhY2UgcGVybWl0IHRvIGFueSBjbGllbnQNCj4gdG8gZGlyZWN0bHkgaW1wYWN0IHRv IGhpcyBvd24gc2VydmljZXMgYW5kIGhpcyBvd24g4oCcdmlydHVhbGl6ZWTigJ0gcmVzb3VyY2Vz IC4NCj4gDQo+IA0KPiBIZW5jZSB0aGUgaW50ZXJmYWNlcyB0byBiZSBjb25zaWRlcmVkIGFyZSB0 d28sIG5vdCB0aHJlZSAoYXMgRGFuIHNhaWQpIEkgdGhpbmsNCj4gdGhpcyByZXBsaWVzIHRvIHF1 ZXN0aW9ucyAxIGFuZCAzLiBKdXN0IHRvIGFkZCBzb21ldGhpbmcgcmVnYXJkaW5nIDIsIEkgd291 bGQNCj4gc2F5IHRoYXQgdGhleSBuZWVkIGp1c3QgYSBzaW5nbGUgZW50cnkgcG9pbnQgdG8gdGhl IG5ldHdvcmsgY29udHJvbCAoY291bGQgYmUgYQ0KPiBzbWFsbCBwaWVjZSBvZiBjb2RlIHJ1bm5p bmcgb24gdG9wIG9mIHRoZSBQQ0Ugb2YgeW91ciBHTVBMUyBkb21haW4pLCB3aGljaA0KPiBhY3Rz IGFzIGFuIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBWTkMgYW5kIHRoZSBjb250cm9sIHBsYW5lIG9m IHlvdXIgbmV0d29yaw0KPiBhbmQgcGVyZm9ybXM6IOKAnC0gTWFwcGluZyBvZiBwaHlzaWNhbCBh bmQgdmlydHVhbCByZXNvdXJjZXPigJ0gYW5kICDigJxSZXF1ZXN0czoNCj4gcGF0aCwgcHJvdmlz aW9uLCBtb2RpZnkgYW5kIHJlc3RvcmXigJ0uDQo+IA0KPiBJQj4+IEFzIEkgc2FpZCwgdGhpcyBp cyB0aGUgdGFzayBvZiB0aGUgdHJhbnNwb3J0IGRvbWFpbiBIeXBlcnZpc29yLCB3aG9zZSByb2xl DQo+IGlzLCBlc3NlbnRpYWxseSwgdG8gdHJhbnNsYXRlIGJhY2sgYW5kIGZvcnRoIGFic3RyYWN0 IDw9PiBhY3R1YWwgdG9wb2xvZ3kNCj4gZWxlbWVudHMgYW5kIHNlcnZpY2UgcmVxdWVzdHMvcmVz cG9uc2VzIGNvbnRhaW5pbmcgdGhlIGFic3RyYWN0L2FjdHVhbA0KPiB0b3BvbG9neSBwYXRocy4g SSB0aGluayB0aGF0IHRoZSBub3J0aC9zb3V0aCBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgdHJhbnNw b3J0DQo+IGRvbWFpbiBIeXBlcnZpc29yIGFuZCB0aGUgZW50aXR5IHJlcHJlc2VudGluZyB0aGUg Y2xpZW50IG9mIHRoZSB0cmFuc3BvcnQNCj4gZG9tYWluIChubyBtYXR0ZXIgaG93IHlvdSBjYWxs IGl0KSBpcyB0aGUgb25seSBpbnRlcmZhY2UgQUNUTiBjYW4gd29yayBvbg0KPiB3aXRoIHRoZSBo b3BlIHRvIHByb2R1Y2Ugc29tZXRoaW5nIHVzZWZ1bC4NCj4gDQo+IENoZWVycw0KPiBEYW5pZWxl DQo+IA0KPiANCj4gDQo+IEZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFv cHRpY2FsLmNvbV0NCj4gU2VudDogdmVuZXJkw6wgMTAgb3R0b2JyZSAyMDE0IDAzOjE2DQo+IFRv OiBLaW5nLCBEYW5pZWw7IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7DQo+IGFj dG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7DQo+ IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFpbC5jb208 bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1 YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50 cw0KPiANCj4gWW91bmcgYW5kIERhbiwNCj4gDQo+IEl0IGRvZXMgbm90IG1hdHRlciBob3cgeW91 IGNhbGwgbWUsIGFuZCBhcyBKb2huIGlzIGhlbHBmdWxseSBhcHBseWluZywgeW91IGNhbg0KPiBp Z25vcmUgd2hhdCBJIGFtIHNheWluZy4gQnV0IGxldCBtZSBleHBsYWluIGluIHNvbWUgbW9yZSBk ZXRhaWxzIHdoYXQgSQ0KPiBtZWFudC4NCj4gDQo+IFN1cHBvc2Ugd2UgaGF2ZSBhIGNsaWVudCAo c3VjaCBhcyBURkspIG9mIGEgbXVsdGktZG9tYWluIHRyYW5zcG9ydCBuZXR3b3JrLA0KPiB3aG8g d2FudHMgdG8gcHJvdmlzaW9uIGFuZCBtYW5pcHVsYXRlIGUyZSB0cmFuc3BvcnQgc2VydmljZXMg dGhlIHdheSBoZQ0KPiB3YW50cyBpdCAoaS5lLiBhcHBseWluZyBoaXMgcG9saWNpZXMpLiBXaGF0 IHdvdWxkIHN1Y2ggY2xpZW50IG5lZWQ/DQo+IA0KPiANCj4gMS4gICAgIEFuIGFjY2VzcyB0byBh IHVuaWZpZWQgbmV0d29yayBURSB0b3BvbG9neSB0aGF0IGNvdWxkIGJlIHVuZGVyc3Rvb2QgYW5k DQo+IHVzZWQgYnkgdGhlIGNsaWVudOKAmXMgcGF0aCBjb21wdXRlciB0byBzZWxlY3Qgc2Vydmlj ZSBlMmUgcGF0aHMuIEhvdyBkb2VzIHRoZQ0KPiBjbGllbnQgZ2V0IHN1Y2ggYSB0b3BvbG9neT8g VGhlIG5lY2Vzc2FyeSBvdmVybGF5IHRvcG9sb2d5IGNvbXByaXNlcw0KPiBhYnN0cmFjdCB0b3Bv bG9naWVzIHByZXNlbnRlZCBmb3IgdGhlIGNsaWVudCBieSBlYWNoIG9mIHRoZSB0cmFuc3BvcnQg ZG9tYWlucw0KPiArIGludGVyLWRvbWFpbiBURSBsaW5rcy4gSGVuY2Ugd2UgYXJlIHRhbGtpbmcg YWJvdXQgaW50ZXJmYWNlICMxIChhbmQgZGF0YQ0KPiBtb2RlbCAjMSkgYmV0d2VlbiBhIHByb3Zp ZGVyIGh5cGVydmlzb3IvVk5DIGFuZCB0aGUgY2xpZW50IGNvbnRyb2xsZXIgdG8NCj4gZXhwb3Nl IGluIGEgdW5pZmllZCBhYnN0cmFjdCAgd2F5ICBpdHMgdG9wb2xvZ3kgb24gcGVyIGNsaWVudC90 ZW5hbnQgYmFzaXMuDQo+IEZ1cnRoZXJtb3JlLCB0aGUgY2xpZW50IGNvbnRyb2xsZXIgY2FuIHVz ZSB0aGlzIGludGVyZmFjZSBpbiB0aGUgb3Bwb3NpdGUNCj4gZGlyZWN0aW9uIHRvIG1vZGlmeSB0 aGUgc2FpZCBhYnN0cmFjdCB0b3BvbG9neSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXLigJlzDQo+ IGFwcHJvdmFsKSwgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHRoZSBvbmx5IGd1eSB3aG8ga25vd3Mg aG93IHRoZSBhYnN0cmFjdA0KPiB0b3BvbG9neSBleHBvc2VkIHRvIGhpbSBzaG91bGQgbG9vayBs aWtlIHRvIGJlIHVzZWZ1bCAoZS5nLiB3aGljaCBhbmQgaG93DQo+IHRoZSBhYnN0cmFjdCBsaW5r cyBzaG91bGQgYmUgZGlzam9pbnQgZnJvbSBlYWNoIG90aGVyLCBob3cgbWFueSBvZiB0aGVtDQo+ IHNob3VsZCBiZSBwcm92aWRlZCwgdGhlaXIgYXR0cmlidXRlcywgZGVzaXJlZCByZWNvdmVyeSBj YXBhYmlsaXRpZXMsIGV0YywpLiBUaGlzDQo+IGtub3dsZWRnZSBpcyBzdXBwb3NlZCB0byBjb21l IGZyb20gdGhlIGNsaWVudOKAmXMgbmV0d29yayBwbGFubmluZy4NCj4gDQo+IDIuICAgICBBIHdh eSB0byBwcm92aXNpb24vbW9kaWZ5L2RlbGV0ZSBlMmUgc2VydmljZXMgd2l0aCB0aGUgdXNlIG9m IHNvDQo+IGNvbXB1dGVkIGUyZSBwYXRocy4gVGhlIGNsaWVudOKAmXMgY29udHJvbGxlciBkb2Vz IHRoYXQgYnkgY2hvcHBpbmcgdGhlIHBhdGhzDQo+IGludG8gcGVyLWRvbWFpbiBzZWdtZW50cyBh bmQgaW5zdHJ1Y3RzIHJlc3BlY3RpdmUgZG9tYWluDQo+IFZOQ3MvSHlwZXJ2aXNvcnMgdG8gc2V0 IHVwL21hbmlwdWxhdGUgc2VydmljZSByZXNwZWN0aXZlIGNvbm5lY3Rpb24NCj4gc2VnbWVudHMu IEhlbmNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGludGVyZmFjZSAjMiAoZGF0YSBtb2RlbCAjMikg Zm9yIHRoZQ0KPiBzZXJ2aWNlIHNlZ21lbnQgbWFuaXB1bGF0aW9uOw0KPiANCj4gMy4gICAgIEEg d2F5IHRvIG1vbml0b3IsIHRyb3VibGVzaG9vdCwgY2Fycnkgb3V0IG1haW50ZW5hbmNlIG9mIHRo ZSBhY3RpdmUgZTJlDQo+IHNlcnZpY2VzLiBUaGlzIHdvdWxkIHJlcXVpcmUgaW50ZXJmYWNlICMz IChkYXRhIG1vZGVsICMzKSBiZXR3ZWVuIHRoZQ0KPiBjbGllbnTigJlzIGNvbnRyb2xsZXIgYW5k IGRvbWFpbnMgVk5Dcy9IeXBlcnZpc29ycyBmb3IgdGhpcyBwdXJwb3NlLg0KPiANCj4gU28sIHdl IGFyZSB0YWxraW5nIDMgWWFuZyBtb2RlbHMgd2l0aCByZXF1aXJlZCBtb2RpZmljYXRpb25zIHRv IG5laXRoZXINCj4gTmV0Y29uZi9SZXN0Y29uZiwgbm9yICBUbyBhbnkgb3RoZXIgbWFuYWdlbWVu dCwgcm91dGluZyBvciBzaWduYWxpbmcNCj4gcHJvdG9jb2wuDQo+IA0KPiBOb3cgSSBoYXZlIGEg Y291cGxlIG9mIHF1ZXN0aW9ucyB0byB5b3U6DQo+IA0KPiAxLiAgICAgSW4gdGhpcyBleGFtcGxl LCB3aGF0IGVsc2UgKGluIGFkZGl0aW9uIHRvIHRoZXNlIHRocmVlIG1vZGVscykgdGhlIGNsaWVu dA0KPiBzdWNoIGFzIFRGSyBpbiB5b3VyIG9waW5pb24gd291bGQgbmVlZD8NCj4gDQo+IDIuICAg ICBXaGF0IGVsc2UgdGhlIG5ldHdvcmsgcHJvdmlkZXJzIGFuZCB0aGVpciB2ZW5kb3JzIHN1Y2gg YXMgQURWQSBvcg0KPiBDSUVOIHdvdWxkIG5lZWQ/DQo+IA0KPiAzLiAgICAgV2hhdCBpcyB0aGUg aW1wb3J0YW5jZSBvZiBhIGNvbnN0cnVjdCBzdWNoIGFzIFBOQz8NCj4gDQo+IA0KPiBNeSBhbnN3 ZXIgdG8gMy4g4oCcSXMgbm90IGltcG9ydGFudCBhdCBhbGwsIGlycmVsZXZhbnTigJ0gZm9yIHRo ZSBmb2xsb3dpbmcgcmVhc29uczoNCj4gDQo+IGEpICAgICBXaGF0IGhhcHBlbnMgYmV5b25kIHRo ZSBWTkMvSHlwZXJ2aXNvciBpbiB0aGUgcHJvdmlkZXIgbmV0d29yayBpcw0KPiBjb21wbGV0ZWx5 IHByb3ByaWV0YXJ5Lg0KPiANCj4gYikgICAgIFRoZXJlIGNvdWxkIGJlIG51bWVyb3VzIHdheXMg YXMgdG8gaG93IHRoZSBwcm92aWRlciBuZXR3b3JrIGlzDQo+IG1hbmFnZWQuIEV4YW1wbGVzOiBj ZW50cmFsaXplZCBQTkMgKGFzIHlvdSBjYWxsIGl0KSwgQURWQSBzdHlsZSBHTVBMUw0KPiBiYXNl ZCBuZXR3b3JrIGludGVsbGlnZW5jZSwgQ0lFTiBzdHlsZSBQTk5JIGJhc2VkIGNvbnRyb2wgcGxh bmUsIGV0Yy4gV2h5IGlzDQo+IHRoYXQgb2YgQUNUTuKAmXMgYnVzaW5lc3M/DQo+IA0KPiBDaGVl cnMsDQo+IElnb3INCj4gDQo+IEZyb206IEtpbmcsIERhbmllbCBbbWFpbHRvOmQua2luZ0BsYW5j YXN0ZXIuYWMudWtdDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDQ6NTggUE0N Cj4gVG86IExlZXlvdW5nOyBJZ29yIEJyeXNraW47IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsN Cj4gYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxs aTsNCj4gZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWls LmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkN Cj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNv bW1lbnRzDQo+IA0KPiBIaSBBbGwsIGluY2x1ZGluZyDigJxJZ25vcuKAnSA7LSkNCj4gDQo+IFR5 cGljYWwgZGljaG90b215IGJldHdlZW4gd2hhdCBvcGVyYXRvcnMgd2FudCBhbmQgd2hhdCB2ZW5k b3JzIGFyZQ0KPiBhY3R1YWxseSB3aWxsaW5nIHRvIHByb3ZpZGUsIGdyb3VwIGNvbnNlbnN1cyB3 aWxsIGV2ZW50dWFsbHkgaGVscCByZXNvbHZlIHRoYXQuDQo+IEVpdGhlciB3YXksIHRoZSBsYXRl c3QgdmVyc2lvbiBvZiB0aGUgRnJhbWV3b3JrIEktRCBpcyB0cnlpbmcgdG8gZm9jdXMgQUNUTg0K PiBkaXNjdXNzaW9uIGFuZCBzY29wZSAoaS5lLiwgdGhlIHByb3RvY29sIHdvcmspIG9uIHRoZSBp bnRlcmZhY2VzIHdoaWNoIGFyZSBpbg0KPiBzY29wZSwgbmFtZWx5Og0KPiANCj4gMS4gVGhlIENO Qy1WTkMgSW50ZXJmYWNlIChDVkkpDQo+IC0gQ3JlYXRlLCBtb2RpZnkgYW5kIGRlbGV0ZSB2aXJ0 dWFsIG5ldHdvcmsgc2VydmljZSBpbnN0YW5jZXMNCj4gLSBSZXNvdXJjZSBtb2RlbA0KPiANCj4g Mi4gVGhlIFZOQy1QTkMgSW50ZXJmYWNlIChWUEkpDQo+IC0gTWFwcGluZyBvZiBwaHlzaWNhbCBh bmQgdmlydHVhbCByZXNvdXJjZXMNCj4gLSBSZXF1ZXN0czogcGF0aCwgcHJvdmlzaW9uLCBtb2Rp ZnkgYW5kIHJlc3RvcmUNCj4gDQo+IEFzIFlvdW5nIHN1Z2dlc3RzLCBpZiB0aGUgVk5DIHJlY2Vp dmVkIHBoeXNpY2FsIHRvcG9sb2d5IGluZm8gaXQgd291bGQgYmUNCj4gcGVyZm9ybWluZyB0aGUg cm9sZSBvZiB0aGUgUGh5c2ljYWwgTmV0d29yayBDb250cm9sbGVyIChQTkMpLCB3aGljaCBpcw0K PiBvYnZpb3VzbHkgYSAoc29tZWhvdykgcmVxdWlyZWQgZnVuY3Rpb24sIGJ1dCB0aGUgaW50ZXJm YWNlIChkaXJlY3QNCj4gcHJvdmlzaW9uaW5nIG9mIHRoZSBhY3R1YWwgcGh5c2ljYWwgbmV0d29y aykgaXMgb3V0IG9mIHNjb3BlIGZvciBBQ1ROLg0KPiANCj4gQnIsIERhbi4NCj4gDQo+IEZyb206 IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWV5b3Vu Zw0KPiBTZW50OiAwOSBPY3RvYmVyIDIwMTQgMjE6MzINCj4gVG86IElnb3IgQnJ5c2tpbjsgQkVM T1RUSSwgU0VSR0lPIChTRVJHSU8pOw0KPiBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYu b3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOw0KPiBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRp ZC5lcz47DQo+IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCj4g Q2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSZTogW0FjdG5dIGRyYWZ0LWNlY2Nh cmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBJZ25vciwNCj4g DQo+IFRoYW5rIHlvdSBmb3IgcHJvdmlkaW5nIHlvdXIgY29tbWVudCB0aGF0IHBhdXNlcyB1cyB0 byB0aGluayBtb3JlIGFuZA0KPiB1bmRlcnN0YW5kIG9uIHRoZSBzYW1lIGxldmVsLiBJIHRoaW5r IHlvdXIgY29tbWVudCB3aWxsIGNvbnRyaWJ1dGUgdG8NCj4gY3J5c3RhbGxpemUgdGhlIHNjb3Bl IG9mIHdvcmsgaGVyZS4NCj4gDQo+IEZpcnN0IG9mIGFsbCwgSSB0aGluayB0aGVyZSB3YXMgYSBt aXN1bmRlcnN0YW5kaW5nIGhlcmUuIEZpcnN0LCB5b3VyIGFzc3VtcHRpb24NCj4gb24gVk5DIHJl Y2VpdmluZyBhY3R1YWwgdW5kZXJseWluZyB0b3BvbG9neSBpcyBpbmNvcnJlY3QuIElmIFZOQyB3 ZXJlIHRvIGhhdmUNCj4gYWN0dWFsbHkgdG9wb2xvZ3kgKGUuZy4gVEVEKSBvZiBhIG5ldHdvcmss IHRoaXMgd291bGQgYmUgY2FsbGVkIGEgUE5DIGFuZCB0aGlzDQo+IGlzIG91dCBvZiBzY29wZSBv ZiBBQ1ROLiBUaGlzIGFzcGVjdCBoYXMgYmVlbiBkaXNjdXNzZWQgYnkgZW1haWwgdGhyZWFkcw0K PiBEYW5pZWxlIHN0YXJ0ZWQgYSBmZXcgd2Vla3MgYWdvLiBDaGVjayB0aGUgYXJjaGl2ZSBvbiB0 aGF0LiBUaGUgcmVhc29uIHRoaXMNCj4gaXMgb3V0IG9mIHNjb3BlIGlzIHRoYXQgUE5DIG11bHRp LWRvbWFpbiBpc3N1ZSBpcyBubyBkaWZmZXJlbnQgZnJvbSB0b2RheeKAmXMNCj4gR01QTFMvUENF IGlzc3VlLCBlc3BlY2lhbGx5IGluIGxpZ2h0IG9mIEgtUENFLiBBQ1ROIGRvZXMgbm90IHN0ZXAg b24gdGhvc2UNCj4gYXJlYXMuIFdoYXQgVk5DIHJlY2VpdmVzIGZyb20gZWFjaCBQTkMgKGRvbWFp biBjb250cm9sbGVyKSBpcyBhbiBhYnN0cmFjdGVkDQo+IHRvcG9sb2d5IHdpdGggdmFyeWluZyBk ZWdyZWVzIGZyb20gYWN0dWFsIHVuZGVybHlpbmcgdG9wb2xvZ3kuIFRoZSByZWFzb24NCj4gd2h5 IHdlIGRpc3Rpbmd1aXNoIHRoZSB0ZXJtIFZOQyBmcm9tIFBOQy4NCj4gDQo+IFdoYXQgY2FuIGJl IGRlZmluZWQgb24gVk5DLVBOQyBpcyBhIHZlcnRpY2FsIHNpZ25hbGluZyBjb29yZGluYXRpb24g ZnJvbQ0KPiBWTkMgdG8gZWFjaCBQTkMuIEFzIGxvbmcgYXMgdGhlIGRldGFpbGVkIHBhdGggY29t cHV0YXRpb24gYW5kIHNpZ25hbGluZw0KPiB3aXRoaW4gYSBkb21haW4gYXJlIGNvbXBsZXRlbHkg dXAgdG8gdGhlIGRvbWFpbiBQTkMuIFZOQyBpcyBub3QgdG8gYmUNCj4gb3BlcmF0ZWQgb24gdGhl IHNhbWUgbGV2ZWwgYXMgUE5DLiBJdHMgZW5kLXRvLWVuZCBwYXRoIGNvbXB1dGF0aW9uIGlzDQo+ IGJhc2VkIG9uIHdoYXQgaXMgZXhwb3NlZCBmcm9tIFBOQ3MgdG8gVk5DLiBUaGUgYWN0dWFsIHRv cG9sb2d5DQo+IGluZm9ybWF0aW9uIGRldGFpbHMgaXMga2VwdCBieSBQTkNzIGFuZCB0aGUgUE5D cyBleHBvc2UgYWJzdHJhY3RlZCB0b3BvbG9neQ0KPiB0aGF0IGNhbiBoaWRlIHRoZSBleGFjdCBk ZXRhaWxzIHdoaWxlIGV4cG9zaW5nIGEgbWluaW11bSBsZXZlbCBvZiBjb25zdHJhaW50cy4NCj4g Rm9yIGluc3RhbmNlLCB0aGUgU1JMRyBvZiB2aXJ0dWFsIGxpbmtzICh3aGljaCBtYXkgYmUgY29u Y2F0ZW5hdGVkIGFjdHVhbA0KPiBsaW5rcykgY2FuIGJlIGV4cG9zZWQgZm9yIGRpdmVyc2l0eSBy b3V0aW5nIGNhbGN1bGF0aW9uIGF0IHRoZSBWTkMuIFRoaXMgaXMgdmVyeQ0KPiBkaWZmZXJlbnQg ZnJvbSBleHBvc2luZyB0aGUgYWN0dWFsIFRFIHRvcG9sb2d5LiBZb3UgY2FuIHZpZXcgdGhpcyBh cyB0d28gbGV2ZWwNCj4gb2YgcGF0aCBjb21wdXRhdGlvbi4gVk5DIGZpcnN0IGNvbXB1dGVzIGFu IGVuZC10by1lbmQgcGF0aCAodXNpbmcNCj4gd2hhdGV2ZXIgY29uc3RyYWludCBpbmZvcm1hdGlv biBpdCBoYXMpLCB0aGVuIGNvb3JkaW5hdGVzIHdpdGggZWFjaCBQTkMNCj4gKHRlbGxpbmcgdGhl IGJvcmRlciBub2RlcyBpbmZvcm1hdGlvbiksIHRoZW4gZWFjaCBQTkMgY29tcHV0ZXMgdGhlIGRv bWFpbg0KPiBzcGVjaWZpYyBwYXRoLiBXaGVuIGEgUE5DIGNhbm5vdCBwcm92aWRlIGEgcGF0aCBz ZWdtZW50IGluIGl0cyBkb21haW4sIHRoZW4NCj4gdGhpcyBuZWVkcyB0byBiZSBzaWduYWxlZCB0 byBWTkMgc28gdGhhdCB0aGUgVk5DIHdvdWxkIGFycmFuZ2UgYW4gYWx0ZXJuYXRlDQo+IHBhdGgg c2VnbWVudCB0byBiZSBhYmxlIHRvIGZpbmQgYSBmZWFzaWJsZSBlbmQtdG8tZW5kIHBhdGguICBJ IHdvdWxkIHNheSB0aGlzDQo+IGlzIGEg4oCcdHdvLXBoYXNl4oCdIHNpZ25hbGluZyBhbmQgcGF0 aCBjb21wdXRhdGlvbi4gVGhlIHBvaW50IGlzIHRoYXQgdGhlcmUgbXVzdA0KPiBiZSBzb21lIGxl dmVsIG9mIGhpZGluZyBvbiBhYnN0cmFjdCB0b3BvbG9neSBleHBvc3VyZSBmcm9tIFBOQyB0byBW TkMgYW5kDQo+IHByb3ByaWV0YXJ5IGNoYXJhY3RlcmlzdGljcyBvZiBvcHRpY2FsIGRldmljZXMg bmVlZCB0byBiZSBkZWFsdCBvbmx5IHdpdGggdGhlDQo+IGNvcnJlc3BvbmRpbmcgUE5DLg0KPiAN Cj4gUmVnYXJkaW5nIHRoZSB0ZXJtIFBOQyB2cy4gQU5DLCBJIHdvdWxkbuKAmXQgY29uY2VybiB0 b28gbXVjaCBhYm91dCB0aGUNCj4gdGVybWlub2xvZ3kgd2hpY2hldmVyIHdvcmtzIGJldHRlci4g VGhhbmsgeW91IGZvciB5b3VyIHN1Z2dlc3Rpb24uDQo+IA0KPiBMYXN0bHksIHBsZWFzZSBjaGVj ayB0aGUgdXNlLWNhc2VzIHdyaXR0ZW4gYnkgb3BlcmF0b3JzIGluIHRoZSBiZWxvdyBsaW5rcw0K PiB0aGF0IGNvbnNpc3RlbnRseSBzYXkgdGhleSBuZWVkIGEgc3RhbmRhcmQgaW50ZXJmYWNlIHRo YXQgY2FuIGNvb3JkaW5hdGUgdGhlaXINCj4gbXVsdGktZG9tYWluIGlzc3Vlcy4NCj4gDQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhbmctYWN0bi1tdWx0aWRvbWFp bi1kY2kvDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtsZWUtYWN0 bi1jb25uZWN0aXZpdHktbXVsdGktdmVuZG9yLQ0KPiBkb21haW5zLw0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdW1ha2ktYWN0bi1tdWx0aXRlbmFudC12bm8vDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvcGV6LWFjdG4tdm5vLW11 bHRpZG9tYWlucy8NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hp bi1hY3RuLW12bm8tbXVsdGktZG9tYWluLw0KPiANCj4gUmVnYXJkcywNCj4gWW91bmcNCj4gDQo+ IFRoYW5rcywNCj4gWW91bmcNCj4gDQo+IA0KPiBGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJ QnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAy MDE0IDE6NDggUE0NCj4gVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgTGVleW91bmc7DQo+ IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7 DQo+IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFpbC5j b208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUpDQo+ IFN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21t ZW50cw0KPiANCj4gSGkgWW91bmcsDQo+IA0KPiBJIGJlbGlldmUgaGF2aW5nIHRoZSBzYW1lIGlu c3RhbmNlIG9mIFZOQyB0YWxraW5nIHRvIGRpZmZlcmVudCB2ZW5kb3IgZG9tYWluDQo+IFBOQ3Mg aXMgYW4gZXh0cmVtZWx5ICBpZGVhbGlzdGljIHZpZXcuDQo+IA0KPiA9PT09PiBCVFcgSSBmaW5k IFBOQyBpcyBhIGJhZCB0ZXJtLCBJIGxpa2UgbXVjaCBiZXR0ZXIgQWN0dWFsIE5ldHdvcmsNCj4g Q29udHJvbGxlciAgKEFOQykuIFZOQyAoYS5rLmEuIGEgSHlwZXJ2aXNvcikgaXMgbWFuYWdpbmcg YWJzdHJhY3QgdG9wb2xvZ2llcywNCj4gYW5kIHRvIGJlIGFibGUgZG8gdGhhdCwgaXQgdGFsa3Mg dG8gYSBBTkMtIGEgY29udHJvbGxlciB3aGljaCBoYXMgYW4gYWNjZXNzIGFuZA0KPiBtYW5hZ2Vz IGFjdHVhbCBwcm92aWRlciBuZXR3b3JrKS4NCj4gDQo+IE9uZSByZWFzb24gZm9yIHRoaXMgaXMg dGhhdCBWTkMgbmVlZHMgdG8gdW5kZXJzdGFuZCB1bmRlcmx5aW5nIGFjdHVhbA0KPiB0b3BvbG9n eSwgZm9yIGV4YW1wbGUsIHRvIGVuc3VyZSB0aGF0IHR3byBhYnN0cmFjdCBURSBsaW5rcyBhcmUg U1JMRyBkaXNqb2ludA0KPiBhcyByZXF1ZXN0ZWQuIEFjdHVhbCB0b3BvbG9neSBzZW1hbnRpY3Mg KGVzcGVjaWFsbHkgaW4gV0RNIGxheWVyKSBpcyB2ZXJ5DQo+IGRpZmZlcmVudCBmcm9tIHZlbmRv ciB0byB2ZW5kb3IgYW5kIGNvbnRhaW5zIGEgZ3JlYXQgdmFyaWV0eSBvZiBwcm9wcmlldGFyeQ0K PiBleHRlbnNpb25zLCBmYWlsaW5nIHRvIHVuZGVyc3RhbmQgd2hpY2ggbGVhZHMgdG8gcHJvZHVj aW5nIHVucHJvdmlzaW9uYWJsZQ0KPiBzZXJ2aWNlIHBhdGhzLiBEbyB5b3UgcmVhbGx5IGJlbGll dmUgdGhhdCBhIHNpbmdsZSBWTkMgY2FuIHRhbGsgaW4gdGhlIHNhbWUNCj4gd2F5IHRvIEFEVkEs IElORk4sIEFMVSBhbmQgSHVhd2VpIEFOQ3M/IFRoaXMgaXMgZXF1aXZhbGVudCB0byBhc2sgYWxs DQo+IG9wdGljYWwgcHJvdmlkZXJzIHRvIHN3aXRjaCB0byBXU09OIDo9KS4NCj4gDQo+IFRoaXMg aXMgbm90IHRvIHNheSB0aGF0IHlvdSBjYW5ub3QgYnVpbGQgYSBoaWVyYXJjaHkgb2YgVk5Dcywg YnV0IGluIHRoaXMgY2FzZQ0KPiBOb3J0aCBWTkMgcGxheXMgcm9sZSBvZiBhIGNsaWVudCBuZXR3 b3JrIGNvbnRyb2xsZXIgd3J0IHRvIFNvdXRoIFZOQywgdGhhdCBpcywNCj4gdXNlcyB0aGUgc2Ft ZSBYIGludGVyZmFjZS4NCj4gSUhNTyB3aGVuZXZlciBhIFZOQyBoYXMgdG8gdGFsayB0byBhIEFO QywgaXQgZG9lcyBzbyBpbiBhIHByb3ByaWV0YXJ5IHdheSwNCj4gaS5lLiBBRFZBLCBJTkZOLCBB TFUgYW5kIEh1YXdlaSB3aWxsIGhhdmUgdGhlaXIgb3duIFZOQ3MgZXhwb3NpbmcgdGhlDQo+IHNh bWUgbm9ydGggYm91bmQgaW50ZXJmYWNlIHRvIHBvdGVudGlhbGx5IHRoZSBzYW1lIGNsaWVudCAo ZS5nLlRGSykuDQo+IElITU8gaW50ZXJmYWNlIFggaXMgdGhlIG9ubHkgaW50ZXJmYWNlIHRoYXQg dGhlIEFDVE4gY2FuIHdvcmsgb24uDQo+IA0KPiBDaGVlcnMsDQo+IElnb3INCj4gDQo+IEZyb206 IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCRUxPVFRJ LCBTRVJHSU8NCj4gKFNFUkdJTykNCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDksIDIwMTQg NTo1OSBBTQ0KPiBUbzogTGVleW91bmc7IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5v cmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7DQo+IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlk LmVzPjsNCj4gbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBD YzogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVj dDogUmU6IFtBY3RuXSBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21t ZW50cw0KPiANCj4gSGkgWW91bmcsDQo+IA0KPiB0aGFua3MgYSBsb3QgZm9yIHJlcGx5ICwgcGxl YXNlIHNlZSBpbiBsaW5lIGp1c3Qgc29tZSBmdXJ0aGVyIGNsYXJpZmljYXRpb24NCj4gDQo+IFJl Z2FyZHMNCj4gU2VyZ2lvDQo+IA0KPiANCj4gDQo+IEZyb206IExlZXlvdW5nIFttYWlsdG86bGVl eW91bmdAaHVhd2VpLmNvbV0NCj4gU2VudDogbWVyY29sZWTDrCA4IG90dG9icmUgMjAxNCAxNzoz NQ0KPiBUbzogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzph Y3RuQGlldGYub3JnPjsgRGFuaWVsZQ0KPiBDZWNjYXJlbGxpOyBkaWVnb0B0aWQuZXM8bWFpbHRv OmRpZWdvQHRpZC5lcz47DQo+IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWls LmNvbT4NCj4gQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSRTogZHJhZnQtY2Vj Y2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCj4gDQo+IEhpIFNlcmdpbywN Cj4gDQo+IFRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayBvbiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50 LiBQbGVhc2Ugc2VlIGluLWxpbmUgZm9yDQo+IG15IGNvbW1lbnQuDQo+IA0KPiBSZWdhcmRzLA0K PiBZb3VuZw0KPiANCj4gRnJvbTogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIFttYWlsdG86c2Vy Z2lvLmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9i ZXIgMDgsIDIwMTQgNzozNCBBTQ0KPiBUbzogYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRm Lm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgTGVleW91bmc7DQo+IGRpZWdvQHRpZC5lczxtYWls dG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21h aWwuY29tPg0KPiBDYzogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBWYXJtYSwgRXZlIEwgKEV2 ZSkNCj4gU3ViamVjdDogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29t bWVudHMNCj4gDQo+IEhpIERhbmllbGUgLCBZb3VuZyBhbmQgYWxsIGF1dGhvcnMsDQo+IA0KPiBJ IHJlYWQgeW91IEZyYW1ld29yayBkcmFmdCBhbmQgSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhh dC4gTW9zdCBhcmUNCj4gZWRpdG9yaWFsICwgb3RoZXIgcXVlc3Rpb25zIGZvciBjbGFyaWZpY2F0 aW9ucy4NCj4gDQo+IEdlbmVyYWwgcXVlc3Rpb246IGluIHRoZSBkcmFmdCB0aGUgY29uY2VwdCBv ZiBWTkMgaXMgaW4gdGhlIHZpZXcgb2YNCj4gaGllcmFyY2hpY2FsIGxldmVsIG9mIGNvbnRyb2xs ZXJzIG9yIGxpbmtlZCB0byB0aGUgbXVsdGktZG9tYWluIGFzcGVjdCB0aGF0DQo+IGNvbXBlbCB0 byBwcm92aWRlIHRvIHRoZSBjdXN0b21lciBhIHNpbmdsZSB2aXJ0dWFsaXplZCBuZXR3b3JrIGV2 ZW4gaWYNCj4gY29tcG9zZWQgYnkgcmVhbCBtdWx0aS1kb21haW4gbXVsdGktdGVjaG5vbG9neSBz dWJuZXR3b3Jrcz8gSSBtZWFuLCB0aGUNCj4g4oCcdmlydHVhbGl6ZXIgZnVuY3Rpb27igJ0gcHJv dmlkZWQgYnkgVk5DLCBpbiBjYXNlIG9mIGEgc2luZ2xlIGRvbWFpbiBjb250ZXh0DQo+IGNvdWxk IGJlIGluc2lkZSBkaXJlY3RseSB0aGUgUE5DICwgY29ycmVjdD8NCj4gDQo+IFlPVU5HPj4gWWVz LiBUaGF0IGlzIHRoZSBjb3JyZWN0IHZpZXcgb2YgVk5DLiBGb3IgYSBzaW5nbGUgZG9tYWluIGNv bnRleHQsDQo+IHRoZSBWTkMgY2FuIGJlIGludGVncmF0ZWQgd2l0aCBQTkMuIEJ1dCB3ZSBuZWVk IHRvIGZhY3RvciBpbiBvdGhlcg0KPiBzY2VuYXJpb3Mgc3VjaCBhcyAxKSBWTkMgdmVuZG9yIG1h eSBiZSBkaWZmZXJlbnQgZnJvbSBQTkMgdmVuZG9yIG9yIDIpDQo+IFZOQyBpcyBhIHNvZnR3YXJl IGZ1bmN0aW9uIHRoYXQgb3BlcmF0b3IgbWF5IHdhbnQgdG8gb3BlcmF0ZSBhcyBpdHMgY29udHJv bC4NCj4gSW4gbXkgb3BpbmlvbiwgZXZlbiBmb3IgYSBzaW5nbGUgZG9tYWluLCBJIHRoaW5rIHRo ZXJlIGlzIGJlbmVmaXQgdG8gZGVmaW5lIHRoaXMNCj4gaW50ZXJmYWNlIGFzIGEgc3RhbmRhcmQg aW50ZXJmYWNlLg0KPiANCj4gU2VjdGlvbiAyICwgcGFnZSA0Og0KPiBhYnN0cmFjdGlvbiBkb2Vz IG5vdCBpbXBseSBhdXRvbWF0aWNhbGx5IHZpcnR1YWxpemF0aW9uLHdoaWxlIHZpcnR1YWxpemF0 aW9uDQo+IGltcGxpZXMgdG8gaGF2ZSBzdXJlbHkgYSBjZXJ0YWluIGZvcm0gb2YgYWJzdHJhY3Rp b24uIEkgd291bGQgc3VnZ2VzdCB0bw0KPiBjb25zaWRlciBnb29kIGRlZmluaXRpb24gY29udGFp bmVkIGludG8gT05GIFNETiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQNCj4gY2hhcHRlciAyLjMgQ29u dmVudGlvbnMgYWJvdXQgYWJzdHJhY3Rpb24gYW5kIHZpcnR1YWxpemF0aW9uLiBBIGdvb2QNCj4g ZGVmaW5pdGlvbiBjYW4gaGVscCBhbGwgdGhlIHJlYWRpbmcuDQo+IA0KPiBZT1VORz4+IEFncmVl LiBXZSB3aWxsIGxvb2sgaW50byB0aGUgbWVudGlvbmVkIGRvY3VtZW50IGlmIHRoZSB1c2FnZSBv Zg0KPiB0ZXJtcyBhcmUgYWxpZ25lZCB3aXRoIHRoaXMgZG9jdW1lbnQuIElmIG5vdCwgd2Ugd2ls bCBjbGFyaWZ5IHRoZSB0ZXJtaW5vbG9neQ0KPiBtb3JlIGNsZWFybHkuDQo+IA0KPiBTZWN0aW9u IDU6IEl0IHNlZW1zIHRvIG1lIHlvdSBtaXhlZCBoZXJlIGFzcGVjdHMgdGhhdCBhcmUgbW9yZSBy ZWxhdGVkIHRvDQo+IHBvbGljeSBsaWtlIGFkbWlzc2lvbiBjb250cm9sICBhbmQgZ3VhcmFudGVl IG9mIGNsaWVudCBpc29sYXRpb24gd2l0aCByZWFsDQo+IGNvbXB1dGF0aW9uYWwgaXNzdWUgbGlr ZSBDb21wdXRpbmcgdGltZSAsIHBhdGggY29uc3RyYWlucyBvciByZS1vcHRpbWl6YXRpb24NCj4g cHJvY2Vzcy4gTW9yZW92ZXIgdGhlIHRlcm0gVk5NIGZvciBWaXJ0dWFsIG5ldHdvcmsgbWFwcGlu ZyBpcyBhIGJpdA0KPiBtaXNsZWFkaW5nIHNpbmNlIHRoaXMgdGVybSBpbiBhbHJlYWR5IHVzZWQg ZS5nLiBpbiBBQk5PIGFyY2hpdGVjdHVyZSBmb3INCj4gVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIu DQo+IA0KPiBZT1VORz4+IEluZGVlZC4gSW4gU2VjdGlvbiA1LCB3ZSB3aWxsIHB1dCBzb21lIG5v dGVzIG9uIHRoZSBhc3BlY3Qgb2YgcmVhbC0NCj4gdGltZSByZWxhdGVkIGZyb20gbm9uIHJlYWwg dGltZSBhc3BlY3QuIFZOTSBpcyBub3QgdG8gYmUgbWl4ZWQgd2l0aCBWaXJ0dWFsDQo+IE5ldHdv cmsgTWFuYWdlci4gSGVyZSBWTk0gaXMgYW4gYWxnb3JpdGhtIHdoaWNoIGlzIGtub3duIGFzIFZp cnR1YWwNCj4gTmV0d29yayBNYXBwaW5nIHdoaWNoIGlzIGEgc29mdHdhcmUgbW9kdWxlIHRoYXQg Y29udmVydHMgY2xpZW50IHJlcXVlc3RzDQo+IGludG8gYWN0dWFsIG5ldHdvcmtzLiBWaXJ0dWFs IE5ldHdvcmsgTWFuYWdlciBpcyBBQk5PIGluIG15IHVuZGVyc3RhbmRpbmcNCj4gaXMgYSBkZXZl bG9wZWQgY29uY2VwdCBmcm9tIFZOVE0uIEJ1dCBEYW4gS2luZyBhbmQgSSB3aWxsIGxvb2sgYXQg dGhpcyBtb3JlDQo+IGNhcmVmdWxseSBvbiB0aGlzIGFzcGVjdCB3aGF0IFZpcnR1YWwgTmV0d29y ayBNYW5hZ2VyIGlzIGRvaW5nLg0KPiANCj4gU0I+Pj4gSWYgSSB1bmRlcnN0b29kIGZvcm0gQWRy aWFuIGFuZCBEYW5pZWwgQUJOTyBkcmFmdCB0aGUgY29uY2VwdCwNCj4gU0I+Pj4gVk5UTSBpcyBz dHJpY3RseSByZWxhdGVkIHRvIHBsYW5uaW5nIGZ1bmN0aW9uIHNvIEkgdGhpcyBpdCBpcyB2ZXJ5 DQo+IFNCPj4+IGltcG9ydCBwb2ludCBpbiB0aGUgY29udGV4dCBvZiBQTkMgLCBJIHdvdWxkIHNh eQ0KPiANCj4gU2VjdGlvbiA2LjEgOiB3aGlsZSBpdCBpcyBjbGVhciB0aGUgc2NvcGUgb2YgdGhl IGRpZmZlcmVudCBjb250cm9sIGludGVyZmFjZQ0KPiBwcmVzZW50ZWQgaW4gZmlndXJlIDUsIEni gJltIGEgYml0IGNvbmZ1c2VkIGFzIHRvIHdoYXQgSS9GIEUgaXMg4oCTIGRhdGEgcGxhbmUNCj4g aW50ZXJmYWNlIHRvIHByb3ZpZGVyIHBoeXNpY2FsIG5ldHdvcms/IE9yIGlzIHRoZSBpbnRlbnRp b24gdG8gcHJvdmlkZSB3aGF0DQo+IGNhbiBiZSB0aGUgdW5kZXJseWluZyBtb2RlbCBvZiByZXNv dXJjZXMgYWxsb2NhdGVkIHRvIGEgY3VzdG9tZXIgZnJvbQ0KPiBuZXR3b3JrIHByb3ZpZGVyIGNv bnRyb2xsZXIsIGFuZCB0aGUgbWFwcGluZyB0byByZWFsIHBoeXNpY2FsIHJlc291cmNlcyA/DQo+ IE5vciBjbGVhciB0byBtZSB0aGUgaW50ZW50aW9uDQo+IA0KPiBZT1VORz4+IEludGVyZmFjZSBF IGlzIG5vdCB3aGF0IEFDVE4gd2lsbCBmb2N1cyBvbi4gSXQgc2ltcGx5IHNob3dzICBhbg0KPiB1 bmRlcmx5aW5nIG1vZGVsIG9mIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gYSBjdXN0b21lciBmcm9t IG5ldHdvcmsNCj4gcHJvdmlkZXIgY29udHJvbGxlciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwg cGh5c2ljYWwgcmVzb3VyY2VzLg0KPiANCj4gU0I+Pj4gU28gaWYgSSBpbnRlcnByZXRlZCBjb3Jy ZWN0bHkgeW91ciBhbnN3ZXIgaXMgbW9yZSBhbiBpbnRlcm5hbCBpbnRlcmZhY2UNCj4gdG8gUE5D ICwgdGhlIGZpZ3VyZSBpcyBtaXNsZWFkaW5nIHNpbmNlIGl0IHNlZW1zIGxpa2UgYSBEUCBpbnRl cmZhY2UgLg0KPiANCj4gDQo+IFNlY3Rpb24gNi4xLCBhbHdheXMgZmlndXJlIDU6IElmIGEgcmVw b3J0IG9mIHBvdGVudGlhbCBOVyB0b3BvbG9neSBiZXR3ZWVuIGENCj4gVk5DIGFuZCBhIENOQyBj YW4gYmUgcXVlcmllZCAsIHRoZSBhcnJvdyBpbiB0aGUgZHJhd24gaGFzIHRvIGJlDQo+IGJpZGly ZWN0aW9uYWwgSSBndWVzcw0KPiANCj4gWU9VTkc+PiBZZXMsIFlvdSBhcmUgcmlnaHQuIEl0IHdp bGwgYmUgZml4ZWQuDQo+IA0KPiBGaWd1cmUgOCBTZWN0aW9uIDYuNCxwYWdlIDI4OiDigJxQQ0Eg YWJzdHJhY3RzIHRoZSBwaHlzaWNhbCBuZXR3b3JrIHRvcG9sb2d5DQo+IGludG8gYW4gYWJzdHJh Y3RlZCB0b3BvbG9neeKAnSBMb29raW5nIGF0IHRoZSBkZXNjcmlwdGlvbiBvZiBWTkMgY29tcG9u ZW50cw0KPiBpbiA2LjIuMiBpdCBpcyB0aGUgcmVzb3VyY2UgbWFuYWdlciBkZXZvdGluZyB0byBw cm92aWRlIGFic3RyYWN0IHRvcG9sb2d5Lg0KPiBEb2VzIG5vdCBleGlzdCBhbnkgUENBIGNvbXBv bmVudC4NCj4gDQo+IA0KPiANCj4gWU9VTkc+PiBTb3JyeSBmb3IgaW5jb25zaXN0ZW5jeS4gVGhl IGludGVudGlvbiB3YXMgdGhlIFBDQSBpcyB0aGUgc2FtZSBhcw0KPiB0aGUgUmVzb3VyY2UgTWFu YWdlciBpbiBWTkMuIFdpbGwgbWFrZSB0aGUgdGVybSBjb25zaXN0ZW50LiBHb29kIGNhdGNoIQ0K PiANCj4gDQo+IA0KPiBGaWd1cmUgOCBTRWN0aW9uIDYuNCwgOiBJbiB0aGUgcGljdHVyZSB0aGVy ZSBpcyBubyBwaGFzZSA3LCBhbmQgdGhlcmUgYXJlIDIgcGhhc2UNCj4gOA0KPiANCj4gWU9VTkc+ PiBUaGFua3MuIEdvb2QgY2F0Y2ghDQo+IA0KPiBQYWdlIDMwIDogSXQgaXMgSW50ZXJmYWNlIEMg bm90IEIgLCBiZXR3ZWVuIFZOQyBhbmQgUE5DDQo+IA0KPiBZT1VORz4+IElmIHlvdSBhcmUgcmVm ZXJyaW5nIHRvIFNlY3Rpb24gNy4zIHdoZXJlOg0KPiANCj4gICAgSW50ZXJmYWNlcyBzaG91bGQg YWxzbyBiZSBzY2FsYWJsZSBhcyBhIGxhcmdlIGFtb3VudCBvZiBkYXRhIG5lZWRzDQo+IA0KPiAg ICB0byBiZSB0cmFuc3BvcnRlZCBhY3Jvc3MgY3VzdG9tZXJzIHRvIHZpcnR1YWwgbmV0d29yayBj b250cm9sbGVycw0KPiANCj4gICAgYW5kIGFjcm9zcyB2aXJ0dWFsIG5ldHdvcmsgY29udHJvbGxl cnMgYW5kIHBoeXNpY2FsIG5ldHdvcmsNCj4gDQo+ICAgIGNvbnRyb2xsZXJzLg0KPiANCj4gDQo+ IA0KPiBJIHRoaW5rIHRoaXMgaW1wbGllcyBib3RoIGludGVyZmFjZXMgQiBhbmQgQyBhbHRob3Vn aCBwcmltYXJpbHkgYmV0d2VlbiBWTkMtDQo+IFBOQy4NCj4gDQo+IA0KPiANCj4gU0I+Pj4gU29y cnkgWW91bmcsIGlpdCBpcyBub3QgcmVmZXJyZWQgdG8gNy4zICwgYnV0IGluIHRoZSBjaGFwdGVy IDYsNSAsDQo+IFNCPj4+IG9uIEludGVyZmFjZSBpbnRlcmFjdGlvbiwgYWZ0ZXIgcG9pbnQgNiwg aXMgaW5kaWNhdGVkIEludGVyZmFjZSBCDQo+IFNCPj4+IGFzIGludGVyZmFjZSBiZXR3ZWVuIFZO QyBhbmQgUE5DLCBmaWd1cmUgNSBzYXlzIGl0IGlzIEkvRiBDDQo+IA0KPiANCj4gVGhhbmtzDQo+ IA0KPiBTZXJnaW8NCj4gDQo+IA0KPiBUaGFua3MNCj4gU2VyZ2lvDQo= From nobody Tue Oct 14 06:35:44 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 7C3881A885D for ; Tue, 14 Oct 2014 06:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 xIbbB9qHhF21 for ; Tue, 14 Oct 2014 06:35:30 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9432E1A8704 for ; Tue, 14 Oct 2014 06:35:29 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9EDZEmi002812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 09:35:14 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 14 Oct 2014 09:35:13 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Tue, 14 Oct 2014 09:35:13 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Tue, 14 Oct 2014 09:35:13 -0400 From: Igor Bryskin To: Daniele Ceccarelli , "BELOTTI, SERGIO (SERGIO)" , Leeyoung , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAUUWIAAAD4nwAABk9WQA== Date: Tue, 14 Oct 2014 13:35:12 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481279E6E8@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481279E6E8@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-14_06:2014-10-14,2014-10-14,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/38BlxgbqkmkGR-Utl6TYPrE4RLA Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 13:35:41 -0000 RGFuaWVsZSBhbmQgU2VyZ2lvLA0KDQpJIHJlc3BlY3RmdWxseSBkaXNhZ3JlZSB3aXRoIHlvdXIg YXJndW1lbnRzIGFuZCBiZWxpZXZlIHRoYXQgaW50ZXJmYWNlcyBCIGFuZCBDIGFyZSB0aGUgc2Ft ZS4gUGxlYXNlLCBjb25zaWRlciB0aGlzOg0KDQoxLiBJbiB0aGUgUENFIGFyY2hpdGVjdHVyZSBh IFBDQyByZXF1ZXN0cyBwYXRoIGNvbXB1dGF0aW9uIGZyb20gYSBQQ0UgdmlhIGRlZmluZWQgZm9y IHRoaXMgcHVycG9zZXMgaW50ZXJmYWNlIC0gUENFUC4gSWYgdGhlIFBDRSBjYW5ub3Qgc2F0aXNm eSB0aGUgcmVxdWVzdCBvbiBpdHMgb3duLCBpdCBtYXkgdXNlIHNvbWUgaGVscCBmcm9tIGFub3Ro ZXIgUENFLiBUbyBkbyBzbyBpdCBiZWNvbWVzIGEgUENDIG9mIHRoZSBzZWNvbmQgUENFIGFuZCBy ZXF1ZXN0cyB0aGUgcGF0aCBjb21wdXRhdGlvbiB2aWEgdGhlICpzYW1lKiBQQ0VQLiBUaGVyZSBh cmUgbnVtZXJvdXMgcmVhc29ucyBhcyB0byB3aHkgaXQgd291bGRuJ3QgYmUgYSBnb29kIHRoaW5n IGlmIFBDRXMgaGFkIHRvIHVzZSBhIGRpZmZlcmVudCBpbnRlcmZhY2UgdG8gdGFsayB0byBlYWNo IG90aGVyLCBhbmQgb25lIG9mIHN1Y2ggcmVhc29ucyBpcyB0aGF0IGl0IGlzIG11Y2ggZWFzaWVy IHRvIG9yY2hlc3RyYXRlIHRoZSByZXF1aXJlZCBoaWVyYXJjaHkgIHdpdGggYSBzaW5nbGUgaW50 ZXJmYWNlLCByYXRoZXIgdGhhbiB3aXRoIHR3byBvciBtb3JlLg0KDQoyLiBJIGhvcGUgd2UgYWxs IGFncmVlIHRoYXQgdGhlIEFDVE4gYXJjaGl0ZWN0dXJlIG11c3QgYmUgaGllcmFyY2hpY2FsIGlu IG5hdHVyZS4gRm9yIGV4YW1wbGUsIG9uIHRoZSBZb3VuZydzIHBpY3R1cmUgYmVsb3cgTmV0d29y ayBkb21haW4gMSBjb3VsZCBiZSBhIG11bHRpLWRvbWFpbiB0cmFuc3BvcnQgbmV0d29yayBpbiBp dHMgb3duIHJpZ2h0IGFuZCBjb25zdW1lIHRoZSBhYnN0cmFjdCB0b3BvbG9naWVzIHByZXNlbnRl ZCBieSBlYWNoIG9mIGl0cyBjaGlsZCBkb21haW5zLCBlYWNoIG9mIHdoaWNoIGNvdWxkIGJlIGFs c28gbXVsdGktZG9tYWluIG5ldHdvcmtzLiBJbiB0aGlzIGNhc2UgdGhlIE5ldHdvcmsgZG9tYWlu IDEgVk5DIHdpbGwgYmUgbm8gZGlmZmVyZW50IGZyb20gdGhlIE11bHRpLWRvbWFpbiBWTkMgKFRl bGVmb25pa2EpICBvbiB0aGUgcGljdHVyZS4gSW4gcGFydGljdWxhciwgdGhlIE5ldHdvcmsgZG9t YWluIDEgVk5DIHdvdWxkIGhhdmUgdG8gZG8gdGhlIHNhbWUgaW50ZXItZG9tYWluIG9yY2hlc3Ry YXRpb24gU2VyZ2lvIGlzIHRhbGtpbmcgYWJvdXQuDQoNCjMuIEkgaG9wZSB3ZSBhbHNvIGFncmVl IHRoYXQgaW50ZXJmYWNlIEMgd2lsbCBpbmNsdWRlIG5vdCBqdXN0IGFic3RyYWN0IHRvcG9sb2d5 IGRpc2NvdmVyeS9tYW5pcHVsYXRpb24gaW50ZXJmYWNlLCBidXQgYWxzbyBzZXJ2aWNlIHByb3Zp c2lvbmluZyBpbnRlcmZhY2UgdG8gcHJvdmlzaW9uIGUyZSBzZXJ2aWNlIHNlZ21lbnRzIGluIGVh Y2ggb2YgdGhlIGNoaWxkIGRvbWFpbnMgdGhlIHNlcnZpY2UgaXMgZ29pbmcgdGhyb3VnaC4gQ29u c2lkZXIgQ3VzdG9tZXIgMSBvbiB0aGUgcGljdHVyZSAoYSBiYW5rIC0gY2xpZW50IG9mIFRlbGVm b25pa2EpIHRoYXQgb25seSBuZWVkcyB0byBpbnRlcmNvbm5lY3QgaXRzIHNpdGVzLiBUaGVyZSBp cyBucCBuZWVkIGZvciBzdWNoIGNsaWVudCB0byB1c2UgYW4gYWJzdHJhY3QgdG9wb2xvZ3kgcHJl c2VudGVkIHRvIGl0IGJ5IHRoZSBUZWxlZm9uaWthIGNvbnRyb2xsZXIgLSB0aGUgQ3VzdG9tZXIg d2lsbCBzaW1wbHkgdXNlIHRoZSBzZXJ2aWNlIHByb3Zpc2lvbmluZyBwYXJ0IG9mIGludGVyZmFj ZSBDLiBIb3dldmVyLCBpdCBpcyBlYXN5IHRvIGVudmlzaW9uIGEgdXNlIGNhc2Ugd2hlcmUgdGhl IEN1c3RvbWVyIChlc3BlY2lhbGx5IHN1Y2ggYXMgaW52ZXN0bWVudCBiYW5rIG9yIGJyb2tlcikg d291bGQgd2FudCB0byB1c2UgYW4gYWJzdHJhY3QgdG9wb2xvZ3kgcHJvdmlkZWQgYnkgdGhlIFRl bGVmb25pa2EgY29udHJvbGxlciAoZS5nLiB0d28gU1JMRyBkaXNqb2ludCBhYnN0cmFjdCBsaW5r cykgdG8gcGxhY2UgaXRzIHNlcnZpY2VzIHdpdGggdGhlICJubyBmYXRlIHNoYXJlIiBndWFyYW50 ZWUuIFRoaXMgaXMgZXZlbiBtb3JlIHRydWUgSU1PIGlmIHRoZSBDdXN0b21lciBpcyBEYW5pZWxl J3MgQ2xvdWQgTmV0d29yayBDb250cm9sbGVyIChDTkMpLiBJbiB0aGlzIGNhc2UgICB0aGUgQ05D IHdpbGwgb3BlcmF0ZSBvbiBtb3JlIGNvbXBsZXggYWJzdHJhY3QgdG9wb2xvZ2llcyBwcm92aWRl ZCBieSBUZWxlZm9uaWthIGFuZCBwb3NzaWJseSBvdGhlciBwcm92aWRlcnMsIHRodXMsIGJlY29t aW5nIGZ1bmN0aW9uYWxseSBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHRoZSBUZWxlZm9uaWthJ3Mg b3duIFZOQy4NCg0KNC4gQ29uc2lkZXJpbmcgbWVudGlvbmVkIGFib3ZlIGFyZ3VtZW50cyBpbiAx Li0zLiB0aGUgb25seSB0aGluZyB0aGF0IHdvdWxkIGp1c3RpZnkgaW50ZXJmYWNlIEIgZGlzdGlu Y3QgZnJvbSBpbnRlcmZhY2UgQyBpcyB0aGUgZm9ybWVyIHByb3ZpZGluZyBzZW1hbnRpY3MgdGhh dCBjb3VsZCBub3QgYmUgZm91bmQgaW4gdGhlIGxhdHRlciwgYW5kIEkgcmVhbGx5IHN0cnVnZ2xl IHRvIGZpbmQgc3VjaCBzZW1hbnRpY3MuDQoNCkNoZWVycywNCklnb3INCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dIA0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxNCwgMjAx NCA2OjI3IEFNDQpUbzogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBJZ29yIEJyeXNraW47IExl ZXlvdW5nOyBLaW5nLCBEYW5pZWw7IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRpZC5lczsgbHV5dWFu ZkBnbWFpbC5jb20NCkNjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1j ZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBJZ29yLA0KDQpJ IGRvbid0IHRoaW5rIHRoYXQgQiBhbmQgQyBhcmUgZ29pbmcgdG8gYmUgdGhlIHNhbWUgaW50ZXJm YWNlIGVpdGhlci4gDQpKdXN0IGxvdWQgdGhpbmtpbmcsIHNvbWUgZXhhbXBsZSB0aGF0IGNvbWUg dG8gbXkgbWluZCBhcmUgYXMgZm9sbG93czoNCg0KMS4gTXVsdGkgZG9tYWluOiBTdXBwb3NlIFRl bGVmb25pY2EgaGFzIGl0cyBvd24gVk5DICh0aGUgcHJldmlvdXMgbWlzdW5kZXJzdGFuZGluZyB3 YXMgZHVlIHRvIHRoZSBmYWN0IHRoYXQgeW91IGNhbGwgVGVsZWZvbmljYSBhcyB0aGUgY2xpZW50 LCB3aGlsZSBmb3IgdGhlIHRlcm1pbm9sb2d5IHVzZWQgaW4gdGhlIGRyYWZ0IFRlbGVmb25pY2Eg aXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIgYW5kIHRoZSBjbGllbnQgaXMgZS5nLiB0aGUgYmFuayBh c2tpbmcgVGVsZWZvbmljYSBmb3IgYSBWUE4gYmV0d2VlbiAzIHBvaW50cykgd2hpY2ggcnVucyBv biB0b3Agb2YgMiBkb21haW5zIHdpdGggUE5DcyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLiBUaGUg Vk5DIGlzIGF3YXJlIG9mIHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlIDMgZG9tYWlucyBiZWxvdyAo aGVuY2UgQyBtdXN0IGJlIGRvbWFpbiBhd2FyZSkgd2hpbGUgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dGhlIGJhbmsgdG8ga25vdyB0aGF0IGRpZmZlcmVudCBkb21haW5zIGFyZSB1c2VkIHRvIGNvbm5l Y3QgaGlzIDMgcG9pbnRzDQoNCjIuIENsb3VkICsgVHJhbnNwb3J0OiBBbiBpbnRlcmVzdGluZyB1 c2UgY2FzZSBpbiBteSBvcGluaW9uIGlzIHRoZSBwcm92aXNpb25pbmcgb2YgY29ubmVjdGl2aXR5 IGJldHdlZW4gZGF0YSBjZW50ZXIgWCBhbmQgWS4gVGhlcmUgd291bGQgYmUgYSBDTkMgKGxldCdz IGNhbGwgaXQgZS5nLiBjbG91ZCBuZXR3b3JrIGNvbnRyb2xsZXIgYXMgaXQgd291bGQgcHJvYmFi bHkgYmUgc29tZXRoaW5nIGRpZmZlcmVudCBmcm9tIGEgUE5DKSBmb3IgZGF0YSBjZW50ZXIgWCwg b25lIGZvciBkYXRhIGNlbnRlciBZIGFuZCBvbmUgb3IgbW9yZSBQTkMgaW4gdGhlIG1pZGRsZS4g VGhlIFZOQyB3b3VsZCBiZSBhbiBlbmFibGUgZm9yIHByb3ZpZGluZyBjb25uZWN0aXZpdHkgYmV0 d2VlbiBkYXRhIGNlbnRlcnMgb3ZlciBhIHRyYW5zcG9ydCBuZXR3b3JrLiBBbHNvIGluIHRoaXMg Y2FzZSBJIHRoaW5rIHRoYXQgaW50ZXJmYWNlcyBCIGFuZCBDIHdvdWxkIGJlIGRpZmZlcmVudC4N Cg0KMy4gT3B0aWNhbCBtdWx0aSBkb21haW46IGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRoYXQgVGVs ZWZvbmljYSB3YW50cyB0byBoYXZlIGEgc2V0IG9mIGltcGFpcm1lbnRzIGZvciBjb21wdXRpbmcg ZW5kIHRvIGVuZCBvcHRpY2FsIHBhdGhzIChpLmUuIG9wdGljYWwgaW1wYWlybWVudCBub3QgbGlt aXRlZCB0byB0aGUgUE5DIGRvbWFpbikuIEluIHRoYXQgY2FzZSB5b3Ugd291bGQgaGF2ZSB0aGVt IHRocm91Z2ggaW50ZXJmYWNlIEMgYnV0IG5vdCBCLg0KDQpNYXliZSB3ZSBtaWdodCBjb21lIHRv IHRoZSBjb25jbHVzaW9uIHRoYXQgb25lIGludGVyZmFjZSBpcyBhIHN1YnNldCBvZiB0aGUgb3Ro ZXIgb3IgbWF5YmUgdGhlcmUgYXJlIHJlcXVpcmVtZW50cyB0aGF0IGxlYWQgdG8gZGVmaW5pbmcg dGhlbSBhcyBzZXBhcmF0ZSBpbnRlcmZhY2VzIHdpdGgganVzdCBhIGxpdHRsZSBiaXQgb2Ygb3Zl cmxhcCwgYnV0IEkgdGhpbmsgaXQgaXMgd29ydGgga2VlcGluZyB0aGVtIHNlcGFyYXRlLg0KSSB3 b3VsZCBsaWtlIHRvIGtub3cgYSBiaXQgbW9yZSBhYm91dCByZXF1aXJlbWVudHMgb24gaW50ZXJm YWNlIEIgYXMgaXQgY291bGQgYmUgYW4gaW50ZXJmYWNlIHRvd2FyZHMgdGhlIGNsaWVudCBjb250 cm9sbGVyICh3aGVyZSBjbGllbnQgPT0gdGhlIGJhbmspIG9yIGRpcmVjdGx5IGFuIGFwcGxpY2F0 aW9uICh3aGljaCBJIGd1ZXNzIGhhcyBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIHRoYW4gdGhlIG9u ZXMgdG8gYmUgcHV0IG9uIGludGYgQykuDQoNCkJSDQpEYW5pZWxlDQoNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKSANCj4g W21haWx0bzpzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb21dDQo+IFNlbnQ6IG1hcnRl ZMOsIDE0IG90dG9icmUgMjAxNCAxMTozOA0KPiBUbzogSWdvciBCcnlza2luOyBMZWV5b3VuZzsg RGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IA0KPiBhY3RuQGlldGYub3JnOyBkaWVn b0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29tDQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4g U3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1l bnRzDQo+IA0KPiBIaSBJZ29yLA0KPiANCj4gIiBJQuOAi05vLiBJIGFtIHNheWluZyB0aGF0IGlu dGVyZmFjZSBCIGFuZCBDIGFyZSBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMuDQo+IEZvciBl eGFtcGxlLCBvbiB0aGUgcGljdHVyZSBOZXR3b3JrIGRvbWFpbiAxIGluIG9yZGVyIHRvIHByb3Zp ZGUgdGhlIA0KPiBhYnN0cmFjdCB0b3BvbG9neSB0byB0aGUgbXVsdGktdmVuZG9yIFZOQywgbWF5 IHVzZSBmdWxseSBvciBwYXJ0aWFsbHkgDQo+IGFic3RyYWN0IHRvcG9sb2dpZXMgcHJvdmlkZWQg Ynkgb25lIG9yIG1vcmUgbG93ZXIgdGllciB0cmFuc3BvcnQgZG9tYWlucy4NCj4gTGlrZXdpc2Us IEN1c3RvbWVyIDEgb24gdGhlIHBpY3R1cmUgbWF5IHVzZSBhbiBhYnN0cmFjdCB0b3BvbG9neSAN Cj4gcHJvdmlkZWQgYnkgTXVsdGktZG9tYWluIG5ldHdvcmsgKHRoZSBWTkMgb24gdGhlIHBpY3R1 cmUgaXMgcGFydCBvZikuDQo+IEluIG90aGVyIHdvcmRzLCB0aGUgc2FtZSBpbnRlcmZhY2UgQyBh bmQgdGhlIHNhbWUgc2V0IG9mIG1vZGVscywgY291bGQgDQo+IGJlIHVzZWQgIGhpZXJhcmNoaWNh bGx5Lg0KPiANCj4gSWdvciINCj4gDQo+IEkgdGVuZCB0byBkaXNhZ3JlZSBoZXJlLiBXaGF0IHRo YXQgY2FuIGJlIGRpc2N1c3NlZCBpbiBteSB2aWV3IGl0IGlzIA0KPiB0aGUgbmVlZCBvciBub3Qg b2YgaW50ZXJmYWNlIEMuIFdoYXQgVk5DIGlzIGdvaW5nIHRvIHByb3ZpZGUgaXMgYSANCj4gZG91 YmxlIGZ1bmN0aW9uIG9mIHZpcnR1YWxpemVyIG9mIHRoZSBuZXR3b3JrIHRvd2FyZHMgY2xpZW50 IA0KPiBhcHBsaWNhdGlvbiBsZXZlbCBhbmQgb3JjaGVzdHJhdGlvbiwgZHVlIHRvIHRoZSBuZWVk IHRvIHNwYW4gbXVsdGlwbGUgDQo+ICh2aXJ0dWFsKU5FcyBvciBtdWx0aXBsZSBuZXR3b3JrIGRv bWFpbiAuIElmIHdlIGltbW1hZ2luZSB0byBlbmNvbXBhc3MgDQo+IHRoZXNlIGZ1bmN0aW9uYWxs eSBpbnRvIG9ubHkgb25lIFNETiBjb250cm9sbGVyICwgbWFuYWdpbmcgYWxsIHZpcnR1YWwgDQo+ IG5ldHdvcmsgeW91IHdvdWxkIG5vdCB1c2UgYW5vdGhlciBpbnRlcmZhY2UgYmV0d2VlbiBWTkMg YW5kIFBOQy4NCj4gQnV0IGhlcmUgWW91bmcgcHV0IGNvcnJlY3RseSBzb21lIHByb2JsZW1zIGFu ZCBpdCBpcyB0aGUgY29ycmVjdCB0aW1lIA0KPiBJIHRoaW5rIHRvIGNvbnNpZGVyIGFsbCB0aGUg YXNwZWN0cy4NCj4gQnV0IHRvd2FyZHMgY2xpZW50IGFwcGxpY2F0aW9uIHRoZXJlIGlzIGFub3Ro ZXIgbGV2ZWwgb2YgYWJzdHJhY3Rpb24sIA0KPiBhIHJlYWwgdmlydHVhbGl6YXRpb24gKHRvIGNs aWVudCkgb2YgcmVzb3VyY2VzIHdpdGggZGlmZmVyZW50IA0KPiBncmFudWxhcml0eSBhbmQgY2hh cmFjdGVyaXN0aWNzIG9mIHRoZSBzZXQgb2YgaW5mb3JtYXRpb24gbmVlZGVkIHRvIA0KPiB0aGUg bG93ZXIgbGV2ZWwgb2YgY29udHJvbGxlciwgYXMgd2VsbCBleHBsYWluZWQgYnkgWW91bmcuDQo+ IEl0IGNhbiBkZWJhdGUgaWYgYW5vdGhlciBzZXBhcmF0ZSBlbnRpdHkgYXMgVk5DIGNhbiBiZSAs IGluIHRoaXMgDQo+IGFyY2hpdGVjdHVyZSwgdGhlIGdvb2QgY2hvaWNlLCBidXQgSSBkbyBub3Qg aGF2ZSBwcmVjbHVzaW9uIG9uIHRoYXQuDQo+IEkgaW5zdGVhZCBzaGFyZSB5b3VyIHNlbnRlbmNl IGFib3V0IGhpZXJhcmNoaWNhbCBsZXZlbCBvZiBjb250cm9sbGVyLg0KPiANCj4gVGhhbmtzDQo+ IA0KPiBSZWdhcmRzDQo+IFNlcmdpbw0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBJZ29yIEJyeXNraW4NCj4gU2VudDogbWFydGVkw6wgMTQgb3R0b2JyZSAyMDE0IDAyOjAx DQo+IFRvOiBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBEYW5pZWxlIENlY2Nh cmVsbGk7IEtpbmcsIA0KPiBEYW5pZWw7IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRpZC5lczsgbHV5 dWFuZkBnbWFpbC5jb20NCj4gQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSZTog W0FjdG5dIGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+ IA0KPiANCj4gWW91bmcsDQo+IA0KPiANCj4gPT0944CLQWZ0ZXIgYWxsIHdlIGFyZSBhZ3JlZWlu ZyB3aXRoIHRoZSBpbnRlcmZhY2VzIG9mIEFDVE4gaW50ZXJlc3QgYXJlIA0KPiBJbnRlcmZhY2Ug QiBhbmQgQywgcmlnaHQ/DQo+IA0KPiBJQuOAi05vLiBJIGFtIHNheWluZyB0aGF0IGludGVyZmFj ZSBCIGFuZCBDIGFyZSBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMuDQo+IEZvciBleGFtcGxl LCBvbiB0aGUgcGljdHVyZSBOZXR3b3JrIGRvbWFpbiAxIGluIG9yZGVyIHRvIHByb3ZpZGUgdGhl IA0KPiBhYnN0cmFjdCB0b3BvbG9neSB0byB0aGUgbXVsdGktdmVuZG9yIFZOQywgbWF5IHVzZSBm dWxseSBvciBwYXJ0aWFsbHkgDQo+IGFic3RyYWN0IHRvcG9sb2dpZXMgcHJvdmlkZWQgYnkgb25l IG9yIG1vcmUgbG93ZXIgdGllciB0cmFuc3BvcnQgZG9tYWlucy4NCj4gTGlrZXdpc2UsIEN1c3Rv bWVyIDEgb24gdGhlIHBpY3R1cmUgbWF5IHVzZSBhbiBhYnN0cmFjdCB0b3BvbG9neSANCj4gcHJv dmlkZWQgYnkgTXVsdGktZG9tYWluIG5ldHdvcmsgKHRoZSBWTkMgb24gdGhlIHBpY3R1cmUgaXMg cGFydCBvZikuDQo+IEluIG90aGVyIHdvcmRzLCB0aGUgc2FtZSBpbnRlcmZhY2UgQyBhbmQgdGhl IHNhbWUgc2V0IG9mIG1vZGVscywgY291bGQgDQo+IGJlIHVzZWQgIGhpZXJhcmNoaWNhbGx5Lg0K PiANCj4gSWdvcg0KPiANCj4gSUI+PiBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIGludGVyZmFjZSBi ZXR3ZWVuIHRyYW5zcG9ydCBkb21haW4gc2VydmVyIA0KPiBJQj4+IGFuZA0KPiB0cmFuc3BvcnQg ZG9tYWluIGNsaWVudC4gSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSB2ZXJ5IHNhbWUgaW50ZXJmYWNl IA0KPiBjYW4gYmUgdXNlZCBiZXR3ZWVuIGEgbXVsdGktZG9tYWluIHByb3ZpZGVyIChlLmcuIFRl bGVmb25pa2EpIGFuZCBpdHMgDQo+IGNsaWVudHMuIE5vdCBhbGwgc3VjaCBjbGllbnRzIGFyZSBk dW1iLCBhcyBEYW5pZWxlIGNsYWltcywgYW5kIG9ubHkgDQo+IGNhcmUgYWJvdXQg4oCcYSBnaXZl biBhbW91bnQgb2YgR2JwcyBmcm9tIEEgdG8gQuKAnS4gSXQgaXMgZWFzeSB0byANCj4gZW52aXNp b24gdGhhdCBzb21lIG9mIHRoZSBjbGllbnRzIHdvdWxkIHdhbnQgZnJvbSBUZWxlZm9uaWNhIGEg Y291cGxlIA0KPiBvZiBTUkxHLWRpc2pvaW50IGFic3RyYWN0IGxpbmtzLCBzbyB0aGF0IHRoZSBj bGllbnRzIGNhbiBoYXZlIGEgc2F5IGluIA0KPiB0aGUgcGxhY2VtZW50IG9mIHRoZWlyICBzZXJ2 aWNlcyBhY3Jvc3MgdGhlIFRlbGVmb25pa2EgbmV0d29yay4gVGhyZWUgcG9pbnRzIGhlcmU6DQo+ IA0KPiBhKSAgICAgIFRoZSBjbGllbnQgd2lsbCBiZSBhYmxlIHRvIGNvbmZpZ3VyZSBmdWxseSBv ciBwYXJ0aWFsbHkgdGhlIGFic3RyYWN0IHRvcG9sb2d5DQo+IGhlIHdhbnRzIHRoZSBuZXR3b3Jr IHRvIHByZXNlbnQgdG8gaGltOw0KPiANCj4gYikgICAgICBUaGUgc2FpZCBhYnN0cmFjdCB0b3Bv bG9neSBjb3VsZCBiZSBhcyBzaW1wbGUgKGUuZy4gYSBzaW5nbGUgYWJzdHJhY3QNCj4gbm9kZSkg b3IgYXMgY29tcGxleCAoZS5nLiBOIGFic3RyYWN0IG5vZGVzIGludGVyY29ubmVjdGVkIGJ5IE0g DQo+IGFic3RyYWN0DQo+IGxpbmtzKSBhcyB0aGUgY2xpZW50IHdhbnRzIGl0IHRvIGJlIChzdWJq ZWN0IHRvIHRoZSBwcm92aWRlcuKAmXMgDQo+IGFwcHJvdmFsKQ0KPiANCj4gYykgICAgICBUaGUg YWJzdHJhY3QgdG9wb2xvZ3kgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQgaXMgY29tcGxldGVseSBk ZWNvdXBsZWQNCj4gZnJvbSB0aGUgcHJvdmlkZXLigJlzIGFjdHVhbCB0b3BvbG9neS4NCj4gDQo+ IFRoZXJlZm9yZSB0aGUgc2FtZSBpbnRlcmZhY2Uvc2V0IG9mIG1vZGVscyBjYW4gYmUgdXNlZCBi ZXR3ZWVuIGFueSANCj4gdHJhbnNwb3J0IG5ldHdvcmsgcHJvdmlkZXIgYW5kIGl0cyBjbGllbnQu IEZ1cnRoZXJtb3JlLCB0aGUgaW50ZXJmYWNlIA0KPiBjYW4gYmUgdXNlZCBpbiB0aGUgaGllcmFy Y2hpY2FsIHdheSwgdGhhdCBpcywgYSBjbGllbnQgb2YgYSB0cmFuc3BvcnQgDQo+IGRvbWFpbiBj YW4gc2VydmUgaXRzIG93biBjbGllbnRzIHVzaW5nIHRoZSBzYW1lIGludGVyZmFjZSBhcyBpdCB1 c2VzIA0KPiB0byB0YWxrIHRvIGl0cyBvd24NCj4gcHJvdmlkZXIocykNCj4gDQo+IEhlcmUgSSB3 b3VsZCBsaWtlIHRvIGdpdmUgeW91IGEgbGl0dGxlIGNsZWFyZXIgcGljdHVyZSBvbiBtdWx0aS1k b21haW4gaXNzdWVzLg0KPiANCj4gICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0t LS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0rDQo+ICAgIHwgICBDdXN0b21lciAxICAgfCAgIHwg ICBDdXN0b21lciAyICB8ICAuLi4gfCBDdXN0b21lciBNICAgfA0KPiAgICArLS0tLS0tLS0tLS0t LS0tLSsgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLSsNCj4gICAgICAg ICAgICAgICAgICAgIFwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgLw0KPiAgICAgICAgICAg ICAgICAgICAgIFwgICAgICAgICAgICB8ICAgICAgICAgICAgIC8NCj4gICAgICAgIEludGVyZmFj ZSBCICAgXCAgICAgICAgICAgfCAgICAgICAgICAgIC8NCj4gICAgICAgICAgICAgICAgICAgICAg IFwgICAgICAgICAgfCAgICAgICAgICAgLw0KPiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgVk5DIE11bHRp LWRvbWFpbiAgIHwgRTJFIGFic3RyYWN0DQo+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg Q29vcmRpbmF0aW9uICAgIHwgdG9wb2xvZ3kgY3JlYXRpb24NCj4gICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICAgICAgIC8g ICAgICAgICB8ICAgICAgICAgICAgXA0KPiAgICAgICAgIEludGVyZmFjZSBDICAgLyAgICAgICAg ICB8ICAgICAgICAgICAgIFwgIE5ldHdvcmsgVG9wb2xvZ3kNCj4gICAgICAgICAgICAgICAgICAg ICAgLyAgICAgICAgICAgfCAgICAgICAgICAgICAgXCAoYWJzdHJhY3QpDQo+ICAgICAgICAgICAg ICAgICAgICAgLyAgICAgICAgICAgIHwgICAgICAgICAgICAgICBcDQo+ICAgICstLS0tLS0tLS0t LS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsN Cj4gICAgfCBOZXR3b3JrIERvbWFpbiAxIHwgICB8IE5ldHdvcmsgRG9tYWluIDIgfCAuLiB8IE5l dHdvcmsgRG9tYWluIE4gfA0KPiAgICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0t LS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAgVmVuZG9yIFggICAg ICAgICAgICAgICAgIFZlbmRvciBZICAgICAgICAgICAgICAgVmVuZG9yIFoNCj4gDQo+IA0KPiBX aGF0IGlzIHNpdHRpbmcgYWJvdmUg4oCcVk5D4oCdICh0aGF0IGNvb3JkaW5hdGVzIG92ZXIgbXVs dGktZG9tYWluIA0KPiBjb250cm9sbGVycykgY2FuIGJlIGFuIGludGVybmFsIHNlcnZpY2Ugb3Jn YW5pemF0aW9uIChvZiB0aGUgc2FtZSANCj4gb3BlcmF0b3IpIG9yIHNlcnZpY2UgcHJvdmlkZXJz IChkaWZmZXJlbnQgb3BlcmF0b3JzLCBmb3JtaW5nIGNhcnJpZXJzIA0KPiBvZiBjYXJyaWVyKS4g VGhlIGNvbnRyb2wgZW50aXR5IG9mIHRoZXNlIGVudGl0aWVzIGlzIHJlZmVycmVkIHRvIGFzIA0K PiBDdXN0b21lciBOZXR3b3JrIGNvbnRyb2wgKENOQykuIFRoZSBWTkMg4oCTQ05DIGludGVyZmFj ZSAoSW50ZXJmYWNlIEIpIA0KPiBoYXMgZGlmZmVyZW50IHJlcXVpcmVtZW50cyB0aGFuIHRoZSBW TkMtUE5DIGludGVyZmFjZSAoSW50ZXJmYWNlIEMpLiANCj4gVG9wb2xvZ3kgYWJzdHJhY3Rpb24g aXMganVzdCBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyBhbmQgaW4gDQo+IG11bHRpLWRvbWFpbiBj YXNlLCB0aGUgVk5DIGlzIHBlcmZvcm1pbmcgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlvbiANCj4g ZnVuY3Rpb24uIFZOQyBuZWVkcyB0byBoYXZlIGEgc3RhbmRhcmQgaW50ZXJmYWNlIHRoYXQgZW5h YmxlIA0KPiBjb21tdW5pY2F0aW9ucyB3aXRoIGRpZmZlcmVudCBraW5kcyBvZiBkb21haW4gbmV0 d29yayBjb250cm9sL21hbmFnZW1lbnQgY29udHJvbCAod2hpY2ggaXMgcmVmZXJyZWQgdG8gYXMg UE5DLCB5b3UgY2FsbCBBTkMpLg0KPiBFYWNoIGRvbWFpbiBoYXMgaXRzIG93biB3YXlzIG9mIGNv bnRyb2xsaW5nIGl0cyBuZXR3b3JrLCB3aGljaCBBQ1ROIGlzIA0KPiBub3QgdG91Y2hpbmcgdGhv c2UgYXQgYWxsLiBXaGF0ZXZlciB0aGUgY2hvaWNlcyBvZiB2ZW5kb3IgY29udHJvbCANCj4gcmVn aW1lIHdpbGwgY29udGludWUgdG8gYmUgZW1wbG95ZWQgKEdNUExTL0FTT04sIFBOTkksIE5NUywg T3BlbkZsb3csIGV0Yy4pLg0KPiANCj4gRm9yIHRoaXMgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlv biBmdW5jdGlvbiBhc3N1bWVkIGJ5IFZOQyBzaG91bGQgYmUgDQo+IG9wZXJhdGVkIG9uIGFuIGFi c3RyYWN0IGxldmVsLiBXZSBkb27igJl0IHdhbnQgdG8gaW5qZWN0IHRoZSBzYW1lIGxldmVsIA0K PiBvZiBhY3R1YWwgbmV0d29yayB0b3BvbG9neSAoZS5nLiwgVEVEKSBhcyB0aGUgZG9tYWluIGNv bnRyb2xsZXIgDQo+IG9wZXJhdGVzIGl0cyBwaHlzaWNhbC9hY3R1YWwgbmV0d29ya3MuIElzIHRo aXMgYWdyZWVhYmxlPyBZb3Ugc2FpZCANCj4gYWJvdmUgdGhpcyBpbiBjKSBUaGUgYWJzdHJhY3Qg dG9wb2xvZ3kgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQgaXMgDQo+IGNvbXBsZXRlbHkgZGVjb3Vw bGVkIGZyb20gdGhlIHByb3ZpZGVy4oCZcyBhY3R1YWwgdG9wb2xvZ3kuDQo+IA0KPiBOb3cgdGhl IFZOQyAobXVsdGktZG9tYWluIGNvb3JkaW5hdG9yKSBuZWVkcyB0byBjb29yZGluYXRlIHNpZ25h bGluZyANCj4gYWNyb3NzIG11bHRpLWRvbWFpbiBjb250cm9sbGVycyAoaW4gdGVybXMgb2YgdGhl IHNlcXVlbmNlIG9mIHRoZSANCj4gZW5kLXRvLWVuZCBwYXRoIGFjcm9zcyBtdWx0aXBsZSBkb21h aW5zKS4gVGhpcyBpcyBhIG5ldyBlbGVtZW50IEkgDQo+IGJlbGlldmUgQUNUTiB3aWxsIGhhdmUg dG8gZGV2ZWxvcC4gVGhpcyBpbnRlcmZhY2UgQyAoVk5DLVBOQykgaXMgdmVyeSANCj4gZGlmZmVy ZW50IGZyb20gSW50ZXJmYWNlIEIgKENOQy1WTkMpLiBUaGVyZSBhcmUgb3RoZXIgZGlmZmVyZW5j ZXMgDQo+IChwbGVhc2Ugc2VlIFNlY3Rpb24gNi41IG9mIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQp LiAgQnV0IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBmcm9tIGFuIGFic3RyYWN0IHRvcG9sb2d5DQo+ IHN0YW5kcG9pbnQsIHNpbWlsYXIgbW9kZWwgd29ya3MgZm9yIEludGVyZmFjZXMgQiBhbmQgQyBh cyB5b3Ugc2FpZCAgYikgICAgICBUaGUNCj4gc2FpZCBhYnN0cmFjdCB0b3BvbG9neSBjb3VsZCBi ZSBhcyBzaW1wbGUgKGUuZy4gYSBzaW5nbGUgYWJzdHJhY3QgDQo+IG5vZGUpIG9yIGFzIGNvbXBs ZXggKGUuZy4gTiBhYnN0cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBieSBNIA0KPiBhYnN0cmFj dCBsaW5rcykgYXMgdGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJv dmlkZXLigJlzIGFwcHJvdmFsKS4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWW91bmcNCj4gDQo+ IA0KPiANCj4gDQo+IEZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRp Y2FsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDk6MTcgQU0NCj4gVG86 IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5p ZWw7IA0KPiBMZWV5b3VuZzsgYWN0bkBpZXRmLm9yZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdt YWlsLmNvbQ0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1YmplY3Q6IFJFOiBkcmFmdC1j ZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KPiANCj4gSGkgU2VyZ2lv LA0KPiBBIGNvdXBsZSBvZiBjb21tZW50cyBpbiBsaW5lLg0KPiANCj4gQ2hlZXJzLA0KPiBJZ29y DQo+IA0KPiBGcm9tOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgDQo+IFttYWlsdG86c2VyZ2lv LmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuY29tXQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTMs IDIwMTQgOToxNSBBTQ0KPiBUbzogSWdvciBCcnlza2luOyBEYW5pZWxlIENlY2NhcmVsbGk7IEtp bmcsIERhbmllbDsgTGVleW91bmc7IA0KPiBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1 eXVhbmZAZ21haWwuY29tDQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSk7IEJFTE9UVEksIFNFUkdJ TyAoU0VSR0lPKQ0KPiBTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29y ay0wMy50eHQgY29tbWVudHMNCj4gDQo+IEhpIElnb3IsDQo+IA0KPiBQbGVhc2UsIHNlZSBpbiBs aW5lDQo+IA0KPiBSZWdhcmRzDQo+IFNlcmdpbw0KPiANCj4gDQo+IEZyb206IElnb3IgQnJ5c2tp biBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NCj4gU2VudDogdmVuZXJkw6wgMTAg b3R0b2JyZSAyMDE0IDIyOjM3DQo+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IEtpbmcsIERhbmll bDsgTGVleW91bmc7IEJFTE9UVEksIFNFUkdJTyANCj4gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8 bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyANCj4gZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQu ZXM+Ow0KPiBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQo+IENj OiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBEYW5pZWxlLA0KPiBQbGVhc2Us IHNlZSBpbiBsaW5lLg0KPiBJZ29yDQo+IA0KPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgW21h aWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBGcmlkYXksIE9j dG9iZXIgMTAsIDIwMTQgMToyNSBQTQ0KPiBUbzogSWdvciBCcnlza2luOyBLaW5nLCBEYW5pZWw7 IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IA0KPiBhY3RuQGlldGYub3JnPG1h aWx0bzphY3RuQGlldGYub3JnPjsgDQo+IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVz PjsNCj4gbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzog VmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4t ZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KPiANCj4gSGkgSWdvciwNCj4gDQo+IFdoYXQgZG8g eW91IG1lYW4gYnkgY2xpZW50IGhlcmU/IFRoZSBvbmUgdGhhdCBpcyB0aGUgZG9jdW1lbnQgaXMg DQo+IGNhbGxlZCDigJxzZXJ2aWNlIHByb3ZpZGVy4oCdIG9yIHRoZSBvbmUgdGhhdCBpcyBjYWxs ZWQg4oCcY2xpZW504oCdID8gRnJvbSANCj4gd2hhdCB5b3Ugc2VuZCBJIHRlbmQgdG8gdGhpbmsg eW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBzZXJ2aWNlIA0KPiBwcm92aWRlciwgYnV0IEkgbWln aHQgYmUgd3JvbmcsIHBsZWFzZSBjb3JyZWN0IG1lLg0KPiANCj4gSUI+PiBCeSBjbGllbnQgSSBt ZWFuIHRoZSBjbGllbnQgb2YgYSB0cmFuc3BvcnQgZG9tYWluLCB0aGUgb25lIHdobyANCj4gSUI+ PiBzcGVha3MNCj4gTmV0Y29uZi9SZXN0Y29uZiB0byB0aGUgdHJhbnNwb3J0IGRvbWFpbi4gVGhl IGd1eSB3aG8gc3BlYWtzIGZyb20gdGhlIA0KPiBvdGhlciBlbmQgKGkuZS4gb24gYmVoYWxmIG9m IHRoZSB0cmFuc3BvcnQgc2VydmljZSBwcm92aWRlcikgIGlzIHRoZSANCj4gdHJhbnNwb3J0IGRv bWFpbuKAmXMgSHlwZXJ2aXNvci4NCj4gDQo+IFNCPj4+IEl0IGlzIGNsZWFyIHdoYXQgeW91IGlu dGVuZCBoZXJlLCBldmVuIGlmIHdvcmQgY2xpZW50IGl0IHNlZW1zIA0KPiBTQj4+PiB0byBtZQ0K PiBtb3JlIHJlbGF0ZWQgdG8gYXBwbGljYXRpb24gdGhhbiB0byBhIHNlcnZpY2UgcHJvdmlkZXIu DQo+IA0KPiBJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdHJh bnNwb3J0IGRvbWFpbiBzZXJ2ZXIgDQo+IElCPj4gYW5kDQo+IHRyYW5zcG9ydCBkb21haW4gY2xp ZW50LiBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHZlcnkgc2FtZSBpbnRlcmZhY2UgDQo+IGNhbiBi ZSB1c2VkIGJldHdlZW4gYSBtdWx0aS1kb21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkg YW5kIGl0cyANCj4gY2xpZW50cy4gTm90IGFsbCBzdWNoIGNsaWVudHMgYXJlIGR1bWIsIGFzIERh bmllbGUgY2xhaW1zLCBhbmQgb25seSANCj4gY2FyZSBhYm91dCDigJxhIGdpdmVuIGFtb3VudCBv ZiBHYnBzIGZyb20gQSB0byBC4oCdLiBJdCBpcyBlYXN5IHRvIA0KPiBlbnZpc2lvbiB0aGF0IHNv bWUgb2YgdGhlIGNsaWVudHMgd291bGQgd2FudCBmcm9tIFRlbGVmb25pY2EgYSBjb3VwbGUgDQo+ IG9mIFNSTEctZGlzam9pbnQgYWJzdHJhY3QgbGlua3MsIHNvIHRoYXQgdGhlIGNsaWVudHMgY2Fu IGhhdmUgYSBzYXkgaW4gDQo+IHRoZSBwbGFjZW1lbnQgb2YgdGhlaXIgIHNlcnZpY2VzIGFjcm9z cyB0aGUgVGVsZWZvbmlrYSBuZXR3b3JrLiBUaHJlZSBwb2ludHMgaGVyZToNCj4gDQo+IGEpICAg ICAgVGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gY29uZmlndXJlIGZ1bGx5IG9yIHBhcnRpYWxs eSB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kNCj4gaGUgd2FudHMgdGhlIG5ldHdvcmsgdG8gcHJlc2Vu dCB0byBoaW07DQo+IA0KPiBiKSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxk IGJlIGFzIHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdA0KPiBub2RlKSBvciBhcyBjb21w bGV4IChlLmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSANCj4gYWJzdHJh Y3QNCj4gbGlua3MpIGFzIHRoZSBjbGllbnQgd2FudHMgaXQgdG8gYmUgKHN1YmplY3QgdG8gdGhl IHByb3ZpZGVy4oCZcyANCj4gYXBwcm92YWwpDQo+IA0KPiBjKSAgICAgIFRoZSBhYnN0cmFjdCB0 b3BvbG9neSBwcmVzZW50ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IGRlY291cGxlZA0K PiBmcm9tIHRoZSBwcm92aWRlcuKAmXMgYWN0dWFsIHRvcG9sb2d5Lg0KPiANCj4gVGhlcmVmb3Jl IHRoZSBzYW1lIGludGVyZmFjZS9zZXQgb2YgbW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55 IA0KPiB0cmFuc3BvcnQgbmV0d29yayBwcm92aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhlcm1v cmUsIHRoZSBpbnRlcmZhY2UgDQo+IGNhbiBiZSB1c2VkIGluIHRoZSBoaWVyYXJjaGljYWwgd2F5 LCB0aGF0IGlzLCBhIGNsaWVudCBvZiBhIHRyYW5zcG9ydCANCj4gZG9tYWluIGNhbiBzZXJ2ZSBp dHMgb3duIGNsaWVudHMgdXNpbmcgdGhlIHNhbWUgaW50ZXJmYWNlIGFzIGl0IHVzZXMgDQo+IHRv IHRhbGsgdG8gaXRzIG93bg0KPiBwcm92aWRlcihzKQ0KPiANCj4gTW9yZW92ZXIgSSB3b3VsZCBh dm9pZCBpbiB0aGlzIHBoYXNlIHRvIG1lbnRpb24gYW55IHJlZmVyZW5jZSB0byANCj4gcHJvdG9j b2wgaW1wbGVtZW50YXRpb24gKGUuZy4gTmV0Y29uZi9SZXN0Y29uZikgOiBJIHRoaW5rIHdlIGFy ZSBpbiANCj4gdGhlIHBoYXNlIHRvIHVuZGVyc3RhbmQgYXJjaGl0ZWN0dXJlLCB3aGF0IGFyZSB0 aGUgcmVsZXZhbnQgDQo+IGludGVyZmFjZXMsIGFuZCB3aGF0IGluZm9ybWF0aW9uIGlzIGV4Y2hh bmdlZCBvdmVyIHRoZSByZWZlcmVuY2UgDQo+IHBvaW50cy9pbnRlcmZhY2VzLiBJIGd1ZXNzIHRo aXMgaXMgY2xlYXJseSBzdGF0ZWQgYWxzbyBpbiB0aGUgY2hhcnRlciBvZiBCb0YuDQo+IA0KPiBJ Qj4+IEFncmVlLiBJIHVzZWQgTmV0Y29uZi9SZXN0Y29uZiBhcyBhbiBleGFtcGxlIHRvIG1ha2Ug aXQgY2xlYXIgDQo+IElCPj4gd2hhdA0KPiBpbnRlcmZhY2UgSSB3YXMgdGFsa2luZyBhYm91dC4N Cj4gDQo+ICBBdCBhbiBhcHByb3ByaWF0ZSB0aW1lIOKAkyBjZXJ0YWlubHkgbm90IG5vdyDigJMg dGhlIG5leHQgc3RlcCBpcyB0byANCj4gY2hlY2sgd2l0aCBvdGhlciBTRE9zIG9uIHRoZSBhdmFp bGFiaWxpdHkgb2YgcmVsZXZhbnQgY29yZS90ZWNobm9sb2d5IA0KPiBzcGVjaWZpYy9hcHBsaWNh dGlvbiBzcGVjaWZpYyBpbmZvcm1hdGlvbiBtb2RlbCDigJxmcmFnbWVudHPigJ0sIGFuZCB0aGVu IA0KPiBmaW5hbGx5IHByb2NlZWQgb24gdGhlIHBhdGggb2YgcHJ1bmluZy9yZWZhY3RvcmluZyBh bmQgbWFwcGluZyB0byANCj4gUkVTVC9KU09OLCBOZXRjb25mL1lBTkcsIGFuZCBhbnkgb3RoZXIg cG9zc2libGUgZGF0YSBtb2RlbGluZyBhbmQgDQo+IGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgZXhp c3RpbmcuIFRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZyAgb2YgdGhlIEJvRiBzY29wZSAuDQo+IA0K PiBJIGRvbuKAmXQgdGhpbmsgdGhlIGNsaWVudCBvZiB0aGUgbXVsdGktZG9tYWluIG5ldHdvcmsg d2FudHMgdG8gaGF2ZSBhIA0KPiBzbyBkZXRhaWxlZCB2aWV3IG9mIHRoZSBuZXR3b3JrLCBoZSBk b2VzIG5vdCBjYXJlIGFib3V0IGRvbWFpbnMsIGludGVyIA0KPiBkb21haW4gbGlua3Mgb3Igd2hh dGV2ZXIsIEkgd291bGQgc2F5IGhlIG9ubHkgY2FyZXMgYWJvdXQgYSBnaXZlbiANCj4gYW1vdW50 IG9mIEdicHMgZnJvbSBBIHRvIEIgd2l0aCBhIGdpdmVuIG1heCBkZWxheSBhbmQgcHJvYmFibHkg c29tZSBkaXZlcnNpdHkgcGFyYW1ldGVycy4NCj4gDQo+IElCPj4gQWdhaW4sIGJ5IGNsaWVudCBJ IG1lYW4gbXVsdGktZG9tYWluIG5ldHdvcmsgY29udHJvbGxlciAoZS5nLiANCj4gSUI+PiBUZWxl Zm9uaWNhDQo+IFNETiBjb250cm9sbGVyKSwgbm90IHRoZSBjbGllbnQgdXNpbmcgc2VydmljZXMg b2YgdGhlIG11bHRpLWRvbWFpbiANCj4gbmV0d29yayAoaS5lLiBub3QgdGhlIFRlbGVmb25pY2Eg Y2xpZW50cykuIFN1Y2ggY2xpZW50IHVzZXMgIHRoZSANCj4gdHJhbnNwb3J0IGRvbWFpbnMgZm9y IGEgcmVhc29uLiDigJxhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBC4oCdIA0KPiBp cyB0b28gbG9vc2UgYW5kIGxpdHRsZSBmb3IgdGhlIGNsaWVudCB0byBkbyB0aGUgbmV0d29yayBw bGFubmluZy4gSU1PIA0KPiB0aGUgY2xpZW50IG5lZWRzIHRvICpwbGFuKiB0aGUgYWJzdHJhY3Qg dG9wb2xvZ2llcyBwcm92aWRlZCBieSB0aGUgDQo+IHRyYW5zcG9ydCBkb21haW5zIHRoZSBzYW1l IG9yIHNpbWlsYXIgd2F5IGFzIGhlIHdvdWxkIHBsYW4gaGlzIG93biBhY3R1YWwgdG9wb2xvZ3ku DQo+IA0KPiBTQj4+PiB5ZXMsIHN1cmUsIGluIHlvdSB2aWV3IG9mIOKAnGNsaWVudOKAnSAsIHRo aXMgaXMgdGhlIHNlcnZpY2UgDQo+IFNCPj4+IHByb3ZpZGVyIERhbmllbGUgaXMNCj4gdGFsa2lu Zywgc28gYW4gYWJzdHJhY3QgdmlldyBvZiB3aGF0IGlzIHRoZSByZWFsIHRyYW5zcG9ydCBuZXR3 b3JrIGlzIA0KPiBjb25zaWRlcmVkIGF0IHRoaXMgbGV2ZWwuIEFzIEkgc2FpZCB0byBZb3VuZywg aW4gbXkgcHJldmlvdXMgbWFpbCwgaW4gDQo+IHRoZSBjYXNlIG9mIGEgc2luZ2xlIGRvbWFpbiBz Y2VuYXJpbyBWTkMgYW5kIFBOQyBjb3VsZCBhbHNvIGNvaW5jaWRlIA0KPiBidXQgaW4gY2FzZSBv ZiBhIG11bHRpLWRvbWFpbiBzY2VuYXJpb3MgdGhlIHNjb3BlIGlzIHRvIHByb3ZpZGUgdG8gDQo+ IGFwcGxpY2F0aW9uIGxheWVyIGEgc2luZ2xlIHZpcnR1YWxpemVkIHZpZXcgb2YgdGhlIHVuZGVy bGluZSBtdWx0aSBkb21haW4gbmV0d29yay4NCj4gDQo+IE9uIHRoZSBvdGhlciBzaWRlLCB0aGUg b25lIHRoYXQgY2FyZXMgYWJvdXQgYWxsIG9mIHRoZSBpc3N1ZXMgeW91IA0KPiBsaXN0ZWQgaXMg dGhlIHNlcnZpY2UgcHJvdmlkZXIgKGFzIHBlciBhY3R1YWwgZG9jdW1lbnQgdGVybWlub2xvZ3kp LiANCj4gSG93ZXZlciBhbHNvIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGRvZXMgbm90IGdvIGludG8g cGh5c2ljYWwgaW1wYWlybWVudCANCj4gZGV0YWlscy4gSGUgY2FyZXMgYWJvdXQgY29ubmVjdGl2 aXR5IGJldHdlZW4gdGhlIGJvcmRlcnMgb2YgdGhlIA0KPiBkb21haW5zLCBpbnRlciBkb21haW4g bGlua3MuIEhvdyBzdWNoIGNvbm5lY3Rpdml0eSBpcyBwcm92aXNpb25lZC9tYW5hZ2VkIGlzIHRo ZSBuZXR3b3JrIHByb3ZpZGVyIGJ1c2luZXNzLg0KPiBUaGUgbmV0d29yayBwcm92aWRlcyBtaWdo dCBiZSB1c2luZyBHTVBMUywgTk1TIGFuZCBPTkYgY29udHJvbGxlciB3aXRoIA0KPiBPcGVuIEZs b3cgb3Igd2hhdGV2ZXIgdG8gY29udHJvbCB0aGUgbmV0d29yay4gTWF5YmUgY2FsbGluZyBpdCBQ TkMgaXMgDQo+IGNvbmZ1c2luZz8gVGhlIFBOQyBjYW4gYmUgYW55IG9mIHRoZSB0aGluZ3MgSeKA mXZlIGxpc3RlZCBhbmQgbXVjaCBtb3JlLg0KPiANCj4gSUI+PiBJbiB0aGlzIGNhc2UgbXkgY2xp ZW50IGlzIHlvdXIgc2VydmljZSBwcm92aWRlciA7PSkuIFlvdSANCj4gSUI+PiBhcmNoaXRlY3R1 cmFsbHkNCj4gc2VwYXJhdGUgY2xpZW50IGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIsIGJlY2F1 c2UgeW91IHByb2JhYmx5IA0KPiBiZWxpZXZlIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gc3RhbmRh cmRpemUgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSANCj4gdHdvLiBJIGRpc2FncmVlIHdpdGgg dGhhdCBhbmQgZG9u4oCZdCB0aGluayBBQ1ROIHNob3VsZCB3b3JrIG9uIHRoaXMuIEluIA0KPiB0 aGUgY29udGV4dCBvZiBBQ1ROIEkgc2VlIG9ubHkgdHdvIGNvbnN0cnVjdHM6IFRyYW5zcG9ydCBk b21haW4gDQo+IGNvbnRyb2xsZXIgKHRyYW5zcG9ydCBzZXJ2aWNlIHByb3ZpZGVyKSBhbmQgIFRy YW5zcG9ydCBjbGllbnQgY29udHJvbGxlciAodHJhbnNwb3J0IHNlcnZpY2UgdXNlcikuDQo+IA0K PiBTQj4+PiBBQ1ROIGhlcmUgaXMgbm90IHJlaW52ZW50aW5nIHRoZSB3aGVlbCAsIGluIG90aGVy IFNETyBTRE4gDQo+IFNCPj4+IHNwZWNpZmljIGlzDQo+IGNvbnNpZGVyZWQgIHRoZSBhcHBsaWNh dGlvbiBsYXllciAsIGFuZCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gQUwgYW5kIA0KPiBTRE4gY29u dHJvbGxlciAoaW4gdGhpcyBjYXNlIHRoZSBWTkMgb2YgQUNUTikgLiBUaGlzIGludGVyZmFjZSBw ZXJtaXQgDQo+IHRvIGFueSBjbGllbnQgdG8gZGlyZWN0bHkgaW1wYWN0IHRvIGhpcyBvd24gc2Vy dmljZXMgYW5kIGhpcyBvd24g4oCcdmlydHVhbGl6ZWTigJ0gcmVzb3VyY2VzIC4NCj4gDQo+IA0K PiBIZW5jZSB0aGUgaW50ZXJmYWNlcyB0byBiZSBjb25zaWRlcmVkIGFyZSB0d28sIG5vdCB0aHJl ZSAoYXMgRGFuIHNhaWQpIA0KPiBJIHRoaW5rIHRoaXMgcmVwbGllcyB0byBxdWVzdGlvbnMgMSBh bmQgMy4gSnVzdCB0byBhZGQgc29tZXRoaW5nIA0KPiByZWdhcmRpbmcgMiwgSSB3b3VsZCBzYXkg dGhhdCB0aGV5IG5lZWQganVzdCBhIHNpbmdsZSBlbnRyeSBwb2ludCB0byANCj4gdGhlIG5ldHdv cmsgY29udHJvbCAoY291bGQgYmUgYSBzbWFsbCBwaWVjZSBvZiBjb2RlIHJ1bm5pbmcgb24gdG9w IG9mIA0KPiB0aGUgUENFIG9mIHlvdXIgR01QTFMgZG9tYWluKSwgd2hpY2ggYWN0cyBhcyBhbiBp bnRlcmZhY2UgYmV0d2VlbiB0aGUgDQo+IFZOQyBhbmQgdGhlIGNvbnRyb2wgcGxhbmUgb2YgeW91 ciBuZXR3b3JrIGFuZCBwZXJmb3Jtczog4oCcLSBNYXBwaW5nIG9mIHBoeXNpY2FsIGFuZCB2aXJ0 dWFsIHJlc291cmNlc+KAnSBhbmQgIOKAnFJlcXVlc3RzOg0KPiBwYXRoLCBwcm92aXNpb24sIG1v ZGlmeSBhbmQgcmVzdG9yZeKAnS4NCj4gDQo+IElCPj4gQXMgSSBzYWlkLCB0aGlzIGlzIHRoZSB0 YXNrIG9mIHRoZSB0cmFuc3BvcnQgZG9tYWluIEh5cGVydmlzb3IsIA0KPiBJQj4+IHdob3NlIHJv bGUNCj4gaXMsIGVzc2VudGlhbGx5LCB0byB0cmFuc2xhdGUgYmFjayBhbmQgZm9ydGggYWJzdHJh Y3QgPD0+IGFjdHVhbCANCj4gdG9wb2xvZ3kgZWxlbWVudHMgYW5kIHNlcnZpY2UgcmVxdWVzdHMv cmVzcG9uc2VzIGNvbnRhaW5pbmcgdGhlIA0KPiBhYnN0cmFjdC9hY3R1YWwgdG9wb2xvZ3kgcGF0 aHMuIEkgdGhpbmsgdGhhdCB0aGUgbm9ydGgvc291dGggaW50ZXJmYWNlIA0KPiBiZXR3ZWVuIHRo ZSB0cmFuc3BvcnQgZG9tYWluIEh5cGVydmlzb3IgYW5kIHRoZSBlbnRpdHkgcmVwcmVzZW50aW5n IA0KPiB0aGUgY2xpZW50IG9mIHRoZSB0cmFuc3BvcnQgZG9tYWluIChubyBtYXR0ZXIgaG93IHlv dSBjYWxsIGl0KSBpcyB0aGUgDQo+IG9ubHkgaW50ZXJmYWNlIEFDVE4gY2FuIHdvcmsgb24gd2l0 aCB0aGUgaG9wZSB0byBwcm9kdWNlIHNvbWV0aGluZyB1c2VmdWwuDQo+IA0KPiBDaGVlcnMNCj4g RGFuaWVsZQ0KPiANCj4gDQo+IA0KPiBGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tp bkBhZHZhb3B0aWNhbC5jb21dDQo+IFNlbnQ6IHZlbmVyZMOsIDEwIG90dG9icmUgMjAxNCAwMzox Ng0KPiBUbzogS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8p OyANCj4gYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2Fy ZWxsaTsgDQo+IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBn bWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChF dmUpDQo+IFN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4 dCBjb21tZW50cw0KPiANCj4gWW91bmcgYW5kIERhbiwNCj4gDQo+IEl0IGRvZXMgbm90IG1hdHRl ciBob3cgeW91IGNhbGwgbWUsIGFuZCBhcyBKb2huIGlzIGhlbHBmdWxseSBhcHBseWluZywgDQo+ IHlvdSBjYW4gaWdub3JlIHdoYXQgSSBhbSBzYXlpbmcuIEJ1dCBsZXQgbWUgZXhwbGFpbiBpbiBz b21lIG1vcmUgDQo+IGRldGFpbHMgd2hhdCBJIG1lYW50Lg0KPiANCj4gU3VwcG9zZSB3ZSBoYXZl IGEgY2xpZW50IChzdWNoIGFzIFRGSykgb2YgYSBtdWx0aS1kb21haW4gdHJhbnNwb3J0IA0KPiBu ZXR3b3JrLCB3aG8gd2FudHMgdG8gcHJvdmlzaW9uIGFuZCBtYW5pcHVsYXRlIGUyZSB0cmFuc3Bv cnQgc2VydmljZXMgDQo+IHRoZSB3YXkgaGUgd2FudHMgaXQgKGkuZS4gYXBwbHlpbmcgaGlzIHBv bGljaWVzKS4gV2hhdCB3b3VsZCBzdWNoIGNsaWVudCBuZWVkPw0KPiANCj4gDQo+IDEuICAgICBB biBhY2Nlc3MgdG8gYSB1bmlmaWVkIG5ldHdvcmsgVEUgdG9wb2xvZ3kgdGhhdCBjb3VsZCBiZSB1 bmRlcnN0b29kIGFuZA0KPiB1c2VkIGJ5IHRoZSBjbGllbnTigJlzIHBhdGggY29tcHV0ZXIgdG8g c2VsZWN0IHNlcnZpY2UgZTJlIHBhdGhzLiBIb3cgDQo+IGRvZXMgdGhlIGNsaWVudCBnZXQgc3Vj aCBhIHRvcG9sb2d5PyBUaGUgbmVjZXNzYXJ5IG92ZXJsYXkgdG9wb2xvZ3kgDQo+IGNvbXByaXNl cyBhYnN0cmFjdCB0b3BvbG9naWVzIHByZXNlbnRlZCBmb3IgdGhlIGNsaWVudCBieSBlYWNoIG9m IHRoZSANCj4gdHJhbnNwb3J0IGRvbWFpbnMNCj4gKyBpbnRlci1kb21haW4gVEUgbGlua3MuIEhl bmNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGludGVyZmFjZSAjMSAoYW5kIA0KPiArIGRhdGENCj4g bW9kZWwgIzEpIGJldHdlZW4gYSBwcm92aWRlciBoeXBlcnZpc29yL1ZOQyBhbmQgdGhlIGNsaWVu dCBjb250cm9sbGVyIA0KPiB0byBleHBvc2UgaW4gYSB1bmlmaWVkIGFic3RyYWN0ICB3YXkgIGl0 cyB0b3BvbG9neSBvbiBwZXIgY2xpZW50L3RlbmFudCBiYXNpcy4NCj4gRnVydGhlcm1vcmUsIHRo ZSBjbGllbnQgY29udHJvbGxlciBjYW4gdXNlIHRoaXMgaW50ZXJmYWNlIGluIHRoZSANCj4gb3Bw b3NpdGUgZGlyZWN0aW9uIHRvIG1vZGlmeSB0aGUgc2FpZCBhYnN0cmFjdCB0b3BvbG9neSAoc3Vi amVjdCB0byANCj4gdGhlIHByb3ZpZGVy4oCZcyBhcHByb3ZhbCksIGJlY2F1c2UgdGhlIGNsaWVu dCBpcyB0aGUgb25seSBndXkgd2hvIGtub3dzIA0KPiBob3cgdGhlIGFic3RyYWN0IHRvcG9sb2d5 IGV4cG9zZWQgdG8gaGltIHNob3VsZCBsb29rIGxpa2UgdG8gYmUgdXNlZnVsIA0KPiAoZS5nLiB3 aGljaCBhbmQgaG93IHRoZSBhYnN0cmFjdCBsaW5rcyBzaG91bGQgYmUgZGlzam9pbnQgZnJvbSBl YWNoIA0KPiBvdGhlciwgaG93IG1hbnkgb2YgdGhlbSBzaG91bGQgYmUgcHJvdmlkZWQsIHRoZWly IGF0dHJpYnV0ZXMsIGRlc2lyZWQgDQo+IHJlY292ZXJ5IGNhcGFiaWxpdGllcywgZXRjLCkuIFRo aXMga25vd2xlZGdlIGlzIHN1cHBvc2VkIHRvIGNvbWUgZnJvbSB0aGUgY2xpZW504oCZcyBuZXR3 b3JrIHBsYW5uaW5nLg0KPiANCj4gMi4gICAgIEEgd2F5IHRvIHByb3Zpc2lvbi9tb2RpZnkvZGVs ZXRlIGUyZSBzZXJ2aWNlcyB3aXRoIHRoZSB1c2Ugb2Ygc28NCj4gY29tcHV0ZWQgZTJlIHBhdGhz LiBUaGUgY2xpZW504oCZcyBjb250cm9sbGVyIGRvZXMgdGhhdCBieSBjaG9wcGluZyB0aGUgDQo+ IHBhdGhzIGludG8gcGVyLWRvbWFpbiBzZWdtZW50cyBhbmQgaW5zdHJ1Y3RzIHJlc3BlY3RpdmUg ZG9tYWluIA0KPiBWTkNzL0h5cGVydmlzb3JzIHRvIHNldCB1cC9tYW5pcHVsYXRlIHNlcnZpY2Ug cmVzcGVjdGl2ZSBjb25uZWN0aW9uIA0KPiBzZWdtZW50cy4gSGVuY2Ugd2UgYXJlIHRhbGtpbmcg YWJvdXQgaW50ZXJmYWNlICMyIChkYXRhIG1vZGVsICMyKSBmb3IgDQo+IHRoZSBzZXJ2aWNlIHNl Z21lbnQgbWFuaXB1bGF0aW9uOw0KPiANCj4gMy4gICAgIEEgd2F5IHRvIG1vbml0b3IsIHRyb3Vi bGVzaG9vdCwgY2Fycnkgb3V0IG1haW50ZW5hbmNlIG9mIHRoZSBhY3RpdmUgZTJlDQo+IHNlcnZp Y2VzLiBUaGlzIHdvdWxkIHJlcXVpcmUgaW50ZXJmYWNlICMzIChkYXRhIG1vZGVsICMzKSBiZXR3 ZWVuIHRoZSANCj4gY2xpZW504oCZcyBjb250cm9sbGVyIGFuZCBkb21haW5zIFZOQ3MvSHlwZXJ2 aXNvcnMgZm9yIHRoaXMgcHVycG9zZS4NCj4gDQo+IFNvLCB3ZSBhcmUgdGFsa2luZyAzIFlhbmcg bW9kZWxzIHdpdGggcmVxdWlyZWQgbW9kaWZpY2F0aW9ucyB0byANCj4gbmVpdGhlciBOZXRjb25m L1Jlc3Rjb25mLCBub3IgIFRvIGFueSBvdGhlciBtYW5hZ2VtZW50LCByb3V0aW5nIG9yIA0KPiBz aWduYWxpbmcgcHJvdG9jb2wuDQo+IA0KPiBOb3cgSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9u cyB0byB5b3U6DQo+IA0KPiAxLiAgICAgSW4gdGhpcyBleGFtcGxlLCB3aGF0IGVsc2UgKGluIGFk ZGl0aW9uIHRvIHRoZXNlIHRocmVlIG1vZGVscykgdGhlIGNsaWVudA0KPiBzdWNoIGFzIFRGSyBp biB5b3VyIG9waW5pb24gd291bGQgbmVlZD8NCj4gDQo+IDIuICAgICBXaGF0IGVsc2UgdGhlIG5l dHdvcmsgcHJvdmlkZXJzIGFuZCB0aGVpciB2ZW5kb3JzIHN1Y2ggYXMgQURWQSBvcg0KPiBDSUVO IHdvdWxkIG5lZWQ/DQo+IA0KPiAzLiAgICAgV2hhdCBpcyB0aGUgaW1wb3J0YW5jZSBvZiBhIGNv bnN0cnVjdCBzdWNoIGFzIFBOQz8NCj4gDQo+IA0KPiBNeSBhbnN3ZXIgdG8gMy4g4oCcSXMgbm90 IGltcG9ydGFudCBhdCBhbGwsIGlycmVsZXZhbnTigJ0gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29u czoNCj4gDQo+IGEpICAgICBXaGF0IGhhcHBlbnMgYmV5b25kIHRoZSBWTkMvSHlwZXJ2aXNvciBp biB0aGUgcHJvdmlkZXIgbmV0d29yayBpcw0KPiBjb21wbGV0ZWx5IHByb3ByaWV0YXJ5Lg0KPiAN Cj4gYikgICAgIFRoZXJlIGNvdWxkIGJlIG51bWVyb3VzIHdheXMgYXMgdG8gaG93IHRoZSBwcm92 aWRlciBuZXR3b3JrIGlzDQo+IG1hbmFnZWQuIEV4YW1wbGVzOiBjZW50cmFsaXplZCBQTkMgKGFz IHlvdSBjYWxsIGl0KSwgQURWQSBzdHlsZSBHTVBMUyANCj4gYmFzZWQgbmV0d29yayBpbnRlbGxp Z2VuY2UsIENJRU4gc3R5bGUgUE5OSSBiYXNlZCBjb250cm9sIHBsYW5lLCBldGMuIA0KPiBXaHkg aXMgdGhhdCBvZiBBQ1RO4oCZcyBidXNpbmVzcz8NCj4gDQo+IENoZWVycywNCj4gSWdvcg0KPiAN Cj4gRnJvbTogS2luZywgRGFuaWVsIFttYWlsdG86ZC5raW5nQGxhbmNhc3Rlci5hYy51a10NCj4g U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDksIDIwMTQgNDo1OCBQTQ0KPiBUbzogTGVleW91bmc7 IElnb3IgQnJ5c2tpbjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyANCj4gYWN0bkBpZXRmLm9y ZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgDQo+IGRpZWdvQHRp ZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1 eXVhbmZAZ21haWwuY29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1YmplY3Q6IFJF OiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KPiANCj4g SGkgQWxsLCBpbmNsdWRpbmcg4oCcSWdub3LigJ0gOy0pDQo+IA0KPiBUeXBpY2FsIGRpY2hvdG9t eSBiZXR3ZWVuIHdoYXQgb3BlcmF0b3JzIHdhbnQgYW5kIHdoYXQgdmVuZG9ycyBhcmUgDQo+IGFj dHVhbGx5IHdpbGxpbmcgdG8gcHJvdmlkZSwgZ3JvdXAgY29uc2Vuc3VzIHdpbGwgZXZlbnR1YWxs eSBoZWxwIHJlc29sdmUgdGhhdC4NCj4gRWl0aGVyIHdheSwgdGhlIGxhdGVzdCB2ZXJzaW9uIG9m IHRoZSBGcmFtZXdvcmsgSS1EIGlzIHRyeWluZyB0byBmb2N1cyANCj4gQUNUTiBkaXNjdXNzaW9u IGFuZCBzY29wZSAoaS5lLiwgdGhlIHByb3RvY29sIHdvcmspIG9uIHRoZSBpbnRlcmZhY2VzIA0K PiB3aGljaCBhcmUgaW4gc2NvcGUsIG5hbWVseToNCj4gDQo+IDEuIFRoZSBDTkMtVk5DIEludGVy ZmFjZSAoQ1ZJKQ0KPiAtIENyZWF0ZSwgbW9kaWZ5IGFuZCBkZWxldGUgdmlydHVhbCBuZXR3b3Jr IHNlcnZpY2UgaW5zdGFuY2VzDQo+IC0gUmVzb3VyY2UgbW9kZWwNCj4gDQo+IDIuIFRoZSBWTkMt UE5DIEludGVyZmFjZSAoVlBJKQ0KPiAtIE1hcHBpbmcgb2YgcGh5c2ljYWwgYW5kIHZpcnR1YWwg cmVzb3VyY2VzDQo+IC0gUmVxdWVzdHM6IHBhdGgsIHByb3Zpc2lvbiwgbW9kaWZ5IGFuZCByZXN0 b3JlDQo+IA0KPiBBcyBZb3VuZyBzdWdnZXN0cywgaWYgdGhlIFZOQyByZWNlaXZlZCBwaHlzaWNh bCB0b3BvbG9neSBpbmZvIGl0IHdvdWxkIA0KPiBiZSBwZXJmb3JtaW5nIHRoZSByb2xlIG9mIHRo ZSBQaHlzaWNhbCBOZXR3b3JrIENvbnRyb2xsZXIgKFBOQyksIHdoaWNoIA0KPiBpcyBvYnZpb3Vz bHkgYSAoc29tZWhvdykgcmVxdWlyZWQgZnVuY3Rpb24sIGJ1dCB0aGUgaW50ZXJmYWNlIChkaXJl Y3QgDQo+IHByb3Zpc2lvbmluZyBvZiB0aGUgYWN0dWFsIHBoeXNpY2FsIG5ldHdvcmspIGlzIG91 dCBvZiBzY29wZSBmb3IgQUNUTi4NCj4gDQo+IEJyLCBEYW4uDQo+IA0KPiBGcm9tOiBBQ1ROIFtt YWlsdG86YWN0bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVleW91bmcNCj4gU2Vu dDogMDkgT2N0b2JlciAyMDE0IDIxOjMyDQo+IFRvOiBJZ29yIEJyeXNraW47IEJFTE9UVEksIFNF UkdJTyAoU0VSR0lPKTsgDQo+IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBE YW5pZWxlIENlY2NhcmVsbGk7IA0KPiBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47 DQo+IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCj4gQ2M6IFZh cm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSZTogW0FjdG5dIGRyYWZ0LWNlY2NhcmVsbGkt YWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBJZ25vciwNCj4gDQo+IFRo YW5rIHlvdSBmb3IgcHJvdmlkaW5nIHlvdXIgY29tbWVudCB0aGF0IHBhdXNlcyB1cyB0byB0aGlu ayBtb3JlIGFuZCANCj4gdW5kZXJzdGFuZCBvbiB0aGUgc2FtZSBsZXZlbC4gSSB0aGluayB5b3Vy IGNvbW1lbnQgd2lsbCBjb250cmlidXRlIHRvIA0KPiBjcnlzdGFsbGl6ZSB0aGUgc2NvcGUgb2Yg d29yayBoZXJlLg0KPiANCj4gRmlyc3Qgb2YgYWxsLCBJIHRoaW5rIHRoZXJlIHdhcyBhIG1pc3Vu ZGVyc3RhbmRpbmcgaGVyZS4gRmlyc3QsIHlvdXIgDQo+IGFzc3VtcHRpb24gb24gVk5DIHJlY2Vp dmluZyBhY3R1YWwgdW5kZXJseWluZyB0b3BvbG9neSBpcyBpbmNvcnJlY3QuIA0KPiBJZiBWTkMg d2VyZSB0byBoYXZlIGFjdHVhbGx5IHRvcG9sb2d5IChlLmcuIFRFRCkgb2YgYSBuZXR3b3JrLCB0 aGlzIA0KPiB3b3VsZCBiZSBjYWxsZWQgYSBQTkMgYW5kIHRoaXMgaXMgb3V0IG9mIHNjb3BlIG9m IEFDVE4uIFRoaXMgYXNwZWN0IA0KPiBoYXMgYmVlbiBkaXNjdXNzZWQgYnkgZW1haWwgdGhyZWFk cyBEYW5pZWxlIHN0YXJ0ZWQgYSBmZXcgd2Vla3MgYWdvLiANCj4gQ2hlY2sgdGhlIGFyY2hpdmUg b24gdGhhdC4gVGhlIHJlYXNvbiB0aGlzIGlzIG91dCBvZiBzY29wZSBpcyB0aGF0IFBOQyANCj4g bXVsdGktZG9tYWluIGlzc3VlIGlzIG5vIGRpZmZlcmVudCBmcm9tIHRvZGF54oCZcyBHTVBMUy9Q Q0UgaXNzdWUsIA0KPiBlc3BlY2lhbGx5IGluIGxpZ2h0IG9mIEgtUENFLiBBQ1ROIGRvZXMgbm90 IHN0ZXAgb24gdGhvc2UgYXJlYXMuIFdoYXQgDQo+IFZOQyByZWNlaXZlcyBmcm9tIGVhY2ggUE5D IChkb21haW4gY29udHJvbGxlcikgaXMgYW4gYWJzdHJhY3RlZCANCj4gdG9wb2xvZ3kgd2l0aCB2 YXJ5aW5nIGRlZ3JlZXMgZnJvbSBhY3R1YWwgdW5kZXJseWluZyB0b3BvbG9neS4gVGhlIHJlYXNv biB3aHkgd2UgZGlzdGluZ3Vpc2ggdGhlIHRlcm0gVk5DIGZyb20gUE5DLg0KPiANCj4gV2hhdCBj YW4gYmUgZGVmaW5lZCBvbiBWTkMtUE5DIGlzIGEgdmVydGljYWwgc2lnbmFsaW5nIGNvb3JkaW5h dGlvbiANCj4gZnJvbSBWTkMgdG8gZWFjaCBQTkMuIEFzIGxvbmcgYXMgdGhlIGRldGFpbGVkIHBh dGggY29tcHV0YXRpb24gYW5kIA0KPiBzaWduYWxpbmcgd2l0aGluIGEgZG9tYWluIGFyZSBjb21w bGV0ZWx5IHVwIHRvIHRoZSBkb21haW4gUE5DLiBWTkMgaXMgDQo+IG5vdCB0byBiZSBvcGVyYXRl ZCBvbiB0aGUgc2FtZSBsZXZlbCBhcyBQTkMuIEl0cyBlbmQtdG8tZW5kIHBhdGggDQo+IGNvbXB1 dGF0aW9uIGlzIGJhc2VkIG9uIHdoYXQgaXMgZXhwb3NlZCBmcm9tIFBOQ3MgdG8gVk5DLiBUaGUg YWN0dWFsIA0KPiB0b3BvbG9neSBpbmZvcm1hdGlvbiBkZXRhaWxzIGlzIGtlcHQgYnkgUE5DcyBh bmQgdGhlIFBOQ3MgZXhwb3NlIA0KPiBhYnN0cmFjdGVkIHRvcG9sb2d5IHRoYXQgY2FuIGhpZGUg dGhlIGV4YWN0IGRldGFpbHMgd2hpbGUgZXhwb3NpbmcgYSBtaW5pbXVtIGxldmVsIG9mIGNvbnN0 cmFpbnRzLg0KPiBGb3IgaW5zdGFuY2UsIHRoZSBTUkxHIG9mIHZpcnR1YWwgbGlua3MgKHdoaWNo IG1heSBiZSBjb25jYXRlbmF0ZWQgDQo+IGFjdHVhbA0KPiBsaW5rcykgY2FuIGJlIGV4cG9zZWQg Zm9yIGRpdmVyc2l0eSByb3V0aW5nIGNhbGN1bGF0aW9uIGF0IHRoZSBWTkMuIA0KPiBUaGlzIGlz IHZlcnkgZGlmZmVyZW50IGZyb20gZXhwb3NpbmcgdGhlIGFjdHVhbCBURSB0b3BvbG9neS4gWW91 IGNhbiANCj4gdmlldyB0aGlzIGFzIHR3byBsZXZlbCBvZiBwYXRoIGNvbXB1dGF0aW9uLiBWTkMg Zmlyc3QgY29tcHV0ZXMgYW4gDQo+IGVuZC10by1lbmQgcGF0aCAodXNpbmcgd2hhdGV2ZXIgY29u c3RyYWludCBpbmZvcm1hdGlvbiBpdCBoYXMpLCB0aGVuIA0KPiBjb29yZGluYXRlcyB3aXRoIGVh Y2ggUE5DICh0ZWxsaW5nIHRoZSBib3JkZXIgbm9kZXMgaW5mb3JtYXRpb24pLCB0aGVuIA0KPiBl YWNoIFBOQyBjb21wdXRlcyB0aGUgZG9tYWluIHNwZWNpZmljIHBhdGguIFdoZW4gYSBQTkMgY2Fu bm90IHByb3ZpZGUgDQo+IGEgcGF0aCBzZWdtZW50IGluIGl0cyBkb21haW4sIHRoZW4gdGhpcyBu ZWVkcyB0byBiZSBzaWduYWxlZCB0byBWTkMgc28gDQo+IHRoYXQgdGhlIFZOQyB3b3VsZCBhcnJh bmdlIGFuIGFsdGVybmF0ZSBwYXRoIHNlZ21lbnQgdG8gYmUgYWJsZSB0byANCj4gZmluZCBhIGZl YXNpYmxlIGVuZC10by1lbmQgcGF0aC4gIEkgd291bGQgc2F5IHRoaXMgaXMgYSDigJx0d28tcGhh c2XigJ0gDQo+IHNpZ25hbGluZyBhbmQgcGF0aCBjb21wdXRhdGlvbi4gVGhlIHBvaW50IGlzIHRo YXQgdGhlcmUgbXVzdCBiZSBzb21lIA0KPiBsZXZlbCBvZiBoaWRpbmcgb24gYWJzdHJhY3QgdG9w b2xvZ3kgZXhwb3N1cmUgZnJvbSBQTkMgdG8gVk5DIGFuZCANCj4gcHJvcHJpZXRhcnkgY2hhcmFj dGVyaXN0aWNzIG9mIG9wdGljYWwgZGV2aWNlcyBuZWVkIHRvIGJlIGRlYWx0IG9ubHkgd2l0aCB0 aGUgY29ycmVzcG9uZGluZyBQTkMuDQo+IA0KPiBSZWdhcmRpbmcgdGhlIHRlcm0gUE5DIHZzLiBB TkMsIEkgd291bGRu4oCZdCBjb25jZXJuIHRvbyBtdWNoIGFib3V0IHRoZSANCj4gdGVybWlub2xv Z3kgd2hpY2hldmVyIHdvcmtzIGJldHRlci4gVGhhbmsgeW91IGZvciB5b3VyIHN1Z2dlc3Rpb24u DQo+IA0KPiBMYXN0bHksIHBsZWFzZSBjaGVjayB0aGUgdXNlLWNhc2VzIHdyaXR0ZW4gYnkgb3Bl cmF0b3JzIGluIHRoZSBiZWxvdyANCj4gbGlua3MgdGhhdCBjb25zaXN0ZW50bHkgc2F5IHRoZXkg bmVlZCBhIHN0YW5kYXJkIGludGVyZmFjZSB0aGF0IGNhbiANCj4gY29vcmRpbmF0ZSB0aGVpciBt dWx0aS1kb21haW4gaXNzdWVzLg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmFuZy1hY3RuLW11bHRpZG9tYWluLWRjaS8NCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQta2xlZS1hY3RuLWNvbm5lY3Rpdml0eS1tdWx0aS12ZQ0KPiBu ZG9yLQ0KPiBkb21haW5zLw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1rdW1ha2ktYWN0bi1tdWx0aXRlbmFudC12bm8vDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWxvcGV6LWFjdG4tdm5vLW11bHRpZG9tYWlucy8NCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hpbi1hY3RuLW12bm8tbXVsdGktZG9tYWlu Lw0KPiANCj4gUmVnYXJkcywNCj4gWW91bmcNCj4gDQo+IFRoYW5rcywNCj4gWW91bmcNCj4gDQo+ IA0KPiBGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21d DQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDE6NDggUE0NCj4gVG86IEJFTE9U VEksIFNFUkdJTyAoU0VSR0lPKTsgTGVleW91bmc7IA0KPiBhY3RuQGlldGYub3JnPG1haWx0bzph Y3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyANCj4gZGllZ29AdGlkLmVzPG1haWx0 bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFp bC5jb20+DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNl Y2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBZb3VuZywN Cj4gDQo+IEkgYmVsaWV2ZSBoYXZpbmcgdGhlIHNhbWUgaW5zdGFuY2Ugb2YgVk5DIHRhbGtpbmcg dG8gZGlmZmVyZW50IHZlbmRvciANCj4gZG9tYWluIFBOQ3MgaXMgYW4gZXh0cmVtZWx5ICBpZGVh bGlzdGljIHZpZXcuDQo+IA0KPiA9PT09PiBCVFcgSSBmaW5kIFBOQyBpcyBhIGJhZCB0ZXJtLCBJ IGxpa2UgbXVjaCBiZXR0ZXIgQWN0dWFsIE5ldHdvcmsgDQo+IENvbnRyb2xsZXIgIChBTkMpLiBW TkMgKGEuay5hLiBhIEh5cGVydmlzb3IpIGlzIG1hbmFnaW5nIGFic3RyYWN0IA0KPiB0b3BvbG9n aWVzLCBhbmQgdG8gYmUgYWJsZSBkbyB0aGF0LCBpdCB0YWxrcyB0byBhIEFOQy0gYSBjb250cm9s bGVyIA0KPiB3aGljaCBoYXMgYW4gYWNjZXNzIGFuZCBtYW5hZ2VzIGFjdHVhbCBwcm92aWRlciBu ZXR3b3JrKS4NCj4gDQo+IE9uZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBWTkMgbmVlZHMgdG8g dW5kZXJzdGFuZCB1bmRlcmx5aW5nIGFjdHVhbCANCj4gdG9wb2xvZ3ksIGZvciBleGFtcGxlLCB0 byBlbnN1cmUgdGhhdCB0d28gYWJzdHJhY3QgVEUgbGlua3MgYXJlIFNSTEcgDQo+IGRpc2pvaW50 IGFzIHJlcXVlc3RlZC4gQWN0dWFsIHRvcG9sb2d5IHNlbWFudGljcyAoZXNwZWNpYWxseSBpbiBX RE0gDQo+IGxheWVyKSBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHZlbmRvciB0byB2ZW5kb3IgYW5k IGNvbnRhaW5zIGEgZ3JlYXQgDQo+IHZhcmlldHkgb2YgcHJvcHJpZXRhcnkgZXh0ZW5zaW9ucywg ZmFpbGluZyB0byB1bmRlcnN0YW5kIHdoaWNoIGxlYWRzIA0KPiB0byBwcm9kdWNpbmcgdW5wcm92 aXNpb25hYmxlIHNlcnZpY2UgcGF0aHMuIERvIHlvdSByZWFsbHkgYmVsaWV2ZSB0aGF0IA0KPiBh IHNpbmdsZSBWTkMgY2FuIHRhbGsgaW4gdGhlIHNhbWUgd2F5IHRvIEFEVkEsIElORk4sIEFMVSBh bmQgSHVhd2VpIA0KPiBBTkNzPyBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gYXNrIGFsbCBvcHRpY2Fs IHByb3ZpZGVycyB0byBzd2l0Y2ggdG8gV1NPTiA6PSkuDQo+IA0KPiBUaGlzIGlzIG5vdCB0byBz YXkgdGhhdCB5b3UgY2Fubm90IGJ1aWxkIGEgaGllcmFyY2h5IG9mIFZOQ3MsIGJ1dCBpbiANCj4g dGhpcyBjYXNlIE5vcnRoIFZOQyBwbGF5cyByb2xlIG9mIGEgY2xpZW50IG5ldHdvcmsgY29udHJv bGxlciB3cnQgdG8gDQo+IFNvdXRoIFZOQywgdGhhdCBpcywgdXNlcyB0aGUgc2FtZSBYIGludGVy ZmFjZS4NCj4gSUhNTyB3aGVuZXZlciBhIFZOQyBoYXMgdG8gdGFsayB0byBhIEFOQywgaXQgZG9l cyBzbyBpbiBhIHByb3ByaWV0YXJ5IA0KPiB3YXksIGkuZS4gQURWQSwgSU5GTiwgQUxVIGFuZCBI dWF3ZWkgd2lsbCBoYXZlIHRoZWlyIG93biBWTkNzIGV4cG9zaW5nIA0KPiB0aGUgc2FtZSBub3J0 aCBib3VuZCBpbnRlcmZhY2UgdG8gcG90ZW50aWFsbHkgdGhlIHNhbWUgY2xpZW50IChlLmcuVEZL KS4NCj4gSUhNTyBpbnRlcmZhY2UgWCBpcyB0aGUgb25seSBpbnRlcmZhY2UgdGhhdCB0aGUgQUNU TiBjYW4gd29yayBvbi4NCj4gDQo+IENoZWVycywNCj4gSWdvcg0KPiANCj4gRnJvbTogQUNUTiBb bWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJFTE9UVEksIFNFUkdJ Tw0KPiAoU0VSR0lPKQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAwOSwgMjAxNCA1OjU5IEFN DQo+IFRvOiBMZWV5b3VuZzsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERh bmllbGUgQ2VjY2FyZWxsaTsgDQo+IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsN Cj4gbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzogQkVM T1RUSSwgU0VSR0lPIChTRVJHSU8pOyBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUmU6 IFtBY3RuXSBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0K PiANCj4gSGkgWW91bmcsDQo+IA0KPiB0aGFua3MgYSBsb3QgZm9yIHJlcGx5ICwgcGxlYXNlIHNl ZSBpbiBsaW5lIGp1c3Qgc29tZSBmdXJ0aGVyIA0KPiBjbGFyaWZpY2F0aW9uDQo+IA0KPiBSZWdh cmRzDQo+IFNlcmdpbw0KPiANCj4gDQo+IA0KPiBGcm9tOiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlv dW5nQGh1YXdlaS5jb21dDQo+IFNlbnQ6IG1lcmNvbGVkw6wgOCBvdHRvYnJlIDIwMTQgMTc6MzUN Cj4gVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0 bkBpZXRmLm9yZz47IA0KPiBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxtYWlsdG86 ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwu Y29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1YmplY3Q6IFJFOiBkcmFmdC1jZWNj YXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KPiANCj4gSGkgU2VyZ2lvLA0K PiANCj4gVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrIG9uIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQu IFBsZWFzZSBzZWUgaW4tbGluZSANCj4gZm9yIG15IGNvbW1lbnQuDQo+IA0KPiBSZWdhcmRzLA0K PiBZb3VuZw0KPiANCj4gRnJvbTogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIA0KPiBbbWFpbHRv OnNlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDA4LCAyMDE0IDc6MzQgQU0NCj4gVG86IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5A aWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IExlZXlvdW5nOyANCj4gZGllZ29AdGlkLmVz PG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFu ZkBnbWFpbC5jb20+DQo+IENjOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IFZhcm1hLCBFdmUg TCAoRXZlKQ0KPiBTdWJqZWN0OiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4 dCBjb21tZW50cw0KPiANCj4gSGkgRGFuaWVsZSAsIFlvdW5nIGFuZCBhbGwgYXV0aG9ycywNCj4g DQo+IEkgcmVhZCB5b3UgRnJhbWV3b3JrIGRyYWZ0IGFuZCBJIGhhdmUgc29tZSBjb21tZW50cyBv biB0aGF0LiBNb3N0IGFyZSANCj4gZWRpdG9yaWFsICwgb3RoZXIgcXVlc3Rpb25zIGZvciBjbGFy aWZpY2F0aW9ucy4NCj4gDQo+IEdlbmVyYWwgcXVlc3Rpb246IGluIHRoZSBkcmFmdCB0aGUgY29u Y2VwdCBvZiBWTkMgaXMgaW4gdGhlIHZpZXcgb2YgDQo+IGhpZXJhcmNoaWNhbCBsZXZlbCBvZiBj b250cm9sbGVycyBvciBsaW5rZWQgdG8gdGhlIG11bHRpLWRvbWFpbiBhc3BlY3QgDQo+IHRoYXQg Y29tcGVsIHRvIHByb3ZpZGUgdG8gdGhlIGN1c3RvbWVyIGEgc2luZ2xlIHZpcnR1YWxpemVkIG5l dHdvcmsgDQo+IGV2ZW4gaWYgY29tcG9zZWQgYnkgcmVhbCBtdWx0aS1kb21haW4gbXVsdGktdGVj aG5vbG9neSBzdWJuZXR3b3Jrcz8gSSANCj4gbWVhbiwgdGhlIOKAnHZpcnR1YWxpemVyIGZ1bmN0 aW9u4oCdIHByb3ZpZGVkIGJ5IFZOQywgaW4gY2FzZSBvZiBhIHNpbmdsZSANCj4gZG9tYWluIGNv bnRleHQgY291bGQgYmUgaW5zaWRlIGRpcmVjdGx5IHRoZSBQTkMgLCBjb3JyZWN0Pw0KPiANCj4g WU9VTkc+PiBZZXMuIFRoYXQgaXMgdGhlIGNvcnJlY3QgdmlldyBvZiBWTkMuIEZvciBhIHNpbmds ZSBkb21haW4gDQo+IFlPVU5HPj4gY29udGV4dCwNCj4gdGhlIFZOQyBjYW4gYmUgaW50ZWdyYXRl ZCB3aXRoIFBOQy4gQnV0IHdlIG5lZWQgdG8gZmFjdG9yIGluIG90aGVyIA0KPiBzY2VuYXJpb3Mg c3VjaCBhcyAxKSBWTkMgdmVuZG9yIG1heSBiZSBkaWZmZXJlbnQgZnJvbSBQTkMgdmVuZG9yIG9y IDIpIA0KPiBWTkMgaXMgYSBzb2Z0d2FyZSBmdW5jdGlvbiB0aGF0IG9wZXJhdG9yIG1heSB3YW50 IHRvIG9wZXJhdGUgYXMgaXRzIGNvbnRyb2wuDQo+IEluIG15IG9waW5pb24sIGV2ZW4gZm9yIGEg c2luZ2xlIGRvbWFpbiwgSSB0aGluayB0aGVyZSBpcyBiZW5lZml0IHRvIA0KPiBkZWZpbmUgdGhp cyBpbnRlcmZhY2UgYXMgYSBzdGFuZGFyZCBpbnRlcmZhY2UuDQo+IA0KPiBTZWN0aW9uIDIgLCBw YWdlIDQ6DQo+IGFic3RyYWN0aW9uIGRvZXMgbm90IGltcGx5IGF1dG9tYXRpY2FsbHkgdmlydHVh bGl6YXRpb24sd2hpbGUgDQo+IHZpcnR1YWxpemF0aW9uIGltcGxpZXMgdG8gaGF2ZSBzdXJlbHkg YSBjZXJ0YWluIGZvcm0gb2YgYWJzdHJhY3Rpb24uIEkgDQo+IHdvdWxkIHN1Z2dlc3QgdG8gY29u c2lkZXIgZ29vZCBkZWZpbml0aW9uIGNvbnRhaW5lZCBpbnRvIE9ORiBTRE4gDQo+IGFyY2hpdGVj dHVyZSBkb2N1bWVudCBjaGFwdGVyIDIuMyBDb252ZW50aW9ucyBhYm91dCBhYnN0cmFjdGlvbiBh bmQgDQo+IHZpcnR1YWxpemF0aW9uLiBBIGdvb2QgZGVmaW5pdGlvbiBjYW4gaGVscCBhbGwgdGhl IHJlYWRpbmcuDQo+IA0KPiBZT1VORz4+IEFncmVlLiBXZSB3aWxsIGxvb2sgaW50byB0aGUgbWVu dGlvbmVkIGRvY3VtZW50IGlmIHRoZSB1c2FnZSANCj4gWU9VTkc+PiBvZg0KPiB0ZXJtcyBhcmUg YWxpZ25lZCB3aXRoIHRoaXMgZG9jdW1lbnQuIElmIG5vdCwgd2Ugd2lsbCBjbGFyaWZ5IHRoZSAN Cj4gdGVybWlub2xvZ3kgbW9yZSBjbGVhcmx5Lg0KPiANCj4gU2VjdGlvbiA1OiBJdCBzZWVtcyB0 byBtZSB5b3UgbWl4ZWQgaGVyZSBhc3BlY3RzIHRoYXQgYXJlIG1vcmUgcmVsYXRlZCANCj4gdG8g cG9saWN5IGxpa2UgYWRtaXNzaW9uIGNvbnRyb2wgIGFuZCBndWFyYW50ZWUgb2YgY2xpZW50IGlz b2xhdGlvbiANCj4gd2l0aCByZWFsIGNvbXB1dGF0aW9uYWwgaXNzdWUgbGlrZSBDb21wdXRpbmcg dGltZSAsIHBhdGggY29uc3RyYWlucyBvciANCj4gcmUtb3B0aW1pemF0aW9uIHByb2Nlc3MuIE1v cmVvdmVyIHRoZSB0ZXJtIFZOTSBmb3IgVmlydHVhbCBuZXR3b3JrIA0KPiBtYXBwaW5nIGlzIGEg Yml0IG1pc2xlYWRpbmcgc2luY2UgdGhpcyB0ZXJtIGluIGFscmVhZHkgdXNlZCBlLmcuIGluIA0K PiBBQk5PIGFyY2hpdGVjdHVyZSBmb3IgVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIuDQo+IA0KPiBZ T1VORz4+IEluZGVlZC4gSW4gU2VjdGlvbiA1LCB3ZSB3aWxsIHB1dCBzb21lIG5vdGVzIG9uIHRo ZSBhc3BlY3Qgb2YgDQo+IFlPVU5HPj4gcmVhbC0NCj4gdGltZSByZWxhdGVkIGZyb20gbm9uIHJl YWwgdGltZSBhc3BlY3QuIFZOTSBpcyBub3QgdG8gYmUgbWl4ZWQgd2l0aCANCj4gVmlydHVhbCBO ZXR3b3JrIE1hbmFnZXIuIEhlcmUgVk5NIGlzIGFuIGFsZ29yaXRobSB3aGljaCBpcyBrbm93biBh cyANCj4gVmlydHVhbCBOZXR3b3JrIE1hcHBpbmcgd2hpY2ggaXMgYSBzb2Z0d2FyZSBtb2R1bGUg dGhhdCBjb252ZXJ0cyANCj4gY2xpZW50IHJlcXVlc3RzIGludG8gYWN0dWFsIG5ldHdvcmtzLiBW aXJ0dWFsIE5ldHdvcmsgTWFuYWdlciBpcyBBQk5PIA0KPiBpbiBteSB1bmRlcnN0YW5kaW5nIGlz IGEgZGV2ZWxvcGVkIGNvbmNlcHQgZnJvbSBWTlRNLiBCdXQgRGFuIEtpbmcgYW5kIA0KPiBJIHdp bGwgbG9vayBhdCB0aGlzIG1vcmUgY2FyZWZ1bGx5IG9uIHRoaXMgYXNwZWN0IHdoYXQgVmlydHVh bCBOZXR3b3JrIE1hbmFnZXIgaXMgZG9pbmcuDQo+IA0KPiBTQj4+PiBJZiBJIHVuZGVyc3Rvb2Qg Zm9ybSBBZHJpYW4gYW5kIERhbmllbCBBQk5PIGRyYWZ0IHRoZSBjb25jZXB0LCANCj4gU0I+Pj4g Vk5UTSBpcyBzdHJpY3RseSByZWxhdGVkIHRvIHBsYW5uaW5nIGZ1bmN0aW9uIHNvIEkgdGhpcyBp dCBpcyANCj4gU0I+Pj4gdmVyeSBpbXBvcnQgcG9pbnQgaW4gdGhlIGNvbnRleHQgb2YgUE5DICwg SSB3b3VsZCBzYXkNCj4gDQo+IFNlY3Rpb24gNi4xIDogd2hpbGUgaXQgaXMgY2xlYXIgdGhlIHNj b3BlIG9mIHRoZSBkaWZmZXJlbnQgY29udHJvbCANCj4gaW50ZXJmYWNlIHByZXNlbnRlZCBpbiBm aWd1cmUgNSwgSeKAmW0gYSBiaXQgY29uZnVzZWQgYXMgdG8gd2hhdCBJL0YgRSANCj4gaXMg4oCT IGRhdGEgcGxhbmUgaW50ZXJmYWNlIHRvIHByb3ZpZGVyIHBoeXNpY2FsIG5ldHdvcms/IE9yIGlz IHRoZSANCj4gaW50ZW50aW9uIHRvIHByb3ZpZGUgd2hhdCBjYW4gYmUgdGhlIHVuZGVybHlpbmcg bW9kZWwgb2YgcmVzb3VyY2VzIA0KPiBhbGxvY2F0ZWQgdG8gYSBjdXN0b21lciBmcm9tIG5ldHdv cmsgcHJvdmlkZXIgY29udHJvbGxlciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwgcGh5c2ljYWwg cmVzb3VyY2VzID8NCj4gTm9yIGNsZWFyIHRvIG1lIHRoZSBpbnRlbnRpb24NCj4gDQo+IFlPVU5H Pj4gSW50ZXJmYWNlIEUgaXMgbm90IHdoYXQgQUNUTiB3aWxsIGZvY3VzIG9uLiBJdCBzaW1wbHkg c2hvd3MgIA0KPiBZT1VORz4+IGFuDQo+IHVuZGVybHlpbmcgbW9kZWwgb2YgcmVzb3VyY2VzIGFs bG9jYXRlZCB0byBhIGN1c3RvbWVyIGZyb20gbmV0d29yayANCj4gcHJvdmlkZXIgY29udHJvbGxl ciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwgcGh5c2ljYWwgcmVzb3VyY2VzLg0KPiANCj4gU0I+ Pj4gU28gaWYgSSBpbnRlcnByZXRlZCBjb3JyZWN0bHkgeW91ciBhbnN3ZXIgaXMgbW9yZSBhbiBp bnRlcm5hbCANCj4gU0I+Pj4gaW50ZXJmYWNlDQo+IHRvIFBOQyAsIHRoZSBmaWd1cmUgaXMgbWlz bGVhZGluZyBzaW5jZSBpdCBzZWVtcyBsaWtlIGEgRFAgaW50ZXJmYWNlIC4NCj4gDQo+IA0KPiBT ZWN0aW9uIDYuMSwgYWx3YXlzIGZpZ3VyZSA1OiBJZiBhIHJlcG9ydCBvZiBwb3RlbnRpYWwgTlcg dG9wb2xvZ3kgDQo+IGJldHdlZW4gYSBWTkMgYW5kIGEgQ05DIGNhbiBiZSBxdWVyaWVkICwgdGhl IGFycm93IGluIHRoZSBkcmF3biBoYXMgdG8gDQo+IGJlIGJpZGlyZWN0aW9uYWwgSSBndWVzcw0K PiANCj4gWU9VTkc+PiBZZXMsIFlvdSBhcmUgcmlnaHQuIEl0IHdpbGwgYmUgZml4ZWQuDQo+IA0K PiBGaWd1cmUgOCBTZWN0aW9uIDYuNCxwYWdlIDI4OiDigJxQQ0EgYWJzdHJhY3RzIHRoZSBwaHlz aWNhbCBuZXR3b3JrIA0KPiB0b3BvbG9neSBpbnRvIGFuIGFic3RyYWN0ZWQgdG9wb2xvZ3nigJ0g TG9va2luZyBhdCB0aGUgZGVzY3JpcHRpb24gb2YgDQo+IFZOQyBjb21wb25lbnRzIGluIDYuMi4y IGl0IGlzIHRoZSByZXNvdXJjZSBtYW5hZ2VyIGRldm90aW5nIHRvIHByb3ZpZGUgYWJzdHJhY3Qg dG9wb2xvZ3kuDQo+IERvZXMgbm90IGV4aXN0IGFueSBQQ0EgY29tcG9uZW50Lg0KPiANCj4gDQo+ IA0KPiBZT1VORz4+IFNvcnJ5IGZvciBpbmNvbnNpc3RlbmN5LiBUaGUgaW50ZW50aW9uIHdhcyB0 aGUgUENBIGlzIHRoZSBzYW1lIA0KPiBZT1VORz4+IGFzDQo+IHRoZSBSZXNvdXJjZSBNYW5hZ2Vy IGluIFZOQy4gV2lsbCBtYWtlIHRoZSB0ZXJtIGNvbnNpc3RlbnQuIEdvb2QgY2F0Y2ghDQo+IA0K PiANCj4gDQo+IEZpZ3VyZSA4IFNFY3Rpb24gNi40LCA6IEluIHRoZSBwaWN0dXJlIHRoZXJlIGlz IG5vIHBoYXNlIDcsIGFuZCB0aGVyZSANCj4gYXJlIDIgcGhhc2UNCj4gOA0KPiANCj4gWU9VTkc+ PiBUaGFua3MuIEdvb2QgY2F0Y2ghDQo+IA0KPiBQYWdlIDMwIDogSXQgaXMgSW50ZXJmYWNlIEMg bm90IEIgLCBiZXR3ZWVuIFZOQyBhbmQgUE5DDQo+IA0KPiBZT1VORz4+IElmIHlvdSBhcmUgcmVm ZXJyaW5nIHRvIFNlY3Rpb24gNy4zIHdoZXJlOg0KPiANCj4gICAgSW50ZXJmYWNlcyBzaG91bGQg YWxzbyBiZSBzY2FsYWJsZSBhcyBhIGxhcmdlIGFtb3VudCBvZiBkYXRhIG5lZWRzDQo+IA0KPiAg ICB0byBiZSB0cmFuc3BvcnRlZCBhY3Jvc3MgY3VzdG9tZXJzIHRvIHZpcnR1YWwgbmV0d29yayBj b250cm9sbGVycw0KPiANCj4gICAgYW5kIGFjcm9zcyB2aXJ0dWFsIG5ldHdvcmsgY29udHJvbGxl cnMgYW5kIHBoeXNpY2FsIG5ldHdvcmsNCj4gDQo+ICAgIGNvbnRyb2xsZXJzLg0KPiANCj4gDQo+ IA0KPiBJIHRoaW5rIHRoaXMgaW1wbGllcyBib3RoIGludGVyZmFjZXMgQiBhbmQgQyBhbHRob3Vn aCBwcmltYXJpbHkgDQo+IGJldHdlZW4gVk5DLSBQTkMuDQo+IA0KPiANCj4gDQo+IFNCPj4+IFNv cnJ5IFlvdW5nLCBpaXQgaXMgbm90IHJlZmVycmVkIHRvIDcuMyAsIGJ1dCBpbiB0aGUgY2hhcHRl ciA2LDUgDQo+IFNCPj4+ICwgb24gSW50ZXJmYWNlIGludGVyYWN0aW9uLCBhZnRlciBwb2ludCA2 LCBpcyBpbmRpY2F0ZWQgDQo+IFNCPj4+IEludGVyZmFjZSBCIGFzIGludGVyZmFjZSBiZXR3ZWVu IFZOQyBhbmQgUE5DLCBmaWd1cmUgNSBzYXlzIGl0IA0KPiBTQj4+PiBpcyBJL0YgQw0KPiANCj4g DQo+IFRoYW5rcw0KPiANCj4gU2VyZ2lvDQo+IA0KPiANCj4gVGhhbmtzDQo+IFNlcmdpbw0K From nobody Tue Oct 14 08:01: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 571201A88E7 for ; Tue, 14 Oct 2014 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 i3pPzrZWK2Ku for ; Tue, 14 Oct 2014 08:00:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0541A88F6 for ; Tue, 14 Oct 2014 08:00:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKN74869; Tue, 14 Oct 2014 15:00:55 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 16:00:53 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 08:00:49 -0700 From: Leeyoung To: Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" , Daniele Ceccarelli , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAgMyeA Date: Tue, 14 Oct 2014 15:00:49 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3DD44@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.247] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/C68gNpCJgbxrmiaMflv8F2_faoI Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 15:01:09 -0000 SGkgSWdvciwNCg0KSSBhbSBhZnJhaWQgdGhhdCB5b3UgaGF2ZSBub3QgcmVhZCB3aGF0IEkgcHV0 LiBZb3UgYXJlIG9ubHkgY29uc2lkZXJpbmcgYWJzdHJhY3QgdG9wb2xvZ3kuIFRoZSBmdW5jdGlv biBvZiBWTkMgYW5kIENOQyBhcmUgZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlciBhcyBJIGVsYWJv cmF0ZSBpbiB0aGUgcHJldmlvdXMgZW1haWwuIElmIHlvdSBjYW4gcmVhZCBtb3JlIGNhcmVmdWxs eSBvbiB0aGUgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBvZiBWTkMgaW4gdGhl IHBpY3R1cmUsIHdlIG1heSBkaXNjdXNzIG1vcmUgZnJ1aXRmdWxseS4gDQoNCkludGVyZmFjZXMg QiBhbmQgQyBhcmUgY2xlYXJseSBkaWZmZXJlbnQgaW50ZXJmYWNlcywgYnV0IHRoZXJlIGFyZSBz b21lIGZ1bmN0aW9ucyAobGlrZSBhYnN0cmFjdCB0b3BvbG9neSkgbWF5IGJlIGJhc2VkIG9uIHNh bWUgbW9kZWwgd2l0aCBkaWZmZXJlbnQgZ3JhbnVsYXJpdHksIGJ1dCB0aGF0IGlzIG9ubHkgb25l IGFzcGVjdCBvZiB0aGUgaW50ZXJmYWNlLiBXaGF0IENOQyBhbmQgVk5DIGRvIGlzIHF1aXRlIGRp ZmZlcmVudCBhcyBJIHNhaWQgYmVmb3JlIFZOQyBoYXMgdG8gY29vcmRpbmF0ZSBtdWx0aS1kb21h aW4gcm91dGluZyBjYWxjdWxhdGlvbiBhbmQgc2lnbmFsaW5nIGNvb3JkaW5hdGlvbiBvdmVyIHNl dmVyYWwgbmV0d29yayBkb21haW5zLiBDTkMgZG9lcyBub3QgZG8gdGhpcyBmdW5jdGlvbi4gDQoN ClJlZ2FyZHMsDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSWdv ciBCcnlza2luIFttYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tXSANClNlbnQ6IE1vbmRh eSwgT2N0b2JlciAxMywgMjAxNCA3OjAxIFBNDQpUbzogTGVleW91bmc7IEJFTE9UVEksIFNFUkdJ TyAoU0VSR0lPKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IGFjdG5AaWV0Zi5v cmc7IGRpZWdvQHRpZC5lczsgbHV5dWFuZkBnbWFpbC5jb20NCkNjOiBWYXJtYSwgRXZlIEwgKEV2 ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBj b21tZW50cw0KDQoNCllvdW5nLA0KDQoNCj09PaG3QWZ0ZXIgYWxsIHdlIGFyZSBhZ3JlZWluZyB3 aXRoIHRoZSBpbnRlcmZhY2VzIG9mIEFDVE4gaW50ZXJlc3QgYXJlIEludGVyZmFjZSBCIGFuZCBD LCByaWdodD8NCg0KSUKht05vLiBJIGFtIHNheWluZyB0aGF0IGludGVyZmFjZSBCIGFuZCBDIGFy ZSBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMuIEZvciBleGFtcGxlLCBvbiB0aGUgcGljdHVy ZSBOZXR3b3JrIGRvbWFpbiAxIGluIG9yZGVyIHRvIHByb3ZpZGUgdGhlIGFic3RyYWN0IHRvcG9s b2d5IHRvIHRoZSBtdWx0aS12ZW5kb3IgVk5DLCBtYXkgdXNlIGZ1bGx5IG9yIHBhcnRpYWxseSBh YnN0cmFjdCB0b3BvbG9naWVzIHByb3ZpZGVkIGJ5IG9uZSBvciBtb3JlIGxvd2VyIHRpZXIgdHJh bnNwb3J0IGRvbWFpbnMuDQpMaWtld2lzZSwgQ3VzdG9tZXIgMSBvbiB0aGUgcGljdHVyZSBtYXkg dXNlIGFuIGFic3RyYWN0IHRvcG9sb2d5IHByb3ZpZGVkIGJ5IE11bHRpLWRvbWFpbiBuZXR3b3Jr ICh0aGUgVk5DIG9uIHRoZSBwaWN0dXJlIGlzIHBhcnQgb2YpLg0KSW4gb3RoZXIgd29yZHMsIHRo ZSBzYW1lIGludGVyZmFjZSBDIGFuZCB0aGUgc2FtZSBzZXQgb2YgbW9kZWxzLCBjb3VsZCBiZSB1 c2VkICBoaWVyYXJjaGljYWxseS4gDQoNCklnb3INCg0KSUI+PiBJIGFtIHRhbGtpbmcgYWJvdXQg dGhlIGludGVyZmFjZSBiZXR3ZWVuIHRyYW5zcG9ydCBkb21haW4gc2VydmVyIGFuZCAgdHJhbnNw b3J0IGRvbWFpbiBjbGllbnQuIEkgd291bGQgYXJndWUgdGhhdCB0aGUgdmVyeSBzYW1lIGludGVy ZmFjZSBjYW4gYmUgdXNlZCBiZXR3ZWVuIGEgbXVsdGktZG9tYWluIHByb3ZpZGVyIChlLmcuIFRl bGVmb25pa2EpIGFuZCBpdHMgY2xpZW50cy4gTm90IGFsbCBzdWNoIGNsaWVudHMgYXJlIGR1bWIs IGFzIERhbmllbGUgY2xhaW1zLCBhbmQgb25seSBjYXJlIGFib3V0IKGwYSBnaXZlbiBhbW91bnQg b2YgR2JwcyBmcm9tIEEgdG8gQqGxLiBJdCBpcyBlYXN5IHRvIGVudmlzaW9uIHRoYXQgc29tZSBv ZiB0aGUgY2xpZW50cyB3b3VsZCB3YW50IGZyb20gVGVsZWZvbmljYSBhIGNvdXBsZSBvZiBTUkxH LWRpc2pvaW50IGFic3RyYWN0IGxpbmtzLCBzbyB0aGF0IHRoZSBjbGllbnRzIGNhbiBoYXZlIGEg c2F5IGluIHRoZSBwbGFjZW1lbnQgb2YgdGhlaXIgIHNlcnZpY2VzIGFjcm9zcyB0aGUgVGVsZWZv bmlrYSBuZXR3b3JrLiBUaHJlZSBwb2ludHMgaGVyZToNCg0KYSkgICAgICBUaGUgY2xpZW50IHdp bGwgYmUgYWJsZSB0byBjb25maWd1cmUgZnVsbHkgb3IgcGFydGlhbGx5IHRoZSBhYnN0cmFjdCB0 b3BvbG9neSBoZSB3YW50cyB0aGUgbmV0d29yayB0byBwcmVzZW50IHRvIGhpbTsNCg0KYikgICAg ICBUaGUgc2FpZCBhYnN0cmFjdCB0b3BvbG9neSBjb3VsZCBiZSBhcyBzaW1wbGUgKGUuZy4gYSBz aW5nbGUgYWJzdHJhY3Qgbm9kZSkgb3IgYXMgY29tcGxleCAoZS5nLiBOIGFic3RyYWN0IG5vZGVz IGludGVyY29ubmVjdGVkIGJ5IE0gYWJzdHJhY3QgbGlua3MpIGFzIHRoZSBjbGllbnQgd2FudHMg aXQgdG8gYmUgKHN1YmplY3QgdG8gdGhlIHByb3ZpZGVyoa9zIGFwcHJvdmFsKQ0KDQpjKSAgICAg IFRoZSBhYnN0cmFjdCB0b3BvbG9neSBwcmVzZW50ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0 ZWx5IGRlY291cGxlZCBmcm9tIHRoZSBwcm92aWRlcqGvcyBhY3R1YWwgdG9wb2xvZ3kuDQoNClRo ZXJlZm9yZSB0aGUgc2FtZSBpbnRlcmZhY2Uvc2V0IG9mIG1vZGVscyBjYW4gYmUgdXNlZCBiZXR3 ZWVuIGFueSB0cmFuc3BvcnQgbmV0d29yayBwcm92aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhl cm1vcmUsIHRoZSBpbnRlcmZhY2UgY2FuIGJlIHVzZWQgaW4gdGhlIGhpZXJhcmNoaWNhbCB3YXks IHRoYXQgaXMsIGEgY2xpZW50IG9mIGEgdHJhbnNwb3J0IGRvbWFpbiBjYW4gc2VydmUgaXRzIG93 biBjbGllbnRzIHVzaW5nIHRoZSBzYW1lIGludGVyZmFjZSBhcyBpdCB1c2VzIHRvIHRhbGsgdG8g aXRzIG93biBwcm92aWRlcihzKQ0KDQpIZXJlIEkgd291bGQgbGlrZSB0byBnaXZlIHlvdSBhIGxp dHRsZSBjbGVhcmVyIHBpY3R1cmUgb24gbXVsdGktZG9tYWluIGlzc3Vlcy4NCg0KICAgKy0tLS0t LS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0rDQog ICB8ICAgQ3VzdG9tZXIgMSAgIHwgICB8ICAgQ3VzdG9tZXIgMiAgfCAgLi4uIHwgQ3VzdG9tZXIg TSAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgKy0t LS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgLw0KICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgfCAgICAgICAgICAgICAv DQogICAgICAgSW50ZXJmYWNlIEIgICBcICAgICAgICAgICB8ICAgICAgICAgICAgLw0KICAgICAg ICAgICAgICAgICAgICAgIFwgICAgICAgICAgfCAgICAgICAgICAgLw0KICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwg ICBWTkMgTXVsdGktZG9tYWluICAgfCBFMkUgYWJzdHJhY3QNCiAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgQ29vcmRpbmF0aW9uICAgIHwgdG9wb2xvZ3kgY3JlYXRpb24NCiAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAg ICAgLyAgICAgICAgIHwgICAgICAgICAgICBcDQogICAgICAgIEludGVyZmFjZSBDICAgLyAgICAg ICAgICB8ICAgICAgICAgICAgIFwgIE5ldHdvcmsgVG9wb2xvZ3kNCiAgICAgICAgICAgICAgICAg ICAgIC8gICAgICAgICAgIHwgICAgICAgICAgICAgIFwgKGFic3RyYWN0KQ0KICAgICAgICAgICAg ICAgICAgICAvICAgICAgICAgICAgfCAgICAgICAgICAgICAgIFwNCiAgICstLS0tLS0tLS0tLS0t LS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsNCiAg IHwgTmV0d29yayBEb21haW4gMSB8ICAgfCBOZXR3b3JrIERvbWFpbiAyIHwgLi4gfCBOZXR3b3Jr IERvbWFpbiBOIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLS0t LSsgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgVmVuZG9yIFggICAgICAgICAgICAg ICAgIFZlbmRvciBZICAgICAgICAgICAgICAgVmVuZG9yIFoNCg0KDQpXaGF0IGlzIHNpdHRpbmcg YWJvdmUgobBWTkOhsSAodGhhdCBjb29yZGluYXRlcyBvdmVyIG11bHRpLWRvbWFpbiBjb250cm9s bGVycykgY2FuIGJlIGFuIGludGVybmFsIHNlcnZpY2Ugb3JnYW5pemF0aW9uIChvZiB0aGUgc2Ft ZSBvcGVyYXRvcikgb3Igc2VydmljZSBwcm92aWRlcnMgKGRpZmZlcmVudCBvcGVyYXRvcnMsIGZv cm1pbmcgY2FycmllcnMgb2YgY2FycmllcikuIFRoZSBjb250cm9sIGVudGl0eSBvZiB0aGVzZSBl bnRpdGllcyBpcyByZWZlcnJlZCB0byBhcyBDdXN0b21lciBOZXR3b3JrIGNvbnRyb2wgKENOQyku IFRoZSBWTkMgqENDTkMgaW50ZXJmYWNlIChJbnRlcmZhY2UgQikgaGFzIGRpZmZlcmVudCByZXF1 aXJlbWVudHMgdGhhbiB0aGUgVk5DLVBOQyBpbnRlcmZhY2UgKEludGVyZmFjZSBDKS4gVG9wb2xv Z3kgYWJzdHJhY3Rpb24gaXMganVzdCBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyBhbmQgaW4gbXVs dGktZG9tYWluIGNhc2UsIHRoZSBWTkMgaXMgcGVyZm9ybWluZyBtdWx0aS1kb21haW4gY29vcmRp bmF0aW9uIGZ1bmN0aW9uLiBWTkMgbmVlZHMgdG8gaGF2ZSBhIHN0YW5kYXJkIGludGVyZmFjZSB0 aGF0IGVuYWJsZSBjb21tdW5pY2F0aW9ucyB3aXRoIGRpZmZlcmVudCBraW5kcyBvZiBkb21haW4g bmV0d29yayBjb250cm9sL21hbmFnZW1lbnQgY29udHJvbCAod2hpY2ggaXMgcmVmZXJyZWQgdG8g YXMgUE5DLCB5b3UgY2FsbCBBTkMpLiBFYWNoIGRvbWFpbiBoYXMgaXRzIG93biB3YXlzIG9mIGNv bnRyb2xsaW5nIGl0cyBuZXR3b3JrLCB3aGljaCBBQ1ROIGlzIG5vdCB0b3VjaGluZyB0aG9zZSBh dCBhbGwuIFdoYXRldmVyIHRoZSBjaG9pY2VzIG9mIHZlbmRvciBjb250cm9sIHJlZ2ltZSB3aWxs IGNvbnRpbnVlIHRvIGJlIGVtcGxveWVkIChHTVBMUy9BU09OLCBQTk5JLCBOTVMsIE9wZW5GbG93 LCBldGMuKS4NCg0KRm9yIHRoaXMgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBh c3N1bWVkIGJ5IFZOQyBzaG91bGQgYmUgb3BlcmF0ZWQgb24gYW4gYWJzdHJhY3QgbGV2ZWwuIFdl IGRvbqGvdCB3YW50IHRvIGluamVjdCB0aGUgc2FtZSBsZXZlbCBvZiBhY3R1YWwgbmV0d29yayB0 b3BvbG9neSAoZS5nLiwgVEVEKSBhcyB0aGUgZG9tYWluIGNvbnRyb2xsZXIgb3BlcmF0ZXMgaXRz IHBoeXNpY2FsL2FjdHVhbCBuZXR3b3Jrcy4gSXMgdGhpcyBhZ3JlZWFibGU/IFlvdSBzYWlkIGFi b3ZlIHRoaXMgaW4gYykgVGhlIGFic3RyYWN0IHRvcG9sb2d5IHByZXNlbnRlZCB0byB0aGUgY2xp ZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVkIGZyb20gdGhlIHByb3ZpZGVyoa9zIGFjdHVhbCB0 b3BvbG9neS4NCg0KTm93IHRoZSBWTkMgKG11bHRpLWRvbWFpbiBjb29yZGluYXRvcikgbmVlZHMg dG8gY29vcmRpbmF0ZSBzaWduYWxpbmcgYWNyb3NzIG11bHRpLWRvbWFpbiBjb250cm9sbGVycyAo aW4gdGVybXMgb2YgdGhlIHNlcXVlbmNlIG9mIHRoZSBlbmQtdG8tZW5kIHBhdGggYWNyb3NzIG11 bHRpcGxlIGRvbWFpbnMpLiBUaGlzIGlzIGEgbmV3IGVsZW1lbnQgSSBiZWxpZXZlIEFDVE4gd2ls bCBoYXZlIHRvIGRldmVsb3AuIFRoaXMgaW50ZXJmYWNlIEMgKFZOQy1QTkMpIGlzIHZlcnkgZGlm ZmVyZW50IGZyb20gSW50ZXJmYWNlIEIgKENOQy1WTkMpLiBUaGVyZSBhcmUgb3RoZXIgZGlmZmVy ZW5jZXMgKHBsZWFzZSBzZWUgU2VjdGlvbiA2LjUgb2YgdGhlIGZyYW1ld29yayBkb2N1bWVudCku ICBCdXQgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGZyb20gYW4gYWJzdHJhY3QgdG9wb2xvZ3kgc3Rh bmRwb2ludCwgc2ltaWxhciBtb2RlbCB3b3JrcyBmb3IgSW50ZXJmYWNlcyBCIGFuZCBDIGFzIHlv dSBzYWlkICBiKSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNp bXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdCBub2RlKSBvciBhcyBjb21wbGV4IChlLmcuIE4g YWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBhYnN0cmFjdCBsaW5rcykgYXMgdGhl IGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXKhr3MgYXBwcm92 YWwpLg0KDQpCZXN0IHJlZ2FyZHMsDQpZb3VuZw0KDQoNCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4g W21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIg MTMsIDIwMTQgOToxNyBBTQ0KVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSBD ZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IExlZXlvdW5nOyBhY3RuQGlldGYub3JnOyBkaWVnb0B0 aWQuZXM7IGx1eXVhbmZAZ21haWwuY29tDQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0 OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0K SGkgU2VyZ2lvLA0KQSBjb3VwbGUgb2YgY29tbWVudHMgaW4gbGluZS4NCg0KQ2hlZXJzLA0KSWdv cg0KDQpGcm9tOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgW21haWx0bzpzZXJnaW8uYmVsb3R0 aUBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQgOTox NSBBTQ0KVG86IElnb3IgQnJ5c2tpbjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7 IExlZXlvdW5nOyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29t DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykNClN1Ympl Y3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0K DQpIaSBJZ29yLA0KDQpQbGVhc2UsIHNlZSBpbiBsaW5lDQoNClJlZ2FyZHMNClNlcmdpbw0KDQoN CkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNl bnQ6IHZlbmVyZKisIDEwIG90dG9icmUgMjAxNCAyMjozNw0KVG86IERhbmllbGUgQ2VjY2FyZWxs aTsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBhY3Ru QGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVn b0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpD YzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3Ru LWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgRGFuaWVsZSwNClBsZWFzZSwgc2VlIGlu IGxpbmUuDQpJZ29yDQoNCkZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTAsIDIwMTQg MToyNSBQTQ0KVG86IElnb3IgQnJ5c2tpbjsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVMT1RU SSwgU0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsg ZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWls dG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBS RTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkg SWdvciwNCg0KV2hhdCBkbyB5b3UgbWVhbiBieSBjbGllbnQgaGVyZT8gVGhlIG9uZSB0aGF0IGlz IHRoZSBkb2N1bWVudCBpcyBjYWxsZWQgobBzZXJ2aWNlIHByb3ZpZGVyobEgb3IgdGhlIG9uZSB0 aGF0IGlzIGNhbGxlZCChsGNsaWVudKGxID8gRnJvbSB3aGF0IHlvdSBzZW5kIEkgdGVuZCB0byB0 aGluayB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNlcnZpY2UgcHJvdmlkZXIsIGJ1dCBJIG1p Z2h0IGJlIHdyb25nLCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KSUI+PiBCeSBjbGllbnQgSSBtZWFu IHRoZSBjbGllbnQgb2YgYSB0cmFuc3BvcnQgZG9tYWluLCB0aGUgb25lIHdobyBzcGVha3MgTmV0 Y29uZi9SZXN0Y29uZiB0byB0aGUgdHJhbnNwb3J0IGRvbWFpbi4gVGhlIGd1eSB3aG8gc3BlYWtz IGZyb20gdGhlIG90aGVyIGVuZCAoaS5lLiBvbiBiZWhhbGYgb2YgdGhlIHRyYW5zcG9ydCBzZXJ2 aWNlIHByb3ZpZGVyKSAgaXMgdGhlIHRyYW5zcG9ydCBkb21haW6hr3MgSHlwZXJ2aXNvci4NCg0K U0I+Pj4gSXQgaXMgY2xlYXIgd2hhdCB5b3UgaW50ZW5kIGhlcmUsIGV2ZW4gaWYgd29yZCBjbGll bnQgaXQgc2VlbXMgdG8gbWUgbW9yZSByZWxhdGVkIHRvIGFwcGxpY2F0aW9uIHRoYW4gdG8gYSBz ZXJ2aWNlIHByb3ZpZGVyLg0KDQpJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNl IGJldHdlZW4gdHJhbnNwb3J0IGRvbWFpbiBzZXJ2ZXIgYW5kICB0cmFuc3BvcnQgZG9tYWluIGNs aWVudC4gSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSB2ZXJ5IHNhbWUgaW50ZXJmYWNlIGNhbiBiZSB1 c2VkIGJldHdlZW4gYSBtdWx0aS1kb21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkgYW5k IGl0cyBjbGllbnRzLiBOb3QgYWxsIHN1Y2ggY2xpZW50cyBhcmUgZHVtYiwgYXMgRGFuaWVsZSBj bGFpbXMsIGFuZCBvbmx5IGNhcmUgYWJvdXQgobBhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20g QSB0byBCobEuIEl0IGlzIGVhc3kgdG8gZW52aXNpb24gdGhhdCBzb21lIG9mIHRoZSBjbGllbnRz IHdvdWxkIHdhbnQgZnJvbSBUZWxlZm9uaWNhIGEgY291cGxlIG9mIFNSTEctZGlzam9pbnQgYWJz dHJhY3QgbGlua3MsIHNvIHRoYXQgdGhlIGNsaWVudHMgY2FuIGhhdmUgYSBzYXkgaW4gdGhlIHBs YWNlbWVudCBvZiB0aGVpciAgc2VydmljZXMgYWNyb3NzIHRoZSBUZWxlZm9uaWthIG5ldHdvcmsu IFRocmVlIHBvaW50cyBoZXJlOg0KDQphKSAgICAgIFRoZSBjbGllbnQgd2lsbCBiZSBhYmxlIHRv IGNvbmZpZ3VyZSBmdWxseSBvciBwYXJ0aWFsbHkgdGhlIGFic3RyYWN0IHRvcG9sb2d5IGhlIHdh bnRzIHRoZSBuZXR3b3JrIHRvIHByZXNlbnQgdG8gaGltOw0KDQpiKSAgICAgIFRoZSBzYWlkIGFi c3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFj dCBub2RlKSBvciBhcyBjb21wbGV4IChlLmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0 ZWQgYnkgTSBhYnN0cmFjdCBsaW5rcykgYXMgdGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3Vi amVjdCB0byB0aGUgcHJvdmlkZXKhr3MgYXBwcm92YWwpDQoNCmMpICAgICAgVGhlIGFic3RyYWN0 IHRvcG9sb2d5IHByZXNlbnRlZCB0byB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVk IGZyb20gdGhlIHByb3ZpZGVyoa9zIGFjdHVhbCB0b3BvbG9neS4NCg0KVGhlcmVmb3JlIHRoZSBz YW1lIGludGVyZmFjZS9zZXQgb2YgbW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55IHRyYW5z cG9ydCBuZXR3b3JrIHByb3ZpZGVyIGFuZCBpdHMgY2xpZW50LiBGdXJ0aGVybW9yZSwgdGhlIGlu dGVyZmFjZSBjYW4gYmUgdXNlZCBpbiB0aGUgaGllcmFyY2hpY2FsIHdheSwgdGhhdCBpcywgYSBj bGllbnQgb2YgYSB0cmFuc3BvcnQgZG9tYWluIGNhbiBzZXJ2ZSBpdHMgb3duIGNsaWVudHMgdXNp bmcgdGhlIHNhbWUgaW50ZXJmYWNlIGFzIGl0IHVzZXMgdG8gdGFsayB0byBpdHMgb3duIHByb3Zp ZGVyKHMpDQoNCk1vcmVvdmVyIEkgd291bGQgYXZvaWQgaW4gdGhpcyBwaGFzZSB0byBtZW50aW9u IGFueSByZWZlcmVuY2UgdG8gcHJvdG9jb2wgaW1wbGVtZW50YXRpb24gKGUuZy4gTmV0Y29uZi9S ZXN0Y29uZikgOiBJIHRoaW5rIHdlIGFyZSBpbiB0aGUgcGhhc2UgdG8gdW5kZXJzdGFuZCBhcmNo aXRlY3R1cmUsIHdoYXQgYXJlIHRoZSByZWxldmFudCBpbnRlcmZhY2VzLCBhbmQgd2hhdCBpbmZv cm1hdGlvbiBpcyBleGNoYW5nZWQgb3ZlciB0aGUgcmVmZXJlbmNlIHBvaW50cy9pbnRlcmZhY2Vz LiBJIGd1ZXNzIHRoaXMgaXMgY2xlYXJseSBzdGF0ZWQgYWxzbyBpbiB0aGUgY2hhcnRlciBvZiBC b0YuDQoNCklCPj4gQWdyZWUuIEkgdXNlZCBOZXRjb25mL1Jlc3Rjb25mIGFzIGFuIGV4YW1wbGUg dG8gbWFrZSBpdCBjbGVhciB3aGF0IGludGVyZmFjZSBJIHdhcyB0YWxraW5nIGFib3V0Lg0KDQog QXQgYW4gYXBwcm9wcmlhdGUgdGltZSCoQyBjZXJ0YWlubHkgbm90IG5vdyCoQyB0aGUgbmV4dCBz dGVwIGlzIHRvIGNoZWNrIHdpdGggb3RoZXIgU0RPcyBvbiB0aGUgYXZhaWxhYmlsaXR5IG9mIHJl bGV2YW50IGNvcmUvdGVjaG5vbG9neSBzcGVjaWZpYy9hcHBsaWNhdGlvbiBzcGVjaWZpYyBpbmZv cm1hdGlvbiBtb2RlbCChsGZyYWdtZW50c6GxLCBhbmQgdGhlbiBmaW5hbGx5IHByb2NlZWQgb24g dGhlIHBhdGggb2YgcHJ1bmluZy9yZWZhY3RvcmluZyBhbmQgbWFwcGluZyB0byBSRVNUL0pTT04s IE5ldGNvbmYvWUFORywgYW5kIGFueSBvdGhlciBwb3NzaWJsZSBkYXRhIG1vZGVsaW5nIGFuZCBj b25maWd1cmF0aW9uIHByb3RvY29sIGV4aXN0aW5nLiBUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcg IG9mIHRoZSBCb0Ygc2NvcGUgLg0KDQpJIGRvbqGvdCB0aGluayB0aGUgY2xpZW50IG9mIHRoZSBt dWx0aS1kb21haW4gbmV0d29yayB3YW50cyB0byBoYXZlIGEgc28gZGV0YWlsZWQgdmlldyBvZiB0 aGUgbmV0d29yaywgaGUgZG9lcyBub3QgY2FyZSBhYm91dCBkb21haW5zLCBpbnRlciBkb21haW4g bGlua3Mgb3Igd2hhdGV2ZXIsIEkgd291bGQgc2F5IGhlIG9ubHkgY2FyZXMgYWJvdXQgYSBnaXZl biBhbW91bnQgb2YgR2JwcyBmcm9tIEEgdG8gQiB3aXRoIGEgZ2l2ZW4gbWF4IGRlbGF5IGFuZCBw cm9iYWJseSBzb21lIGRpdmVyc2l0eSBwYXJhbWV0ZXJzLg0KDQpJQj4+IEFnYWluLCBieSBjbGll bnQgSSBtZWFuIG11bHRpLWRvbWFpbiBuZXR3b3JrIGNvbnRyb2xsZXIgKGUuZy4gVGVsZWZvbmlj YSBTRE4gY29udHJvbGxlciksIG5vdCB0aGUgY2xpZW50IHVzaW5nIHNlcnZpY2VzIG9mIHRoZSBt dWx0aS1kb21haW4gbmV0d29yayAoaS5lLiBub3QgdGhlIFRlbGVmb25pY2EgY2xpZW50cykuIFN1 Y2ggY2xpZW50IHVzZXMgIHRoZSB0cmFuc3BvcnQgZG9tYWlucyBmb3IgYSByZWFzb24uIKGwYSBn aXZlbiBhbW91bnQgb2YgR2JwcyBmcm9tIEEgdG8gQqGxIGlzIHRvbyBsb29zZSBhbmQgbGl0dGxl IGZvciB0aGUgY2xpZW50IHRvIGRvIHRoZSBuZXR3b3JrIHBsYW5uaW5nLiBJTU8gdGhlIGNsaWVu dCBuZWVkcyB0byAqcGxhbiogdGhlIGFic3RyYWN0IHRvcG9sb2dpZXMgcHJvdmlkZWQgYnkgdGhl IHRyYW5zcG9ydCBkb21haW5zIHRoZSBzYW1lIG9yIHNpbWlsYXIgd2F5IGFzIGhlIHdvdWxkIHBs YW4gaGlzIG93biBhY3R1YWwgdG9wb2xvZ3kuDQoNClNCPj4+IHllcywgc3VyZSwgaW4geW91IHZp ZXcgb2YgobBjbGllbnShsSAsIHRoaXMgaXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIgRGFuaWVsZSBp cyB0YWxraW5nLCBzbyBhbiBhYnN0cmFjdCB2aWV3IG9mIHdoYXQgaXMgdGhlIHJlYWwgdHJhbnNw b3J0IG5ldHdvcmsgaXMgY29uc2lkZXJlZCBhdCB0aGlzIGxldmVsLiBBcyBJIHNhaWQgdG8gWW91 bmcsIGluIG15IHByZXZpb3VzIG1haWwsIGluIHRoZSBjYXNlIG9mIGEgc2luZ2xlIGRvbWFpbiBz Y2VuYXJpbyBWTkMgYW5kIFBOQyBjb3VsZCBhbHNvIGNvaW5jaWRlIGJ1dCBpbiBjYXNlIG9mIGEg bXVsdGktZG9tYWluIHNjZW5hcmlvcyB0aGUgc2NvcGUgaXMgdG8gcHJvdmlkZSB0byBhcHBsaWNh dGlvbiBsYXllciBhIHNpbmdsZSB2aXJ0dWFsaXplZCB2aWV3IG9mIHRoZSB1bmRlcmxpbmUgbXVs dGkgZG9tYWluIG5ldHdvcmsuDQoNCk9uIHRoZSBvdGhlciBzaWRlLCB0aGUgb25lIHRoYXQgY2Fy ZXMgYWJvdXQgYWxsIG9mIHRoZSBpc3N1ZXMgeW91IGxpc3RlZCBpcyB0aGUgc2VydmljZSBwcm92 aWRlciAoYXMgcGVyIGFjdHVhbCBkb2N1bWVudCB0ZXJtaW5vbG9neSkuIEhvd2V2ZXIgYWxzbyB0 aGUgc2VydmljZSBwcm92aWRlciBkb2VzIG5vdCBnbyBpbnRvIHBoeXNpY2FsIGltcGFpcm1lbnQg ZGV0YWlscy4gSGUgY2FyZXMgYWJvdXQgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhlIGJvcmRlcnMg b2YgdGhlIGRvbWFpbnMsIGludGVyIGRvbWFpbiBsaW5rcy4gSG93IHN1Y2ggY29ubmVjdGl2aXR5 IGlzIHByb3Zpc2lvbmVkL21hbmFnZWQgaXMgdGhlIG5ldHdvcmsgcHJvdmlkZXIgYnVzaW5lc3Mu IFRoZSBuZXR3b3JrIHByb3ZpZGVzIG1pZ2h0IGJlIHVzaW5nIEdNUExTLCBOTVMgYW5kIE9ORiBj b250cm9sbGVyIHdpdGggT3BlbiBGbG93IG9yIHdoYXRldmVyIHRvIGNvbnRyb2wgdGhlIG5ldHdv cmsuIE1heWJlIGNhbGxpbmcgaXQgUE5DIGlzIGNvbmZ1c2luZz8gVGhlIFBOQyBjYW4gYmUgYW55 IG9mIHRoZSB0aGluZ3MgSaGvdmUgbGlzdGVkIGFuZCBtdWNoIG1vcmUuDQoNCklCPj4gSW4gdGhp cyBjYXNlIG15IGNsaWVudCBpcyB5b3VyIHNlcnZpY2UgcHJvdmlkZXIgOz0pLiBZb3UgYXJjaGl0 ZWN0dXJhbGx5IHNlcGFyYXRlIGNsaWVudCBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLCBiZWNh dXNlIHlvdSBwcm9iYWJseSBiZWxpZXZlIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gc3RhbmRhcmRp emUgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSB0d28uIEkgZGlzYWdyZWUgd2l0aCB0aGF0IGFu ZCBkb26hr3QgdGhpbmsgQUNUTiBzaG91bGQgd29yayBvbiB0aGlzLiBJbiB0aGUgY29udGV4dCBv ZiBBQ1ROIEkgc2VlIG9ubHkgdHdvIGNvbnN0cnVjdHM6IFRyYW5zcG9ydCBkb21haW4gY29udHJv bGxlciAodHJhbnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpIGFuZCAgVHJhbnNwb3J0IGNsaWVudCBj b250cm9sbGVyICh0cmFuc3BvcnQgc2VydmljZSB1c2VyKS4NCg0KU0I+Pj4gQUNUTiBoZXJlIGlz IG5vdCByZWludmVudGluZyB0aGUgd2hlZWwgLCBpbiBvdGhlciBTRE8gU0ROIHNwZWNpZmljIGlz IGNvbnNpZGVyZWQgIHRoZSBhcHBsaWNhdGlvbiBsYXllciAsIGFuZCB0aGUgaW50ZXJmYWNlIGJl dHdlZW4gQUwgYW5kIFNETiBjb250cm9sbGVyIChpbiB0aGlzIGNhc2UgdGhlIFZOQyBvZiBBQ1RO KSAuIFRoaXMgaW50ZXJmYWNlIHBlcm1pdCB0byBhbnkgY2xpZW50IHRvIGRpcmVjdGx5IGltcGFj dCB0byBoaXMgb3duIHNlcnZpY2VzIGFuZCBoaXMgb3duIKGwdmlydHVhbGl6ZWShsSByZXNvdXJj ZXMgLg0KDQoNCkhlbmNlIHRoZSBpbnRlcmZhY2VzIHRvIGJlIGNvbnNpZGVyZWQgYXJlIHR3bywg bm90IHRocmVlIChhcyBEYW4gc2FpZCkgSSB0aGluayB0aGlzIHJlcGxpZXMgdG8gcXVlc3Rpb25z IDEgYW5kIDMuIEp1c3QgdG8gYWRkIHNvbWV0aGluZyByZWdhcmRpbmcgMiwgSSB3b3VsZCBzYXkg dGhhdCB0aGV5IG5lZWQganVzdCBhIHNpbmdsZSBlbnRyeSBwb2ludCB0byB0aGUgbmV0d29yayBj b250cm9sIChjb3VsZCBiZSBhIHNtYWxsIHBpZWNlIG9mIGNvZGUgcnVubmluZyBvbiB0b3Agb2Yg dGhlIFBDRSBvZiB5b3VyIEdNUExTIGRvbWFpbiksIHdoaWNoIGFjdHMgYXMgYW4gaW50ZXJmYWNl IGJldHdlZW4gdGhlIFZOQyBhbmQgdGhlIGNvbnRyb2wgcGxhbmUgb2YgeW91ciBuZXR3b3JrIGFu ZCBwZXJmb3JtczogobAtIE1hcHBpbmcgb2YgcGh5c2ljYWwgYW5kIHZpcnR1YWwgcmVzb3VyY2Vz obEgYW5kICChsFJlcXVlc3RzOiBwYXRoLCBwcm92aXNpb24sIG1vZGlmeSBhbmQgcmVzdG9yZaGx Lg0KDQpJQj4+IEFzIEkgc2FpZCwgdGhpcyBpcyB0aGUgdGFzayBvZiB0aGUgdHJhbnNwb3J0IGRv bWFpbiBIeXBlcnZpc29yLCB3aG9zZSByb2xlIGlzLCBlc3NlbnRpYWxseSwgdG8gdHJhbnNsYXRl IGJhY2sgYW5kIGZvcnRoIGFic3RyYWN0IDw9PiBhY3R1YWwgdG9wb2xvZ3kgZWxlbWVudHMgYW5k IHNlcnZpY2UgcmVxdWVzdHMvcmVzcG9uc2VzIGNvbnRhaW5pbmcgdGhlIGFic3RyYWN0L2FjdHVh bCB0b3BvbG9neSBwYXRocy4gSSB0aGluayB0aGF0IHRoZSBub3J0aC9zb3V0aCBpbnRlcmZhY2Ug YmV0d2VlbiB0aGUgdHJhbnNwb3J0IGRvbWFpbiBIeXBlcnZpc29yIGFuZCB0aGUgZW50aXR5IHJl cHJlc2VudGluZyB0aGUgY2xpZW50IG9mIHRoZSB0cmFuc3BvcnQgZG9tYWluIChubyBtYXR0ZXIg aG93IHlvdSBjYWxsIGl0KSBpcyB0aGUgb25seSBpbnRlcmZhY2UgQUNUTiBjYW4gd29yayBvbiB3 aXRoIHRoZSBob3BlIHRvIHByb2R1Y2Ugc29tZXRoaW5nIHVzZWZ1bC4NCg0KQ2hlZXJzDQpEYW5p ZWxlDQoNCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNh bC5jb21dDQpTZW50OiB2ZW5lcmSorCAxMCBvdHRvYnJlIDIwMTQgMDM6MTYNClRvOiBLaW5nLCBE YW5pZWw7IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8 bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxt YWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21h aWwuY29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2Nh cmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCllvdW5nIGFuZCBEYW4sDQoN Ckl0IGRvZXMgbm90IG1hdHRlciBob3cgeW91IGNhbGwgbWUsIGFuZCBhcyBKb2huIGlzIGhlbHBm dWxseSBhcHBseWluZywgeW91IGNhbiBpZ25vcmUgd2hhdCBJIGFtIHNheWluZy4gQnV0IGxldCBt ZSBleHBsYWluIGluIHNvbWUgbW9yZSBkZXRhaWxzIHdoYXQgSSBtZWFudC4NCg0KU3VwcG9zZSB3 ZSBoYXZlIGEgY2xpZW50IChzdWNoIGFzIFRGSykgb2YgYSBtdWx0aS1kb21haW4gdHJhbnNwb3J0 IG5ldHdvcmssIHdobyB3YW50cyB0byBwcm92aXNpb24gYW5kIG1hbmlwdWxhdGUgZTJlIHRyYW5z cG9ydCBzZXJ2aWNlcyB0aGUgd2F5IGhlIHdhbnRzIGl0IChpLmUuIGFwcGx5aW5nIGhpcyBwb2xp Y2llcykuIFdoYXQgd291bGQgc3VjaCBjbGllbnQgbmVlZD8NCg0KDQoxLiAgICAgQW4gYWNjZXNz IHRvIGEgdW5pZmllZCBuZXR3b3JrIFRFIHRvcG9sb2d5IHRoYXQgY291bGQgYmUgdW5kZXJzdG9v ZCBhbmQgdXNlZCBieSB0aGUgY2xpZW50oa9zIHBhdGggY29tcHV0ZXIgdG8gc2VsZWN0IHNlcnZp Y2UgZTJlIHBhdGhzLiBIb3cgZG9lcyB0aGUgY2xpZW50IGdldCBzdWNoIGEgdG9wb2xvZ3k/IFRo ZSBuZWNlc3Nhcnkgb3ZlcmxheSB0b3BvbG9neSBjb21wcmlzZXMgYWJzdHJhY3QgdG9wb2xvZ2ll cyBwcmVzZW50ZWQgZm9yIHRoZSBjbGllbnQgYnkgZWFjaCBvZiB0aGUgdHJhbnNwb3J0IGRvbWFp bnMgKyBpbnRlci1kb21haW4gVEUgbGlua3MuIEhlbmNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGlu dGVyZmFjZSAjMSAoYW5kIGRhdGEgbW9kZWwgIzEpIGJldHdlZW4gYSBwcm92aWRlciBoeXBlcnZp c29yL1ZOQyBhbmQgdGhlIGNsaWVudCBjb250cm9sbGVyIHRvIGV4cG9zZSBpbiBhIHVuaWZpZWQg YWJzdHJhY3QgIHdheSAgaXRzIHRvcG9sb2d5IG9uIHBlciBjbGllbnQvdGVuYW50IGJhc2lzLiBG dXJ0aGVybW9yZSwgdGhlIGNsaWVudCBjb250cm9sbGVyIGNhbiB1c2UgdGhpcyBpbnRlcmZhY2Ug aW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiB0byBtb2RpZnkgdGhlIHNhaWQgYWJzdHJhY3QgdG9w b2xvZ3kgKHN1YmplY3QgdG8gdGhlIHByb3ZpZGVyoa9zICBhcHByb3ZhbCksIGJlY2F1c2UgdGhl IGNsaWVudCBpcyB0aGUgb25seSBndXkgd2hvIGtub3dzIGhvdyB0aGUgYWJzdHJhY3QgdG9wb2xv Z3kgZXhwb3NlZCB0byBoaW0gc2hvdWxkIGxvb2sgbGlrZSB0byBiZSB1c2VmdWwgKGUuZy4gd2hp Y2ggYW5kIGhvdyB0aGUgYWJzdHJhY3QgbGlua3Mgc2hvdWxkIGJlIGRpc2pvaW50IGZyb20gZWFj aCBvdGhlciwgaG93IG1hbnkgb2YgdGhlbSBzaG91bGQgYmUgcHJvdmlkZWQsIHRoZWlyIGF0dHJp YnV0ZXMsIGRlc2lyZWQgcmVjb3ZlcnkgY2FwYWJpbGl0aWVzLCBldGMsKS4gVGhpcyBrbm93bGVk Z2UgaXMgc3VwcG9zZWQgdG8gY29tZSBmcm9tIHRoZSBjbGllbnShr3MgbmV0d29yayBwbGFubmlu Zy4NCg0KMi4gICAgIEEgd2F5IHRvIHByb3Zpc2lvbi9tb2RpZnkvZGVsZXRlIGUyZSBzZXJ2aWNl cyB3aXRoIHRoZSB1c2Ugb2Ygc28gY29tcHV0ZWQgZTJlIHBhdGhzLiBUaGUgY2xpZW50oa9zIGNv bnRyb2xsZXIgZG9lcyB0aGF0IGJ5IGNob3BwaW5nIHRoZSBwYXRocyBpbnRvIHBlci1kb21haW4g c2VnbWVudHMgYW5kIGluc3RydWN0cyByZXNwZWN0aXZlIGRvbWFpbiBWTkNzL0h5cGVydmlzb3Jz IHRvIHNldCB1cC9tYW5pcHVsYXRlIHNlcnZpY2UgcmVzcGVjdGl2ZSBjb25uZWN0aW9uIHNlZ21l bnRzLiBIZW5jZSB3ZSBhcmUgdGFsa2luZyBhYm91dCBpbnRlcmZhY2UgIzIgKGRhdGEgbW9kZWwg IzIpIGZvciB0aGUgc2VydmljZSBzZWdtZW50IG1hbmlwdWxhdGlvbjsNCg0KMy4gICAgIEEgd2F5 IHRvIG1vbml0b3IsIHRyb3VibGVzaG9vdCwgY2Fycnkgb3V0IG1haW50ZW5hbmNlIG9mIHRoZSBh Y3RpdmUgZTJlIHNlcnZpY2VzLiBUaGlzIHdvdWxkIHJlcXVpcmUgaW50ZXJmYWNlICMzIChkYXRh IG1vZGVsICMzKSBiZXR3ZWVuIHRoZSBjbGllbnShr3MgY29udHJvbGxlciBhbmQgZG9tYWlucyBW TkNzL0h5cGVydmlzb3JzIGZvciB0aGlzIHB1cnBvc2UuDQoNClNvLCB3ZSBhcmUgdGFsa2luZyAz IFlhbmcgbW9kZWxzIHdpdGggcmVxdWlyZWQgbW9kaWZpY2F0aW9ucyB0byBuZWl0aGVyIE5ldGNv bmYvUmVzdGNvbmYsIG5vciAgVG8gYW55IG90aGVyIG1hbmFnZW1lbnQsIHJvdXRpbmcgb3Igc2ln bmFsaW5nIHByb3RvY29sLg0KDQpOb3cgSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9ucyB0byB5 b3U6DQoNCjEuICAgICBJbiB0aGlzIGV4YW1wbGUsIHdoYXQgZWxzZSAoaW4gYWRkaXRpb24gdG8g dGhlc2UgdGhyZWUgbW9kZWxzKSB0aGUgY2xpZW50IHN1Y2ggYXMgVEZLIGluIHlvdXIgb3Bpbmlv biB3b3VsZCBuZWVkPw0KDQoyLiAgICAgV2hhdCBlbHNlIHRoZSBuZXR3b3JrIHByb3ZpZGVycyBh bmQgdGhlaXIgdmVuZG9ycyBzdWNoIGFzIEFEVkEgb3IgQ0lFTiB3b3VsZCBuZWVkPw0KDQozLiAg ICAgV2hhdCBpcyB0aGUgaW1wb3J0YW5jZSBvZiBhIGNvbnN0cnVjdCBzdWNoIGFzIFBOQz8NCg0K DQpNeSBhbnN3ZXIgdG8gMy4gobBJcyBub3QgaW1wb3J0YW50IGF0IGFsbCwgaXJyZWxldmFudKGx IGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQoNCmEpICAgICBXaGF0IGhhcHBlbnMgYmV5b25k IHRoZSBWTkMvSHlwZXJ2aXNvciBpbiB0aGUgcHJvdmlkZXIgbmV0d29yayBpcyBjb21wbGV0ZWx5 IHByb3ByaWV0YXJ5Lg0KDQpiKSAgICAgVGhlcmUgY291bGQgYmUgbnVtZXJvdXMgd2F5cyBhcyB0 byBob3cgdGhlIHByb3ZpZGVyIG5ldHdvcmsgaXMgbWFuYWdlZC4gRXhhbXBsZXM6IGNlbnRyYWxp emVkIFBOQyAoYXMgeW91IGNhbGwgaXQpLCBBRFZBIHN0eWxlIEdNUExTIGJhc2VkIG5ldHdvcmsg aW50ZWxsaWdlbmNlLCBDSUVOIHN0eWxlIFBOTkkgYmFzZWQgY29udHJvbCBwbGFuZSwgZXRjLiBX aHkgaXMgdGhhdCBvZiBBQ1ROoa9zIGJ1c2luZXNzPw0KDQpDaGVlcnMsDQpJZ29yDQoNCkZyb206 IEtpbmcsIERhbmllbCBbbWFpbHRvOmQua2luZ0BsYW5jYXN0ZXIuYWMudWtdDQpTZW50OiBUaHVy c2RheSwgT2N0b2JlciAwOSwgMjAxNCA0OjU4IFBNDQpUbzogTGVleW91bmc7IElnb3IgQnJ5c2tp bjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGll dGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRp ZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNjOiBW YXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJh bWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBBbGwsIGluY2x1ZGluZyChsElnbm9yobEgOy0p DQoNClR5cGljYWwgZGljaG90b215IGJldHdlZW4gd2hhdCBvcGVyYXRvcnMgd2FudCBhbmQgd2hh dCB2ZW5kb3JzIGFyZSBhY3R1YWxseSB3aWxsaW5nIHRvIHByb3ZpZGUsIGdyb3VwIGNvbnNlbnN1 cyB3aWxsIGV2ZW50dWFsbHkgaGVscCByZXNvbHZlIHRoYXQuIEVpdGhlciB3YXksIHRoZSBsYXRl c3QgdmVyc2lvbiBvZiB0aGUgRnJhbWV3b3JrIEktRCBpcyB0cnlpbmcgdG8gZm9jdXMgQUNUTiBk aXNjdXNzaW9uIGFuZCBzY29wZSAoaS5lLiwgdGhlIHByb3RvY29sIHdvcmspIG9uIHRoZSBpbnRl cmZhY2VzIHdoaWNoIGFyZSBpbiBzY29wZSwgbmFtZWx5Og0KDQoxLiBUaGUgQ05DLVZOQyBJbnRl cmZhY2UgKENWSSkNCi0gQ3JlYXRlLCBtb2RpZnkgYW5kIGRlbGV0ZSB2aXJ0dWFsIG5ldHdvcmsg c2VydmljZSBpbnN0YW5jZXMNCi0gUmVzb3VyY2UgbW9kZWwNCg0KMi4gVGhlIFZOQy1QTkMgSW50 ZXJmYWNlIChWUEkpDQotIE1hcHBpbmcgb2YgcGh5c2ljYWwgYW5kIHZpcnR1YWwgcmVzb3VyY2Vz DQotIFJlcXVlc3RzOiBwYXRoLCBwcm92aXNpb24sIG1vZGlmeSBhbmQgcmVzdG9yZQ0KDQpBcyBZ b3VuZyBzdWdnZXN0cywgaWYgdGhlIFZOQyByZWNlaXZlZCBwaHlzaWNhbCB0b3BvbG9neSBpbmZv IGl0IHdvdWxkIGJlIHBlcmZvcm1pbmcgdGhlIHJvbGUgb2YgdGhlIFBoeXNpY2FsIE5ldHdvcmsg Q29udHJvbGxlciAoUE5DKSwgd2hpY2ggaXMgb2J2aW91c2x5IGEgKHNvbWVob3cpIHJlcXVpcmVk IGZ1bmN0aW9uLCBidXQgdGhlIGludGVyZmFjZSAoZGlyZWN0IHByb3Zpc2lvbmluZyBvZiB0aGUg YWN0dWFsIHBoeXNpY2FsIG5ldHdvcmspIGlzIG91dCBvZiBzY29wZSBmb3IgQUNUTi4NCg0KQnIs IERhbi4NCg0KRnJvbTogQUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIExlZXlvdW5nDQpTZW50OiAwOSBPY3RvYmVyIDIwMTQgMjE6MzINClRvOiBJZ29yIEJy eXNraW47IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0 bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVn b0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpD YzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSZTogW0FjdG5dIGRyYWZ0LWNlY2NhcmVs bGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIElnbm9yLA0KDQpUaGFuayB5 b3UgZm9yIHByb3ZpZGluZyB5b3VyIGNvbW1lbnQgdGhhdCBwYXVzZXMgdXMgdG8gdGhpbmsgbW9y ZSBhbmQgdW5kZXJzdGFuZCBvbiB0aGUgc2FtZSBsZXZlbC4gSSB0aGluayB5b3VyIGNvbW1lbnQg d2lsbCBjb250cmlidXRlIHRvIGNyeXN0YWxsaXplIHRoZSBzY29wZSBvZiB3b3JrIGhlcmUuDQoN CkZpcnN0IG9mIGFsbCwgSSB0aGluayB0aGVyZSB3YXMgYSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUu IEZpcnN0LCB5b3VyIGFzc3VtcHRpb24gb24gVk5DIHJlY2VpdmluZyBhY3R1YWwgdW5kZXJseWlu ZyB0b3BvbG9neSBpcyBpbmNvcnJlY3QuIElmIFZOQyB3ZXJlIHRvIGhhdmUgYWN0dWFsbHkgdG9w b2xvZ3kgKGUuZy4gVEVEKSBvZiBhIG5ldHdvcmssIHRoaXMgd291bGQgYmUgY2FsbGVkIGEgUE5D IGFuZCB0aGlzIGlzIG91dCBvZiBzY29wZSBvZiBBQ1ROLiBUaGlzIGFzcGVjdCBoYXMgYmVlbiBk aXNjdXNzZWQgYnkgZW1haWwgdGhyZWFkcyBEYW5pZWxlIHN0YXJ0ZWQgYSBmZXcgd2Vla3MgYWdv LiBDaGVjayB0aGUgYXJjaGl2ZSBvbiB0aGF0LiBUaGUgcmVhc29uIHRoaXMgaXMgb3V0IG9mIHNj b3BlIGlzIHRoYXQgUE5DIG11bHRpLWRvbWFpbiBpc3N1ZSBpcyBubyBkaWZmZXJlbnQgZnJvbSB0 b2RheaGvcyBHTVBMUy9QQ0UgaXNzdWUsIGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgSC1QQ0UuIEFD VE4gZG9lcyBub3Qgc3RlcCBvbiB0aG9zZSBhcmVhcy4gV2hhdCBWTkMgcmVjZWl2ZXMgZnJvbSBl YWNoIFBOQyAoZG9tYWluIGNvbnRyb2xsZXIpIGlzIGFuIGFic3RyYWN0ZWQgdG9wb2xvZ3kgd2l0 aCB2YXJ5aW5nIGRlZ3JlZXMgZnJvbSBhY3R1YWwgdW5kZXJseWluZyB0b3BvbG9neS4gVGhlIHJl YXNvbiB3aHkgd2UgZGlzdGluZ3Vpc2ggdGhlIHRlcm0gVk5DIGZyb20gUE5DLg0KDQpXaGF0IGNh biBiZSBkZWZpbmVkIG9uIFZOQy1QTkMgaXMgYSB2ZXJ0aWNhbCBzaWduYWxpbmcgY29vcmRpbmF0 aW9uIGZyb20gVk5DIHRvIGVhY2ggUE5DLiBBcyBsb25nIGFzIHRoZSBkZXRhaWxlZCBwYXRoIGNv bXB1dGF0aW9uIGFuZCBzaWduYWxpbmcgd2l0aGluIGEgZG9tYWluIGFyZSBjb21wbGV0ZWx5IHVw IHRvIHRoZSBkb21haW4gUE5DLiBWTkMgaXMgbm90IHRvIGJlIG9wZXJhdGVkIG9uIHRoZSBzYW1l IGxldmVsIGFzIFBOQy4gSXRzIGVuZC10by1lbmQgcGF0aCBjb21wdXRhdGlvbiBpcyBiYXNlZCBv biB3aGF0IGlzIGV4cG9zZWQgZnJvbSBQTkNzIHRvIFZOQy4gVGhlIGFjdHVhbCB0b3BvbG9neSBp bmZvcm1hdGlvbiBkZXRhaWxzIGlzIGtlcHQgYnkgUE5DcyBhbmQgdGhlIFBOQ3MgZXhwb3NlIGFi c3RyYWN0ZWQgdG9wb2xvZ3kgdGhhdCBjYW4gaGlkZSB0aGUgZXhhY3QgZGV0YWlscyB3aGlsZSBl eHBvc2luZyBhIG1pbmltdW0gbGV2ZWwgb2YgY29uc3RyYWludHMuIEZvciBpbnN0YW5jZSwgdGhl IFNSTEcgb2YgdmlydHVhbCBsaW5rcyAod2hpY2ggbWF5IGJlIGNvbmNhdGVuYXRlZCBhY3R1YWwg bGlua3MpIGNhbiBiZSBleHBvc2VkIGZvciBkaXZlcnNpdHkgcm91dGluZyBjYWxjdWxhdGlvbiBh dCB0aGUgVk5DLiBUaGlzIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gZXhwb3NpbmcgdGhlIGFjdHVh bCBURSB0b3BvbG9neS4gWW91IGNhbiB2aWV3IHRoaXMgYXMgdHdvIGxldmVsIG9mIHBhdGggY29t cHV0YXRpb24uIFZOQyBmaXJzdCBjb21wdXRlcyBhbiBlbmQtdG8tZW5kIHBhdGggKHVzaW5nIHdo YXRldmVyIGNvbnN0cmFpbnQgaW5mb3JtYXRpb24gaXQgaGFzKSwgdGhlbiBjb29yZGluYXRlcyB3 aXRoIGVhY2ggUE5DICh0ZWxsaW5nIHRoZSBib3JkZXIgbm9kZXMgaW5mb3JtYXRpb24pLCB0aGVu IGVhY2ggUE5DIGNvbXB1dGVzIHRoZSBkb21haW4gc3BlY2lmaWMgcGF0aC4gV2hlbiBhIFBOQyBj YW5ub3QgcHJvdmlkZSBhIHBhdGggc2VnbWVudCBpbiBpdHMgZG9tYWluLCB0aGVuIHRoaXMgbmVl ZHMgdG8gYmUgc2lnbmFsZWQgdG8gVk5DIHNvIHRoYXQgdGhlIFZOQyB3b3VsZCBhcnJhbmdlIGFu IGFsdGVybmF0ZSBwYXRoIHNlZ21lbnQgdG8gYmUgYWJsZSB0byBmaW5kIGEgZmVhc2libGUgZW5k LXRvLWVuZCBwYXRoLiAgSSB3b3VsZCBzYXkgdGhpcyBpcyBhIKGwdHdvLXBoYXNlobEgc2lnbmFs aW5nIGFuZCBwYXRoIGNvbXB1dGF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB0aGVyZSBtdXN0IGJl IHNvbWUgbGV2ZWwgb2YgaGlkaW5nIG9uIGFic3RyYWN0IHRvcG9sb2d5IGV4cG9zdXJlIGZyb20g UE5DIHRvIFZOQyBhbmQgcHJvcHJpZXRhcnkgY2hhcmFjdGVyaXN0aWNzIG9mIG9wdGljYWwgZGV2 aWNlcyBuZWVkIHRvIGJlIGRlYWx0IG9ubHkgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBQTkMuDQoN ClJlZ2FyZGluZyB0aGUgdGVybSBQTkMgdnMuIEFOQywgSSB3b3VsZG6hr3QgY29uY2VybiB0b28g bXVjaCBhYm91dCB0aGUgdGVybWlub2xvZ3kgd2hpY2hldmVyIHdvcmtzIGJldHRlci4gVGhhbmsg eW91IGZvciB5b3VyIHN1Z2dlc3Rpb24uDQoNCkxhc3RseSwgcGxlYXNlIGNoZWNrIHRoZSB1c2Ut Y2FzZXMgd3JpdHRlbiBieSBvcGVyYXRvcnMgaW4gdGhlIGJlbG93IGxpbmtzIHRoYXQgY29uc2lz dGVudGx5IHNheSB0aGV5IG5lZWQgYSBzdGFuZGFyZCBpbnRlcmZhY2UgdGhhdCBjYW4gY29vcmRp bmF0ZSB0aGVpciBtdWx0aS1kb21haW4gaXNzdWVzLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1mYW5nLWFjdG4tbXVsdGlkb21haW4tZGNpLw0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2xlZS1hY3RuLWNvbm5lY3Rpdml0eS1tdWx0aS12 ZW5kb3ItZG9tYWlucy8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1 bWFraS1hY3RuLW11bHRpdGVuYW50LXZuby8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWxvcGV6LWFjdG4tdm5vLW11bHRpZG9tYWlucy8NCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNoaW4tYWN0bi1tdm5vLW11bHRpLWRvbWFpbi8NCg0KUmVn YXJkcywNCllvdW5nDQoNClRoYW5rcywNCllvdW5nDQoNCg0KRnJvbTogSWdvciBCcnlza2luIFtt YWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MDksIDIwMTQgMTo0OCBQTQ0KVG86IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgTGVleW91bmc7 IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7 IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFp bHRvOmx1eXVhbmZAZ21haWwuY29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDog UkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhp IFlvdW5nLA0KDQpJIGJlbGlldmUgaGF2aW5nIHRoZSBzYW1lIGluc3RhbmNlIG9mIFZOQyB0YWxr aW5nIHRvIGRpZmZlcmVudCB2ZW5kb3IgZG9tYWluIFBOQ3MgaXMgYW4gZXh0cmVtZWx5ICBpZGVh bGlzdGljIHZpZXcuDQoNCj09PT0+IEJUVyBJIGZpbmQgUE5DIGlzIGEgYmFkIHRlcm0sIEkgbGlr ZSBtdWNoIGJldHRlciBBY3R1YWwgTmV0d29yayBDb250cm9sbGVyICAoQU5DKS4gVk5DIChhLmsu YS4gYSBIeXBlcnZpc29yKSBpcyBtYW5hZ2luZyBhYnN0cmFjdCB0b3BvbG9naWVzLCBhbmQgdG8g YmUgYWJsZSBkbyB0aGF0LCBpdCB0YWxrcyB0byBhIEFOQy0gYSBjb250cm9sbGVyIHdoaWNoIGhh cyBhbiBhY2Nlc3MgYW5kIG1hbmFnZXMgYWN0dWFsIHByb3ZpZGVyIG5ldHdvcmspLg0KDQpPbmUg cmVhc29uIGZvciB0aGlzIGlzIHRoYXQgVk5DIG5lZWRzIHRvIHVuZGVyc3RhbmQgdW5kZXJseWlu ZyBhY3R1YWwgdG9wb2xvZ3ksIGZvciBleGFtcGxlLCB0byBlbnN1cmUgdGhhdCB0d28gYWJzdHJh Y3QgVEUgbGlua3MgYXJlIFNSTEcgZGlzam9pbnQgYXMgcmVxdWVzdGVkLiBBY3R1YWwgdG9wb2xv Z3kgc2VtYW50aWNzIChlc3BlY2lhbGx5IGluIFdETSBsYXllcikgaXMgdmVyeSBkaWZmZXJlbnQg ZnJvbSB2ZW5kb3IgdG8gdmVuZG9yIGFuZCBjb250YWlucyBhIGdyZWF0IHZhcmlldHkgb2YgcHJv cHJpZXRhcnkgZXh0ZW5zaW9ucywgZmFpbGluZyB0byB1bmRlcnN0YW5kIHdoaWNoIGxlYWRzIHRv IHByb2R1Y2luZyB1bnByb3Zpc2lvbmFibGUgc2VydmljZSBwYXRocy4gRG8geW91IHJlYWxseSBi ZWxpZXZlIHRoYXQgYSBzaW5nbGUgVk5DIGNhbiB0YWxrIGluIHRoZSBzYW1lIHdheSB0byBBRFZB LCBJTkZOLCBBTFUgYW5kIEh1YXdlaSBBTkNzPyBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gYXNrIGFs bCBvcHRpY2FsIHByb3ZpZGVycyB0byBzd2l0Y2ggdG8gV1NPTiA6PSkuDQoNClRoaXMgaXMgbm90 IHRvIHNheSB0aGF0IHlvdSBjYW5ub3QgYnVpbGQgYSBoaWVyYXJjaHkgb2YgVk5DcywgYnV0IGlu IHRoaXMgY2FzZSBOb3J0aCBWTkMgcGxheXMgcm9sZSBvZiBhIGNsaWVudCBuZXR3b3JrIGNvbnRy b2xsZXIgd3J0IHRvIFNvdXRoIFZOQywgdGhhdCBpcywgdXNlcyB0aGUgc2FtZSBYIGludGVyZmFj ZS4NCklITU8gd2hlbmV2ZXIgYSBWTkMgaGFzIHRvIHRhbGsgdG8gYSBBTkMsIGl0IGRvZXMgc28g aW4gYSBwcm9wcmlldGFyeSB3YXksIGkuZS4gQURWQSwgSU5GTiwgQUxVIGFuZCBIdWF3ZWkgd2ls bCBoYXZlIHRoZWlyIG93biBWTkNzIGV4cG9zaW5nIHRoZSBzYW1lIG5vcnRoIGJvdW5kIGludGVy ZmFjZSB0byBwb3RlbnRpYWxseSB0aGUgc2FtZSBjbGllbnQgKGUuZy5URkspLg0KSUhNTyBpbnRl cmZhY2UgWCBpcyB0aGUgb25seSBpbnRlcmZhY2UgdGhhdCB0aGUgQUNUTiBjYW4gd29yayBvbi4N Cg0KQ2hlZXJzLA0KSWdvcg0KDQpGcm9tOiBBQ1ROIFttYWlsdG86YWN0bi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pDQpTZW50OiBUaHVyc2Rh eSwgT2N0b2JlciAwOSwgMjAxNCA1OjU5IEFNDQpUbzogTGVleW91bmc7IGFjdG5AaWV0Zi5vcmc8 bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxt YWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21h aWwuY29tPg0KQ2M6IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgVmFybWEsIEV2ZSBMIChFdmUp DQpTdWJqZWN0OiBSZTogW0FjdG5dIGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMu dHh0IGNvbW1lbnRzDQoNCkhpIFlvdW5nLA0KDQp0aGFua3MgYSBsb3QgZm9yIHJlcGx5ICwgcGxl YXNlIHNlZSBpbiBsaW5lIGp1c3Qgc29tZSBmdXJ0aGVyIGNsYXJpZmljYXRpb24NCg0KUmVnYXJk cw0KU2VyZ2lvDQoNCg0KDQpGcm9tOiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5j b21dDQpTZW50OiBtZXJjb2xlZKisIDggb3R0b2JyZSAyMDE0IDE3OjM1DQpUbzogQkVMT1RUSSwg U0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFu aWVsZSBDZWNjYXJlbGxpOyBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47IGx1eXVh bmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNjOiBWYXJtYSwgRXZlIEwg KEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4 dCBjb21tZW50cw0KDQpIaSBTZXJnaW8sDQoNClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayBvbiB0 aGUgZnJhbWV3b3JrIGRvY3VtZW50LiBQbGVhc2Ugc2VlIGluLWxpbmUgZm9yIG15IGNvbW1lbnQu DQoNClJlZ2FyZHMsDQpZb3VuZw0KDQpGcm9tOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgW21h aWx0bzpzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiBXZWRuZXNkYXks IE9jdG9iZXIgMDgsIDIwMTQgNzozNCBBTQ0KVG86IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5A aWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IExlZXlvdW5nOyBkaWVnb0B0aWQuZXM8bWFp bHRvOmRpZWdvQHRpZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWls LmNvbT4NCkNjOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IFZhcm1hLCBFdmUgTCAoRXZlKQ0K U3ViamVjdDogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMN Cg0KSGkgRGFuaWVsZSAsIFlvdW5nIGFuZCBhbGwgYXV0aG9ycywNCg0KSSByZWFkIHlvdSBGcmFt ZXdvcmsgZHJhZnQgYW5kIEkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoYXQuIE1vc3QgYXJlIGVk aXRvcmlhbCAsIG90aGVyIHF1ZXN0aW9ucyBmb3IgY2xhcmlmaWNhdGlvbnMuDQoNCkdlbmVyYWwg cXVlc3Rpb246IGluIHRoZSBkcmFmdCB0aGUgY29uY2VwdCBvZiBWTkMgaXMgaW4gdGhlIHZpZXcg b2YgaGllcmFyY2hpY2FsIGxldmVsIG9mIGNvbnRyb2xsZXJzIG9yIGxpbmtlZCB0byB0aGUgbXVs dGktZG9tYWluIGFzcGVjdCB0aGF0IGNvbXBlbCB0byBwcm92aWRlIHRvIHRoZSBjdXN0b21lciBh IHNpbmdsZSB2aXJ0dWFsaXplZCBuZXR3b3JrIGV2ZW4gaWYgY29tcG9zZWQgYnkgcmVhbCBtdWx0 aS1kb21haW4gbXVsdGktdGVjaG5vbG9neSBzdWJuZXR3b3Jrcz8gSSBtZWFuLCB0aGUgobB2aXJ0 dWFsaXplciBmdW5jdGlvbqGxIHByb3ZpZGVkIGJ5IFZOQywgaW4gY2FzZSBvZiBhIHNpbmdsZSBk b21haW4gY29udGV4dCBjb3VsZCBiZSBpbnNpZGUgZGlyZWN0bHkgdGhlIFBOQyAsIGNvcnJlY3Q/ DQoNCllPVU5HPj4gWWVzLiBUaGF0IGlzIHRoZSBjb3JyZWN0IHZpZXcgb2YgVk5DLiBGb3IgYSBz aW5nbGUgZG9tYWluIGNvbnRleHQsIHRoZSBWTkMgY2FuIGJlIGludGVncmF0ZWQgd2l0aCBQTkMu IEJ1dCB3ZSBuZWVkIHRvIGZhY3RvciBpbiBvdGhlciBzY2VuYXJpb3Mgc3VjaCBhcyAxKSBWTkMg dmVuZG9yIG1heSBiZSBkaWZmZXJlbnQgZnJvbSBQTkMgdmVuZG9yIG9yIDIpIFZOQyBpcyBhIHNv ZnR3YXJlIGZ1bmN0aW9uIHRoYXQgb3BlcmF0b3IgbWF5IHdhbnQgdG8gb3BlcmF0ZSBhcyBpdHMg Y29udHJvbC4gSW4gbXkgb3BpbmlvbiwgZXZlbiBmb3IgYSBzaW5nbGUgZG9tYWluLCBJIHRoaW5r IHRoZXJlIGlzIGJlbmVmaXQgdG8gZGVmaW5lIHRoaXMgaW50ZXJmYWNlIGFzIGEgc3RhbmRhcmQg aW50ZXJmYWNlLg0KDQpTZWN0aW9uIDIgLCBwYWdlIDQ6DQphYnN0cmFjdGlvbiBkb2VzIG5vdCBp bXBseSBhdXRvbWF0aWNhbGx5IHZpcnR1YWxpemF0aW9uLHdoaWxlIHZpcnR1YWxpemF0aW9uIGlt cGxpZXMgdG8gaGF2ZSBzdXJlbHkgYSBjZXJ0YWluIGZvcm0gb2YgYWJzdHJhY3Rpb24uIEkgd291 bGQgc3VnZ2VzdCB0byBjb25zaWRlciBnb29kIGRlZmluaXRpb24gY29udGFpbmVkIGludG8gT05G IFNETiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgY2hhcHRlciAyLjMgQ29udmVudGlvbnMgYWJvdXQg YWJzdHJhY3Rpb24gYW5kIHZpcnR1YWxpemF0aW9uLiBBIGdvb2QgZGVmaW5pdGlvbiBjYW4gaGVs cCBhbGwgdGhlIHJlYWRpbmcuDQoNCllPVU5HPj4gQWdyZWUuIFdlIHdpbGwgbG9vayBpbnRvIHRo ZSBtZW50aW9uZWQgZG9jdW1lbnQgaWYgdGhlIHVzYWdlIG9mIHRlcm1zIGFyZSBhbGlnbmVkIHdp dGggdGhpcyBkb2N1bWVudC4gSWYgbm90LCB3ZSB3aWxsIGNsYXJpZnkgdGhlIHRlcm1pbm9sb2d5 IG1vcmUgY2xlYXJseS4NCg0KU2VjdGlvbiA1OiBJdCBzZWVtcyB0byBtZSB5b3UgbWl4ZWQgaGVy ZSBhc3BlY3RzIHRoYXQgYXJlIG1vcmUgcmVsYXRlZCB0byBwb2xpY3kgbGlrZSBhZG1pc3Npb24g Y29udHJvbCAgYW5kIGd1YXJhbnRlZSBvZiBjbGllbnQgaXNvbGF0aW9uIHdpdGggcmVhbCBjb21w dXRhdGlvbmFsIGlzc3VlIGxpa2UgQ29tcHV0aW5nIHRpbWUgLCBwYXRoIGNvbnN0cmFpbnMgb3Ig cmUtb3B0aW1pemF0aW9uIHByb2Nlc3MuIE1vcmVvdmVyIHRoZSB0ZXJtIFZOTSBmb3IgVmlydHVh bCBuZXR3b3JrIG1hcHBpbmcgaXMgYSBiaXQgbWlzbGVhZGluZyBzaW5jZSB0aGlzIHRlcm0gaW4g YWxyZWFkeSB1c2VkIGUuZy4gaW4gQUJOTyBhcmNoaXRlY3R1cmUgZm9yIFZpcnR1YWwgTmV0d29y ayBNYW5hZ2VyLg0KDQpZT1VORz4+IEluZGVlZC4gSW4gU2VjdGlvbiA1LCB3ZSB3aWxsIHB1dCBz b21lIG5vdGVzIG9uIHRoZSBhc3BlY3Qgb2YgcmVhbC10aW1lIHJlbGF0ZWQgZnJvbSBub24gcmVh bCB0aW1lIGFzcGVjdC4gVk5NIGlzIG5vdCB0byBiZSBtaXhlZCB3aXRoIFZpcnR1YWwgTmV0d29y ayBNYW5hZ2VyLiBIZXJlIFZOTSBpcyBhbiBhbGdvcml0aG0gd2hpY2ggaXMga25vd24gYXMgVmly dHVhbCBOZXR3b3JrIE1hcHBpbmcgd2hpY2ggaXMgYSBzb2Z0d2FyZSBtb2R1bGUgdGhhdCBjb252 ZXJ0cyBjbGllbnQgcmVxdWVzdHMgaW50byBhY3R1YWwgbmV0d29ya3MuIFZpcnR1YWwgTmV0d29y ayBNYW5hZ2VyIGlzIEFCTk8gaW4gbXkgdW5kZXJzdGFuZGluZyBpcyBhIGRldmVsb3BlZCBjb25j ZXB0IGZyb20gVk5UTS4gQnV0IERhbiBLaW5nIGFuZCBJIHdpbGwgbG9vayBhdCB0aGlzIG1vcmUg Y2FyZWZ1bGx5IG9uIHRoaXMgYXNwZWN0IHdoYXQgVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIgaXMg ZG9pbmcuDQoNClNCPj4+IElmIEkgdW5kZXJzdG9vZCBmb3JtIEFkcmlhbiBhbmQgRGFuaWVsIEFC Tk8gZHJhZnQgdGhlIGNvbmNlcHQsIA0KU0I+Pj4gVk5UTSBpcyBzdHJpY3RseSByZWxhdGVkIHRv IHBsYW5uaW5nIGZ1bmN0aW9uIHNvIEkgdGhpcyBpdCBpcyB2ZXJ5IA0KU0I+Pj4gaW1wb3J0IHBv aW50IGluIHRoZSBjb250ZXh0IG9mIFBOQyAsIEkgd291bGQgc2F5DQoNClNlY3Rpb24gNi4xIDog d2hpbGUgaXQgaXMgY2xlYXIgdGhlIHNjb3BlIG9mIHRoZSBkaWZmZXJlbnQgY29udHJvbCBpbnRl cmZhY2UgcHJlc2VudGVkIGluIGZpZ3VyZSA1LCBJoa9tIGEgYml0IGNvbmZ1c2VkIGFzIHRvIHdo YXQgSS9GIEUgaXMgqEMgZGF0YSBwbGFuZSBpbnRlcmZhY2UgdG8gcHJvdmlkZXIgcGh5c2ljYWwg bmV0d29yaz8gT3IgaXMgdGhlIGludGVudGlvbiB0byBwcm92aWRlIHdoYXQgY2FuIGJlIHRoZSB1 bmRlcmx5aW5nIG1vZGVsIG9mIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gYSBjdXN0b21lciBmcm9t IG5ldHdvcmsgcHJvdmlkZXIgY29udHJvbGxlciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwgcGh5 c2ljYWwgcmVzb3VyY2VzID8gTm9yIGNsZWFyIHRvIG1lIHRoZSBpbnRlbnRpb24NCg0KWU9VTkc+ PiBJbnRlcmZhY2UgRSBpcyBub3Qgd2hhdCBBQ1ROIHdpbGwgZm9jdXMgb24uIEl0IHNpbXBseSBz aG93cyAgYW4gdW5kZXJseWluZyBtb2RlbCBvZiByZXNvdXJjZXMgYWxsb2NhdGVkIHRvIGEgY3Vz dG9tZXIgZnJvbSBuZXR3b3JrIHByb3ZpZGVyIGNvbnRyb2xsZXIsIGFuZCB0aGUgbWFwcGluZyB0 byByZWFsIHBoeXNpY2FsIHJlc291cmNlcy4NCg0KU0I+Pj4gU28gaWYgSSBpbnRlcnByZXRlZCBj b3JyZWN0bHkgeW91ciBhbnN3ZXIgaXMgbW9yZSBhbiBpbnRlcm5hbCBpbnRlcmZhY2UgdG8gUE5D ICwgdGhlIGZpZ3VyZSBpcyBtaXNsZWFkaW5nIHNpbmNlIGl0IHNlZW1zIGxpa2UgYSBEUCBpbnRl cmZhY2UgLg0KDQoNClNlY3Rpb24gNi4xLCBhbHdheXMgZmlndXJlIDU6IElmIGEgcmVwb3J0IG9m IHBvdGVudGlhbCBOVyB0b3BvbG9neSBiZXR3ZWVuIGEgVk5DIGFuZCBhIENOQyBjYW4gYmUgcXVl cmllZCAsIHRoZSBhcnJvdyBpbiB0aGUgZHJhd24gaGFzIHRvIGJlIGJpZGlyZWN0aW9uYWwgSSBn dWVzcw0KDQpZT1VORz4+IFllcywgWW91IGFyZSByaWdodC4gSXQgd2lsbCBiZSBmaXhlZC4NCg0K RmlndXJlIDggU2VjdGlvbiA2LjQscGFnZSAyODogobBQQ0EgYWJzdHJhY3RzIHRoZSBwaHlzaWNh bCBuZXR3b3JrIHRvcG9sb2d5IGludG8gYW4gYWJzdHJhY3RlZCB0b3BvbG9neaGxIExvb2tpbmcg YXQgdGhlIGRlc2NyaXB0aW9uIG9mIFZOQyBjb21wb25lbnRzIGluIDYuMi4yIGl0IGlzIHRoZSBy ZXNvdXJjZSBtYW5hZ2VyIGRldm90aW5nIHRvIHByb3ZpZGUgYWJzdHJhY3QgdG9wb2xvZ3kuIERv ZXMgbm90IGV4aXN0IGFueSBQQ0EgY29tcG9uZW50Lg0KDQoNCg0KWU9VTkc+PiBTb3JyeSBmb3Ig aW5jb25zaXN0ZW5jeS4gVGhlIGludGVudGlvbiB3YXMgdGhlIFBDQSBpcyB0aGUgc2FtZSBhcyB0 aGUgUmVzb3VyY2UgTWFuYWdlciBpbiBWTkMuIFdpbGwgbWFrZSB0aGUgdGVybSBjb25zaXN0ZW50 LiBHb29kIGNhdGNoIQ0KDQoNCg0KRmlndXJlIDggU0VjdGlvbiA2LjQsIDogSW4gdGhlIHBpY3R1 cmUgdGhlcmUgaXMgbm8gcGhhc2UgNywgYW5kIHRoZXJlIGFyZSAyIHBoYXNlIDgNCg0KWU9VTkc+ PiBUaGFua3MuIEdvb2QgY2F0Y2ghDQoNClBhZ2UgMzAgOiBJdCBpcyBJbnRlcmZhY2UgQyBub3Qg QiAsIGJldHdlZW4gVk5DIGFuZCBQTkMNCg0KWU9VTkc+PiBJZiB5b3UgYXJlIHJlZmVycmluZyB0 byBTZWN0aW9uIDcuMyB3aGVyZToNCg0KICAgSW50ZXJmYWNlcyBzaG91bGQgYWxzbyBiZSBzY2Fs YWJsZSBhcyBhIGxhcmdlIGFtb3VudCBvZiBkYXRhIG5lZWRzDQoNCiAgIHRvIGJlIHRyYW5zcG9y dGVkIGFjcm9zcyBjdXN0b21lcnMgdG8gdmlydHVhbCBuZXR3b3JrIGNvbnRyb2xsZXJzDQoNCiAg IGFuZCBhY3Jvc3MgdmlydHVhbCBuZXR3b3JrIGNvbnRyb2xsZXJzIGFuZCBwaHlzaWNhbCBuZXR3 b3JrDQoNCiAgIGNvbnRyb2xsZXJzLg0KDQoNCg0KSSB0aGluayB0aGlzIGltcGxpZXMgYm90aCBp bnRlcmZhY2VzIEIgYW5kIEMgYWx0aG91Z2ggcHJpbWFyaWx5IGJldHdlZW4gVk5DLVBOQy4NCg0K DQoNClNCPj4+IFNvcnJ5IFlvdW5nLCBpaXQgaXMgbm90IHJlZmVycmVkIHRvIDcuMyAsIGJ1dCBp biB0aGUgY2hhcHRlciA2LDUgLCANClNCPj4+IG9uIEludGVyZmFjZSBpbnRlcmFjdGlvbiwgYWZ0 ZXIgcG9pbnQgNiwgaXMgaW5kaWNhdGVkIEludGVyZmFjZSBCIA0KU0I+Pj4gYXMgaW50ZXJmYWNl IGJldHdlZW4gVk5DIGFuZCBQTkMsIGZpZ3VyZSA1IHNheXMgaXQgaXMgSS9GIEMNCg0KDQpUaGFu a3MNCg0KU2VyZ2lvDQoNCg0KVGhhbmtzDQpTZXJnaW8NCg== From nobody Tue Oct 14 08:08:34 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 EF2AA1A8920 for ; Tue, 14 Oct 2014 08:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 48mXYegnMTIq for ; Tue, 14 Oct 2014 08:07:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9391A88EC for ; Tue, 14 Oct 2014 08:07:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKN75480; Tue, 14 Oct 2014 15:07:50 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 16:07:49 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 08:07:42 -0700 From: Leeyoung To: "BELOTTI, SERGIO (SERGIO)" , "Igor Bryskin" , Daniele Ceccarelli , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAUUWIAAAw1vGA= Date: Tue, 14 Oct 2014 15:07:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3DD71@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/hSwDpBLnGFi4lwRYqd-79PG7BnU Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 15:08:10 -0000 SGkgU2VyZ2lvLA0KDQpJIGFncmVlIHdpdGggeW91IG9uIHlvdXIgcGVyc3BlY3RpdmUgb24gVk5D J3MgZHVhbCBmdW5jdGlvbmFsaXR5LCB2aXJ0dWFsaXplciArIG11bHRpLWRvbWFpbiBvcmNoZXN0 cmF0aW9uLg0KDQpSZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC RUxPVFRJLCBTRVJHSU8gKFNFUkdJTykNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTQsIDIwMTQg NDozOCBBTQ0KVG86IElnb3IgQnJ5c2tpbjsgTGVleW91bmc7IERhbmllbGUgQ2VjY2FyZWxsaTsg S2luZywgRGFuaWVsOyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwu Y29tDQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSZTogW0FjdG5dIGRyYWZ0LWNl Y2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIElnb3IsDQoNCiIg SULjgItOby4gSSBhbSBzYXlpbmcgdGhhdCBpbnRlcmZhY2UgQiBhbmQgQyBhcmUgZXhhY3RseSB0 aGUgc2FtZSBpbnRlcmZhY2VzLiBGb3IgZXhhbXBsZSwgb24gdGhlIHBpY3R1cmUgTmV0d29yayBk b21haW4gMSBpbiBvcmRlciB0byBwcm92aWRlIHRoZSBhYnN0cmFjdCB0b3BvbG9neSB0byB0aGUg bXVsdGktdmVuZG9yIFZOQywgbWF5IHVzZSBmdWxseSBvciBwYXJ0aWFsbHkgYWJzdHJhY3QgdG9w b2xvZ2llcyBwcm92aWRlZCBieSBvbmUgb3IgbW9yZSBsb3dlciB0aWVyIHRyYW5zcG9ydCBkb21h aW5zLg0KTGlrZXdpc2UsIEN1c3RvbWVyIDEgb24gdGhlIHBpY3R1cmUgbWF5IHVzZSBhbiBhYnN0 cmFjdCB0b3BvbG9neSBwcm92aWRlZCBieSBNdWx0aS1kb21haW4gbmV0d29yayAodGhlIFZOQyBv biB0aGUgcGljdHVyZSBpcyBwYXJ0IG9mKS4NCkluIG90aGVyIHdvcmRzLCB0aGUgc2FtZSBpbnRl cmZhY2UgQyBhbmQgdGhlIHNhbWUgc2V0IG9mIG1vZGVscywgY291bGQgYmUgdXNlZCAgaGllcmFy Y2hpY2FsbHkuIA0KDQpJZ29yIg0KDQpJIHRlbmQgdG8gZGlzYWdyZWUgaGVyZS4gV2hhdCB0aGF0 IGNhbiBiZSBkaXNjdXNzZWQgaW4gbXkgdmlldyBpdCBpcyB0aGUgbmVlZCBvciBub3Qgb2YgaW50 ZXJmYWNlIEMuIFdoYXQgVk5DIGlzIGdvaW5nIHRvIHByb3ZpZGUgaXMgYSBkb3VibGUgZnVuY3Rp b24gb2YgdmlydHVhbGl6ZXIgb2YgdGhlIG5ldHdvcmsgdG93YXJkcyBjbGllbnQgYXBwbGljYXRp b24gbGV2ZWwgYW5kIG9yY2hlc3RyYXRpb24sIGR1ZSB0byB0aGUgbmVlZCB0byBzcGFuIG11bHRp cGxlICh2aXJ0dWFsKU5FcyBvciBtdWx0aXBsZSBuZXR3b3JrIGRvbWFpbiAuIElmIHdlIGltbW1h Z2luZSB0byBlbmNvbXBhc3MgdGhlc2UgZnVuY3Rpb25hbGx5IGludG8gb25seSBvbmUgU0ROIGNv bnRyb2xsZXIgLCBtYW5hZ2luZyBhbGwgdmlydHVhbCBuZXR3b3JrIHlvdSB3b3VsZCBub3QgdXNl IGFub3RoZXIgaW50ZXJmYWNlIGJldHdlZW4gVk5DIGFuZCBQTkMuDQpCdXQgaGVyZSBZb3VuZyBw dXQgY29ycmVjdGx5IHNvbWUgcHJvYmxlbXMgYW5kIGl0IGlzIHRoZSBjb3JyZWN0IHRpbWUgSSB0 aGluayB0byBjb25zaWRlciBhbGwgdGhlIGFzcGVjdHMuDQpCdXQgdG93YXJkcyBjbGllbnQgYXBw bGljYXRpb24gdGhlcmUgaXMgYW5vdGhlciBsZXZlbCBvZiBhYnN0cmFjdGlvbiwgYSByZWFsIHZp cnR1YWxpemF0aW9uICh0byBjbGllbnQpIG9mIHJlc291cmNlcyB3aXRoIGRpZmZlcmVudCBncmFu dWxhcml0eSBhbmQgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBzZXQgb2YgaW5mb3JtYXRpb24gbmVl ZGVkIHRvIHRoZSBsb3dlciBsZXZlbCBvZiBjb250cm9sbGVyLCBhcyB3ZWxsIGV4cGxhaW5lZCBi eSBZb3VuZy4NCkl0IGNhbiBkZWJhdGUgaWYgYW5vdGhlciBzZXBhcmF0ZSBlbnRpdHkgYXMgVk5D IGNhbiBiZSAsIGluIHRoaXMgYXJjaGl0ZWN0dXJlLCB0aGUgZ29vZCBjaG9pY2UsIGJ1dCBJIGRv IG5vdCBoYXZlIHByZWNsdXNpb24gb24gdGhhdC4gDQpJIGluc3RlYWQgc2hhcmUgeW91ciBzZW50 ZW5jZSBhYm91dCBoaWVyYXJjaGljYWwgbGV2ZWwgb2YgY29udHJvbGxlci4gDQoNClRoYW5rcw0K DQpSZWdhcmRzDQpTZXJnaW8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QUNUTiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElnb3IgQnJ5 c2tpbg0KU2VudDogbWFydGVkw6wgMTQgb3R0b2JyZSAyMDE0IDAyOjAxDQpUbzogTGVleW91bmc7 IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5p ZWw7IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRpZC5lczsgbHV5dWFuZkBnbWFpbC5jb20NCkNjOiBW YXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJlOiBbQWN0bl0gZHJhZnQtY2VjY2FyZWxsaS1h Y3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KDQpZb3VuZywNCg0KDQo9PT3jgItBZnRl ciBhbGwgd2UgYXJlIGFncmVlaW5nIHdpdGggdGhlIGludGVyZmFjZXMgb2YgQUNUTiBpbnRlcmVz dCBhcmUgSW50ZXJmYWNlIEIgYW5kIEMsIHJpZ2h0Pw0KDQpJQuOAi05vLiBJIGFtIHNheWluZyB0 aGF0IGludGVyZmFjZSBCIGFuZCBDIGFyZSBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMuIEZv ciBleGFtcGxlLCBvbiB0aGUgcGljdHVyZSBOZXR3b3JrIGRvbWFpbiAxIGluIG9yZGVyIHRvIHBy b3ZpZGUgdGhlIGFic3RyYWN0IHRvcG9sb2d5IHRvIHRoZSBtdWx0aS12ZW5kb3IgVk5DLCBtYXkg dXNlIGZ1bGx5IG9yIHBhcnRpYWxseSBhYnN0cmFjdCB0b3BvbG9naWVzIHByb3ZpZGVkIGJ5IG9u ZSBvciBtb3JlIGxvd2VyIHRpZXIgdHJhbnNwb3J0IGRvbWFpbnMuDQpMaWtld2lzZSwgQ3VzdG9t ZXIgMSBvbiB0aGUgcGljdHVyZSBtYXkgdXNlIGFuIGFic3RyYWN0IHRvcG9sb2d5IHByb3ZpZGVk IGJ5IE11bHRpLWRvbWFpbiBuZXR3b3JrICh0aGUgVk5DIG9uIHRoZSBwaWN0dXJlIGlzIHBhcnQg b2YpLg0KSW4gb3RoZXIgd29yZHMsIHRoZSBzYW1lIGludGVyZmFjZSBDIGFuZCB0aGUgc2FtZSBz ZXQgb2YgbW9kZWxzLCBjb3VsZCBiZSB1c2VkICBoaWVyYXJjaGljYWxseS4gDQoNCklnb3INCg0K SUI+PiBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRyYW5zcG9ydCBk b21haW4gc2VydmVyIGFuZCAgdHJhbnNwb3J0IGRvbWFpbiBjbGllbnQuIEkgd291bGQgYXJndWUg dGhhdCB0aGUgdmVyeSBzYW1lIGludGVyZmFjZSBjYW4gYmUgdXNlZCBiZXR3ZWVuIGEgbXVsdGkt ZG9tYWluIHByb3ZpZGVyIChlLmcuIFRlbGVmb25pa2EpIGFuZCBpdHMgY2xpZW50cy4gTm90IGFs bCBzdWNoIGNsaWVudHMgYXJlIGR1bWIsIGFzIERhbmllbGUgY2xhaW1zLCBhbmQgb25seSBjYXJl IGFib3V0IOKAnGEgZ2l2ZW4gYW1vdW50IG9mIEdicHMgZnJvbSBBIHRvIELigJ0uIEl0IGlzIGVh c3kgdG8gZW52aXNpb24gdGhhdCBzb21lIG9mIHRoZSBjbGllbnRzIHdvdWxkIHdhbnQgZnJvbSBU ZWxlZm9uaWNhIGEgY291cGxlIG9mIFNSTEctZGlzam9pbnQgYWJzdHJhY3QgbGlua3MsIHNvIHRo YXQgdGhlIGNsaWVudHMgY2FuIGhhdmUgYSBzYXkgaW4gdGhlIHBsYWNlbWVudCBvZiB0aGVpciAg c2VydmljZXMgYWNyb3NzIHRoZSBUZWxlZm9uaWthIG5ldHdvcmsuIFRocmVlIHBvaW50cyBoZXJl Og0KDQphKSAgICAgIFRoZSBjbGllbnQgd2lsbCBiZSBhYmxlIHRvIGNvbmZpZ3VyZSBmdWxseSBv ciBwYXJ0aWFsbHkgdGhlIGFic3RyYWN0IHRvcG9sb2d5IGhlIHdhbnRzIHRoZSBuZXR3b3JrIHRv IHByZXNlbnQgdG8gaGltOw0KDQpiKSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNv dWxkIGJlIGFzIHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdCBub2RlKSBvciBhcyBjb21w bGV4IChlLmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBhYnN0cmFjdCBs aW5rcykgYXMgdGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlk ZXLigJlzIGFwcHJvdmFsKQ0KDQpjKSAgICAgIFRoZSBhYnN0cmFjdCB0b3BvbG9neSBwcmVzZW50 ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IGRlY291cGxlZCBmcm9tIHRoZSBwcm92aWRl cuKAmXMgYWN0dWFsIHRvcG9sb2d5Lg0KDQpUaGVyZWZvcmUgdGhlIHNhbWUgaW50ZXJmYWNlL3Nl dCBvZiBtb2RlbHMgY2FuIGJlIHVzZWQgYmV0d2VlbiBhbnkgdHJhbnNwb3J0IG5ldHdvcmsgcHJv dmlkZXIgYW5kIGl0cyBjbGllbnQuIEZ1cnRoZXJtb3JlLCB0aGUgaW50ZXJmYWNlIGNhbiBiZSB1 c2VkIGluIHRoZSBoaWVyYXJjaGljYWwgd2F5LCB0aGF0IGlzLCBhIGNsaWVudCBvZiBhIHRyYW5z cG9ydCBkb21haW4gY2FuIHNlcnZlIGl0cyBvd24gY2xpZW50cyB1c2luZyB0aGUgc2FtZSBpbnRl cmZhY2UgYXMgaXQgdXNlcyB0byB0YWxrIHRvIGl0cyBvd24gcHJvdmlkZXIocykNCg0KSGVyZSBJ IHdvdWxkIGxpa2UgdG8gZ2l2ZSB5b3UgYSBsaXR0bGUgY2xlYXJlciBwaWN0dXJlIG9uIG11bHRp LWRvbWFpbiBpc3N1ZXMuDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0t LS0rICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgfCAgIEN1c3RvbWVyIDEgICB8ICAgfCAgIEN1 c3RvbWVyIDIgIHwgIC4uLiB8IEN1c3RvbWVyIE0gICB8DQogICArLS0tLS0tLS0tLS0tLS0tLSsg ICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAg ICAgICBcICAgICAgICAgICAgIHwgICAgICAgICAgICAgIC8NCiAgICAgICAgICAgICAgICAgICAg XCAgICAgICAgICAgIHwgICAgICAgICAgICAgLw0KICAgICAgIEludGVyZmFjZSBCICAgXCAgICAg ICAgICAgfCAgICAgICAgICAgIC8NCiAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgIHwg ICAgICAgICAgIC8NCiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgVk5DIE11bHRpLWRvbWFpbiAgIHwgRTJFIGFi c3RyYWN0DQogICAgICAgICAgICAgICAgICAgICAgfCAgICAgIENvb3JkaW5hdGlvbiAgICB8IHRv cG9sb2d5IGNyZWF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICB8ICAgICAgICAgICAgXA0K ICAgICAgICBJbnRlcmZhY2UgQyAgIC8gICAgICAgICAgfCAgICAgICAgICAgICBcICBOZXR3b3Jr IFRvcG9sb2d5DQogICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICB8ICAgICAgICAgICAg ICBcIChhYnN0cmFjdCkNCiAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgICAgIHwgICAgICAg ICAgICAgICBcDQogICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0tLS0tLS0r ICAgICstLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IE5ldHdvcmsgRG9tYWluIDEgfCAgIHwgTmV0 d29yayBEb21haW4gMiB8IC4uIHwgTmV0d29yayBEb21haW4gTiB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tKyAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0tLS0tLS0rDQog ICAgICAgIFZlbmRvciBYICAgICAgICAgICAgICAgICBWZW5kb3IgWSAgICAgICAgICAgICAgIFZl bmRvciBaDQoNCg0KV2hhdCBpcyBzaXR0aW5nIGFib3ZlIOKAnFZOQ+KAnSAodGhhdCBjb29yZGlu YXRlcyBvdmVyIG11bHRpLWRvbWFpbiBjb250cm9sbGVycykgY2FuIGJlIGFuIGludGVybmFsIHNl cnZpY2Ugb3JnYW5pemF0aW9uIChvZiB0aGUgc2FtZSBvcGVyYXRvcikgb3Igc2VydmljZSBwcm92 aWRlcnMgKGRpZmZlcmVudCBvcGVyYXRvcnMsIGZvcm1pbmcgY2FycmllcnMgb2YgY2Fycmllciku IFRoZSBjb250cm9sIGVudGl0eSBvZiB0aGVzZSBlbnRpdGllcyBpcyByZWZlcnJlZCB0byBhcyBD dXN0b21lciBOZXR3b3JrIGNvbnRyb2wgKENOQykuIFRoZSBWTkMg4oCTQ05DIGludGVyZmFjZSAo SW50ZXJmYWNlIEIpIGhhcyBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIHRoYW4gdGhlIFZOQy1QTkMg aW50ZXJmYWNlIChJbnRlcmZhY2UgQykuIFRvcG9sb2d5IGFic3RyYWN0aW9uIGlzIGp1c3Qgb25l IG9mIHRoZSByZXF1aXJlbWVudHMgYW5kIGluIG11bHRpLWRvbWFpbiBjYXNlLCB0aGUgVk5DIGlz IHBlcmZvcm1pbmcgbXVsdGktZG9tYWluIGNvb3JkaW5hdGlvbiBmdW5jdGlvbi4gVk5DIG5lZWRz IHRvIGhhdmUgYSBzdGFuZGFyZCBpbnRlcmZhY2UgdGhhdCBlbmFibGUgY29tbXVuaWNhdGlvbnMg d2l0aCBkaWZmZXJlbnQga2luZHMgb2YgZG9tYWluIG5ldHdvcmsgY29udHJvbC9tYW5hZ2VtZW50 IGNvbnRyb2wgKHdoaWNoIGlzIHJlZmVycmVkIHRvIGFzIFBOQywgeW91IGNhbGwgQU5DKS4gRWFj aCBkb21haW4gaGFzIGl0cyBvd24gd2F5cyBvZiBjb250cm9sbGluZyBpdHMgbmV0d29yaywgd2hp Y2ggQUNUTiBpcyBub3QgdG91Y2hpbmcgdGhvc2UgYXQgYWxsLiBXaGF0ZXZlciB0aGUgY2hvaWNl cyBvZiB2ZW5kb3IgY29udHJvbCByZWdpbWUgd2lsbCBjb250aW51ZSB0byBiZSBlbXBsb3llZCAo R01QTFMvQVNPTiwgUE5OSSwgTk1TLCBPcGVuRmxvdywgZXRjLikuDQoNCkZvciB0aGlzIG11bHRp LWRvbWFpbiBjb29yZGluYXRpb24gZnVuY3Rpb24gYXNzdW1lZCBieSBWTkMgc2hvdWxkIGJlIG9w ZXJhdGVkIG9uIGFuIGFic3RyYWN0IGxldmVsLiBXZSBkb27igJl0IHdhbnQgdG8gaW5qZWN0IHRo ZSBzYW1lIGxldmVsIG9mIGFjdHVhbCBuZXR3b3JrIHRvcG9sb2d5IChlLmcuLCBURUQpIGFzIHRo ZSBkb21haW4gY29udHJvbGxlciBvcGVyYXRlcyBpdHMgcGh5c2ljYWwvYWN0dWFsIG5ldHdvcmtz LiBJcyB0aGlzIGFncmVlYWJsZT8gWW91IHNhaWQgYWJvdmUgdGhpcyBpbiBjKSBUaGUgYWJzdHJh Y3QgdG9wb2xvZ3kgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQgaXMgY29tcGxldGVseSBkZWNvdXBs ZWQgZnJvbSB0aGUgcHJvdmlkZXLigJlzIGFjdHVhbCB0b3BvbG9neS4NCg0KTm93IHRoZSBWTkMg KG11bHRpLWRvbWFpbiBjb29yZGluYXRvcikgbmVlZHMgdG8gY29vcmRpbmF0ZSBzaWduYWxpbmcg YWNyb3NzIG11bHRpLWRvbWFpbiBjb250cm9sbGVycyAoaW4gdGVybXMgb2YgdGhlIHNlcXVlbmNl IG9mIHRoZSBlbmQtdG8tZW5kIHBhdGggYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMpLiBUaGlzIGlz IGEgbmV3IGVsZW1lbnQgSSBiZWxpZXZlIEFDVE4gd2lsbCBoYXZlIHRvIGRldmVsb3AuIFRoaXMg aW50ZXJmYWNlIEMgKFZOQy1QTkMpIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gSW50ZXJmYWNlIEIg KENOQy1WTkMpLiBUaGVyZSBhcmUgb3RoZXIgZGlmZmVyZW5jZXMgKHBsZWFzZSBzZWUgU2VjdGlv biA2LjUgb2YgdGhlIGZyYW1ld29yayBkb2N1bWVudCkuICBCdXQgSSBhZ3JlZSB3aXRoIHlvdSB0 aGF0IGZyb20gYW4gYWJzdHJhY3QgdG9wb2xvZ3kgc3RhbmRwb2ludCwgc2ltaWxhciBtb2RlbCB3 b3JrcyBmb3IgSW50ZXJmYWNlcyBCIGFuZCBDIGFzIHlvdSBzYWlkICBiKSAgICAgIFRoZSBzYWlk IGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0 cmFjdCBub2RlKSBvciBhcyBjb21wbGV4IChlLmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25u ZWN0ZWQgYnkgTSBhYnN0cmFjdCBsaW5rcykgYXMgdGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAo c3ViamVjdCB0byB0aGUgcHJvdmlkZXLigJlzIGFwcHJvdmFsKS4NCg0KQmVzdCByZWdhcmRzLA0K WW91bmcNCg0KDQoNCg0KRnJvbTogSWdvciBCcnlza2luIFttYWlsdG86SUJyeXNraW5AYWR2YW9w dGljYWwuY29tXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDk6MTcgQU0NClRvOiBC RUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywgRGFuaWVs OyBMZWV5b3VuZzsgYWN0bkBpZXRmLm9yZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdtYWlsLmNv bQ0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGkt YWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIFNlcmdpbywNCkEgY291cGxlIG9m IGNvbW1lbnRzIGluIGxpbmUuDQoNCkNoZWVycywNCklnb3INCg0KRnJvbTogQkVMT1RUSSwgU0VS R0lPIChTRVJHSU8pIFttYWlsdG86c2VyZ2lvLmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuY29tXQ0K U2VudDogTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDk6MTUgQU0NClRvOiBJZ29yIEJyeXNraW47 IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgYWN0bkBpZXRmLm9y ZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdtYWlsLmNvbQ0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZl KTsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxs aS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgSWdvciwNCg0KUGxlYXNlLCBz ZWUgaW4gbGluZQ0KDQpSZWdhcmRzDQpTZXJnaW8NCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21h aWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50OiB2ZW5lcmTDrCAxMCBvdHRvYnJl IDIwMTQgMjI6MzcNClRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IEtpbmcsIERhbmllbDsgTGVleW91 bmc7IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBp ZXRmLm9yZz47IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFp bC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0K U3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1l bnRzDQoNCkhpIERhbmllbGUsDQpQbGVhc2UsIHNlZSBpbiBsaW5lLg0KSWdvcg0KDQpGcm9tOiBE YW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t XQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDEwLCAyMDE0IDE6MjUgUE0NClRvOiBJZ29yIEJyeXNr aW47IEtpbmcsIERhbmllbDsgTGVleW91bmc7IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgYWN0 bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IGRpZWdvQHRpZC5lczxtYWlsdG86ZGll Z29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0K Q2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIElnb3IsDQoNCldoYXQgZG8geW91IG1l YW4gYnkgY2xpZW50IGhlcmU/IFRoZSBvbmUgdGhhdCBpcyB0aGUgZG9jdW1lbnQgaXMgY2FsbGVk IOKAnHNlcnZpY2UgcHJvdmlkZXLigJ0gb3IgdGhlIG9uZSB0aGF0IGlzIGNhbGxlZCDigJxjbGll bnTigJ0gPyBGcm9tIHdoYXQgeW91IHNlbmQgSSB0ZW5kIHRvIHRoaW5rIHlvdSBhcmUgdGFsa2lu ZyBhYm91dCB0aGUgc2VydmljZSBwcm92aWRlciwgYnV0IEkgbWlnaHQgYmUgd3JvbmcsIHBsZWFz ZSBjb3JyZWN0IG1lLg0KDQpJQj4+IEJ5IGNsaWVudCBJIG1lYW4gdGhlIGNsaWVudCBvZiBhIHRy YW5zcG9ydCBkb21haW4sIHRoZSBvbmUgd2hvIHNwZWFrcyBOZXRjb25mL1Jlc3Rjb25mIHRvIHRo ZSB0cmFuc3BvcnQgZG9tYWluLiBUaGUgZ3V5IHdobyBzcGVha3MgZnJvbSB0aGUgb3RoZXIgZW5k IChpLmUuIG9uIGJlaGFsZiBvZiB0aGUgdHJhbnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpICBpcyB0 aGUgdHJhbnNwb3J0IGRvbWFpbuKAmXMgSHlwZXJ2aXNvci4NCg0KU0I+Pj4gSXQgaXMgY2xlYXIg d2hhdCB5b3UgaW50ZW5kIGhlcmUsIGV2ZW4gaWYgd29yZCBjbGllbnQgaXQgc2VlbXMgdG8gbWUg bW9yZSByZWxhdGVkIHRvIGFwcGxpY2F0aW9uIHRoYW4gdG8gYSBzZXJ2aWNlIHByb3ZpZGVyLg0K DQpJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdHJhbnNwb3J0 IGRvbWFpbiBzZXJ2ZXIgYW5kICB0cmFuc3BvcnQgZG9tYWluIGNsaWVudC4gSSB3b3VsZCBhcmd1 ZSB0aGF0IHRoZSB2ZXJ5IHNhbWUgaW50ZXJmYWNlIGNhbiBiZSB1c2VkIGJldHdlZW4gYSBtdWx0 aS1kb21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkgYW5kIGl0cyBjbGllbnRzLiBOb3Qg YWxsIHN1Y2ggY2xpZW50cyBhcmUgZHVtYiwgYXMgRGFuaWVsZSBjbGFpbXMsIGFuZCBvbmx5IGNh cmUgYWJvdXQg4oCcYSBnaXZlbiBhbW91bnQgb2YgR2JwcyBmcm9tIEEgdG8gQuKAnS4gSXQgaXMg ZWFzeSB0byBlbnZpc2lvbiB0aGF0IHNvbWUgb2YgdGhlIGNsaWVudHMgd291bGQgd2FudCBmcm9t IFRlbGVmb25pY2EgYSBjb3VwbGUgb2YgU1JMRy1kaXNqb2ludCBhYnN0cmFjdCBsaW5rcywgc28g dGhhdCB0aGUgY2xpZW50cyBjYW4gaGF2ZSBhIHNheSBpbiB0aGUgcGxhY2VtZW50IG9mIHRoZWly ICBzZXJ2aWNlcyBhY3Jvc3MgdGhlIFRlbGVmb25pa2EgbmV0d29yay4gVGhyZWUgcG9pbnRzIGhl cmU6DQoNCmEpICAgICAgVGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gY29uZmlndXJlIGZ1bGx5 IG9yIHBhcnRpYWxseSB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgaGUgd2FudHMgdGhlIG5ldHdvcmsg dG8gcHJlc2VudCB0byBoaW07DQoNCmIpICAgICAgVGhlIHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kg Y291bGQgYmUgYXMgc2ltcGxlIChlLmcuIGEgc2luZ2xlIGFic3RyYWN0IG5vZGUpIG9yIGFzIGNv bXBsZXggKGUuZy4gTiBhYnN0cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBieSBNIGFic3RyYWN0 IGxpbmtzKSBhcyB0aGUgY2xpZW50IHdhbnRzIGl0IHRvIGJlIChzdWJqZWN0IHRvIHRoZSBwcm92 aWRlcuKAmXMgYXBwcm92YWwpDQoNCmMpICAgICAgVGhlIGFic3RyYWN0IHRvcG9sb2d5IHByZXNl bnRlZCB0byB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVkIGZyb20gdGhlIHByb3Zp ZGVy4oCZcyBhY3R1YWwgdG9wb2xvZ3kuDQoNClRoZXJlZm9yZSB0aGUgc2FtZSBpbnRlcmZhY2Uv c2V0IG9mIG1vZGVscyBjYW4gYmUgdXNlZCBiZXR3ZWVuIGFueSB0cmFuc3BvcnQgbmV0d29yayBw cm92aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhlcm1vcmUsIHRoZSBpbnRlcmZhY2UgY2FuIGJl IHVzZWQgaW4gdGhlIGhpZXJhcmNoaWNhbCB3YXksIHRoYXQgaXMsIGEgY2xpZW50IG9mIGEgdHJh bnNwb3J0IGRvbWFpbiBjYW4gc2VydmUgaXRzIG93biBjbGllbnRzIHVzaW5nIHRoZSBzYW1lIGlu dGVyZmFjZSBhcyBpdCB1c2VzIHRvIHRhbGsgdG8gaXRzIG93biBwcm92aWRlcihzKQ0KDQpNb3Jl b3ZlciBJIHdvdWxkIGF2b2lkIGluIHRoaXMgcGhhc2UgdG8gbWVudGlvbiBhbnkgcmVmZXJlbmNl IHRvIHByb3RvY29sIGltcGxlbWVudGF0aW9uIChlLmcuIE5ldGNvbmYvUmVzdGNvbmYpIDogSSB0 aGluayB3ZSBhcmUgaW4gdGhlIHBoYXNlIHRvIHVuZGVyc3RhbmQgYXJjaGl0ZWN0dXJlLCB3aGF0 IGFyZSB0aGUgcmVsZXZhbnQgaW50ZXJmYWNlcywgYW5kIHdoYXQgaW5mb3JtYXRpb24gaXMgZXhj aGFuZ2VkIG92ZXIgdGhlIHJlZmVyZW5jZSBwb2ludHMvaW50ZXJmYWNlcy4gSSBndWVzcyB0aGlz IGlzIGNsZWFybHkgc3RhdGVkIGFsc28gaW4gdGhlIGNoYXJ0ZXIgb2YgQm9GLg0KDQpJQj4+IEFn cmVlLiBJIHVzZWQgTmV0Y29uZi9SZXN0Y29uZiBhcyBhbiBleGFtcGxlIHRvIG1ha2UgaXQgY2xl YXIgd2hhdCBpbnRlcmZhY2UgSSB3YXMgdGFsa2luZyBhYm91dC4NCg0KIEF0IGFuIGFwcHJvcHJp YXRlIHRpbWUg4oCTIGNlcnRhaW5seSBub3Qgbm93IOKAkyB0aGUgbmV4dCBzdGVwIGlzIHRvIGNo ZWNrIHdpdGggb3RoZXIgU0RPcyBvbiB0aGUgYXZhaWxhYmlsaXR5IG9mIHJlbGV2YW50IGNvcmUv dGVjaG5vbG9neSBzcGVjaWZpYy9hcHBsaWNhdGlvbiBzcGVjaWZpYyBpbmZvcm1hdGlvbiBtb2Rl bCDigJxmcmFnbWVudHPigJ0sIGFuZCB0aGVuIGZpbmFsbHkgcHJvY2VlZCBvbiB0aGUgcGF0aCBv ZiBwcnVuaW5nL3JlZmFjdG9yaW5nIGFuZCBtYXBwaW5nIHRvIFJFU1QvSlNPTiwgTmV0Y29uZi9Z QU5HLCBhbmQgYW55IG90aGVyIHBvc3NpYmxlIGRhdGEgbW9kZWxpbmcgYW5kIGNvbmZpZ3VyYXRp b24gcHJvdG9jb2wgZXhpc3RpbmcuIFRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZyAgb2YgdGhlIEJv RiBzY29wZSAuDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgY2xpZW50IG9mIHRoZSBtdWx0aS1kb21h aW4gbmV0d29yayB3YW50cyB0byBoYXZlIGEgc28gZGV0YWlsZWQgdmlldyBvZiB0aGUgbmV0d29y aywgaGUgZG9lcyBub3QgY2FyZSBhYm91dCBkb21haW5zLCBpbnRlciBkb21haW4gbGlua3Mgb3Ig d2hhdGV2ZXIsIEkgd291bGQgc2F5IGhlIG9ubHkgY2FyZXMgYWJvdXQgYSBnaXZlbiBhbW91bnQg b2YgR2JwcyBmcm9tIEEgdG8gQiB3aXRoIGEgZ2l2ZW4gbWF4IGRlbGF5IGFuZCBwcm9iYWJseSBz b21lIGRpdmVyc2l0eSBwYXJhbWV0ZXJzLg0KDQpJQj4+IEFnYWluLCBieSBjbGllbnQgSSBtZWFu IG11bHRpLWRvbWFpbiBuZXR3b3JrIGNvbnRyb2xsZXIgKGUuZy4gVGVsZWZvbmljYSBTRE4gY29u dHJvbGxlciksIG5vdCB0aGUgY2xpZW50IHVzaW5nIHNlcnZpY2VzIG9mIHRoZSBtdWx0aS1kb21h aW4gbmV0d29yayAoaS5lLiBub3QgdGhlIFRlbGVmb25pY2EgY2xpZW50cykuIFN1Y2ggY2xpZW50 IHVzZXMgIHRoZSB0cmFuc3BvcnQgZG9tYWlucyBmb3IgYSByZWFzb24uIOKAnGEgZ2l2ZW4gYW1v dW50IG9mIEdicHMgZnJvbSBBIHRvIELigJ0gaXMgdG9vIGxvb3NlIGFuZCBsaXR0bGUgZm9yIHRo ZSBjbGllbnQgdG8gZG8gdGhlIG5ldHdvcmsgcGxhbm5pbmcuIElNTyB0aGUgY2xpZW50IG5lZWRz IHRvICpwbGFuKiB0aGUgYWJzdHJhY3QgdG9wb2xvZ2llcyBwcm92aWRlZCBieSB0aGUgdHJhbnNw b3J0IGRvbWFpbnMgdGhlIHNhbWUgb3Igc2ltaWxhciB3YXkgYXMgaGUgd291bGQgcGxhbiBoaXMg b3duIGFjdHVhbCB0b3BvbG9neS4NCg0KU0I+Pj4geWVzLCBzdXJlLCBpbiB5b3UgdmlldyBvZiDi gJxjbGllbnTigJ0gLCB0aGlzIGlzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIERhbmllbGUgaXMgdGFs a2luZywgc28gYW4gYWJzdHJhY3QgdmlldyBvZiB3aGF0IGlzIHRoZSByZWFsIHRyYW5zcG9ydCBu ZXR3b3JrIGlzIGNvbnNpZGVyZWQgYXQgdGhpcyBsZXZlbC4gQXMgSSBzYWlkIHRvIFlvdW5nLCBp biBteSBwcmV2aW91cyBtYWlsLCBpbiB0aGUgY2FzZSBvZiBhIHNpbmdsZSBkb21haW4gc2NlbmFy aW8gVk5DIGFuZCBQTkMgY291bGQgYWxzbyBjb2luY2lkZSBidXQgaW4gY2FzZSBvZiBhIG11bHRp LWRvbWFpbiBzY2VuYXJpb3MgdGhlIHNjb3BlIGlzIHRvIHByb3ZpZGUgdG8gYXBwbGljYXRpb24g bGF5ZXIgYSBzaW5nbGUgdmlydHVhbGl6ZWQgdmlldyBvZiB0aGUgdW5kZXJsaW5lIG11bHRpIGRv bWFpbiBuZXR3b3JrLg0KDQpPbiB0aGUgb3RoZXIgc2lkZSwgdGhlIG9uZSB0aGF0IGNhcmVzIGFi b3V0IGFsbCBvZiB0aGUgaXNzdWVzIHlvdSBsaXN0ZWQgaXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIg KGFzIHBlciBhY3R1YWwgZG9jdW1lbnQgdGVybWlub2xvZ3kpLiBIb3dldmVyIGFsc28gdGhlIHNl cnZpY2UgcHJvdmlkZXIgZG9lcyBub3QgZ28gaW50byBwaHlzaWNhbCBpbXBhaXJtZW50IGRldGFp bHMuIEhlIGNhcmVzIGFib3V0IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZSBib3JkZXJzIG9mIHRo ZSBkb21haW5zLCBpbnRlciBkb21haW4gbGlua3MuIEhvdyBzdWNoIGNvbm5lY3Rpdml0eSBpcyBw cm92aXNpb25lZC9tYW5hZ2VkIGlzIHRoZSBuZXR3b3JrIHByb3ZpZGVyIGJ1c2luZXNzLiBUaGUg bmV0d29yayBwcm92aWRlcyBtaWdodCBiZSB1c2luZyBHTVBMUywgTk1TIGFuZCBPTkYgY29udHJv bGxlciB3aXRoIE9wZW4gRmxvdyBvciB3aGF0ZXZlciB0byBjb250cm9sIHRoZSBuZXR3b3JrLiBN YXliZSBjYWxsaW5nIGl0IFBOQyBpcyBjb25mdXNpbmc/IFRoZSBQTkMgY2FuIGJlIGFueSBvZiB0 aGUgdGhpbmdzIEnigJl2ZSBsaXN0ZWQgYW5kIG11Y2ggbW9yZS4NCg0KSUI+PiBJbiB0aGlzIGNh c2UgbXkgY2xpZW50IGlzIHlvdXIgc2VydmljZSBwcm92aWRlciA7PSkuIFlvdSBhcmNoaXRlY3R1 cmFsbHkgc2VwYXJhdGUgY2xpZW50IGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIsIGJlY2F1c2Ug eW91IHByb2JhYmx5IGJlbGlldmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBzdGFuZGFyZGl6ZSB0 aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIHR3by4gSSBkaXNhZ3JlZSB3aXRoIHRoYXQgYW5kIGRv buKAmXQgdGhpbmsgQUNUTiBzaG91bGQgd29yayBvbiB0aGlzLiBJbiB0aGUgY29udGV4dCBvZiBB Q1ROIEkgc2VlIG9ubHkgdHdvIGNvbnN0cnVjdHM6IFRyYW5zcG9ydCBkb21haW4gY29udHJvbGxl ciAodHJhbnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpIGFuZCAgVHJhbnNwb3J0IGNsaWVudCBjb250 cm9sbGVyICh0cmFuc3BvcnQgc2VydmljZSB1c2VyKS4NCg0KU0I+Pj4gQUNUTiBoZXJlIGlzIG5v dCByZWludmVudGluZyB0aGUgd2hlZWwgLCBpbiBvdGhlciBTRE8gU0ROIHNwZWNpZmljIGlzIGNv bnNpZGVyZWQgIHRoZSBhcHBsaWNhdGlvbiBsYXllciAsIGFuZCB0aGUgaW50ZXJmYWNlIGJldHdl ZW4gQUwgYW5kIFNETiBjb250cm9sbGVyIChpbiB0aGlzIGNhc2UgdGhlIFZOQyBvZiBBQ1ROKSAu IFRoaXMgaW50ZXJmYWNlIHBlcm1pdCB0byBhbnkgY2xpZW50IHRvIGRpcmVjdGx5IGltcGFjdCB0 byBoaXMgb3duIHNlcnZpY2VzIGFuZCBoaXMgb3duIOKAnHZpcnR1YWxpemVk4oCdIHJlc291cmNl cyAuDQoNCg0KSGVuY2UgdGhlIGludGVyZmFjZXMgdG8gYmUgY29uc2lkZXJlZCBhcmUgdHdvLCBu b3QgdGhyZWUgKGFzIERhbiBzYWlkKSBJIHRoaW5rIHRoaXMgcmVwbGllcyB0byBxdWVzdGlvbnMg MSBhbmQgMy4gSnVzdCB0byBhZGQgc29tZXRoaW5nIHJlZ2FyZGluZyAyLCBJIHdvdWxkIHNheSB0 aGF0IHRoZXkgbmVlZCBqdXN0IGEgc2luZ2xlIGVudHJ5IHBvaW50IHRvIHRoZSBuZXR3b3JrIGNv bnRyb2wgKGNvdWxkIGJlIGEgc21hbGwgcGllY2Ugb2YgY29kZSBydW5uaW5nIG9uIHRvcCBvZiB0 aGUgUENFIG9mIHlvdXIgR01QTFMgZG9tYWluKSwgd2hpY2ggYWN0cyBhcyBhbiBpbnRlcmZhY2Ug YmV0d2VlbiB0aGUgVk5DIGFuZCB0aGUgY29udHJvbCBwbGFuZSBvZiB5b3VyIG5ldHdvcmsgYW5k IHBlcmZvcm1zOiDigJwtIE1hcHBpbmcgb2YgcGh5c2ljYWwgYW5kIHZpcnR1YWwgcmVzb3VyY2Vz 4oCdIGFuZCAg4oCcUmVxdWVzdHM6IHBhdGgsIHByb3Zpc2lvbiwgbW9kaWZ5IGFuZCByZXN0b3Jl 4oCdLg0KDQpJQj4+IEFzIEkgc2FpZCwgdGhpcyBpcyB0aGUgdGFzayBvZiB0aGUgdHJhbnNwb3J0 IGRvbWFpbiBIeXBlcnZpc29yLCB3aG9zZSByb2xlIGlzLCBlc3NlbnRpYWxseSwgdG8gdHJhbnNs YXRlIGJhY2sgYW5kIGZvcnRoIGFic3RyYWN0IDw9PiBhY3R1YWwgdG9wb2xvZ3kgZWxlbWVudHMg YW5kIHNlcnZpY2UgcmVxdWVzdHMvcmVzcG9uc2VzIGNvbnRhaW5pbmcgdGhlIGFic3RyYWN0L2Fj dHVhbCB0b3BvbG9neSBwYXRocy4gSSB0aGluayB0aGF0IHRoZSBub3J0aC9zb3V0aCBpbnRlcmZh Y2UgYmV0d2VlbiB0aGUgdHJhbnNwb3J0IGRvbWFpbiBIeXBlcnZpc29yIGFuZCB0aGUgZW50aXR5 IHJlcHJlc2VudGluZyB0aGUgY2xpZW50IG9mIHRoZSB0cmFuc3BvcnQgZG9tYWluIChubyBtYXR0 ZXIgaG93IHlvdSBjYWxsIGl0KSBpcyB0aGUgb25seSBpbnRlcmZhY2UgQUNUTiBjYW4gd29yayBv biB3aXRoIHRoZSBob3BlIHRvIHByb2R1Y2Ugc29tZXRoaW5nIHVzZWZ1bC4NCg0KQ2hlZXJzDQpE YW5pZWxlDQoNCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0 aWNhbC5jb21dDQpTZW50OiB2ZW5lcmTDrCAxMCBvdHRvYnJlIDIwMTQgMDM6MTYNClRvOiBLaW5n LCBEYW5pZWw7IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5v cmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5l czxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZA Z21haWwuY29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNl Y2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCllvdW5nIGFuZCBEYW4s DQoNCkl0IGRvZXMgbm90IG1hdHRlciBob3cgeW91IGNhbGwgbWUsIGFuZCBhcyBKb2huIGlzIGhl bHBmdWxseSBhcHBseWluZywgeW91IGNhbiBpZ25vcmUgd2hhdCBJIGFtIHNheWluZy4gQnV0IGxl dCBtZSBleHBsYWluIGluIHNvbWUgbW9yZSBkZXRhaWxzIHdoYXQgSSBtZWFudC4NCg0KU3VwcG9z ZSB3ZSBoYXZlIGEgY2xpZW50IChzdWNoIGFzIFRGSykgb2YgYSBtdWx0aS1kb21haW4gdHJhbnNw b3J0IG5ldHdvcmssIHdobyB3YW50cyB0byBwcm92aXNpb24gYW5kIG1hbmlwdWxhdGUgZTJlIHRy YW5zcG9ydCBzZXJ2aWNlcyB0aGUgd2F5IGhlIHdhbnRzIGl0IChpLmUuIGFwcGx5aW5nIGhpcyBw b2xpY2llcykuIFdoYXQgd291bGQgc3VjaCBjbGllbnQgbmVlZD8NCg0KDQoxLiAgICAgQW4gYWNj ZXNzIHRvIGEgdW5pZmllZCBuZXR3b3JrIFRFIHRvcG9sb2d5IHRoYXQgY291bGQgYmUgdW5kZXJz dG9vZCBhbmQgdXNlZCBieSB0aGUgY2xpZW504oCZcyBwYXRoIGNvbXB1dGVyIHRvIHNlbGVjdCBz ZXJ2aWNlIGUyZSBwYXRocy4gSG93IGRvZXMgdGhlIGNsaWVudCBnZXQgc3VjaCBhIHRvcG9sb2d5 PyBUaGUgbmVjZXNzYXJ5IG92ZXJsYXkgdG9wb2xvZ3kgY29tcHJpc2VzIGFic3RyYWN0IHRvcG9s b2dpZXMgcHJlc2VudGVkIGZvciB0aGUgY2xpZW50IGJ5IGVhY2ggb2YgdGhlIHRyYW5zcG9ydCBk b21haW5zICsgaW50ZXItZG9tYWluIFRFIGxpbmtzLiBIZW5jZSB3ZSBhcmUgdGFsa2luZyBhYm91 dCBpbnRlcmZhY2UgIzEgKGFuZCBkYXRhIG1vZGVsICMxKSBiZXR3ZWVuIGEgcHJvdmlkZXIgaHlw ZXJ2aXNvci9WTkMgYW5kIHRoZSBjbGllbnQgY29udHJvbGxlciB0byBleHBvc2UgaW4gYSB1bmlm aWVkIGFic3RyYWN0ICB3YXkgIGl0cyB0b3BvbG9neSBvbiBwZXIgY2xpZW50L3RlbmFudCBiYXNp cy4gRnVydGhlcm1vcmUsIHRoZSBjbGllbnQgY29udHJvbGxlciBjYW4gdXNlIHRoaXMgaW50ZXJm YWNlIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gdG8gbW9kaWZ5IHRoZSBzYWlkIGFic3RyYWN0 IHRvcG9sb2d5IChzdWJqZWN0IHRvIHRoZSBwcm92aWRlcuKAmXMgIGFwcHJvdmFsKSwgYmVjYXVz ZSB0aGUgY2xpZW50IGlzIHRoZSBvbmx5IGd1eSB3aG8ga25vd3MgaG93IHRoZSBhYnN0cmFjdCB0 b3BvbG9neSBleHBvc2VkIHRvIGhpbSBzaG91bGQgbG9vayBsaWtlIHRvIGJlIHVzZWZ1bCAoZS5n LiB3aGljaCBhbmQgaG93IHRoZSBhYnN0cmFjdCBsaW5rcyBzaG91bGQgYmUgZGlzam9pbnQgZnJv bSBlYWNoIG90aGVyLCBob3cgbWFueSBvZiB0aGVtIHNob3VsZCBiZSBwcm92aWRlZCwgdGhlaXIg YXR0cmlidXRlcywgZGVzaXJlZCByZWNvdmVyeSBjYXBhYmlsaXRpZXMsIGV0YywpLiBUaGlzIGtu b3dsZWRnZSBpcyBzdXBwb3NlZCB0byBjb21lIGZyb20gdGhlIGNsaWVudOKAmXMgbmV0d29yayBw bGFubmluZy4NCg0KMi4gICAgIEEgd2F5IHRvIHByb3Zpc2lvbi9tb2RpZnkvZGVsZXRlIGUyZSBz ZXJ2aWNlcyB3aXRoIHRoZSB1c2Ugb2Ygc28gY29tcHV0ZWQgZTJlIHBhdGhzLiBUaGUgY2xpZW50 4oCZcyBjb250cm9sbGVyIGRvZXMgdGhhdCBieSBjaG9wcGluZyB0aGUgcGF0aHMgaW50byBwZXIt ZG9tYWluIHNlZ21lbnRzIGFuZCBpbnN0cnVjdHMgcmVzcGVjdGl2ZSBkb21haW4gVk5Dcy9IeXBl cnZpc29ycyB0byBzZXQgdXAvbWFuaXB1bGF0ZSBzZXJ2aWNlIHJlc3BlY3RpdmUgY29ubmVjdGlv biBzZWdtZW50cy4gSGVuY2Ugd2UgYXJlIHRhbGtpbmcgYWJvdXQgaW50ZXJmYWNlICMyIChkYXRh IG1vZGVsICMyKSBmb3IgdGhlIHNlcnZpY2Ugc2VnbWVudCBtYW5pcHVsYXRpb247DQoNCjMuICAg ICBBIHdheSB0byBtb25pdG9yLCB0cm91Ymxlc2hvb3QsIGNhcnJ5IG91dCBtYWludGVuYW5jZSBv ZiB0aGUgYWN0aXZlIGUyZSBzZXJ2aWNlcy4gVGhpcyB3b3VsZCByZXF1aXJlIGludGVyZmFjZSAj MyAoZGF0YSBtb2RlbCAjMykgYmV0d2VlbiB0aGUgY2xpZW504oCZcyBjb250cm9sbGVyIGFuZCBk b21haW5zIFZOQ3MvSHlwZXJ2aXNvcnMgZm9yIHRoaXMgcHVycG9zZS4NCg0KU28sIHdlIGFyZSB0 YWxraW5nIDMgWWFuZyBtb2RlbHMgd2l0aCByZXF1aXJlZCBtb2RpZmljYXRpb25zIHRvIG5laXRo ZXIgTmV0Y29uZi9SZXN0Y29uZiwgbm9yICBUbyBhbnkgb3RoZXIgbWFuYWdlbWVudCwgcm91dGlu ZyBvciBzaWduYWxpbmcgcHJvdG9jb2wuDQoNCk5vdyBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rp b25zIHRvIHlvdToNCg0KMS4gICAgIEluIHRoaXMgZXhhbXBsZSwgd2hhdCBlbHNlIChpbiBhZGRp dGlvbiB0byB0aGVzZSB0aHJlZSBtb2RlbHMpIHRoZSBjbGllbnQgc3VjaCBhcyBURksgaW4geW91 ciBvcGluaW9uIHdvdWxkIG5lZWQ/DQoNCjIuICAgICBXaGF0IGVsc2UgdGhlIG5ldHdvcmsgcHJv dmlkZXJzIGFuZCB0aGVpciB2ZW5kb3JzIHN1Y2ggYXMgQURWQSBvciBDSUVOIHdvdWxkIG5lZWQ/ DQoNCjMuICAgICBXaGF0IGlzIHRoZSBpbXBvcnRhbmNlIG9mIGEgY29uc3RydWN0IHN1Y2ggYXMg UE5DPw0KDQoNCk15IGFuc3dlciB0byAzLiDigJxJcyBub3QgaW1wb3J0YW50IGF0IGFsbCwgaXJy ZWxldmFudOKAnSBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0KDQphKSAgICAgV2hhdCBoYXBw ZW5zIGJleW9uZCB0aGUgVk5DL0h5cGVydmlzb3IgaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgaXMg Y29tcGxldGVseSBwcm9wcmlldGFyeS4NCg0KYikgICAgIFRoZXJlIGNvdWxkIGJlIG51bWVyb3Vz IHdheXMgYXMgdG8gaG93IHRoZSBwcm92aWRlciBuZXR3b3JrIGlzIG1hbmFnZWQuIEV4YW1wbGVz OiBjZW50cmFsaXplZCBQTkMgKGFzIHlvdSBjYWxsIGl0KSwgQURWQSBzdHlsZSBHTVBMUyBiYXNl ZCBuZXR3b3JrIGludGVsbGlnZW5jZSwgQ0lFTiBzdHlsZSBQTk5JIGJhc2VkIGNvbnRyb2wgcGxh bmUsIGV0Yy4gV2h5IGlzIHRoYXQgb2YgQUNUTuKAmXMgYnVzaW5lc3M/DQoNCkNoZWVycywNCkln b3INCg0KRnJvbTogS2luZywgRGFuaWVsIFttYWlsdG86ZC5raW5nQGxhbmNhc3Rlci5hYy51a10N ClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDQ6NTggUE0NClRvOiBMZWV5b3VuZzsg SWdvciBCcnlza2luOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8bWFp bHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxtYWls dG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwu Y29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVs bGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIEFsbCwgaW5jbHVkaW5nIOKA nElnbm9y4oCdIDstKQ0KDQpUeXBpY2FsIGRpY2hvdG9teSBiZXR3ZWVuIHdoYXQgb3BlcmF0b3Jz IHdhbnQgYW5kIHdoYXQgdmVuZG9ycyBhcmUgYWN0dWFsbHkgd2lsbGluZyB0byBwcm92aWRlLCBn cm91cCBjb25zZW5zdXMgd2lsbCBldmVudHVhbGx5IGhlbHAgcmVzb2x2ZSB0aGF0LiBFaXRoZXIg d2F5LCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIEZyYW1ld29yayBJLUQgaXMgdHJ5aW5nIHRv IGZvY3VzIEFDVE4gZGlzY3Vzc2lvbiBhbmQgc2NvcGUgKGkuZS4sIHRoZSBwcm90b2NvbCB3b3Jr KSBvbiB0aGUgaW50ZXJmYWNlcyB3aGljaCBhcmUgaW4gc2NvcGUsIG5hbWVseToNCg0KMS4gVGhl IENOQy1WTkMgSW50ZXJmYWNlIChDVkkpDQotIENyZWF0ZSwgbW9kaWZ5IGFuZCBkZWxldGUgdmly dHVhbCBuZXR3b3JrIHNlcnZpY2UgaW5zdGFuY2VzDQotIFJlc291cmNlIG1vZGVsDQoNCjIuIFRo ZSBWTkMtUE5DIEludGVyZmFjZSAoVlBJKQ0KLSBNYXBwaW5nIG9mIHBoeXNpY2FsIGFuZCB2aXJ0 dWFsIHJlc291cmNlcw0KLSBSZXF1ZXN0czogcGF0aCwgcHJvdmlzaW9uLCBtb2RpZnkgYW5kIHJl c3RvcmUNCg0KQXMgWW91bmcgc3VnZ2VzdHMsIGlmIHRoZSBWTkMgcmVjZWl2ZWQgcGh5c2ljYWwg dG9wb2xvZ3kgaW5mbyBpdCB3b3VsZCBiZSBwZXJmb3JtaW5nIHRoZSByb2xlIG9mIHRoZSBQaHlz aWNhbCBOZXR3b3JrIENvbnRyb2xsZXIgKFBOQyksIHdoaWNoIGlzIG9idmlvdXNseSBhIChzb21l aG93KSByZXF1aXJlZCBmdW5jdGlvbiwgYnV0IHRoZSBpbnRlcmZhY2UgKGRpcmVjdCBwcm92aXNp b25pbmcgb2YgdGhlIGFjdHVhbCBwaHlzaWNhbCBuZXR3b3JrKSBpcyBvdXQgb2Ygc2NvcGUgZm9y IEFDVE4uDQoNCkJyLCBEYW4uDQoNCkZyb206IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWV5b3VuZw0KU2VudDogMDkgT2N0b2JlciAyMDE0IDIxOjMy DQpUbzogSWdvciBCcnlza2luOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5v cmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5l czxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZA Z21haWwuY29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUmU6IFtBY3RuXSBk cmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBJZ25v ciwNCg0KVGhhbmsgeW91IGZvciBwcm92aWRpbmcgeW91ciBjb21tZW50IHRoYXQgcGF1c2VzIHVz IHRvIHRoaW5rIG1vcmUgYW5kIHVuZGVyc3RhbmQgb24gdGhlIHNhbWUgbGV2ZWwuIEkgdGhpbmsg eW91ciBjb21tZW50IHdpbGwgY29udHJpYnV0ZSB0byBjcnlzdGFsbGl6ZSB0aGUgc2NvcGUgb2Yg d29yayBoZXJlLg0KDQpGaXJzdCBvZiBhbGwsIEkgdGhpbmsgdGhlcmUgd2FzIGEgbWlzdW5kZXJz dGFuZGluZyBoZXJlLiBGaXJzdCwgeW91ciBhc3N1bXB0aW9uIG9uIFZOQyByZWNlaXZpbmcgYWN0 dWFsIHVuZGVybHlpbmcgdG9wb2xvZ3kgaXMgaW5jb3JyZWN0LiBJZiBWTkMgd2VyZSB0byBoYXZl IGFjdHVhbGx5IHRvcG9sb2d5IChlLmcuIFRFRCkgb2YgYSBuZXR3b3JrLCB0aGlzIHdvdWxkIGJl IGNhbGxlZCBhIFBOQyBhbmQgdGhpcyBpcyBvdXQgb2Ygc2NvcGUgb2YgQUNUTi4gVGhpcyBhc3Bl Y3QgaGFzIGJlZW4gZGlzY3Vzc2VkIGJ5IGVtYWlsIHRocmVhZHMgRGFuaWVsZSBzdGFydGVkIGEg ZmV3IHdlZWtzIGFnby4gQ2hlY2sgdGhlIGFyY2hpdmUgb24gdGhhdC4gVGhlIHJlYXNvbiB0aGlz IGlzIG91dCBvZiBzY29wZSBpcyB0aGF0IFBOQyBtdWx0aS1kb21haW4gaXNzdWUgaXMgbm8gZGlm ZmVyZW50IGZyb20gdG9kYXnigJlzIEdNUExTL1BDRSBpc3N1ZSwgZXNwZWNpYWxseSBpbiBsaWdo dCBvZiBILVBDRS4gQUNUTiBkb2VzIG5vdCBzdGVwIG9uIHRob3NlIGFyZWFzLiBXaGF0IFZOQyBy ZWNlaXZlcyBmcm9tIGVhY2ggUE5DIChkb21haW4gY29udHJvbGxlcikgaXMgYW4gYWJzdHJhY3Rl ZCB0b3BvbG9neSB3aXRoIHZhcnlpbmcgZGVncmVlcyBmcm9tIGFjdHVhbCB1bmRlcmx5aW5nIHRv cG9sb2d5LiBUaGUgcmVhc29uIHdoeSB3ZSBkaXN0aW5ndWlzaCB0aGUgdGVybSBWTkMgZnJvbSBQ TkMuDQoNCldoYXQgY2FuIGJlIGRlZmluZWQgb24gVk5DLVBOQyBpcyBhIHZlcnRpY2FsIHNpZ25h bGluZyBjb29yZGluYXRpb24gZnJvbSBWTkMgdG8gZWFjaCBQTkMuIEFzIGxvbmcgYXMgdGhlIGRl dGFpbGVkIHBhdGggY29tcHV0YXRpb24gYW5kIHNpZ25hbGluZyB3aXRoaW4gYSBkb21haW4gYXJl IGNvbXBsZXRlbHkgdXAgdG8gdGhlIGRvbWFpbiBQTkMuIFZOQyBpcyBub3QgdG8gYmUgb3BlcmF0 ZWQgb24gdGhlIHNhbWUgbGV2ZWwgYXMgUE5DLiBJdHMgZW5kLXRvLWVuZCBwYXRoIGNvbXB1dGF0 aW9uIGlzIGJhc2VkIG9uIHdoYXQgaXMgZXhwb3NlZCBmcm9tIFBOQ3MgdG8gVk5DLiBUaGUgYWN0 dWFsIHRvcG9sb2d5IGluZm9ybWF0aW9uIGRldGFpbHMgaXMga2VwdCBieSBQTkNzIGFuZCB0aGUg UE5DcyBleHBvc2UgYWJzdHJhY3RlZCB0b3BvbG9neSB0aGF0IGNhbiBoaWRlIHRoZSBleGFjdCBk ZXRhaWxzIHdoaWxlIGV4cG9zaW5nIGEgbWluaW11bSBsZXZlbCBvZiBjb25zdHJhaW50cy4gRm9y IGluc3RhbmNlLCB0aGUgU1JMRyBvZiB2aXJ0dWFsIGxpbmtzICh3aGljaCBtYXkgYmUgY29uY2F0 ZW5hdGVkIGFjdHVhbCBsaW5rcykgY2FuIGJlIGV4cG9zZWQgZm9yIGRpdmVyc2l0eSByb3V0aW5n IGNhbGN1bGF0aW9uIGF0IHRoZSBWTkMuIFRoaXMgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBleHBv c2luZyB0aGUgYWN0dWFsIFRFIHRvcG9sb2d5LiBZb3UgY2FuIHZpZXcgdGhpcyBhcyB0d28gbGV2 ZWwgb2YgcGF0aCBjb21wdXRhdGlvbi4gVk5DIGZpcnN0IGNvbXB1dGVzIGFuIGVuZC10by1lbmQg cGF0aCAodXNpbmcgd2hhdGV2ZXIgY29uc3RyYWludCBpbmZvcm1hdGlvbiBpdCBoYXMpLCB0aGVu IGNvb3JkaW5hdGVzIHdpdGggZWFjaCBQTkMgKHRlbGxpbmcgdGhlIGJvcmRlciBub2RlcyBpbmZv cm1hdGlvbiksIHRoZW4gZWFjaCBQTkMgY29tcHV0ZXMgdGhlIGRvbWFpbiBzcGVjaWZpYyBwYXRo LiBXaGVuIGEgUE5DIGNhbm5vdCBwcm92aWRlIGEgcGF0aCBzZWdtZW50IGluIGl0cyBkb21haW4s IHRoZW4gdGhpcyBuZWVkcyB0byBiZSBzaWduYWxlZCB0byBWTkMgc28gdGhhdCB0aGUgVk5DIHdv dWxkIGFycmFuZ2UgYW4gYWx0ZXJuYXRlIHBhdGggc2VnbWVudCB0byBiZSBhYmxlIHRvIGZpbmQg YSBmZWFzaWJsZSBlbmQtdG8tZW5kIHBhdGguICBJIHdvdWxkIHNheSB0aGlzIGlzIGEg4oCcdHdv LXBoYXNl4oCdIHNpZ25hbGluZyBhbmQgcGF0aCBjb21wdXRhdGlvbi4gVGhlIHBvaW50IGlzIHRo YXQgdGhlcmUgbXVzdCBiZSBzb21lIGxldmVsIG9mIGhpZGluZyBvbiBhYnN0cmFjdCB0b3BvbG9n eSBleHBvc3VyZSBmcm9tIFBOQyB0byBWTkMgYW5kIHByb3ByaWV0YXJ5IGNoYXJhY3RlcmlzdGlj cyBvZiBvcHRpY2FsIGRldmljZXMgbmVlZCB0byBiZSBkZWFsdCBvbmx5IHdpdGggdGhlIGNvcnJl c3BvbmRpbmcgUE5DLg0KDQpSZWdhcmRpbmcgdGhlIHRlcm0gUE5DIHZzLiBBTkMsIEkgd291bGRu 4oCZdCBjb25jZXJuIHRvbyBtdWNoIGFib3V0IHRoZSB0ZXJtaW5vbG9neSB3aGljaGV2ZXIgd29y a3MgYmV0dGVyLiBUaGFuayB5b3UgZm9yIHlvdXIgc3VnZ2VzdGlvbi4NCg0KTGFzdGx5LCBwbGVh c2UgY2hlY2sgdGhlIHVzZS1jYXNlcyB3cml0dGVuIGJ5IG9wZXJhdG9ycyBpbiB0aGUgYmVsb3cg bGlua3MgdGhhdCBjb25zaXN0ZW50bHkgc2F5IHRoZXkgbmVlZCBhIHN0YW5kYXJkIGludGVyZmFj ZSB0aGF0IGNhbiBjb29yZGluYXRlIHRoZWlyIG11bHRpLWRvbWFpbiBpc3N1ZXMuDQoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhbmctYWN0bi1tdWx0aWRvbWFpbi1k Y2kvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rbGVlLWFjdG4tY29u bmVjdGl2aXR5LW11bHRpLXZlbmRvci1kb21haW5zLw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQta3VtYWtpLWFjdG4tbXVsdGl0ZW5hbnQtdm5vLw0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotYWN0bi12bm8tbXVsdGlkb21haW5zLw0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hpbi1hY3RuLW12bm8tbXVs dGktZG9tYWluLw0KDQpSZWdhcmRzLA0KWW91bmcNCg0KVGhhbmtzLA0KWW91bmcNCg0KDQpGcm9t OiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpTZW50OiBU aHVyc2RheSwgT2N0b2JlciAwOSwgMjAxNCAxOjQ4IFBNDQpUbzogQkVMT1RUSSwgU0VSR0lPIChT RVJHSU8pOyBMZWV5b3VuZzsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERh bmllbGUgQ2VjY2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1 YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBM IChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50 eHQgY29tbWVudHMNCg0KSGkgWW91bmcsDQoNCkkgYmVsaWV2ZSBoYXZpbmcgdGhlIHNhbWUgaW5z dGFuY2Ugb2YgVk5DIHRhbGtpbmcgdG8gZGlmZmVyZW50IHZlbmRvciBkb21haW4gUE5DcyBpcyBh biBleHRyZW1lbHkgIGlkZWFsaXN0aWMgdmlldy4NCg0KPT09PT4gQlRXIEkgZmluZCBQTkMgaXMg YSBiYWQgdGVybSwgSSBsaWtlIG11Y2ggYmV0dGVyIEFjdHVhbCBOZXR3b3JrIENvbnRyb2xsZXIg IChBTkMpLiBWTkMgKGEuay5hLiBhIEh5cGVydmlzb3IpIGlzIG1hbmFnaW5nIGFic3RyYWN0IHRv cG9sb2dpZXMsIGFuZCB0byBiZSBhYmxlIGRvIHRoYXQsIGl0IHRhbGtzIHRvIGEgQU5DLSBhIGNv bnRyb2xsZXIgd2hpY2ggaGFzIGFuIGFjY2VzcyBhbmQgbWFuYWdlcyBhY3R1YWwgcHJvdmlkZXIg bmV0d29yaykuDQoNCk9uZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBWTkMgbmVlZHMgdG8gdW5k ZXJzdGFuZCB1bmRlcmx5aW5nIGFjdHVhbCB0b3BvbG9neSwgZm9yIGV4YW1wbGUsIHRvIGVuc3Vy ZSB0aGF0IHR3byBhYnN0cmFjdCBURSBsaW5rcyBhcmUgU1JMRyBkaXNqb2ludCBhcyByZXF1ZXN0 ZWQuIEFjdHVhbCB0b3BvbG9neSBzZW1hbnRpY3MgKGVzcGVjaWFsbHkgaW4gV0RNIGxheWVyKSBp cyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHZlbmRvciB0byB2ZW5kb3IgYW5kIGNvbnRhaW5zIGEgZ3Jl YXQgdmFyaWV0eSBvZiBwcm9wcmlldGFyeSBleHRlbnNpb25zLCBmYWlsaW5nIHRvIHVuZGVyc3Rh bmQgd2hpY2ggbGVhZHMgdG8gcHJvZHVjaW5nIHVucHJvdmlzaW9uYWJsZSBzZXJ2aWNlIHBhdGhz LiBEbyB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBhIHNpbmdsZSBWTkMgY2FuIHRhbGsgaW4gdGhl IHNhbWUgd2F5IHRvIEFEVkEsIElORk4sIEFMVSBhbmQgSHVhd2VpIEFOQ3M/IFRoaXMgaXMgZXF1 aXZhbGVudCB0byBhc2sgYWxsIG9wdGljYWwgcHJvdmlkZXJzIHRvIHN3aXRjaCB0byBXU09OIDo9 KS4NCg0KVGhpcyBpcyBub3QgdG8gc2F5IHRoYXQgeW91IGNhbm5vdCBidWlsZCBhIGhpZXJhcmNo eSBvZiBWTkNzLCBidXQgaW4gdGhpcyBjYXNlIE5vcnRoIFZOQyBwbGF5cyByb2xlIG9mIGEgY2xp ZW50IG5ldHdvcmsgY29udHJvbGxlciB3cnQgdG8gU291dGggVk5DLCB0aGF0IGlzLCB1c2VzIHRo ZSBzYW1lIFggaW50ZXJmYWNlLg0KSUhNTyB3aGVuZXZlciBhIFZOQyBoYXMgdG8gdGFsayB0byBh IEFOQywgaXQgZG9lcyBzbyBpbiBhIHByb3ByaWV0YXJ5IHdheSwgaS5lLiBBRFZBLCBJTkZOLCBB TFUgYW5kIEh1YXdlaSB3aWxsIGhhdmUgdGhlaXIgb3duIFZOQ3MgZXhwb3NpbmcgdGhlIHNhbWUg bm9ydGggYm91bmQgaW50ZXJmYWNlIHRvIHBvdGVudGlhbGx5IHRoZSBzYW1lIGNsaWVudCAoZS5n LlRGSykuDQpJSE1PIGludGVyZmFjZSBYIGlzIHRoZSBvbmx5IGludGVyZmFjZSB0aGF0IHRoZSBB Q1ROIGNhbiB3b3JrIG9uLg0KDQpDaGVlcnMsDQpJZ29yDQoNCkZyb206IEFDVE4gW21haWx0bzph Y3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJ TykNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDU6NTkgQU0NClRvOiBMZWV5b3Vu ZzsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxs aTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWlsLmNvbTxt YWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBW YXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJlOiBbQWN0bl0gZHJhZnQtY2VjY2FyZWxsaS1h Y3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgWW91bmcsDQoNCnRoYW5rcyBhIGxv dCBmb3IgcmVwbHkgLCBwbGVhc2Ugc2VlIGluIGxpbmUganVzdCBzb21lIGZ1cnRoZXIgY2xhcmlm aWNhdGlvbg0KDQpSZWdhcmRzDQpTZXJnaW8NCg0KDQoNCkZyb206IExlZXlvdW5nIFttYWlsdG86 bGVleW91bmdAaHVhd2VpLmNvbV0NClNlbnQ6IG1lcmNvbGVkw6wgOCBvdHRvYnJlIDIwMTQgMTc6 MzUNClRvOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFj dG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxtYWlsdG86ZGll Z29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0K Q2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIFNlcmdpbywNCg0KVGhhbmtzIGZvciB5 b3VyIGZlZWRiYWNrIG9uIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQuIFBsZWFzZSBzZWUgaW4tbGlu ZSBmb3IgbXkgY29tbWVudC4NCg0KUmVnYXJkcywNCllvdW5nDQoNCkZyb206IEJFTE9UVEksIFNF UkdJTyAoU0VSR0lPKSBbbWFpbHRvOnNlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwOCwgMjAxNCA3OjM0IEFNDQpUbzogYWN0bkBpZXRm Lm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgTGVleW91bmc7 IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFp bHRvOmx1eXVhbmZAZ21haWwuY29tPg0KQ2M6IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgVmFy bWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3Jr LTAzLnR4dCBjb21tZW50cw0KDQpIaSBEYW5pZWxlICwgWW91bmcgYW5kIGFsbCBhdXRob3JzLA0K DQpJIHJlYWQgeW91IEZyYW1ld29yayBkcmFmdCBhbmQgSSBoYXZlIHNvbWUgY29tbWVudHMgb24g dGhhdC4gTW9zdCBhcmUgZWRpdG9yaWFsICwgb3RoZXIgcXVlc3Rpb25zIGZvciBjbGFyaWZpY2F0 aW9ucy4NCg0KR2VuZXJhbCBxdWVzdGlvbjogaW4gdGhlIGRyYWZ0IHRoZSBjb25jZXB0IG9mIFZO QyBpcyBpbiB0aGUgdmlldyBvZiBoaWVyYXJjaGljYWwgbGV2ZWwgb2YgY29udHJvbGxlcnMgb3Ig bGlua2VkIHRvIHRoZSBtdWx0aS1kb21haW4gYXNwZWN0IHRoYXQgY29tcGVsIHRvIHByb3ZpZGUg dG8gdGhlIGN1c3RvbWVyIGEgc2luZ2xlIHZpcnR1YWxpemVkIG5ldHdvcmsgZXZlbiBpZiBjb21w b3NlZCBieSByZWFsIG11bHRpLWRvbWFpbiBtdWx0aS10ZWNobm9sb2d5IHN1Ym5ldHdvcmtzPyBJ IG1lYW4sIHRoZSDigJx2aXJ0dWFsaXplciBmdW5jdGlvbuKAnSBwcm92aWRlZCBieSBWTkMsIGlu IGNhc2Ugb2YgYSBzaW5nbGUgZG9tYWluIGNvbnRleHQgY291bGQgYmUgaW5zaWRlIGRpcmVjdGx5 IHRoZSBQTkMgLCBjb3JyZWN0Pw0KDQpZT1VORz4+IFllcy4gVGhhdCBpcyB0aGUgY29ycmVjdCB2 aWV3IG9mIFZOQy4gRm9yIGEgc2luZ2xlIGRvbWFpbiBjb250ZXh0LCB0aGUgVk5DIGNhbiBiZSBp bnRlZ3JhdGVkIHdpdGggUE5DLiBCdXQgd2UgbmVlZCB0byBmYWN0b3IgaW4gb3RoZXIgc2NlbmFy aW9zIHN1Y2ggYXMgMSkgVk5DIHZlbmRvciBtYXkgYmUgZGlmZmVyZW50IGZyb20gUE5DIHZlbmRv ciBvciAyKSBWTkMgaXMgYSBzb2Z0d2FyZSBmdW5jdGlvbiB0aGF0IG9wZXJhdG9yIG1heSB3YW50 IHRvIG9wZXJhdGUgYXMgaXRzIGNvbnRyb2wuIEluIG15IG9waW5pb24sIGV2ZW4gZm9yIGEgc2lu Z2xlIGRvbWFpbiwgSSB0aGluayB0aGVyZSBpcyBiZW5lZml0IHRvIGRlZmluZSB0aGlzIGludGVy ZmFjZSBhcyBhIHN0YW5kYXJkIGludGVyZmFjZS4NCg0KU2VjdGlvbiAyICwgcGFnZSA0Og0KYWJz dHJhY3Rpb24gZG9lcyBub3QgaW1wbHkgYXV0b21hdGljYWxseSB2aXJ0dWFsaXphdGlvbix3aGls ZSB2aXJ0dWFsaXphdGlvbiBpbXBsaWVzIHRvIGhhdmUgc3VyZWx5IGEgY2VydGFpbiBmb3JtIG9m IGFic3RyYWN0aW9uLiBJIHdvdWxkIHN1Z2dlc3QgdG8gY29uc2lkZXIgZ29vZCBkZWZpbml0aW9u IGNvbnRhaW5lZCBpbnRvIE9ORiBTRE4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGNoYXB0ZXIgMi4z IENvbnZlbnRpb25zIGFib3V0IGFic3RyYWN0aW9uIGFuZCB2aXJ0dWFsaXphdGlvbi4gQSBnb29k IGRlZmluaXRpb24gY2FuIGhlbHAgYWxsIHRoZSByZWFkaW5nLg0KDQpZT1VORz4+IEFncmVlLiBX ZSB3aWxsIGxvb2sgaW50byB0aGUgbWVudGlvbmVkIGRvY3VtZW50IGlmIHRoZSB1c2FnZSBvZiB0 ZXJtcyBhcmUgYWxpZ25lZCB3aXRoIHRoaXMgZG9jdW1lbnQuIElmIG5vdCwgd2Ugd2lsbCBjbGFy aWZ5IHRoZSB0ZXJtaW5vbG9neSBtb3JlIGNsZWFybHkuDQoNClNlY3Rpb24gNTogSXQgc2VlbXMg dG8gbWUgeW91IG1peGVkIGhlcmUgYXNwZWN0cyB0aGF0IGFyZSBtb3JlIHJlbGF0ZWQgdG8gcG9s aWN5IGxpa2UgYWRtaXNzaW9uIGNvbnRyb2wgIGFuZCBndWFyYW50ZWUgb2YgY2xpZW50IGlzb2xh dGlvbiB3aXRoIHJlYWwgY29tcHV0YXRpb25hbCBpc3N1ZSBsaWtlIENvbXB1dGluZyB0aW1lICwg cGF0aCBjb25zdHJhaW5zIG9yIHJlLW9wdGltaXphdGlvbiBwcm9jZXNzLiBNb3Jlb3ZlciB0aGUg dGVybSBWTk0gZm9yIFZpcnR1YWwgbmV0d29yayBtYXBwaW5nIGlzIGEgYml0IG1pc2xlYWRpbmcg c2luY2UgdGhpcyB0ZXJtIGluIGFscmVhZHkgdXNlZCBlLmcuIGluIEFCTk8gYXJjaGl0ZWN0dXJl IGZvciBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdlci4NCg0KWU9VTkc+PiBJbmRlZWQuIEluIFNlY3Rp b24gNSwgd2Ugd2lsbCBwdXQgc29tZSBub3RlcyBvbiB0aGUgYXNwZWN0IG9mIHJlYWwtdGltZSBy ZWxhdGVkIGZyb20gbm9uIHJlYWwgdGltZSBhc3BlY3QuIFZOTSBpcyBub3QgdG8gYmUgbWl4ZWQg d2l0aCBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdlci4gSGVyZSBWTk0gaXMgYW4gYWxnb3JpdGhtIHdo aWNoIGlzIGtub3duIGFzIFZpcnR1YWwgTmV0d29yayBNYXBwaW5nIHdoaWNoIGlzIGEgc29mdHdh cmUgbW9kdWxlIHRoYXQgY29udmVydHMgY2xpZW50IHJlcXVlc3RzIGludG8gYWN0dWFsIG5ldHdv cmtzLiBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdlciBpcyBBQk5PIGluIG15IHVuZGVyc3RhbmRpbmcg aXMgYSBkZXZlbG9wZWQgY29uY2VwdCBmcm9tIFZOVE0uIEJ1dCBEYW4gS2luZyBhbmQgSSB3aWxs IGxvb2sgYXQgdGhpcyBtb3JlIGNhcmVmdWxseSBvbiB0aGlzIGFzcGVjdCB3aGF0IFZpcnR1YWwg TmV0d29yayBNYW5hZ2VyIGlzIGRvaW5nLg0KDQpTQj4+PiBJZiBJIHVuZGVyc3Rvb2QgZm9ybSBB ZHJpYW4gYW5kIERhbmllbCBBQk5PIGRyYWZ0IHRoZSBjb25jZXB0LCANClNCPj4+IFZOVE0gaXMg c3RyaWN0bHkgcmVsYXRlZCB0byBwbGFubmluZyBmdW5jdGlvbiBzbyBJIHRoaXMgaXQgaXMgdmVy eSANClNCPj4+IGltcG9ydCBwb2ludCBpbiB0aGUgY29udGV4dCBvZiBQTkMgLCBJIHdvdWxkIHNh eQ0KDQpTZWN0aW9uIDYuMSA6IHdoaWxlIGl0IGlzIGNsZWFyIHRoZSBzY29wZSBvZiB0aGUgZGlm ZmVyZW50IGNvbnRyb2wgaW50ZXJmYWNlIHByZXNlbnRlZCBpbiBmaWd1cmUgNSwgSeKAmW0gYSBi aXQgY29uZnVzZWQgYXMgdG8gd2hhdCBJL0YgRSBpcyDigJMgZGF0YSBwbGFuZSBpbnRlcmZhY2Ug dG8gcHJvdmlkZXIgcGh5c2ljYWwgbmV0d29yaz8gT3IgaXMgdGhlIGludGVudGlvbiB0byBwcm92 aWRlIHdoYXQgY2FuIGJlIHRoZSB1bmRlcmx5aW5nIG1vZGVsIG9mIHJlc291cmNlcyBhbGxvY2F0 ZWQgdG8gYSBjdXN0b21lciBmcm9tIG5ldHdvcmsgcHJvdmlkZXIgY29udHJvbGxlciwgYW5kIHRo ZSBtYXBwaW5nIHRvIHJlYWwgcGh5c2ljYWwgcmVzb3VyY2VzID8gTm9yIGNsZWFyIHRvIG1lIHRo ZSBpbnRlbnRpb24NCg0KWU9VTkc+PiBJbnRlcmZhY2UgRSBpcyBub3Qgd2hhdCBBQ1ROIHdpbGwg Zm9jdXMgb24uIEl0IHNpbXBseSBzaG93cyAgYW4gdW5kZXJseWluZyBtb2RlbCBvZiByZXNvdXJj ZXMgYWxsb2NhdGVkIHRvIGEgY3VzdG9tZXIgZnJvbSBuZXR3b3JrIHByb3ZpZGVyIGNvbnRyb2xs ZXIsIGFuZCB0aGUgbWFwcGluZyB0byByZWFsIHBoeXNpY2FsIHJlc291cmNlcy4NCg0KU0I+Pj4g U28gaWYgSSBpbnRlcnByZXRlZCBjb3JyZWN0bHkgeW91ciBhbnN3ZXIgaXMgbW9yZSBhbiBpbnRl cm5hbCBpbnRlcmZhY2UgdG8gUE5DICwgdGhlIGZpZ3VyZSBpcyBtaXNsZWFkaW5nIHNpbmNlIGl0 IHNlZW1zIGxpa2UgYSBEUCBpbnRlcmZhY2UgLg0KDQoNClNlY3Rpb24gNi4xLCBhbHdheXMgZmln dXJlIDU6IElmIGEgcmVwb3J0IG9mIHBvdGVudGlhbCBOVyB0b3BvbG9neSBiZXR3ZWVuIGEgVk5D IGFuZCBhIENOQyBjYW4gYmUgcXVlcmllZCAsIHRoZSBhcnJvdyBpbiB0aGUgZHJhd24gaGFzIHRv IGJlIGJpZGlyZWN0aW9uYWwgSSBndWVzcw0KDQpZT1VORz4+IFllcywgWW91IGFyZSByaWdodC4g SXQgd2lsbCBiZSBmaXhlZC4NCg0KRmlndXJlIDggU2VjdGlvbiA2LjQscGFnZSAyODog4oCcUENB IGFic3RyYWN0cyB0aGUgcGh5c2ljYWwgbmV0d29yayB0b3BvbG9neSBpbnRvIGFuIGFic3RyYWN0 ZWQgdG9wb2xvZ3nigJ0gTG9va2luZyBhdCB0aGUgZGVzY3JpcHRpb24gb2YgVk5DIGNvbXBvbmVu dHMgaW4gNi4yLjIgaXQgaXMgdGhlIHJlc291cmNlIG1hbmFnZXIgZGV2b3RpbmcgdG8gcHJvdmlk ZSBhYnN0cmFjdCB0b3BvbG9neS4gRG9lcyBub3QgZXhpc3QgYW55IFBDQSBjb21wb25lbnQuDQoN Cg0KDQpZT1VORz4+IFNvcnJ5IGZvciBpbmNvbnNpc3RlbmN5LiBUaGUgaW50ZW50aW9uIHdhcyB0 aGUgUENBIGlzIHRoZSBzYW1lIGFzIHRoZSBSZXNvdXJjZSBNYW5hZ2VyIGluIFZOQy4gV2lsbCBt YWtlIHRoZSB0ZXJtIGNvbnNpc3RlbnQuIEdvb2QgY2F0Y2ghDQoNCg0KDQpGaWd1cmUgOCBTRWN0 aW9uIDYuNCwgOiBJbiB0aGUgcGljdHVyZSB0aGVyZSBpcyBubyBwaGFzZSA3LCBhbmQgdGhlcmUg YXJlIDIgcGhhc2UgOA0KDQpZT1VORz4+IFRoYW5rcy4gR29vZCBjYXRjaCENCg0KUGFnZSAzMCA6 IEl0IGlzIEludGVyZmFjZSBDIG5vdCBCICwgYmV0d2VlbiBWTkMgYW5kIFBOQw0KDQpZT1VORz4+ IElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIFNlY3Rpb24gNy4zIHdoZXJlOg0KDQogICBJbnRlcmZh Y2VzIHNob3VsZCBhbHNvIGJlIHNjYWxhYmxlIGFzIGEgbGFyZ2UgYW1vdW50IG9mIGRhdGEgbmVl ZHMNCg0KICAgdG8gYmUgdHJhbnNwb3J0ZWQgYWNyb3NzIGN1c3RvbWVycyB0byB2aXJ0dWFsIG5l dHdvcmsgY29udHJvbGxlcnMNCg0KICAgYW5kIGFjcm9zcyB2aXJ0dWFsIG5ldHdvcmsgY29udHJv bGxlcnMgYW5kIHBoeXNpY2FsIG5ldHdvcmsNCg0KICAgY29udHJvbGxlcnMuDQoNCg0KDQpJIHRo aW5rIHRoaXMgaW1wbGllcyBib3RoIGludGVyZmFjZXMgQiBhbmQgQyBhbHRob3VnaCBwcmltYXJp bHkgYmV0d2VlbiBWTkMtUE5DLg0KDQoNCg0KU0I+Pj4gU29ycnkgWW91bmcsIGlpdCBpcyBub3Qg cmVmZXJyZWQgdG8gNy4zICwgYnV0IGluIHRoZSBjaGFwdGVyIDYsNSAsIA0KU0I+Pj4gb24gSW50 ZXJmYWNlIGludGVyYWN0aW9uLCBhZnRlciBwb2ludCA2LCBpcyBpbmRpY2F0ZWQgSW50ZXJmYWNl IEIgDQpTQj4+PiBhcyBpbnRlcmZhY2UgYmV0d2VlbiBWTkMgYW5kIFBOQywgZmlndXJlIDUgc2F5 cyBpdCBpcyBJL0YgQw0KDQoNClRoYW5rcw0KDQpTZXJnaW8NCg0KDQpUaGFua3MNClNlcmdpbw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFDVE4gbWFp bGluZyBsaXN0DQpBQ1ROQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FjdG4NCg== From nobody Tue Oct 14 08:11:42 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 279061A8901 for ; Tue, 14 Oct 2014 08:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 4paicQ4pTZj7 for ; Tue, 14 Oct 2014 08:11:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2611A87B0 for ; Tue, 14 Oct 2014 08:09:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKN75649; Tue, 14 Oct 2014 15:09:50 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 16:09:48 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 08:09:44 -0700 From: Leeyoung To: Daniele Ceccarelli , "BELOTTI, SERGIO (SERGIO)" , Igor Bryskin , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAUUWIAAAD4nwAAC18ZIA== Date: Tue, 14 Oct 2014 15:09:43 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3DD88@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481279E6E8@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481279E6E8@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/UGtA6CHBrfyIXFJWDrQdHm-6H_A Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 15:11:14 -0000 X-List-Received-Date: Tue, 14 Oct 2014 15:11:14 -0000 SGkgRGFuaWVsZSwNCg0KSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91IG9uIHlvdXIgdGhyZWUg cG9pbnRzLiBQZXJoYXBzLCB3ZSBjYW4gZ28gaW50byBtb3JlIGZydWl0ZnVsIGRpc2N1c3Npb24g YnkgbG9va2luZyBhdCBTZWN0aW9uIDYuNSAoUmVxdWlyZW1lbnRzIGZvciBJbnRlcmZhY2UgQiBh bmQgQykuIA0KDQpUaGFua3MsDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE0LCAyMDE0IDU6MjcgQU0NClRvOiBC RUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IElnb3IgQnJ5c2tpbjsgTGVleW91bmc7IEtpbmcsIERh bmllbDsgYWN0bkBpZXRmLm9yZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdtYWlsLmNvbQ0KQ2M6 IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1m cmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIElnb3IsDQoNCkkgZG9uJ3QgdGhpbmsgdGhh dCBCIGFuZCBDIGFyZSBnb2luZyB0byBiZSB0aGUgc2FtZSBpbnRlcmZhY2UgZWl0aGVyLiANCkp1 c3QgbG91ZCB0aGlua2luZywgc29tZSBleGFtcGxlIHRoYXQgY29tZSB0byBteSBtaW5kIGFyZSBh cyBmb2xsb3dzOg0KDQoxLiBNdWx0aSBkb21haW46IFN1cHBvc2UgVGVsZWZvbmljYSBoYXMgaXRz IG93biBWTkMgKHRoZSBwcmV2aW91cyBtaXN1bmRlcnN0YW5kaW5nIHdhcyBkdWUgdG8gdGhlIGZh Y3QgdGhhdCB5b3UgY2FsbCBUZWxlZm9uaWNhIGFzIHRoZSBjbGllbnQsIHdoaWxlIGZvciB0aGUg dGVybWlub2xvZ3kgdXNlZCBpbiB0aGUgZHJhZnQgVGVsZWZvbmljYSBpcyB0aGUgc2VydmljZSBw cm92aWRlciBhbmQgdGhlIGNsaWVudCBpcyBlLmcuIHRoZSBiYW5rIGFza2luZyBUZWxlZm9uaWNh IGZvciBhIFZQTiBiZXR3ZWVuIDMgcG9pbnRzKSB3aGljaCBydW5zIG9uIHRvcCBvZiAyIGRvbWFp bnMgd2l0aCBQTkNzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIFRoZSBWTkMgaXMgYXdhcmUgb2Yg dGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgMyBkb21haW5zIGJlbG93IChoZW5jZSBDIG11c3QgYmUg ZG9tYWluIGF3YXJlKSB3aGlsZSB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgYmFuayB0byBrbm93 IHRoYXQgZGlmZmVyZW50IGRvbWFpbnMgYXJlIHVzZWQgdG8gY29ubmVjdCBoaXMgMyBwb2ludHMN Cg0KMi4gQ2xvdWQgKyBUcmFuc3BvcnQ6IEFuIGludGVyZXN0aW5nIHVzZSBjYXNlIGluIG15IG9w aW5pb24gaXMgdGhlIHByb3Zpc2lvbmluZyBvZiBjb25uZWN0aXZpdHkgYmV0d2VlbiBkYXRhIGNl bnRlciBYIGFuZCBZLiBUaGVyZSB3b3VsZCBiZSBhIENOQyAobGV0J3MgY2FsbCBpdCBlLmcuIGNs b3VkIG5ldHdvcmsgY29udHJvbGxlciBhcyBpdCB3b3VsZCBwcm9iYWJseSBiZSBzb21ldGhpbmcg ZGlmZmVyZW50IGZyb20gYSBQTkMpIGZvciBkYXRhIGNlbnRlciBYLCBvbmUgZm9yIGRhdGEgY2Vu dGVyIFkgYW5kIG9uZSBvciBtb3JlIFBOQyBpbiB0aGUgbWlkZGxlLiBUaGUgVk5DIHdvdWxkIGJl IGFuIGVuYWJsZSBmb3IgcHJvdmlkaW5nIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGRhdGEgY2VudGVy cyBvdmVyIGEgdHJhbnNwb3J0IG5ldHdvcmsuIEFsc28gaW4gdGhpcyBjYXNlIEkgdGhpbmsgdGhh dCBpbnRlcmZhY2VzIEIgYW5kIEMgd291bGQgYmUgZGlmZmVyZW50Lg0KDQozLiBPcHRpY2FsIG11 bHRpIGRvbWFpbjogaXQgbWlnaHQgYmUgcG9zc2libGUgdGhhdCBUZWxlZm9uaWNhIHdhbnRzIHRv IGhhdmUgYSBzZXQgb2YgaW1wYWlybWVudHMgZm9yIGNvbXB1dGluZyBlbmQgdG8gZW5kIG9wdGlj YWwgcGF0aHMgKGkuZS4gb3B0aWNhbCBpbXBhaXJtZW50IG5vdCBsaW1pdGVkIHRvIHRoZSBQTkMg ZG9tYWluKS4gSW4gdGhhdCBjYXNlIHlvdSB3b3VsZCBoYXZlIHRoZW0gdGhyb3VnaCBpbnRlcmZh Y2UgQyBidXQgbm90IEIuDQoNCk1heWJlIHdlIG1pZ2h0IGNvbWUgdG8gdGhlIGNvbmNsdXNpb24g dGhhdCBvbmUgaW50ZXJmYWNlIGlzIGEgc3Vic2V0IG9mIHRoZSBvdGhlciBvciBtYXliZSB0aGVy ZSBhcmUgcmVxdWlyZW1lbnRzIHRoYXQgbGVhZCB0byBkZWZpbmluZyB0aGVtIGFzIHNlcGFyYXRl IGludGVyZmFjZXMgd2l0aCBqdXN0IGEgbGl0dGxlIGJpdCBvZiBvdmVybGFwLCBidXQgSSB0aGlu ayBpdCBpcyB3b3J0aCBrZWVwaW5nIHRoZW0gc2VwYXJhdGUuDQpJIHdvdWxkIGxpa2UgdG8ga25v dyBhIGJpdCBtb3JlIGFib3V0IHJlcXVpcmVtZW50cyBvbiBpbnRlcmZhY2UgQiBhcyBpdCBjb3Vs ZCBiZSBhbiBpbnRlcmZhY2UgdG93YXJkcyB0aGUgY2xpZW50IGNvbnRyb2xsZXIgKHdoZXJlIGNs aWVudCA9PSB0aGUgYmFuaykgb3IgZGlyZWN0bHkgYW4gYXBwbGljYXRpb24gKHdoaWNoIEkgZ3Vl c3MgaGFzIGRpZmZlcmVudCByZXF1aXJlbWVudHMgdGhhbiB0aGUgb25lcyB0byBiZSBwdXQgb24g aW50ZiBDKS4NCg0KQlINCkRhbmllbGUNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIA0KPiBbbWFpbHRvOnNlcmdpby5i ZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2VudDogbWFydGVkw6wgMTQgb3R0b2JyZSAy MDE0IDExOjM4DQo+IFRvOiBJZ29yIEJyeXNraW47IExlZXlvdW5nOyBEYW5pZWxlIENlY2NhcmVs bGk7IEtpbmcsIERhbmllbDsgDQo+IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRpZC5lczsgbHV5dWFu ZkBnbWFpbC5jb20NCj4gQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSRTogZHJh ZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCj4gDQo+IEhpIEln b3IsDQo+IA0KPiAiIElC44CLTm8uIEkgYW0gc2F5aW5nIHRoYXQgaW50ZXJmYWNlIEIgYW5kIEMg YXJlIGV4YWN0bHkgdGhlIHNhbWUgaW50ZXJmYWNlcy4NCj4gRm9yIGV4YW1wbGUsIG9uIHRoZSBw aWN0dXJlIE5ldHdvcmsgZG9tYWluIDEgaW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgDQo+IGFic3Ry YWN0IHRvcG9sb2d5IHRvIHRoZSBtdWx0aS12ZW5kb3IgVk5DLCBtYXkgdXNlIGZ1bGx5IG9yIHBh cnRpYWxseSANCj4gYWJzdHJhY3QgdG9wb2xvZ2llcyBwcm92aWRlZCBieSBvbmUgb3IgbW9yZSBs b3dlciB0aWVyIHRyYW5zcG9ydCBkb21haW5zLg0KPiBMaWtld2lzZSwgQ3VzdG9tZXIgMSBvbiB0 aGUgcGljdHVyZSBtYXkgdXNlIGFuIGFic3RyYWN0IHRvcG9sb2d5IA0KPiBwcm92aWRlZCBieSBN dWx0aS1kb21haW4gbmV0d29yayAodGhlIFZOQyBvbiB0aGUgcGljdHVyZSBpcyBwYXJ0IG9mKS4N Cj4gSW4gb3RoZXIgd29yZHMsIHRoZSBzYW1lIGludGVyZmFjZSBDIGFuZCB0aGUgc2FtZSBzZXQg b2YgbW9kZWxzLCBjb3VsZCANCj4gYmUgdXNlZCAgaGllcmFyY2hpY2FsbHkuDQo+IA0KPiBJZ29y Ig0KPiANCj4gSSB0ZW5kIHRvIGRpc2FncmVlIGhlcmUuIFdoYXQgdGhhdCBjYW4gYmUgZGlzY3Vz c2VkIGluIG15IHZpZXcgaXQgaXMgDQo+IHRoZSBuZWVkIG9yIG5vdCBvZiBpbnRlcmZhY2UgQy4g V2hhdCBWTkMgaXMgZ29pbmcgdG8gcHJvdmlkZSBpcyBhIA0KPiBkb3VibGUgZnVuY3Rpb24gb2Yg dmlydHVhbGl6ZXIgb2YgdGhlIG5ldHdvcmsgdG93YXJkcyBjbGllbnQgDQo+IGFwcGxpY2F0aW9u IGxldmVsIGFuZCBvcmNoZXN0cmF0aW9uLCBkdWUgdG8gdGhlIG5lZWQgdG8gc3BhbiBtdWx0aXBs ZSANCj4gKHZpcnR1YWwpTkVzIG9yIG11bHRpcGxlIG5ldHdvcmsgZG9tYWluIC4gSWYgd2UgaW1t bWFnaW5lIHRvIGVuY29tcGFzcyANCj4gdGhlc2UgZnVuY3Rpb25hbGx5IGludG8gb25seSBvbmUg U0ROIGNvbnRyb2xsZXIgLCBtYW5hZ2luZyBhbGwgdmlydHVhbCANCj4gbmV0d29yayB5b3Ugd291 bGQgbm90IHVzZSBhbm90aGVyIGludGVyZmFjZSBiZXR3ZWVuIFZOQyBhbmQgUE5DLg0KPiBCdXQg aGVyZSBZb3VuZyBwdXQgY29ycmVjdGx5IHNvbWUgcHJvYmxlbXMgYW5kIGl0IGlzIHRoZSBjb3Jy ZWN0IHRpbWUgDQo+IEkgdGhpbmsgdG8gY29uc2lkZXIgYWxsIHRoZSBhc3BlY3RzLg0KPiBCdXQg dG93YXJkcyBjbGllbnQgYXBwbGljYXRpb24gdGhlcmUgaXMgYW5vdGhlciBsZXZlbCBvZiBhYnN0 cmFjdGlvbiwgDQo+IGEgcmVhbCB2aXJ0dWFsaXphdGlvbiAodG8gY2xpZW50KSBvZiByZXNvdXJj ZXMgd2l0aCBkaWZmZXJlbnQgDQo+IGdyYW51bGFyaXR5IGFuZCBjaGFyYWN0ZXJpc3RpY3Mgb2Yg dGhlIHNldCBvZiBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gDQo+IHRoZSBsb3dlciBsZXZlbCBvZiBj b250cm9sbGVyLCBhcyB3ZWxsIGV4cGxhaW5lZCBieSBZb3VuZy4NCj4gSXQgY2FuIGRlYmF0ZSBp ZiBhbm90aGVyIHNlcGFyYXRlIGVudGl0eSBhcyBWTkMgY2FuIGJlICwgaW4gdGhpcyANCj4gYXJj aGl0ZWN0dXJlLCB0aGUgZ29vZCBjaG9pY2UsIGJ1dCBJIGRvIG5vdCBoYXZlIHByZWNsdXNpb24g b24gdGhhdC4NCj4gSSBpbnN0ZWFkIHNoYXJlIHlvdXIgc2VudGVuY2UgYWJvdXQgaGllcmFyY2hp Y2FsIGxldmVsIG9mIGNvbnRyb2xsZXIuDQo+IA0KPiBUaGFua3MNCj4gDQo+IFJlZ2FyZHMNCj4g U2VyZ2lvDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQUNU TiBbbWFpbHRvOmFjdG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElnb3IgQnJ5c2tp bg0KPiBTZW50OiBtYXJ0ZWTDrCAxNCBvdHRvYnJlIDIwMTQgMDI6MDENCj4gVG86IExlZXlvdW5n OyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywgDQo+ IERhbmllbDsgYWN0bkBpZXRmLm9yZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdtYWlsLmNvbQ0K PiBDYzogVmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1YmplY3Q6IFJlOiBbQWN0bl0gZHJhZnQtY2Vj Y2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCj4gDQo+IA0KPiBZb3VuZywN Cj4gDQo+IA0KPiA9PT3jgItBZnRlciBhbGwgd2UgYXJlIGFncmVlaW5nIHdpdGggdGhlIGludGVy ZmFjZXMgb2YgQUNUTiBpbnRlcmVzdCBhcmUgDQo+IEludGVyZmFjZSBCIGFuZCBDLCByaWdodD8N Cj4gDQo+IElC44CLTm8uIEkgYW0gc2F5aW5nIHRoYXQgaW50ZXJmYWNlIEIgYW5kIEMgYXJlIGV4 YWN0bHkgdGhlIHNhbWUgaW50ZXJmYWNlcy4NCj4gRm9yIGV4YW1wbGUsIG9uIHRoZSBwaWN0dXJl IE5ldHdvcmsgZG9tYWluIDEgaW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgDQo+IGFic3RyYWN0IHRv cG9sb2d5IHRvIHRoZSBtdWx0aS12ZW5kb3IgVk5DLCBtYXkgdXNlIGZ1bGx5IG9yIHBhcnRpYWxs eSANCj4gYWJzdHJhY3QgdG9wb2xvZ2llcyBwcm92aWRlZCBieSBvbmUgb3IgbW9yZSBsb3dlciB0 aWVyIHRyYW5zcG9ydCBkb21haW5zLg0KPiBMaWtld2lzZSwgQ3VzdG9tZXIgMSBvbiB0aGUgcGlj dHVyZSBtYXkgdXNlIGFuIGFic3RyYWN0IHRvcG9sb2d5IA0KPiBwcm92aWRlZCBieSBNdWx0aS1k b21haW4gbmV0d29yayAodGhlIFZOQyBvbiB0aGUgcGljdHVyZSBpcyBwYXJ0IG9mKS4NCj4gSW4g b3RoZXIgd29yZHMsIHRoZSBzYW1lIGludGVyZmFjZSBDIGFuZCB0aGUgc2FtZSBzZXQgb2YgbW9k ZWxzLCBjb3VsZCANCj4gYmUgdXNlZCAgaGllcmFyY2hpY2FsbHkuDQo+IA0KPiBJZ29yDQo+IA0K PiBJQj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdHJhbnNwb3J0 IGRvbWFpbiBzZXJ2ZXIgDQo+IElCPj4gYW5kDQo+IHRyYW5zcG9ydCBkb21haW4gY2xpZW50LiBJ IHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHZlcnkgc2FtZSBpbnRlcmZhY2UgDQo+IGNhbiBiZSB1c2Vk IGJldHdlZW4gYSBtdWx0aS1kb21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkgYW5kIGl0 cyANCj4gY2xpZW50cy4gTm90IGFsbCBzdWNoIGNsaWVudHMgYXJlIGR1bWIsIGFzIERhbmllbGUg Y2xhaW1zLCBhbmQgb25seSANCj4gY2FyZSBhYm91dCDigJxhIGdpdmVuIGFtb3VudCBvZiBHYnBz IGZyb20gQSB0byBC4oCdLiBJdCBpcyBlYXN5IHRvIA0KPiBlbnZpc2lvbiB0aGF0IHNvbWUgb2Yg dGhlIGNsaWVudHMgd291bGQgd2FudCBmcm9tIFRlbGVmb25pY2EgYSBjb3VwbGUgDQo+IG9mIFNS TEctZGlzam9pbnQgYWJzdHJhY3QgbGlua3MsIHNvIHRoYXQgdGhlIGNsaWVudHMgY2FuIGhhdmUg YSBzYXkgaW4gDQo+IHRoZSBwbGFjZW1lbnQgb2YgdGhlaXIgIHNlcnZpY2VzIGFjcm9zcyB0aGUg VGVsZWZvbmlrYSBuZXR3b3JrLiBUaHJlZSBwb2ludHMgaGVyZToNCj4gDQo+IGEpICAgICAgVGhl IGNsaWVudCB3aWxsIGJlIGFibGUgdG8gY29uZmlndXJlIGZ1bGx5IG9yIHBhcnRpYWxseSB0aGUg YWJzdHJhY3QgdG9wb2xvZ3kNCj4gaGUgd2FudHMgdGhlIG5ldHdvcmsgdG8gcHJlc2VudCB0byBo aW07DQo+IA0KPiBiKSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFz IHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdA0KPiBub2RlKSBvciBhcyBjb21wbGV4IChl LmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSANCj4gYWJzdHJhY3QNCj4g bGlua3MpIGFzIHRoZSBjbGllbnQgd2FudHMgaXQgdG8gYmUgKHN1YmplY3QgdG8gdGhlIHByb3Zp ZGVy4oCZcyANCj4gYXBwcm92YWwpDQo+IA0KPiBjKSAgICAgIFRoZSBhYnN0cmFjdCB0b3BvbG9n eSBwcmVzZW50ZWQgdG8gdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IGRlY291cGxlZA0KPiBmcm9t IHRoZSBwcm92aWRlcuKAmXMgYWN0dWFsIHRvcG9sb2d5Lg0KPiANCj4gVGhlcmVmb3JlIHRoZSBz YW1lIGludGVyZmFjZS9zZXQgb2YgbW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55IA0KPiB0 cmFuc3BvcnQgbmV0d29yayBwcm92aWRlciBhbmQgaXRzIGNsaWVudC4gRnVydGhlcm1vcmUsIHRo ZSBpbnRlcmZhY2UgDQo+IGNhbiBiZSB1c2VkIGluIHRoZSBoaWVyYXJjaGljYWwgd2F5LCB0aGF0 IGlzLCBhIGNsaWVudCBvZiBhIHRyYW5zcG9ydCANCj4gZG9tYWluIGNhbiBzZXJ2ZSBpdHMgb3du IGNsaWVudHMgdXNpbmcgdGhlIHNhbWUgaW50ZXJmYWNlIGFzIGl0IHVzZXMgDQo+IHRvIHRhbGsg dG8gaXRzIG93bg0KPiBwcm92aWRlcihzKQ0KPiANCj4gSGVyZSBJIHdvdWxkIGxpa2UgdG8gZ2l2 ZSB5b3UgYSBsaXR0bGUgY2xlYXJlciBwaWN0dXJlIG9uIG11bHRpLWRvbWFpbiBpc3N1ZXMuDQo+ IA0KPiAgICArLS0tLS0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICstLS0t LS0tLS0tLS0tLSsNCj4gICAgfCAgIEN1c3RvbWVyIDEgICB8ICAgfCAgIEN1c3RvbWVyIDIgIHwg IC4uLiB8IEN1c3RvbWVyIE0gICB8DQo+ICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICstLS0tLS0t LS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICAgXCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAvDQo+ICAgICAgICAgICAgICAgICAgICAgXCAgICAg ICAgICAgIHwgICAgICAgICAgICAgLw0KPiAgICAgICAgSW50ZXJmYWNlIEIgICBcICAgICAgICAg ICB8ICAgICAgICAgICAgLw0KPiAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICB8ICAg ICAgICAgICAvDQo+ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCj4gICAgICAgICAgICAgICAgICAgICAgIHwgICBWTkMgTXVsdGktZG9tYWluICAgfCBFMkUg YWJzdHJhY3QNCj4gICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBDb29yZGluYXRpb24gICAg fCB0b3BvbG9neSBjcmVhdGlvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgIHwgICAgICAg ICAgICBcDQo+ICAgICAgICAgSW50ZXJmYWNlIEMgICAvICAgICAgICAgIHwgICAgICAgICAgICAg XCAgTmV0d29yayBUb3BvbG9neQ0KPiAgICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICB8 ICAgICAgICAgICAgICBcIChhYnN0cmFjdCkNCj4gICAgICAgICAgICAgICAgICAgICAvICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIFwNCj4gICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICArLS0t LS0tLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgICB8IE5ldHdvcmsg RG9tYWluIDEgfCAgIHwgTmV0d29yayBEb21haW4gMiB8IC4uIHwgTmV0d29yayBEb21haW4gTiB8 DQo+ICAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICAgKy0t LS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAgICBWZW5kb3IgWCAgICAgICAgICAgICAgICAgVmVu ZG9yIFkgICAgICAgICAgICAgICBWZW5kb3IgWg0KPiANCj4gDQo+IFdoYXQgaXMgc2l0dGluZyBh Ym92ZSDigJxWTkPigJ0gKHRoYXQgY29vcmRpbmF0ZXMgb3ZlciBtdWx0aS1kb21haW4gDQo+IGNv bnRyb2xsZXJzKSBjYW4gYmUgYW4gaW50ZXJuYWwgc2VydmljZSBvcmdhbml6YXRpb24gKG9mIHRo ZSBzYW1lIA0KPiBvcGVyYXRvcikgb3Igc2VydmljZSBwcm92aWRlcnMgKGRpZmZlcmVudCBvcGVy YXRvcnMsIGZvcm1pbmcgY2FycmllcnMgDQo+IG9mIGNhcnJpZXIpLiBUaGUgY29udHJvbCBlbnRp dHkgb2YgdGhlc2UgZW50aXRpZXMgaXMgcmVmZXJyZWQgdG8gYXMgDQo+IEN1c3RvbWVyIE5ldHdv cmsgY29udHJvbCAoQ05DKS4gVGhlIFZOQyDigJNDTkMgaW50ZXJmYWNlIChJbnRlcmZhY2UgQikg DQo+IGhhcyBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIHRoYW4gdGhlIFZOQy1QTkMgaW50ZXJmYWNl IChJbnRlcmZhY2UgQykuIA0KPiBUb3BvbG9neSBhYnN0cmFjdGlvbiBpcyBqdXN0IG9uZSBvZiB0 aGUgcmVxdWlyZW1lbnRzIGFuZCBpbiANCj4gbXVsdGktZG9tYWluIGNhc2UsIHRoZSBWTkMgaXMg cGVyZm9ybWluZyBtdWx0aS1kb21haW4gY29vcmRpbmF0aW9uIA0KPiBmdW5jdGlvbi4gVk5DIG5l ZWRzIHRvIGhhdmUgYSBzdGFuZGFyZCBpbnRlcmZhY2UgdGhhdCBlbmFibGUgDQo+IGNvbW11bmlj YXRpb25zIHdpdGggZGlmZmVyZW50IGtpbmRzIG9mIGRvbWFpbiBuZXR3b3JrIGNvbnRyb2wvbWFu YWdlbWVudCBjb250cm9sICh3aGljaCBpcyByZWZlcnJlZCB0byBhcyBQTkMsIHlvdSBjYWxsIEFO QykuDQo+IEVhY2ggZG9tYWluIGhhcyBpdHMgb3duIHdheXMgb2YgY29udHJvbGxpbmcgaXRzIG5l dHdvcmssIHdoaWNoIEFDVE4gaXMgDQo+IG5vdCB0b3VjaGluZyB0aG9zZSBhdCBhbGwuIFdoYXRl dmVyIHRoZSBjaG9pY2VzIG9mIHZlbmRvciBjb250cm9sIA0KPiByZWdpbWUgd2lsbCBjb250aW51 ZSB0byBiZSBlbXBsb3llZCAoR01QTFMvQVNPTiwgUE5OSSwgTk1TLCBPcGVuRmxvdywgZXRjLiku DQo+IA0KPiBGb3IgdGhpcyBtdWx0aS1kb21haW4gY29vcmRpbmF0aW9uIGZ1bmN0aW9uIGFzc3Vt ZWQgYnkgVk5DIHNob3VsZCBiZSANCj4gb3BlcmF0ZWQgb24gYW4gYWJzdHJhY3QgbGV2ZWwuIFdl IGRvbuKAmXQgd2FudCB0byBpbmplY3QgdGhlIHNhbWUgbGV2ZWwgDQo+IG9mIGFjdHVhbCBuZXR3 b3JrIHRvcG9sb2d5IChlLmcuLCBURUQpIGFzIHRoZSBkb21haW4gY29udHJvbGxlciANCj4gb3Bl cmF0ZXMgaXRzIHBoeXNpY2FsL2FjdHVhbCBuZXR3b3Jrcy4gSXMgdGhpcyBhZ3JlZWFibGU/IFlv dSBzYWlkIA0KPiBhYm92ZSB0aGlzIGluIGMpIFRoZSBhYnN0cmFjdCB0b3BvbG9neSBwcmVzZW50 ZWQgdG8gdGhlIGNsaWVudCBpcyANCj4gY29tcGxldGVseSBkZWNvdXBsZWQgZnJvbSB0aGUgcHJv dmlkZXLigJlzIGFjdHVhbCB0b3BvbG9neS4NCj4gDQo+IE5vdyB0aGUgVk5DIChtdWx0aS1kb21h aW4gY29vcmRpbmF0b3IpIG5lZWRzIHRvIGNvb3JkaW5hdGUgc2lnbmFsaW5nIA0KPiBhY3Jvc3Mg bXVsdGktZG9tYWluIGNvbnRyb2xsZXJzIChpbiB0ZXJtcyBvZiB0aGUgc2VxdWVuY2Ugb2YgdGhl IA0KPiBlbmQtdG8tZW5kIHBhdGggYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMpLiBUaGlzIGlzIGEg bmV3IGVsZW1lbnQgSSANCj4gYmVsaWV2ZSBBQ1ROIHdpbGwgaGF2ZSB0byBkZXZlbG9wLiBUaGlz IGludGVyZmFjZSBDIChWTkMtUE5DKSBpcyB2ZXJ5IA0KPiBkaWZmZXJlbnQgZnJvbSBJbnRlcmZh Y2UgQiAoQ05DLVZOQykuIFRoZXJlIGFyZSBvdGhlciBkaWZmZXJlbmNlcyANCj4gKHBsZWFzZSBz ZWUgU2VjdGlvbiA2LjUgb2YgdGhlIGZyYW1ld29yayBkb2N1bWVudCkuICBCdXQgSSBhZ3JlZSB3 aXRoIHlvdSB0aGF0IGZyb20gYW4gYWJzdHJhY3QgdG9wb2xvZ3kNCj4gc3RhbmRwb2ludCwgc2lt aWxhciBtb2RlbCB3b3JrcyBmb3IgSW50ZXJmYWNlcyBCIGFuZCBDIGFzIHlvdSBzYWlkICBiKSAg ICAgIFRoZQ0KPiBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxkIGJlIGFzIHNpbXBsZSAoZS5n LiBhIHNpbmdsZSBhYnN0cmFjdCANCj4gbm9kZSkgb3IgYXMgY29tcGxleCAoZS5nLiBOIGFic3Ry YWN0IG5vZGVzIGludGVyY29ubmVjdGVkIGJ5IE0gDQo+IGFic3RyYWN0IGxpbmtzKSBhcyB0aGUg Y2xpZW50IHdhbnRzIGl0IHRvIGJlIChzdWJqZWN0IHRvIHRoZSBwcm92aWRlcuKAmXMgYXBwcm92 YWwpLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBZb3VuZw0KPiANCj4gDQo+IA0KPiANCj4gRnJv bTogSWdvciBCcnlza2luIFttYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tXQ0KPiBTZW50 OiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQgOToxNyBBTQ0KPiBUbzogQkVMT1RUSSwgU0VSR0lP IChTRVJHSU8pOyBEYW5pZWxlIENlY2NhcmVsbGk7IEtpbmcsIERhbmllbDsgDQo+IExlZXlvdW5n OyBhY3RuQGlldGYub3JnOyBkaWVnb0B0aWQuZXM7IGx1eXVhbmZAZ21haWwuY29tDQo+IENjOiBW YXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1m cmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBTZXJnaW8sDQo+IEEgY291cGxlIG9m IGNvbW1lbnRzIGluIGxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IElnb3INCj4gDQo+IEZyb206IEJF TE9UVEksIFNFUkdJTyAoU0VSR0lPKSANCj4gW21haWx0bzpzZXJnaW8uYmVsb3R0aUBhbGNhdGVs LWx1Y2VudC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMywgMjAxNCA5OjE1IEFNDQo+ IFRvOiBJZ29yIEJyeXNraW47IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywgRGFuaWVsOyBMZWV5 b3VuZzsgDQo+IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRpZC5lczsgbHV5dWFuZkBnbWFpbC5jb20N Cj4gQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKTsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pDQo+IFN1 YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50 cw0KPiANCj4gSGkgSWdvciwNCj4gDQo+IFBsZWFzZSwgc2VlIGluIGxpbmUNCj4gDQo+IFJlZ2Fy ZHMNCj4gU2VyZ2lvDQo+IA0KPiANCj4gRnJvbTogSWdvciBCcnlza2luIFttYWlsdG86SUJyeXNr aW5AYWR2YW9wdGljYWwuY29tXQ0KPiBTZW50OiB2ZW5lcmTDrCAxMCBvdHRvYnJlIDIwMTQgMjI6 MzcNCj4gVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgS2luZywgRGFuaWVsOyBMZWV5b3VuZzsgQkVM T1RUSSwgU0VSR0lPIA0KPiAoU0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRm Lm9yZz47IA0KPiBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47DQo+IGx1eXVhbmZA Z21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCj4gQ2M6IFZhcm1hLCBFdmUgTCAo RXZlKQ0KPiBTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50 eHQgY29tbWVudHMNCj4gDQo+IEhpIERhbmllbGUsDQo+IFBsZWFzZSwgc2VlIGluIGxpbmUuDQo+ IElnb3INCj4gDQo+IEZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2Vj Y2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMCwgMjAxNCAx OjI1IFBNDQo+IFRvOiBJZ29yIEJyeXNraW47IEtpbmcsIERhbmllbDsgTGVleW91bmc7IEJFTE9U VEksIFNFUkdJTyAoU0VSR0lPKTsgDQo+IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5v cmc+OyANCj4gZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdt YWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2 ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0 IGNvbW1lbnRzDQo+IA0KPiBIaSBJZ29yLA0KPiANCj4gV2hhdCBkbyB5b3UgbWVhbiBieSBjbGll bnQgaGVyZT8gVGhlIG9uZSB0aGF0IGlzIHRoZSBkb2N1bWVudCBpcyANCj4gY2FsbGVkIOKAnHNl cnZpY2UgcHJvdmlkZXLigJ0gb3IgdGhlIG9uZSB0aGF0IGlzIGNhbGxlZCDigJxjbGllbnTigJ0g PyBGcm9tIA0KPiB3aGF0IHlvdSBzZW5kIEkgdGVuZCB0byB0aGluayB5b3UgYXJlIHRhbGtpbmcg YWJvdXQgdGhlIHNlcnZpY2UgDQo+IHByb3ZpZGVyLCBidXQgSSBtaWdodCBiZSB3cm9uZywgcGxl YXNlIGNvcnJlY3QgbWUuDQo+IA0KPiBJQj4+IEJ5IGNsaWVudCBJIG1lYW4gdGhlIGNsaWVudCBv ZiBhIHRyYW5zcG9ydCBkb21haW4sIHRoZSBvbmUgd2hvIA0KPiBJQj4+IHNwZWFrcw0KPiBOZXRj b25mL1Jlc3Rjb25mIHRvIHRoZSB0cmFuc3BvcnQgZG9tYWluLiBUaGUgZ3V5IHdobyBzcGVha3Mg ZnJvbSB0aGUgDQo+IG90aGVyIGVuZCAoaS5lLiBvbiBiZWhhbGYgb2YgdGhlIHRyYW5zcG9ydCBz ZXJ2aWNlIHByb3ZpZGVyKSAgaXMgdGhlIA0KPiB0cmFuc3BvcnQgZG9tYWlu4oCZcyBIeXBlcnZp c29yLg0KPiANCj4gU0I+Pj4gSXQgaXMgY2xlYXIgd2hhdCB5b3UgaW50ZW5kIGhlcmUsIGV2ZW4g aWYgd29yZCBjbGllbnQgaXQgc2VlbXMgDQo+IFNCPj4+IHRvIG1lDQo+IG1vcmUgcmVsYXRlZCB0 byBhcHBsaWNhdGlvbiB0aGFuIHRvIGEgc2VydmljZSBwcm92aWRlci4NCj4gDQo+IElCPj4gSSBh bSB0YWxraW5nIGFib3V0IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0cmFuc3BvcnQgZG9tYWluIHNl cnZlciANCj4gSUI+PiBhbmQNCj4gdHJhbnNwb3J0IGRvbWFpbiBjbGllbnQuIEkgd291bGQgYXJn dWUgdGhhdCB0aGUgdmVyeSBzYW1lIGludGVyZmFjZSANCj4gY2FuIGJlIHVzZWQgYmV0d2VlbiBh IG11bHRpLWRvbWFpbiBwcm92aWRlciAoZS5nLiBUZWxlZm9uaWthKSBhbmQgaXRzIA0KPiBjbGll bnRzLiBOb3QgYWxsIHN1Y2ggY2xpZW50cyBhcmUgZHVtYiwgYXMgRGFuaWVsZSBjbGFpbXMsIGFu ZCBvbmx5IA0KPiBjYXJlIGFib3V0IOKAnGEgZ2l2ZW4gYW1vdW50IG9mIEdicHMgZnJvbSBBIHRv IELigJ0uIEl0IGlzIGVhc3kgdG8gDQo+IGVudmlzaW9uIHRoYXQgc29tZSBvZiB0aGUgY2xpZW50 cyB3b3VsZCB3YW50IGZyb20gVGVsZWZvbmljYSBhIGNvdXBsZSANCj4gb2YgU1JMRy1kaXNqb2lu dCBhYnN0cmFjdCBsaW5rcywgc28gdGhhdCB0aGUgY2xpZW50cyBjYW4gaGF2ZSBhIHNheSBpbiAN Cj4gdGhlIHBsYWNlbWVudCBvZiB0aGVpciAgc2VydmljZXMgYWNyb3NzIHRoZSBUZWxlZm9uaWth IG5ldHdvcmsuIFRocmVlIHBvaW50cyBoZXJlOg0KPiANCj4gYSkgICAgICBUaGUgY2xpZW50IHdp bGwgYmUgYWJsZSB0byBjb25maWd1cmUgZnVsbHkgb3IgcGFydGlhbGx5IHRoZSBhYnN0cmFjdCB0 b3BvbG9neQ0KPiBoZSB3YW50cyB0aGUgbmV0d29yayB0byBwcmVzZW50IHRvIGhpbTsNCj4gDQo+ IGIpICAgICAgVGhlIHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kgY291bGQgYmUgYXMgc2ltcGxlIChl LmcuIGEgc2luZ2xlIGFic3RyYWN0DQo+IG5vZGUpIG9yIGFzIGNvbXBsZXggKGUuZy4gTiBhYnN0 cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBieSBNIA0KPiBhYnN0cmFjdA0KPiBsaW5rcykgYXMg dGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXLigJlzIA0K PiBhcHByb3ZhbCkNCj4gDQo+IGMpICAgICAgVGhlIGFic3RyYWN0IHRvcG9sb2d5IHByZXNlbnRl ZCB0byB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVkDQo+IGZyb20gdGhlIHByb3Zp ZGVy4oCZcyBhY3R1YWwgdG9wb2xvZ3kuDQo+IA0KPiBUaGVyZWZvcmUgdGhlIHNhbWUgaW50ZXJm YWNlL3NldCBvZiBtb2RlbHMgY2FuIGJlIHVzZWQgYmV0d2VlbiBhbnkgDQo+IHRyYW5zcG9ydCBu ZXR3b3JrIHByb3ZpZGVyIGFuZCBpdHMgY2xpZW50LiBGdXJ0aGVybW9yZSwgdGhlIGludGVyZmFj ZSANCj4gY2FuIGJlIHVzZWQgaW4gdGhlIGhpZXJhcmNoaWNhbCB3YXksIHRoYXQgaXMsIGEgY2xp ZW50IG9mIGEgdHJhbnNwb3J0IA0KPiBkb21haW4gY2FuIHNlcnZlIGl0cyBvd24gY2xpZW50cyB1 c2luZyB0aGUgc2FtZSBpbnRlcmZhY2UgYXMgaXQgdXNlcyANCj4gdG8gdGFsayB0byBpdHMgb3du DQo+IHByb3ZpZGVyKHMpDQo+IA0KPiBNb3Jlb3ZlciBJIHdvdWxkIGF2b2lkIGluIHRoaXMgcGhh c2UgdG8gbWVudGlvbiBhbnkgcmVmZXJlbmNlIHRvIA0KPiBwcm90b2NvbCBpbXBsZW1lbnRhdGlv biAoZS5nLiBOZXRjb25mL1Jlc3Rjb25mKSA6IEkgdGhpbmsgd2UgYXJlIGluIA0KPiB0aGUgcGhh c2UgdG8gdW5kZXJzdGFuZCBhcmNoaXRlY3R1cmUsIHdoYXQgYXJlIHRoZSByZWxldmFudCANCj4g aW50ZXJmYWNlcywgYW5kIHdoYXQgaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIG92ZXIgdGhlIHJl ZmVyZW5jZSANCj4gcG9pbnRzL2ludGVyZmFjZXMuIEkgZ3Vlc3MgdGhpcyBpcyBjbGVhcmx5IHN0 YXRlZCBhbHNvIGluIHRoZSBjaGFydGVyIG9mIEJvRi4NCj4gDQo+IElCPj4gQWdyZWUuIEkgdXNl ZCBOZXRjb25mL1Jlc3Rjb25mIGFzIGFuIGV4YW1wbGUgdG8gbWFrZSBpdCBjbGVhciANCj4gSUI+ PiB3aGF0DQo+IGludGVyZmFjZSBJIHdhcyB0YWxraW5nIGFib3V0Lg0KPiANCj4gIEF0IGFuIGFw cHJvcHJpYXRlIHRpbWUg4oCTIGNlcnRhaW5seSBub3Qgbm93IOKAkyB0aGUgbmV4dCBzdGVwIGlz IHRvIA0KPiBjaGVjayB3aXRoIG90aGVyIFNET3Mgb24gdGhlIGF2YWlsYWJpbGl0eSBvZiByZWxl dmFudCBjb3JlL3RlY2hub2xvZ3kgDQo+IHNwZWNpZmljL2FwcGxpY2F0aW9uIHNwZWNpZmljIGlu Zm9ybWF0aW9uIG1vZGVsIOKAnGZyYWdtZW50c+KAnSwgYW5kIHRoZW4gDQo+IGZpbmFsbHkgcHJv Y2VlZCBvbiB0aGUgcGF0aCBvZiBwcnVuaW5nL3JlZmFjdG9yaW5nIGFuZCBtYXBwaW5nIHRvIA0K PiBSRVNUL0pTT04sIE5ldGNvbmYvWUFORywgYW5kIGFueSBvdGhlciBwb3NzaWJsZSBkYXRhIG1v ZGVsaW5nIGFuZCANCj4gY29uZmlndXJhdGlvbiBwcm90b2NvbCBleGlzdGluZy4gVGhpcyBpcyBt eSB1bmRlcnN0YW5kaW5nICBvZiB0aGUgQm9GIHNjb3BlIC4NCj4gDQo+IEkgZG9u4oCZdCB0aGlu ayB0aGUgY2xpZW50IG9mIHRoZSBtdWx0aS1kb21haW4gbmV0d29yayB3YW50cyB0byBoYXZlIGEg DQo+IHNvIGRldGFpbGVkIHZpZXcgb2YgdGhlIG5ldHdvcmssIGhlIGRvZXMgbm90IGNhcmUgYWJv dXQgZG9tYWlucywgaW50ZXIgDQo+IGRvbWFpbiBsaW5rcyBvciB3aGF0ZXZlciwgSSB3b3VsZCBz YXkgaGUgb25seSBjYXJlcyBhYm91dCBhIGdpdmVuIA0KPiBhbW91bnQgb2YgR2JwcyBmcm9tIEEg dG8gQiB3aXRoIGEgZ2l2ZW4gbWF4IGRlbGF5IGFuZCBwcm9iYWJseSBzb21lIGRpdmVyc2l0eSBw YXJhbWV0ZXJzLg0KPiANCj4gSUI+PiBBZ2FpbiwgYnkgY2xpZW50IEkgbWVhbiBtdWx0aS1kb21h aW4gbmV0d29yayBjb250cm9sbGVyIChlLmcuIA0KPiBJQj4+IFRlbGVmb25pY2ENCj4gU0ROIGNv bnRyb2xsZXIpLCBub3QgdGhlIGNsaWVudCB1c2luZyBzZXJ2aWNlcyBvZiB0aGUgbXVsdGktZG9t YWluIA0KPiBuZXR3b3JrIChpLmUuIG5vdCB0aGUgVGVsZWZvbmljYSBjbGllbnRzKS4gU3VjaCBj bGllbnQgdXNlcyAgdGhlIA0KPiB0cmFuc3BvcnQgZG9tYWlucyBmb3IgYSByZWFzb24uIOKAnGEg Z2l2ZW4gYW1vdW50IG9mIEdicHMgZnJvbSBBIHRvIELigJ0gDQo+IGlzIHRvbyBsb29zZSBhbmQg bGl0dGxlIGZvciB0aGUgY2xpZW50IHRvIGRvIHRoZSBuZXR3b3JrIHBsYW5uaW5nLiBJTU8gDQo+ IHRoZSBjbGllbnQgbmVlZHMgdG8gKnBsYW4qIHRoZSBhYnN0cmFjdCB0b3BvbG9naWVzIHByb3Zp ZGVkIGJ5IHRoZSANCj4gdHJhbnNwb3J0IGRvbWFpbnMgdGhlIHNhbWUgb3Igc2ltaWxhciB3YXkg YXMgaGUgd291bGQgcGxhbiBoaXMgb3duIGFjdHVhbCB0b3BvbG9neS4NCj4gDQo+IFNCPj4+IHll cywgc3VyZSwgaW4geW91IHZpZXcgb2Yg4oCcY2xpZW504oCdICwgdGhpcyBpcyB0aGUgc2Vydmlj ZSANCj4gU0I+Pj4gcHJvdmlkZXIgRGFuaWVsZSBpcw0KPiB0YWxraW5nLCBzbyBhbiBhYnN0cmFj dCB2aWV3IG9mIHdoYXQgaXMgdGhlIHJlYWwgdHJhbnNwb3J0IG5ldHdvcmsgaXMgDQo+IGNvbnNp ZGVyZWQgYXQgdGhpcyBsZXZlbC4gQXMgSSBzYWlkIHRvIFlvdW5nLCBpbiBteSBwcmV2aW91cyBt YWlsLCBpbiANCj4gdGhlIGNhc2Ugb2YgYSBzaW5nbGUgZG9tYWluIHNjZW5hcmlvIFZOQyBhbmQg UE5DIGNvdWxkIGFsc28gY29pbmNpZGUgDQo+IGJ1dCBpbiBjYXNlIG9mIGEgbXVsdGktZG9tYWlu IHNjZW5hcmlvcyB0aGUgc2NvcGUgaXMgdG8gcHJvdmlkZSB0byANCj4gYXBwbGljYXRpb24gbGF5 ZXIgYSBzaW5nbGUgdmlydHVhbGl6ZWQgdmlldyBvZiB0aGUgdW5kZXJsaW5lIG11bHRpIGRvbWFp biBuZXR3b3JrLg0KPiANCj4gT24gdGhlIG90aGVyIHNpZGUsIHRoZSBvbmUgdGhhdCBjYXJlcyBh Ym91dCBhbGwgb2YgdGhlIGlzc3VlcyB5b3UgDQo+IGxpc3RlZCBpcyB0aGUgc2VydmljZSBwcm92 aWRlciAoYXMgcGVyIGFjdHVhbCBkb2N1bWVudCB0ZXJtaW5vbG9neSkuIA0KPiBIb3dldmVyIGFs c28gdGhlIHNlcnZpY2UgcHJvdmlkZXIgZG9lcyBub3QgZ28gaW50byBwaHlzaWNhbCBpbXBhaXJt ZW50IA0KPiBkZXRhaWxzLiBIZSBjYXJlcyBhYm91dCBjb25uZWN0aXZpdHkgYmV0d2VlbiB0aGUg Ym9yZGVycyBvZiB0aGUgDQo+IGRvbWFpbnMsIGludGVyIGRvbWFpbiBsaW5rcy4gSG93IHN1Y2gg Y29ubmVjdGl2aXR5IGlzIHByb3Zpc2lvbmVkL21hbmFnZWQgaXMgdGhlIG5ldHdvcmsgcHJvdmlk ZXIgYnVzaW5lc3MuDQo+IFRoZSBuZXR3b3JrIHByb3ZpZGVzIG1pZ2h0IGJlIHVzaW5nIEdNUExT LCBOTVMgYW5kIE9ORiBjb250cm9sbGVyIHdpdGggDQo+IE9wZW4gRmxvdyBvciB3aGF0ZXZlciB0 byBjb250cm9sIHRoZSBuZXR3b3JrLiBNYXliZSBjYWxsaW5nIGl0IFBOQyBpcyANCj4gY29uZnVz aW5nPyBUaGUgUE5DIGNhbiBiZSBhbnkgb2YgdGhlIHRoaW5ncyBJ4oCZdmUgbGlzdGVkIGFuZCBt dWNoIG1vcmUuDQo+IA0KPiBJQj4+IEluIHRoaXMgY2FzZSBteSBjbGllbnQgaXMgeW91ciBzZXJ2 aWNlIHByb3ZpZGVyIDs9KS4gWW91IA0KPiBJQj4+IGFyY2hpdGVjdHVyYWxseQ0KPiBzZXBhcmF0 ZSBjbGllbnQgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciwgYmVjYXVzZSB5b3UgcHJvYmFibHkg DQo+IGJlbGlldmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBzdGFuZGFyZGl6ZSB0aGUgaW50ZXJm YWNlIGJldHdlZW4gdGhlIA0KPiB0d28uIEkgZGlzYWdyZWUgd2l0aCB0aGF0IGFuZCBkb27igJl0 IHRoaW5rIEFDVE4gc2hvdWxkIHdvcmsgb24gdGhpcy4gSW4gDQo+IHRoZSBjb250ZXh0IG9mIEFD VE4gSSBzZWUgb25seSB0d28gY29uc3RydWN0czogVHJhbnNwb3J0IGRvbWFpbiANCj4gY29udHJv bGxlciAodHJhbnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpIGFuZCAgVHJhbnNwb3J0IGNsaWVudCBj b250cm9sbGVyICh0cmFuc3BvcnQgc2VydmljZSB1c2VyKS4NCj4gDQo+IFNCPj4+IEFDVE4gaGVy ZSBpcyBub3QgcmVpbnZlbnRpbmcgdGhlIHdoZWVsICwgaW4gb3RoZXIgU0RPIFNETiANCj4gU0I+ Pj4gc3BlY2lmaWMgaXMNCj4gY29uc2lkZXJlZCAgdGhlIGFwcGxpY2F0aW9uIGxheWVyICwgYW5k IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBBTCBhbmQgDQo+IFNETiBjb250cm9sbGVyIChpbiB0aGlz IGNhc2UgdGhlIFZOQyBvZiBBQ1ROKSAuIFRoaXMgaW50ZXJmYWNlIHBlcm1pdCANCj4gdG8gYW55 IGNsaWVudCB0byBkaXJlY3RseSBpbXBhY3QgdG8gaGlzIG93biBzZXJ2aWNlcyBhbmQgaGlzIG93 biDigJx2aXJ0dWFsaXplZOKAnSByZXNvdXJjZXMgLg0KPiANCj4gDQo+IEhlbmNlIHRoZSBpbnRl cmZhY2VzIHRvIGJlIGNvbnNpZGVyZWQgYXJlIHR3bywgbm90IHRocmVlIChhcyBEYW4gc2FpZCkg DQo+IEkgdGhpbmsgdGhpcyByZXBsaWVzIHRvIHF1ZXN0aW9ucyAxIGFuZCAzLiBKdXN0IHRvIGFk ZCBzb21ldGhpbmcgDQo+IHJlZ2FyZGluZyAyLCBJIHdvdWxkIHNheSB0aGF0IHRoZXkgbmVlZCBq dXN0IGEgc2luZ2xlIGVudHJ5IHBvaW50IHRvIA0KPiB0aGUgbmV0d29yayBjb250cm9sIChjb3Vs ZCBiZSBhIHNtYWxsIHBpZWNlIG9mIGNvZGUgcnVubmluZyBvbiB0b3Agb2YgDQo+IHRoZSBQQ0Ug b2YgeW91ciBHTVBMUyBkb21haW4pLCB3aGljaCBhY3RzIGFzIGFuIGludGVyZmFjZSBiZXR3ZWVu IHRoZSANCj4gVk5DIGFuZCB0aGUgY29udHJvbCBwbGFuZSBvZiB5b3VyIG5ldHdvcmsgYW5kIHBl cmZvcm1zOiDigJwtIE1hcHBpbmcgb2YgcGh5c2ljYWwgYW5kIHZpcnR1YWwgcmVzb3VyY2Vz4oCd IGFuZCAg4oCcUmVxdWVzdHM6DQo+IHBhdGgsIHByb3Zpc2lvbiwgbW9kaWZ5IGFuZCByZXN0b3Jl 4oCdLg0KPiANCj4gSUI+PiBBcyBJIHNhaWQsIHRoaXMgaXMgdGhlIHRhc2sgb2YgdGhlIHRyYW5z cG9ydCBkb21haW4gSHlwZXJ2aXNvciwgDQo+IElCPj4gd2hvc2Ugcm9sZQ0KPiBpcywgZXNzZW50 aWFsbHksIHRvIHRyYW5zbGF0ZSBiYWNrIGFuZCBmb3J0aCBhYnN0cmFjdCA8PT4gYWN0dWFsIA0K PiB0b3BvbG9neSBlbGVtZW50cyBhbmQgc2VydmljZSByZXF1ZXN0cy9yZXNwb25zZXMgY29udGFp bmluZyB0aGUgDQo+IGFic3RyYWN0L2FjdHVhbCB0b3BvbG9neSBwYXRocy4gSSB0aGluayB0aGF0 IHRoZSBub3J0aC9zb3V0aCBpbnRlcmZhY2UgDQo+IGJldHdlZW4gdGhlIHRyYW5zcG9ydCBkb21h aW4gSHlwZXJ2aXNvciBhbmQgdGhlIGVudGl0eSByZXByZXNlbnRpbmcgDQo+IHRoZSBjbGllbnQg b2YgdGhlIHRyYW5zcG9ydCBkb21haW4gKG5vIG1hdHRlciBob3cgeW91IGNhbGwgaXQpIGlzIHRo ZSANCj4gb25seSBpbnRlcmZhY2UgQUNUTiBjYW4gd29yayBvbiB3aXRoIHRoZSBob3BlIHRvIHBy b2R1Y2Ugc29tZXRoaW5nIHVzZWZ1bC4NCj4gDQo+IENoZWVycw0KPiBEYW5pZWxlDQo+IA0KPiAN Cj4gDQo+IEZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNv bV0NCj4gU2VudDogdmVuZXJkw6wgMTAgb3R0b2JyZSAyMDE0IDAzOjE2DQo+IFRvOiBLaW5nLCBE YW5pZWw7IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IA0KPiBhY3RuQGlldGYu b3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyANCj4gZGllZ29A dGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86 bHV5dWFuZkBnbWFpbC5jb20+DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDog UkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0K PiBZb3VuZyBhbmQgRGFuLA0KPiANCj4gSXQgZG9lcyBub3QgbWF0dGVyIGhvdyB5b3UgY2FsbCBt ZSwgYW5kIGFzIEpvaG4gaXMgaGVscGZ1bGx5IGFwcGx5aW5nLCANCj4geW91IGNhbiBpZ25vcmUg d2hhdCBJIGFtIHNheWluZy4gQnV0IGxldCBtZSBleHBsYWluIGluIHNvbWUgbW9yZSANCj4gZGV0 YWlscyB3aGF0IEkgbWVhbnQuDQo+IA0KPiBTdXBwb3NlIHdlIGhhdmUgYSBjbGllbnQgKHN1Y2gg YXMgVEZLKSBvZiBhIG11bHRpLWRvbWFpbiB0cmFuc3BvcnQgDQo+IG5ldHdvcmssIHdobyB3YW50 cyB0byBwcm92aXNpb24gYW5kIG1hbmlwdWxhdGUgZTJlIHRyYW5zcG9ydCBzZXJ2aWNlcyANCj4g dGhlIHdheSBoZSB3YW50cyBpdCAoaS5lLiBhcHBseWluZyBoaXMgcG9saWNpZXMpLiBXaGF0IHdv dWxkIHN1Y2ggY2xpZW50IG5lZWQ/DQo+IA0KPiANCj4gMS4gICAgIEFuIGFjY2VzcyB0byBhIHVu aWZpZWQgbmV0d29yayBURSB0b3BvbG9neSB0aGF0IGNvdWxkIGJlIHVuZGVyc3Rvb2QgYW5kDQo+ IHVzZWQgYnkgdGhlIGNsaWVudOKAmXMgcGF0aCBjb21wdXRlciB0byBzZWxlY3Qgc2VydmljZSBl MmUgcGF0aHMuIEhvdyANCj4gZG9lcyB0aGUgY2xpZW50IGdldCBzdWNoIGEgdG9wb2xvZ3k/IFRo ZSBuZWNlc3Nhcnkgb3ZlcmxheSB0b3BvbG9neSANCj4gY29tcHJpc2VzIGFic3RyYWN0IHRvcG9s b2dpZXMgcHJlc2VudGVkIGZvciB0aGUgY2xpZW50IGJ5IGVhY2ggb2YgdGhlIA0KPiB0cmFuc3Bv cnQgZG9tYWlucw0KPiArIGludGVyLWRvbWFpbiBURSBsaW5rcy4gSGVuY2Ugd2UgYXJlIHRhbGtp bmcgYWJvdXQgaW50ZXJmYWNlICMxIChhbmQgDQo+ICsgZGF0YQ0KPiBtb2RlbCAjMSkgYmV0d2Vl biBhIHByb3ZpZGVyIGh5cGVydmlzb3IvVk5DIGFuZCB0aGUgY2xpZW50IGNvbnRyb2xsZXIgDQo+ IHRvIGV4cG9zZSBpbiBhIHVuaWZpZWQgYWJzdHJhY3QgIHdheSAgaXRzIHRvcG9sb2d5IG9uIHBl ciBjbGllbnQvdGVuYW50IGJhc2lzLg0KPiBGdXJ0aGVybW9yZSwgdGhlIGNsaWVudCBjb250cm9s bGVyIGNhbiB1c2UgdGhpcyBpbnRlcmZhY2UgaW4gdGhlIA0KPiBvcHBvc2l0ZSBkaXJlY3Rpb24g dG8gbW9kaWZ5IHRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IChzdWJqZWN0IHRvIA0KPiB0aGUg cHJvdmlkZXLigJlzIGFwcHJvdmFsKSwgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHRoZSBvbmx5IGd1 eSB3aG8ga25vd3MgDQo+IGhvdyB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgZXhwb3NlZCB0byBoaW0g c2hvdWxkIGxvb2sgbGlrZSB0byBiZSB1c2VmdWwgDQo+IChlLmcuIHdoaWNoIGFuZCBob3cgdGhl IGFic3RyYWN0IGxpbmtzIHNob3VsZCBiZSBkaXNqb2ludCBmcm9tIGVhY2ggDQo+IG90aGVyLCBo b3cgbWFueSBvZiB0aGVtIHNob3VsZCBiZSBwcm92aWRlZCwgdGhlaXIgYXR0cmlidXRlcywgZGVz aXJlZCANCj4gcmVjb3ZlcnkgY2FwYWJpbGl0aWVzLCBldGMsKS4gVGhpcyBrbm93bGVkZ2UgaXMg c3VwcG9zZWQgdG8gY29tZSBmcm9tIHRoZSBjbGllbnTigJlzIG5ldHdvcmsgcGxhbm5pbmcuDQo+ IA0KPiAyLiAgICAgQSB3YXkgdG8gcHJvdmlzaW9uL21vZGlmeS9kZWxldGUgZTJlIHNlcnZpY2Vz IHdpdGggdGhlIHVzZSBvZiBzbw0KPiBjb21wdXRlZCBlMmUgcGF0aHMuIFRoZSBjbGllbnTigJlz IGNvbnRyb2xsZXIgZG9lcyB0aGF0IGJ5IGNob3BwaW5nIHRoZSANCj4gcGF0aHMgaW50byBwZXIt ZG9tYWluIHNlZ21lbnRzIGFuZCBpbnN0cnVjdHMgcmVzcGVjdGl2ZSBkb21haW4gDQo+IFZOQ3Mv SHlwZXJ2aXNvcnMgdG8gc2V0IHVwL21hbmlwdWxhdGUgc2VydmljZSByZXNwZWN0aXZlIGNvbm5l Y3Rpb24gDQo+IHNlZ21lbnRzLiBIZW5jZSB3ZSBhcmUgdGFsa2luZyBhYm91dCBpbnRlcmZhY2Ug IzIgKGRhdGEgbW9kZWwgIzIpIGZvciANCj4gdGhlIHNlcnZpY2Ugc2VnbWVudCBtYW5pcHVsYXRp b247DQo+IA0KPiAzLiAgICAgQSB3YXkgdG8gbW9uaXRvciwgdHJvdWJsZXNob290LCBjYXJyeSBv dXQgbWFpbnRlbmFuY2Ugb2YgdGhlIGFjdGl2ZSBlMmUNCj4gc2VydmljZXMuIFRoaXMgd291bGQg cmVxdWlyZSBpbnRlcmZhY2UgIzMgKGRhdGEgbW9kZWwgIzMpIGJldHdlZW4gdGhlIA0KPiBjbGll bnTigJlzIGNvbnRyb2xsZXIgYW5kIGRvbWFpbnMgVk5Dcy9IeXBlcnZpc29ycyBmb3IgdGhpcyBw dXJwb3NlLg0KPiANCj4gU28sIHdlIGFyZSB0YWxraW5nIDMgWWFuZyBtb2RlbHMgd2l0aCByZXF1 aXJlZCBtb2RpZmljYXRpb25zIHRvIA0KPiBuZWl0aGVyIE5ldGNvbmYvUmVzdGNvbmYsIG5vciAg VG8gYW55IG90aGVyIG1hbmFnZW1lbnQsIHJvdXRpbmcgb3IgDQo+IHNpZ25hbGluZyBwcm90b2Nv bC4NCj4gDQo+IE5vdyBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHRvIHlvdToNCj4gDQo+ IDEuICAgICBJbiB0aGlzIGV4YW1wbGUsIHdoYXQgZWxzZSAoaW4gYWRkaXRpb24gdG8gdGhlc2Ug dGhyZWUgbW9kZWxzKSB0aGUgY2xpZW50DQo+IHN1Y2ggYXMgVEZLIGluIHlvdXIgb3BpbmlvbiB3 b3VsZCBuZWVkPw0KPiANCj4gMi4gICAgIFdoYXQgZWxzZSB0aGUgbmV0d29yayBwcm92aWRlcnMg YW5kIHRoZWlyIHZlbmRvcnMgc3VjaCBhcyBBRFZBIG9yDQo+IENJRU4gd291bGQgbmVlZD8NCj4g DQo+IDMuICAgICBXaGF0IGlzIHRoZSBpbXBvcnRhbmNlIG9mIGEgY29uc3RydWN0IHN1Y2ggYXMg UE5DPw0KPiANCj4gDQo+IE15IGFuc3dlciB0byAzLiDigJxJcyBub3QgaW1wb3J0YW50IGF0IGFs bCwgaXJyZWxldmFudOKAnSBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0KPiANCj4gYSkgICAg IFdoYXQgaGFwcGVucyBiZXlvbmQgdGhlIFZOQy9IeXBlcnZpc29yIGluIHRoZSBwcm92aWRlciBu ZXR3b3JrIGlzDQo+IGNvbXBsZXRlbHkgcHJvcHJpZXRhcnkuDQo+IA0KPiBiKSAgICAgVGhlcmUg Y291bGQgYmUgbnVtZXJvdXMgd2F5cyBhcyB0byBob3cgdGhlIHByb3ZpZGVyIG5ldHdvcmsgaXMN Cj4gbWFuYWdlZC4gRXhhbXBsZXM6IGNlbnRyYWxpemVkIFBOQyAoYXMgeW91IGNhbGwgaXQpLCBB RFZBIHN0eWxlIEdNUExTIA0KPiBiYXNlZCBuZXR3b3JrIGludGVsbGlnZW5jZSwgQ0lFTiBzdHls ZSBQTk5JIGJhc2VkIGNvbnRyb2wgcGxhbmUsIGV0Yy4gDQo+IFdoeSBpcyB0aGF0IG9mIEFDVE7i gJlzIGJ1c2luZXNzPw0KPiANCj4gQ2hlZXJzLA0KPiBJZ29yDQo+IA0KPiBGcm9tOiBLaW5nLCBE YW5pZWwgW21haWx0bzpkLmtpbmdAbGFuY2FzdGVyLmFjLnVrXQ0KPiBTZW50OiBUaHVyc2RheSwg T2N0b2JlciAwOSwgMjAxNCA0OjU4IFBNDQo+IFRvOiBMZWV5b3VuZzsgSWdvciBCcnlza2luOyBC RUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IA0KPiBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGll dGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyANCj4gZGllZ29AdGlkLmVzPG1haWx0bzpkaWVn b0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+ DQo+IENjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVs bGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBBbGwsIGluY2x1ZGlu ZyDigJxJZ25vcuKAnSA7LSkNCj4gDQo+IFR5cGljYWwgZGljaG90b215IGJldHdlZW4gd2hhdCBv cGVyYXRvcnMgd2FudCBhbmQgd2hhdCB2ZW5kb3JzIGFyZSANCj4gYWN0dWFsbHkgd2lsbGluZyB0 byBwcm92aWRlLCBncm91cCBjb25zZW5zdXMgd2lsbCBldmVudHVhbGx5IGhlbHAgcmVzb2x2ZSB0 aGF0Lg0KPiBFaXRoZXIgd2F5LCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIEZyYW1ld29yayBJ LUQgaXMgdHJ5aW5nIHRvIGZvY3VzIA0KPiBBQ1ROIGRpc2N1c3Npb24gYW5kIHNjb3BlIChpLmUu LCB0aGUgcHJvdG9jb2wgd29yaykgb24gdGhlIGludGVyZmFjZXMgDQo+IHdoaWNoIGFyZSBpbiBz Y29wZSwgbmFtZWx5Og0KPiANCj4gMS4gVGhlIENOQy1WTkMgSW50ZXJmYWNlIChDVkkpDQo+IC0g Q3JlYXRlLCBtb2RpZnkgYW5kIGRlbGV0ZSB2aXJ0dWFsIG5ldHdvcmsgc2VydmljZSBpbnN0YW5j ZXMNCj4gLSBSZXNvdXJjZSBtb2RlbA0KPiANCj4gMi4gVGhlIFZOQy1QTkMgSW50ZXJmYWNlIChW UEkpDQo+IC0gTWFwcGluZyBvZiBwaHlzaWNhbCBhbmQgdmlydHVhbCByZXNvdXJjZXMNCj4gLSBS ZXF1ZXN0czogcGF0aCwgcHJvdmlzaW9uLCBtb2RpZnkgYW5kIHJlc3RvcmUNCj4gDQo+IEFzIFlv dW5nIHN1Z2dlc3RzLCBpZiB0aGUgVk5DIHJlY2VpdmVkIHBoeXNpY2FsIHRvcG9sb2d5IGluZm8g aXQgd291bGQgDQo+IGJlIHBlcmZvcm1pbmcgdGhlIHJvbGUgb2YgdGhlIFBoeXNpY2FsIE5ldHdv cmsgQ29udHJvbGxlciAoUE5DKSwgd2hpY2ggDQo+IGlzIG9idmlvdXNseSBhIChzb21laG93KSBy ZXF1aXJlZCBmdW5jdGlvbiwgYnV0IHRoZSBpbnRlcmZhY2UgKGRpcmVjdCANCj4gcHJvdmlzaW9u aW5nIG9mIHRoZSBhY3R1YWwgcGh5c2ljYWwgbmV0d29yaykgaXMgb3V0IG9mIHNjb3BlIGZvciBB Q1ROLg0KPiANCj4gQnIsIERhbi4NCj4gDQo+IEZyb206IEFDVE4gW21haWx0bzphY3RuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWV5b3VuZw0KPiBTZW50OiAwOSBPY3RvYmVyIDIw MTQgMjE6MzINCj4gVG86IElnb3IgQnJ5c2tpbjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyAN Cj4gYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxs aTsgDQo+IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsNCj4gbHV5dWFuZkBnbWFp bC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KPiBDYzogVmFybWEsIEV2ZSBMIChFdmUp DQo+IFN1YmplY3Q6IFJlOiBbQWN0bl0gZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0w My50eHQgY29tbWVudHMNCj4gDQo+IEhpIElnbm9yLA0KPiANCj4gVGhhbmsgeW91IGZvciBwcm92 aWRpbmcgeW91ciBjb21tZW50IHRoYXQgcGF1c2VzIHVzIHRvIHRoaW5rIG1vcmUgYW5kIA0KPiB1 bmRlcnN0YW5kIG9uIHRoZSBzYW1lIGxldmVsLiBJIHRoaW5rIHlvdXIgY29tbWVudCB3aWxsIGNv bnRyaWJ1dGUgdG8gDQo+IGNyeXN0YWxsaXplIHRoZSBzY29wZSBvZiB3b3JrIGhlcmUuDQo+IA0K PiBGaXJzdCBvZiBhbGwsIEkgdGhpbmsgdGhlcmUgd2FzIGEgbWlzdW5kZXJzdGFuZGluZyBoZXJl LiBGaXJzdCwgeW91ciANCj4gYXNzdW1wdGlvbiBvbiBWTkMgcmVjZWl2aW5nIGFjdHVhbCB1bmRl cmx5aW5nIHRvcG9sb2d5IGlzIGluY29ycmVjdC4gDQo+IElmIFZOQyB3ZXJlIHRvIGhhdmUgYWN0 dWFsbHkgdG9wb2xvZ3kgKGUuZy4gVEVEKSBvZiBhIG5ldHdvcmssIHRoaXMgDQo+IHdvdWxkIGJl IGNhbGxlZCBhIFBOQyBhbmQgdGhpcyBpcyBvdXQgb2Ygc2NvcGUgb2YgQUNUTi4gVGhpcyBhc3Bl Y3QgDQo+IGhhcyBiZWVuIGRpc2N1c3NlZCBieSBlbWFpbCB0aHJlYWRzIERhbmllbGUgc3RhcnRl ZCBhIGZldyB3ZWVrcyBhZ28uIA0KPiBDaGVjayB0aGUgYXJjaGl2ZSBvbiB0aGF0LiBUaGUgcmVh c29uIHRoaXMgaXMgb3V0IG9mIHNjb3BlIGlzIHRoYXQgUE5DIA0KPiBtdWx0aS1kb21haW4gaXNz dWUgaXMgbm8gZGlmZmVyZW50IGZyb20gdG9kYXnigJlzIEdNUExTL1BDRSBpc3N1ZSwgDQo+IGVz cGVjaWFsbHkgaW4gbGlnaHQgb2YgSC1QQ0UuIEFDVE4gZG9lcyBub3Qgc3RlcCBvbiB0aG9zZSBh cmVhcy4gV2hhdCANCj4gVk5DIHJlY2VpdmVzIGZyb20gZWFjaCBQTkMgKGRvbWFpbiBjb250cm9s bGVyKSBpcyBhbiBhYnN0cmFjdGVkIA0KPiB0b3BvbG9neSB3aXRoIHZhcnlpbmcgZGVncmVlcyBm cm9tIGFjdHVhbCB1bmRlcmx5aW5nIHRvcG9sb2d5LiBUaGUgcmVhc29uIHdoeSB3ZSBkaXN0aW5n dWlzaCB0aGUgdGVybSBWTkMgZnJvbSBQTkMuDQo+IA0KPiBXaGF0IGNhbiBiZSBkZWZpbmVkIG9u IFZOQy1QTkMgaXMgYSB2ZXJ0aWNhbCBzaWduYWxpbmcgY29vcmRpbmF0aW9uIA0KPiBmcm9tIFZO QyB0byBlYWNoIFBOQy4gQXMgbG9uZyBhcyB0aGUgZGV0YWlsZWQgcGF0aCBjb21wdXRhdGlvbiBh bmQgDQo+IHNpZ25hbGluZyB3aXRoaW4gYSBkb21haW4gYXJlIGNvbXBsZXRlbHkgdXAgdG8gdGhl IGRvbWFpbiBQTkMuIFZOQyBpcyANCj4gbm90IHRvIGJlIG9wZXJhdGVkIG9uIHRoZSBzYW1lIGxl dmVsIGFzIFBOQy4gSXRzIGVuZC10by1lbmQgcGF0aCANCj4gY29tcHV0YXRpb24gaXMgYmFzZWQg b24gd2hhdCBpcyBleHBvc2VkIGZyb20gUE5DcyB0byBWTkMuIFRoZSBhY3R1YWwgDQo+IHRvcG9s b2d5IGluZm9ybWF0aW9uIGRldGFpbHMgaXMga2VwdCBieSBQTkNzIGFuZCB0aGUgUE5DcyBleHBv c2UgDQo+IGFic3RyYWN0ZWQgdG9wb2xvZ3kgdGhhdCBjYW4gaGlkZSB0aGUgZXhhY3QgZGV0YWls cyB3aGlsZSBleHBvc2luZyBhIG1pbmltdW0gbGV2ZWwgb2YgY29uc3RyYWludHMuDQo+IEZvciBp bnN0YW5jZSwgdGhlIFNSTEcgb2YgdmlydHVhbCBsaW5rcyAod2hpY2ggbWF5IGJlIGNvbmNhdGVu YXRlZCANCj4gYWN0dWFsDQo+IGxpbmtzKSBjYW4gYmUgZXhwb3NlZCBmb3IgZGl2ZXJzaXR5IHJv dXRpbmcgY2FsY3VsYXRpb24gYXQgdGhlIFZOQy4gDQo+IFRoaXMgaXMgdmVyeSBkaWZmZXJlbnQg ZnJvbSBleHBvc2luZyB0aGUgYWN0dWFsIFRFIHRvcG9sb2d5LiBZb3UgY2FuIA0KPiB2aWV3IHRo aXMgYXMgdHdvIGxldmVsIG9mIHBhdGggY29tcHV0YXRpb24uIFZOQyBmaXJzdCBjb21wdXRlcyBh biANCj4gZW5kLXRvLWVuZCBwYXRoICh1c2luZyB3aGF0ZXZlciBjb25zdHJhaW50IGluZm9ybWF0 aW9uIGl0IGhhcyksIHRoZW4gDQo+IGNvb3JkaW5hdGVzIHdpdGggZWFjaCBQTkMgKHRlbGxpbmcg dGhlIGJvcmRlciBub2RlcyBpbmZvcm1hdGlvbiksIHRoZW4gDQo+IGVhY2ggUE5DIGNvbXB1dGVz IHRoZSBkb21haW4gc3BlY2lmaWMgcGF0aC4gV2hlbiBhIFBOQyBjYW5ub3QgcHJvdmlkZSANCj4g YSBwYXRoIHNlZ21lbnQgaW4gaXRzIGRvbWFpbiwgdGhlbiB0aGlzIG5lZWRzIHRvIGJlIHNpZ25h bGVkIHRvIFZOQyBzbyANCj4gdGhhdCB0aGUgVk5DIHdvdWxkIGFycmFuZ2UgYW4gYWx0ZXJuYXRl IHBhdGggc2VnbWVudCB0byBiZSBhYmxlIHRvIA0KPiBmaW5kIGEgZmVhc2libGUgZW5kLXRvLWVu ZCBwYXRoLiAgSSB3b3VsZCBzYXkgdGhpcyBpcyBhIOKAnHR3by1waGFzZeKAnSANCj4gc2lnbmFs aW5nIGFuZCBwYXRoIGNvbXB1dGF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB0aGVyZSBtdXN0IGJl IHNvbWUgDQo+IGxldmVsIG9mIGhpZGluZyBvbiBhYnN0cmFjdCB0b3BvbG9neSBleHBvc3VyZSBm cm9tIFBOQyB0byBWTkMgYW5kIA0KPiBwcm9wcmlldGFyeSBjaGFyYWN0ZXJpc3RpY3Mgb2Ygb3B0 aWNhbCBkZXZpY2VzIG5lZWQgdG8gYmUgZGVhbHQgb25seSB3aXRoIHRoZSBjb3JyZXNwb25kaW5n IFBOQy4NCj4gDQo+IFJlZ2FyZGluZyB0aGUgdGVybSBQTkMgdnMuIEFOQywgSSB3b3VsZG7igJl0 IGNvbmNlcm4gdG9vIG11Y2ggYWJvdXQgdGhlIA0KPiB0ZXJtaW5vbG9neSB3aGljaGV2ZXIgd29y a3MgYmV0dGVyLiBUaGFuayB5b3UgZm9yIHlvdXIgc3VnZ2VzdGlvbi4NCj4gDQo+IExhc3RseSwg cGxlYXNlIGNoZWNrIHRoZSB1c2UtY2FzZXMgd3JpdHRlbiBieSBvcGVyYXRvcnMgaW4gdGhlIGJl bG93IA0KPiBsaW5rcyB0aGF0IGNvbnNpc3RlbnRseSBzYXkgdGhleSBuZWVkIGEgc3RhbmRhcmQg aW50ZXJmYWNlIHRoYXQgY2FuIA0KPiBjb29yZGluYXRlIHRoZWlyIG11bHRpLWRvbWFpbiBpc3N1 ZXMuDQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYW5nLWFj dG4tbXVsdGlkb21haW4tZGNpLw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1rbGVlLWFjdG4tY29ubmVjdGl2aXR5LW11bHRpLXZlDQo+IG5kb3ItDQo+IGRvbWFpbnMv DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1bWFraS1hY3RuLW11 bHRpdGVuYW50LXZuby8NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bG9wZXotYWN0bi12bm8tbXVsdGlkb21haW5zLw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1zaGluLWFjdG4tbXZuby1tdWx0aS1kb21haW4vDQo+IA0KPiBSZWdhcmRz LA0KPiBZb3VuZw0KPiANCj4gVGhhbmtzLA0KPiBZb3VuZw0KPiANCj4gDQo+IEZyb206IElnb3Ig QnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NCj4gU2VudDogVGh1cnNk YXksIE9jdG9iZXIgMDksIDIwMTQgMTo0OCBQTQ0KPiBUbzogQkVMT1RUSSwgU0VSR0lPIChTRVJH SU8pOyBMZWV5b3VuZzsgDQo+IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBE YW5pZWxlIENlY2NhcmVsbGk7IA0KPiBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47 DQo+IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCj4gQ2M6IFZh cm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZy YW1ld29yay0wMy50eHQgY29tbWVudHMNCj4gDQo+IEhpIFlvdW5nLA0KPiANCj4gSSBiZWxpZXZl IGhhdmluZyB0aGUgc2FtZSBpbnN0YW5jZSBvZiBWTkMgdGFsa2luZyB0byBkaWZmZXJlbnQgdmVu ZG9yIA0KPiBkb21haW4gUE5DcyBpcyBhbiBleHRyZW1lbHkgIGlkZWFsaXN0aWMgdmlldy4NCj4g DQo+ID09PT0+IEJUVyBJIGZpbmQgUE5DIGlzIGEgYmFkIHRlcm0sIEkgbGlrZSBtdWNoIGJldHRl ciBBY3R1YWwgTmV0d29yayANCj4gQ29udHJvbGxlciAgKEFOQykuIFZOQyAoYS5rLmEuIGEgSHlw ZXJ2aXNvcikgaXMgbWFuYWdpbmcgYWJzdHJhY3QgDQo+IHRvcG9sb2dpZXMsIGFuZCB0byBiZSBh YmxlIGRvIHRoYXQsIGl0IHRhbGtzIHRvIGEgQU5DLSBhIGNvbnRyb2xsZXIgDQo+IHdoaWNoIGhh cyBhbiBhY2Nlc3MgYW5kIG1hbmFnZXMgYWN0dWFsIHByb3ZpZGVyIG5ldHdvcmspLg0KPiANCj4g T25lIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0IFZOQyBuZWVkcyB0byB1bmRlcnN0YW5kIHVuZGVy bHlpbmcgYWN0dWFsIA0KPiB0b3BvbG9neSwgZm9yIGV4YW1wbGUsIHRvIGVuc3VyZSB0aGF0IHR3 byBhYnN0cmFjdCBURSBsaW5rcyBhcmUgU1JMRyANCj4gZGlzam9pbnQgYXMgcmVxdWVzdGVkLiBB Y3R1YWwgdG9wb2xvZ3kgc2VtYW50aWNzIChlc3BlY2lhbGx5IGluIFdETSANCj4gbGF5ZXIpIGlz IHZlcnkgZGlmZmVyZW50IGZyb20gdmVuZG9yIHRvIHZlbmRvciBhbmQgY29udGFpbnMgYSBncmVh dCANCj4gdmFyaWV0eSBvZiBwcm9wcmlldGFyeSBleHRlbnNpb25zLCBmYWlsaW5nIHRvIHVuZGVy c3RhbmQgd2hpY2ggbGVhZHMgDQo+IHRvIHByb2R1Y2luZyB1bnByb3Zpc2lvbmFibGUgc2Vydmlj ZSBwYXRocy4gRG8geW91IHJlYWxseSBiZWxpZXZlIHRoYXQgDQo+IGEgc2luZ2xlIFZOQyBjYW4g dGFsayBpbiB0aGUgc2FtZSB3YXkgdG8gQURWQSwgSU5GTiwgQUxVIGFuZCBIdWF3ZWkgDQo+IEFO Q3M/IFRoaXMgaXMgZXF1aXZhbGVudCB0byBhc2sgYWxsIG9wdGljYWwgcHJvdmlkZXJzIHRvIHN3 aXRjaCB0byBXU09OIDo9KS4NCj4gDQo+IFRoaXMgaXMgbm90IHRvIHNheSB0aGF0IHlvdSBjYW5u b3QgYnVpbGQgYSBoaWVyYXJjaHkgb2YgVk5DcywgYnV0IGluIA0KPiB0aGlzIGNhc2UgTm9ydGgg Vk5DIHBsYXlzIHJvbGUgb2YgYSBjbGllbnQgbmV0d29yayBjb250cm9sbGVyIHdydCB0byANCj4g U291dGggVk5DLCB0aGF0IGlzLCB1c2VzIHRoZSBzYW1lIFggaW50ZXJmYWNlLg0KPiBJSE1PIHdo ZW5ldmVyIGEgVk5DIGhhcyB0byB0YWxrIHRvIGEgQU5DLCBpdCBkb2VzIHNvIGluIGEgcHJvcHJp ZXRhcnkgDQo+IHdheSwgaS5lLiBBRFZBLCBJTkZOLCBBTFUgYW5kIEh1YXdlaSB3aWxsIGhhdmUg dGhlaXIgb3duIFZOQ3MgZXhwb3NpbmcgDQo+IHRoZSBzYW1lIG5vcnRoIGJvdW5kIGludGVyZmFj ZSB0byBwb3RlbnRpYWxseSB0aGUgc2FtZSBjbGllbnQgKGUuZy5URkspLg0KPiBJSE1PIGludGVy ZmFjZSBYIGlzIHRoZSBvbmx5IGludGVyZmFjZSB0aGF0IHRoZSBBQ1ROIGNhbiB3b3JrIG9uLg0K PiANCj4gQ2hlZXJzLA0KPiBJZ29yDQo+IA0KPiBGcm9tOiBBQ1ROIFttYWlsdG86YWN0bi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQkVMT1RUSSwgU0VSR0lPDQo+IChTRVJHSU8pDQo+ IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDU6NTkgQU0NCj4gVG86IExlZXlvdW5n OyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxp OyANCj4gZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0KPiBsdXl1YW5mQGdtYWls LmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQo+IENjOiBCRUxPVFRJLCBTRVJHSU8gKFNF UkdJTyk7IFZhcm1hLCBFdmUgTCAoRXZlKQ0KPiBTdWJqZWN0OiBSZTogW0FjdG5dIGRyYWZ0LWNl Y2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBZb3VuZywN Cj4gDQo+IHRoYW5rcyBhIGxvdCBmb3IgcmVwbHkgLCBwbGVhc2Ugc2VlIGluIGxpbmUganVzdCBz b21lIGZ1cnRoZXIgDQo+IGNsYXJpZmljYXRpb24NCj4gDQo+IFJlZ2FyZHMNCj4gU2VyZ2lvDQo+ IA0KPiANCj4gDQo+IEZyb206IExlZXlvdW5nIFttYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0N Cj4gU2VudDogbWVyY29sZWTDrCA4IG90dG9icmUgMjAxNCAxNzozNQ0KPiBUbzogQkVMT1RUSSwg U0VSR0lPIChTRVJHSU8pOyBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgDQo+ IERhbmllbGUgQ2VjY2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+Ow0K PiBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQo+IENjOiBWYXJt YSwgRXZlIEwgKEV2ZSkNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFt ZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0KPiBIaSBTZXJnaW8sDQo+IA0KPiBUaGFua3MgZm9y IHlvdXIgZmVlZGJhY2sgb24gdGhlIGZyYW1ld29yayBkb2N1bWVudC4gUGxlYXNlIHNlZSBpbi1s aW5lIA0KPiBmb3IgbXkgY29tbWVudC4NCj4gDQo+IFJlZ2FyZHMsDQo+IFlvdW5nDQo+IA0KPiBG cm9tOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgDQo+IFttYWlsdG86c2VyZ2lvLmJlbG90dGlA YWxjYXRlbC1sdWNlbnQuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDgsIDIwMTQg NzozNCBBTQ0KPiBUbzogYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmll bGUgQ2VjY2FyZWxsaTsgTGVleW91bmc7IA0KPiBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRp ZC5lcz47DQo+IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCj4g Q2M6IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgVmFybWEsIEV2ZSBMIChFdmUpDQo+IFN1Ympl Y3Q6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQo+IA0K PiBIaSBEYW5pZWxlICwgWW91bmcgYW5kIGFsbCBhdXRob3JzLA0KPiANCj4gSSByZWFkIHlvdSBG cmFtZXdvcmsgZHJhZnQgYW5kIEkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoYXQuIE1vc3QgYXJl IA0KPiBlZGl0b3JpYWwgLCBvdGhlciBxdWVzdGlvbnMgZm9yIGNsYXJpZmljYXRpb25zLg0KPiAN Cj4gR2VuZXJhbCBxdWVzdGlvbjogaW4gdGhlIGRyYWZ0IHRoZSBjb25jZXB0IG9mIFZOQyBpcyBp biB0aGUgdmlldyBvZiANCj4gaGllcmFyY2hpY2FsIGxldmVsIG9mIGNvbnRyb2xsZXJzIG9yIGxp bmtlZCB0byB0aGUgbXVsdGktZG9tYWluIGFzcGVjdCANCj4gdGhhdCBjb21wZWwgdG8gcHJvdmlk ZSB0byB0aGUgY3VzdG9tZXIgYSBzaW5nbGUgdmlydHVhbGl6ZWQgbmV0d29yayANCj4gZXZlbiBp ZiBjb21wb3NlZCBieSByZWFsIG11bHRpLWRvbWFpbiBtdWx0aS10ZWNobm9sb2d5IHN1Ym5ldHdv cmtzPyBJIA0KPiBtZWFuLCB0aGUg4oCcdmlydHVhbGl6ZXIgZnVuY3Rpb27igJ0gcHJvdmlkZWQg YnkgVk5DLCBpbiBjYXNlIG9mIGEgc2luZ2xlIA0KPiBkb21haW4gY29udGV4dCBjb3VsZCBiZSBp bnNpZGUgZGlyZWN0bHkgdGhlIFBOQyAsIGNvcnJlY3Q/DQo+IA0KPiBZT1VORz4+IFllcy4gVGhh dCBpcyB0aGUgY29ycmVjdCB2aWV3IG9mIFZOQy4gRm9yIGEgc2luZ2xlIGRvbWFpbiANCj4gWU9V Tkc+PiBjb250ZXh0LA0KPiB0aGUgVk5DIGNhbiBiZSBpbnRlZ3JhdGVkIHdpdGggUE5DLiBCdXQg d2UgbmVlZCB0byBmYWN0b3IgaW4gb3RoZXIgDQo+IHNjZW5hcmlvcyBzdWNoIGFzIDEpIFZOQyB2 ZW5kb3IgbWF5IGJlIGRpZmZlcmVudCBmcm9tIFBOQyB2ZW5kb3Igb3IgMikgDQo+IFZOQyBpcyBh IHNvZnR3YXJlIGZ1bmN0aW9uIHRoYXQgb3BlcmF0b3IgbWF5IHdhbnQgdG8gb3BlcmF0ZSBhcyBp dHMgY29udHJvbC4NCj4gSW4gbXkgb3BpbmlvbiwgZXZlbiBmb3IgYSBzaW5nbGUgZG9tYWluLCBJ IHRoaW5rIHRoZXJlIGlzIGJlbmVmaXQgdG8gDQo+IGRlZmluZSB0aGlzIGludGVyZmFjZSBhcyBh IHN0YW5kYXJkIGludGVyZmFjZS4NCj4gDQo+IFNlY3Rpb24gMiAsIHBhZ2UgNDoNCj4gYWJzdHJh Y3Rpb24gZG9lcyBub3QgaW1wbHkgYXV0b21hdGljYWxseSB2aXJ0dWFsaXphdGlvbix3aGlsZSAN Cj4gdmlydHVhbGl6YXRpb24gaW1wbGllcyB0byBoYXZlIHN1cmVseSBhIGNlcnRhaW4gZm9ybSBv ZiBhYnN0cmFjdGlvbi4gSSANCj4gd291bGQgc3VnZ2VzdCB0byBjb25zaWRlciBnb29kIGRlZmlu aXRpb24gY29udGFpbmVkIGludG8gT05GIFNETiANCj4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGNo YXB0ZXIgMi4zIENvbnZlbnRpb25zIGFib3V0IGFic3RyYWN0aW9uIGFuZCANCj4gdmlydHVhbGl6 YXRpb24uIEEgZ29vZCBkZWZpbml0aW9uIGNhbiBoZWxwIGFsbCB0aGUgcmVhZGluZy4NCj4gDQo+ IFlPVU5HPj4gQWdyZWUuIFdlIHdpbGwgbG9vayBpbnRvIHRoZSBtZW50aW9uZWQgZG9jdW1lbnQg aWYgdGhlIHVzYWdlIA0KPiBZT1VORz4+IG9mDQo+IHRlcm1zIGFyZSBhbGlnbmVkIHdpdGggdGhp cyBkb2N1bWVudC4gSWYgbm90LCB3ZSB3aWxsIGNsYXJpZnkgdGhlIA0KPiB0ZXJtaW5vbG9neSBt b3JlIGNsZWFybHkuDQo+IA0KPiBTZWN0aW9uIDU6IEl0IHNlZW1zIHRvIG1lIHlvdSBtaXhlZCBo ZXJlIGFzcGVjdHMgdGhhdCBhcmUgbW9yZSByZWxhdGVkIA0KPiB0byBwb2xpY3kgbGlrZSBhZG1p c3Npb24gY29udHJvbCAgYW5kIGd1YXJhbnRlZSBvZiBjbGllbnQgaXNvbGF0aW9uIA0KPiB3aXRo IHJlYWwgY29tcHV0YXRpb25hbCBpc3N1ZSBsaWtlIENvbXB1dGluZyB0aW1lICwgcGF0aCBjb25z dHJhaW5zIG9yIA0KPiByZS1vcHRpbWl6YXRpb24gcHJvY2Vzcy4gTW9yZW92ZXIgdGhlIHRlcm0g Vk5NIGZvciBWaXJ0dWFsIG5ldHdvcmsgDQo+IG1hcHBpbmcgaXMgYSBiaXQgbWlzbGVhZGluZyBz aW5jZSB0aGlzIHRlcm0gaW4gYWxyZWFkeSB1c2VkIGUuZy4gaW4gDQo+IEFCTk8gYXJjaGl0ZWN0 dXJlIGZvciBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdlci4NCj4gDQo+IFlPVU5HPj4gSW5kZWVkLiBJ biBTZWN0aW9uIDUsIHdlIHdpbGwgcHV0IHNvbWUgbm90ZXMgb24gdGhlIGFzcGVjdCBvZiANCj4g WU9VTkc+PiByZWFsLQ0KPiB0aW1lIHJlbGF0ZWQgZnJvbSBub24gcmVhbCB0aW1lIGFzcGVjdC4g Vk5NIGlzIG5vdCB0byBiZSBtaXhlZCB3aXRoIA0KPiBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdlci4g SGVyZSBWTk0gaXMgYW4gYWxnb3JpdGhtIHdoaWNoIGlzIGtub3duIGFzIA0KPiBWaXJ0dWFsIE5l dHdvcmsgTWFwcGluZyB3aGljaCBpcyBhIHNvZnR3YXJlIG1vZHVsZSB0aGF0IGNvbnZlcnRzIA0K PiBjbGllbnQgcmVxdWVzdHMgaW50byBhY3R1YWwgbmV0d29ya3MuIFZpcnR1YWwgTmV0d29yayBN YW5hZ2VyIGlzIEFCTk8gDQo+IGluIG15IHVuZGVyc3RhbmRpbmcgaXMgYSBkZXZlbG9wZWQgY29u Y2VwdCBmcm9tIFZOVE0uIEJ1dCBEYW4gS2luZyBhbmQgDQo+IEkgd2lsbCBsb29rIGF0IHRoaXMg bW9yZSBjYXJlZnVsbHkgb24gdGhpcyBhc3BlY3Qgd2hhdCBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdl ciBpcyBkb2luZy4NCj4gDQo+IFNCPj4+IElmIEkgdW5kZXJzdG9vZCBmb3JtIEFkcmlhbiBhbmQg RGFuaWVsIEFCTk8gZHJhZnQgdGhlIGNvbmNlcHQsIA0KPiBTQj4+PiBWTlRNIGlzIHN0cmljdGx5 IHJlbGF0ZWQgdG8gcGxhbm5pbmcgZnVuY3Rpb24gc28gSSB0aGlzIGl0IGlzIA0KPiBTQj4+PiB2 ZXJ5IGltcG9ydCBwb2ludCBpbiB0aGUgY29udGV4dCBvZiBQTkMgLCBJIHdvdWxkIHNheQ0KPiAN Cj4gU2VjdGlvbiA2LjEgOiB3aGlsZSBpdCBpcyBjbGVhciB0aGUgc2NvcGUgb2YgdGhlIGRpZmZl cmVudCBjb250cm9sIA0KPiBpbnRlcmZhY2UgcHJlc2VudGVkIGluIGZpZ3VyZSA1LCBJ4oCZbSBh IGJpdCBjb25mdXNlZCBhcyB0byB3aGF0IEkvRiBFIA0KPiBpcyDigJMgZGF0YSBwbGFuZSBpbnRl cmZhY2UgdG8gcHJvdmlkZXIgcGh5c2ljYWwgbmV0d29yaz8gT3IgaXMgdGhlIA0KPiBpbnRlbnRp b24gdG8gcHJvdmlkZSB3aGF0IGNhbiBiZSB0aGUgdW5kZXJseWluZyBtb2RlbCBvZiByZXNvdXJj ZXMgDQo+IGFsbG9jYXRlZCB0byBhIGN1c3RvbWVyIGZyb20gbmV0d29yayBwcm92aWRlciBjb250 cm9sbGVyLCBhbmQgdGhlIG1hcHBpbmcgdG8gcmVhbCBwaHlzaWNhbCByZXNvdXJjZXMgPw0KPiBO b3IgY2xlYXIgdG8gbWUgdGhlIGludGVudGlvbg0KPiANCj4gWU9VTkc+PiBJbnRlcmZhY2UgRSBp cyBub3Qgd2hhdCBBQ1ROIHdpbGwgZm9jdXMgb24uIEl0IHNpbXBseSBzaG93cyAgDQo+IFlPVU5H Pj4gYW4NCj4gdW5kZXJseWluZyBtb2RlbCBvZiByZXNvdXJjZXMgYWxsb2NhdGVkIHRvIGEgY3Vz dG9tZXIgZnJvbSBuZXR3b3JrIA0KPiBwcm92aWRlciBjb250cm9sbGVyLCBhbmQgdGhlIG1hcHBp bmcgdG8gcmVhbCBwaHlzaWNhbCByZXNvdXJjZXMuDQo+IA0KPiBTQj4+PiBTbyBpZiBJIGludGVy cHJldGVkIGNvcnJlY3RseSB5b3VyIGFuc3dlciBpcyBtb3JlIGFuIGludGVybmFsIA0KPiBTQj4+ PiBpbnRlcmZhY2UNCj4gdG8gUE5DICwgdGhlIGZpZ3VyZSBpcyBtaXNsZWFkaW5nIHNpbmNlIGl0 IHNlZW1zIGxpa2UgYSBEUCBpbnRlcmZhY2UgLg0KPiANCj4gDQo+IFNlY3Rpb24gNi4xLCBhbHdh eXMgZmlndXJlIDU6IElmIGEgcmVwb3J0IG9mIHBvdGVudGlhbCBOVyB0b3BvbG9neSANCj4gYmV0 d2VlbiBhIFZOQyBhbmQgYSBDTkMgY2FuIGJlIHF1ZXJpZWQgLCB0aGUgYXJyb3cgaW4gdGhlIGRy YXduIGhhcyB0byANCj4gYmUgYmlkaXJlY3Rpb25hbCBJIGd1ZXNzDQo+IA0KPiBZT1VORz4+IFll cywgWW91IGFyZSByaWdodC4gSXQgd2lsbCBiZSBmaXhlZC4NCj4gDQo+IEZpZ3VyZSA4IFNlY3Rp b24gNi40LHBhZ2UgMjg6IOKAnFBDQSBhYnN0cmFjdHMgdGhlIHBoeXNpY2FsIG5ldHdvcmsgDQo+ IHRvcG9sb2d5IGludG8gYW4gYWJzdHJhY3RlZCB0b3BvbG9neeKAnSBMb29raW5nIGF0IHRoZSBk ZXNjcmlwdGlvbiBvZiANCj4gVk5DIGNvbXBvbmVudHMgaW4gNi4yLjIgaXQgaXMgdGhlIHJlc291 cmNlIG1hbmFnZXIgZGV2b3RpbmcgdG8gcHJvdmlkZSBhYnN0cmFjdCB0b3BvbG9neS4NCj4gRG9l cyBub3QgZXhpc3QgYW55IFBDQSBjb21wb25lbnQuDQo+IA0KPiANCj4gDQo+IFlPVU5HPj4gU29y cnkgZm9yIGluY29uc2lzdGVuY3kuIFRoZSBpbnRlbnRpb24gd2FzIHRoZSBQQ0EgaXMgdGhlIHNh bWUgDQo+IFlPVU5HPj4gYXMNCj4gdGhlIFJlc291cmNlIE1hbmFnZXIgaW4gVk5DLiBXaWxsIG1h a2UgdGhlIHRlcm0gY29uc2lzdGVudC4gR29vZCBjYXRjaCENCj4gDQo+IA0KPiANCj4gRmlndXJl IDggU0VjdGlvbiA2LjQsIDogSW4gdGhlIHBpY3R1cmUgdGhlcmUgaXMgbm8gcGhhc2UgNywgYW5k IHRoZXJlIA0KPiBhcmUgMiBwaGFzZQ0KPiA4DQo+IA0KPiBZT1VORz4+IFRoYW5rcy4gR29vZCBj YXRjaCENCj4gDQo+IFBhZ2UgMzAgOiBJdCBpcyBJbnRlcmZhY2UgQyBub3QgQiAsIGJldHdlZW4g Vk5DIGFuZCBQTkMNCj4gDQo+IFlPVU5HPj4gSWYgeW91IGFyZSByZWZlcnJpbmcgdG8gU2VjdGlv biA3LjMgd2hlcmU6DQo+IA0KPiAgICBJbnRlcmZhY2VzIHNob3VsZCBhbHNvIGJlIHNjYWxhYmxl IGFzIGEgbGFyZ2UgYW1vdW50IG9mIGRhdGEgbmVlZHMNCj4gDQo+ICAgIHRvIGJlIHRyYW5zcG9y dGVkIGFjcm9zcyBjdXN0b21lcnMgdG8gdmlydHVhbCBuZXR3b3JrIGNvbnRyb2xsZXJzDQo+IA0K PiAgICBhbmQgYWNyb3NzIHZpcnR1YWwgbmV0d29yayBjb250cm9sbGVycyBhbmQgcGh5c2ljYWwg bmV0d29yaw0KPiANCj4gICAgY29udHJvbGxlcnMuDQo+IA0KPiANCj4gDQo+IEkgdGhpbmsgdGhp cyBpbXBsaWVzIGJvdGggaW50ZXJmYWNlcyBCIGFuZCBDIGFsdGhvdWdoIHByaW1hcmlseSANCj4g YmV0d2VlbiBWTkMtIFBOQy4NCj4gDQo+IA0KPiANCj4gU0I+Pj4gU29ycnkgWW91bmcsIGlpdCBp cyBub3QgcmVmZXJyZWQgdG8gNy4zICwgYnV0IGluIHRoZSBjaGFwdGVyIDYsNSANCj4gU0I+Pj4g LCBvbiBJbnRlcmZhY2UgaW50ZXJhY3Rpb24sIGFmdGVyIHBvaW50IDYsIGlzIGluZGljYXRlZCAN Cj4gU0I+Pj4gSW50ZXJmYWNlIEIgYXMgaW50ZXJmYWNlIGJldHdlZW4gVk5DIGFuZCBQTkMsIGZp Z3VyZSA1IHNheXMgaXQgDQo+IFNCPj4+IGlzIEkvRiBDDQo+IA0KPiANCj4gVGhhbmtzDQo+IA0K PiBTZXJnaW8NCj4gDQo+IA0KPiBUaGFua3MNCj4gU2VyZ2lvDQo= From nobody Tue Oct 14 08:40:59 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 710331A8954 for ; Tue, 14 Oct 2014 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 v361Xp1Qic7C for ; Tue, 14 Oct 2014 08:40:42 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA45D1A87B0 for ; Tue, 14 Oct 2014 08:40:41 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9EFeViQ004789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 11:40:31 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 14 Oct 2014 11:40:31 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Tue, 14 Oct 2014 11:40:30 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Tue, 14 Oct 2014 11:40:30 -0400 From: Igor Bryskin To: Leeyoung , "BELOTTI, SERGIO (SERGIO)" , Daniele Ceccarelli , "King, Daniel" , "actn@ietf.org" , "diego@tid.es" , "luyuanf@gmail.com" Thread-Topic: draft-ceccarelli-actn-framework-03.txt comments Thread-Index: Ac/i6xUhYJMQCp3kRnKA0n1plOXI1wAGyfbQACfyxMAAEVsAEAAEL75AAAFbsYAACSWiYAAaCV2gAAzP9CAAiCNVYAACSweQAA4f0GAABoqa9AAgMyeAAADcmvA= Date: Tue, 14 Oct 2014 15:40:30 +0000 Message-ID: <5329da93db694f2685ef35ccbfa01d47@ATL-SRV-MBX1.advaoptical.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729C3C87B@dfweml706-chm> <874e9d7ce46c40608a6fd9221985fec1@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3CF36@dfweml706-chm> <65174429B5AF4C45BD0798810EC48E0A3236F248@EX-0-MB2.lancs.local> <58713f40bbb24e379d6dc56ea85af0af@ATL-SRV-MBX1.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE481279D3AE@ESESSMB301.ericsson.se> <4003c11315234da8944051d37e30c796@ATL-SRV-MBX1.advaoptical.com> , <7AEB3D6833318045B4AE71C2C87E8E1729C3DB7E@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C3DD44@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3DD44@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-14_07:2014-10-14,2014-10-14,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/ZMOwPXAJv-CZpYj6dSxVGsiKP00 Cc: "Varma, Eve L \(Eve\)" Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments 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: Tue, 14 Oct 2014 15:40:55 -0000 WW91bmcsDQo9PT5JIGFtIGFmcmFpZCB0aGF0IHlvdSBoYXZlIG5vdCByZWFkIHdoYXQgSSBwdXQu IA0KRG9uJ3QgYmUgYWZyYWlkIDo9KS4gTm90IG9ubHkgSSByZWFkICwgYnV0IEkgaGF2ZSBhbiBp bXBsZW1lbnRhdGlvbiBjbG9zZSB0byB3aGF0IHlvdSBkZXNjcmliZS4NCg0KPT09PiBZb3UgYXJl IG9ubHkgY29uc2lkZXJpbmcgYWJzdHJhY3QgdG9wb2xvZ3kuDQpObyBJIGFtIG5vdC4gV2hhdCBj YW4geW91IGRvIHdpdGggdGhlIGFic3RyYWN0IHRvcG9sb2d5LCBhcGFydCBmcm9tIHVzaW5nIGl0 IGZvciBzZXJ2aWNlIHByb3Zpc2lvbmluZz8gTG9vayBhdCBpdCB3aXRoIGEgc2V4eSBHVUk/DQoN Cj09PT4gIFRoZSBmdW5jdGlvbiBvZiBWTkMgYW5kIENOQyBhcmUgZGlmZmVyZW50IGZyb20gZWFj aCBvdGhlciBhcyBJIGVsYWJvcmF0ZSBpbiB0aGUgcHJldmlvdXMgZW1haWwuDQoNClN1cmUsIGJ1 dCB0aGV5IGJvdGggYXJlIHBhcnRzIG9mIHRoZSBzYW1lIG5ldHdvcmsgY29udHJvbGxlciB3aGlj aCBleHBvc2VzIGFuZCB1c2VzIHRoZSBzYW1lIGludGVyZmFjZSAoaW50ZXJmYWNlIEMpIGFuZCB0 aGUgc2FtZSBzZXQgb2YgbW9kZWxzIChvbmUgZm9yIGFic3RyYWN0IHRvcG9sb2d5IG1hbmlwdWxh dGlvbiBhbmQgb25lIGZvciB0aGUgc2VydmljZSBwcm92aXNpb25pbmcpIG5vcnRoLWJvdW5kIGFu ZCBzb3V0aC1ib3VuZC4gVGhpcyBpcyBob3cgeW91IG1ha2UgdGhlIGFyY2hpdGVjdHVyZSBoaWVy YXJjaGljYWwuDQoNCj09PT4gSWYgeW91IGNhbiByZWFkIG1vcmUgY2FyZWZ1bGx5IG9uIHRoZSBt dWx0aS1kb21haW4gY29vcmRpbmF0aW9uIGZ1bmN0aW9uIG9mIFZOQyBpbiB0aGUgcGljdHVyZSwg d2UgbWF5IGRpc2N1c3MgbW9yZSBmcnVpdGZ1bGx5LiANCkkgYWxzbyBzdWdnZXN0IHlvdSB0byBy ZWFkIGNhcmVmdWxseSBteSByZXNwb25zZSB0byBTZXJnaW8gYW5kIERhbmllbGUuDQoNCkNoZWVy cywNCklnb3INCg0KSW50ZXJmYWNlcyBCIGFuZCBDIGFyZSBjbGVhcmx5IGRpZmZlcmVudCBpbnRl cmZhY2VzLCBidXQgdGhlcmUgYXJlIHNvbWUgZnVuY3Rpb25zIChsaWtlIGFic3RyYWN0IHRvcG9s b2d5KSBtYXkgYmUgYmFzZWQgb24gc2FtZSBtb2RlbCB3aXRoIGRpZmZlcmVudCBncmFudWxhcml0 eSwgYnV0IHRoYXQgaXMgb25seSBvbmUgYXNwZWN0IG9mIHRoZSBpbnRlcmZhY2UuIFdoYXQgQ05D IGFuZCBWTkMgZG8gaXMgcXVpdGUgZGlmZmVyZW50IGFzIEkgc2FpZCBiZWZvcmUgVk5DIGhhcyB0 byBjb29yZGluYXRlIG11bHRpLWRvbWFpbiByb3V0aW5nIGNhbGN1bGF0aW9uIGFuZCBzaWduYWxp bmcgY29vcmRpbmF0aW9uIG92ZXIgc2V2ZXJhbCBuZXR3b3JrIGRvbWFpbnMuIENOQyBkb2VzIG5v dCBkbyB0aGlzIGZ1bmN0aW9uLiANCg0KUmVnYXJkcywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0 aWNhbC5jb21dIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDc6MDEgUE0NClRvOiBM ZWV5b3VuZzsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBEYW5pZWxlIENlY2NhcmVsbGk7IEtp bmcsIERhbmllbDsgYWN0bkBpZXRmLm9yZzsgZGllZ29AdGlkLmVzOyBsdXl1YW5mQGdtYWlsLmNv bQ0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGkt YWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCg0KWW91bmcsDQoNCg0KPT09obdBZnRl ciBhbGwgd2UgYXJlIGFncmVlaW5nIHdpdGggdGhlIGludGVyZmFjZXMgb2YgQUNUTiBpbnRlcmVz dCBhcmUgSW50ZXJmYWNlIEIgYW5kIEMsIHJpZ2h0Pw0KDQpJQqG3Tm8uIEkgYW0gc2F5aW5nIHRo YXQgaW50ZXJmYWNlIEIgYW5kIEMgYXJlIGV4YWN0bHkgdGhlIHNhbWUgaW50ZXJmYWNlcy4gRm9y IGV4YW1wbGUsIG9uIHRoZSBwaWN0dXJlIE5ldHdvcmsgZG9tYWluIDEgaW4gb3JkZXIgdG8gcHJv dmlkZSB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgdG8gdGhlIG11bHRpLXZlbmRvciBWTkMsIG1heSB1 c2UgZnVsbHkgb3IgcGFydGlhbGx5IGFic3RyYWN0IHRvcG9sb2dpZXMgcHJvdmlkZWQgYnkgb25l IG9yIG1vcmUgbG93ZXIgdGllciB0cmFuc3BvcnQgZG9tYWlucy4NCkxpa2V3aXNlLCBDdXN0b21l ciAxIG9uIHRoZSBwaWN0dXJlIG1heSB1c2UgYW4gYWJzdHJhY3QgdG9wb2xvZ3kgcHJvdmlkZWQg YnkgTXVsdGktZG9tYWluIG5ldHdvcmsgKHRoZSBWTkMgb24gdGhlIHBpY3R1cmUgaXMgcGFydCBv ZikuDQpJbiBvdGhlciB3b3JkcywgdGhlIHNhbWUgaW50ZXJmYWNlIEMgYW5kIHRoZSBzYW1lIHNl dCBvZiBtb2RlbHMsIGNvdWxkIGJlIHVzZWQgIGhpZXJhcmNoaWNhbGx5LiANCg0KSWdvcg0KDQpJ Qj4+IEkgYW0gdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdHJhbnNwb3J0IGRv bWFpbiBzZXJ2ZXIgYW5kICB0cmFuc3BvcnQgZG9tYWluIGNsaWVudC4gSSB3b3VsZCBhcmd1ZSB0 aGF0IHRoZSB2ZXJ5IHNhbWUgaW50ZXJmYWNlIGNhbiBiZSB1c2VkIGJldHdlZW4gYSBtdWx0aS1k b21haW4gcHJvdmlkZXIgKGUuZy4gVGVsZWZvbmlrYSkgYW5kIGl0cyBjbGllbnRzLiBOb3QgYWxs IHN1Y2ggY2xpZW50cyBhcmUgZHVtYiwgYXMgRGFuaWVsZSBjbGFpbXMsIGFuZCBvbmx5IGNhcmUg YWJvdXQgobBhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBCobEuIEl0IGlzIGVhc3kg dG8gZW52aXNpb24gdGhhdCBzb21lIG9mIHRoZSBjbGllbnRzIHdvdWxkIHdhbnQgZnJvbSBUZWxl Zm9uaWNhIGEgY291cGxlIG9mIFNSTEctZGlzam9pbnQgYWJzdHJhY3QgbGlua3MsIHNvIHRoYXQg dGhlIGNsaWVudHMgY2FuIGhhdmUgYSBzYXkgaW4gdGhlIHBsYWNlbWVudCBvZiB0aGVpciAgc2Vy dmljZXMgYWNyb3NzIHRoZSBUZWxlZm9uaWthIG5ldHdvcmsuIFRocmVlIHBvaW50cyBoZXJlOg0K DQphKSAgICAgIFRoZSBjbGllbnQgd2lsbCBiZSBhYmxlIHRvIGNvbmZpZ3VyZSBmdWxseSBvciBw YXJ0aWFsbHkgdGhlIGFic3RyYWN0IHRvcG9sb2d5IGhlIHdhbnRzIHRoZSBuZXR3b3JrIHRvIHBy ZXNlbnQgdG8gaGltOw0KDQpiKSAgICAgIFRoZSBzYWlkIGFic3RyYWN0IHRvcG9sb2d5IGNvdWxk IGJlIGFzIHNpbXBsZSAoZS5nLiBhIHNpbmdsZSBhYnN0cmFjdCBub2RlKSBvciBhcyBjb21wbGV4 IChlLmcuIE4gYWJzdHJhY3Qgbm9kZXMgaW50ZXJjb25uZWN0ZWQgYnkgTSBhYnN0cmFjdCBsaW5r cykgYXMgdGhlIGNsaWVudCB3YW50cyBpdCB0byBiZSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXKh r3MgYXBwcm92YWwpDQoNCmMpICAgICAgVGhlIGFic3RyYWN0IHRvcG9sb2d5IHByZXNlbnRlZCB0 byB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgZGVjb3VwbGVkIGZyb20gdGhlIHByb3ZpZGVyoa9z IGFjdHVhbCB0b3BvbG9neS4NCg0KVGhlcmVmb3JlIHRoZSBzYW1lIGludGVyZmFjZS9zZXQgb2Yg bW9kZWxzIGNhbiBiZSB1c2VkIGJldHdlZW4gYW55IHRyYW5zcG9ydCBuZXR3b3JrIHByb3ZpZGVy IGFuZCBpdHMgY2xpZW50LiBGdXJ0aGVybW9yZSwgdGhlIGludGVyZmFjZSBjYW4gYmUgdXNlZCBp biB0aGUgaGllcmFyY2hpY2FsIHdheSwgdGhhdCBpcywgYSBjbGllbnQgb2YgYSB0cmFuc3BvcnQg ZG9tYWluIGNhbiBzZXJ2ZSBpdHMgb3duIGNsaWVudHMgdXNpbmcgdGhlIHNhbWUgaW50ZXJmYWNl IGFzIGl0IHVzZXMgdG8gdGFsayB0byBpdHMgb3duIHByb3ZpZGVyKHMpDQoNCkhlcmUgSSB3b3Vs ZCBsaWtlIHRvIGdpdmUgeW91IGEgbGl0dGxlIGNsZWFyZXIgcGljdHVyZSBvbiBtdWx0aS1kb21h aW4gaXNzdWVzLg0KDQogICArLS0tLS0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLS0tKyAg ICAgICstLS0tLS0tLS0tLS0tLSsNCiAgIHwgICBDdXN0b21lciAxICAgfCAgIHwgICBDdXN0b21l ciAyICB8ICAuLi4gfCBDdXN0b21lciBNICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgKy0t LS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAg XCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAvDQogICAgICAgICAgICAgICAgICAgIFwgICAg ICAgICAgICB8ICAgICAgICAgICAgIC8NCiAgICAgICBJbnRlcmZhY2UgQiAgIFwgICAgICAgICAg IHwgICAgICAgICAgICAvDQogICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICB8ICAgICAg ICAgICAvDQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICAgICAgICAgICAgICAgICAgICAgfCAgIFZOQyBNdWx0aS1kb21haW4gICB8IEUyRSBhYnN0cmFj dA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBDb29yZGluYXRpb24gICAgfCB0b3BvbG9n eSBjcmVhdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgfCAgICAgICAgICAgIFwNCiAgICAg ICAgSW50ZXJmYWNlIEMgICAvICAgICAgICAgIHwgICAgICAgICAgICAgXCAgTmV0d29yayBUb3Bv bG9neQ0KICAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgICAgfCAgICAgICAgICAgICAgXCAo YWJzdHJhY3QpDQogICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgICB8ICAgICAgICAgICAg ICAgXA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAr LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBOZXR3b3JrIERvbWFpbiAxIHwgICB8IE5ldHdvcmsg RG9tYWluIDIgfCAuLiB8IE5ldHdvcmsgRG9tYWluIE4gfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LSsgICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAg ICBWZW5kb3IgWCAgICAgICAgICAgICAgICAgVmVuZG9yIFkgICAgICAgICAgICAgICBWZW5kb3Ig Wg0KDQoNCldoYXQgaXMgc2l0dGluZyBhYm92ZSChsFZOQ6GxICh0aGF0IGNvb3JkaW5hdGVzIG92 ZXIgbXVsdGktZG9tYWluIGNvbnRyb2xsZXJzKSBjYW4gYmUgYW4gaW50ZXJuYWwgc2VydmljZSBv cmdhbml6YXRpb24gKG9mIHRoZSBzYW1lIG9wZXJhdG9yKSBvciBzZXJ2aWNlIHByb3ZpZGVycyAo ZGlmZmVyZW50IG9wZXJhdG9ycywgZm9ybWluZyBjYXJyaWVycyBvZiBjYXJyaWVyKS4gVGhlIGNv bnRyb2wgZW50aXR5IG9mIHRoZXNlIGVudGl0aWVzIGlzIHJlZmVycmVkIHRvIGFzIEN1c3RvbWVy IE5ldHdvcmsgY29udHJvbCAoQ05DKS4gVGhlIFZOQyCoQ0NOQyBpbnRlcmZhY2UgKEludGVyZmFj ZSBCKSBoYXMgZGlmZmVyZW50IHJlcXVpcmVtZW50cyB0aGFuIHRoZSBWTkMtUE5DIGludGVyZmFj ZSAoSW50ZXJmYWNlIEMpLiBUb3BvbG9neSBhYnN0cmFjdGlvbiBpcyBqdXN0IG9uZSBvZiB0aGUg cmVxdWlyZW1lbnRzIGFuZCBpbiBtdWx0aS1kb21haW4gY2FzZSwgdGhlIFZOQyBpcyBwZXJmb3Jt aW5nIG11bHRpLWRvbWFpbiBjb29yZGluYXRpb24gZnVuY3Rpb24uIFZOQyBuZWVkcyB0byBoYXZl IGEgc3RhbmRhcmQgaW50ZXJmYWNlIHRoYXQgZW5hYmxlIGNvbW11bmljYXRpb25zIHdpdGggZGlm ZmVyZW50IGtpbmRzIG9mIGRvbWFpbiBuZXR3b3JrIGNvbnRyb2wvbWFuYWdlbWVudCBjb250cm9s ICh3aGljaCBpcyByZWZlcnJlZCB0byBhcyBQTkMsIHlvdSBjYWxsIEFOQykuIEVhY2ggZG9tYWlu IGhhcyBpdHMgb3duIHdheXMgb2YgY29udHJvbGxpbmcgaXRzIG5ldHdvcmssIHdoaWNoIEFDVE4g aXMgbm90IHRvdWNoaW5nIHRob3NlIGF0IGFsbC4gV2hhdGV2ZXIgdGhlIGNob2ljZXMgb2YgdmVu ZG9yIGNvbnRyb2wgcmVnaW1lIHdpbGwgY29udGludWUgdG8gYmUgZW1wbG95ZWQgKEdNUExTL0FT T04sIFBOTkksIE5NUywgT3BlbkZsb3csIGV0Yy4pLg0KDQpGb3IgdGhpcyBtdWx0aS1kb21haW4g Y29vcmRpbmF0aW9uIGZ1bmN0aW9uIGFzc3VtZWQgYnkgVk5DIHNob3VsZCBiZSBvcGVyYXRlZCBv biBhbiBhYnN0cmFjdCBsZXZlbC4gV2UgZG9uoa90IHdhbnQgdG8gaW5qZWN0IHRoZSBzYW1lIGxl dmVsIG9mIGFjdHVhbCBuZXR3b3JrIHRvcG9sb2d5IChlLmcuLCBURUQpIGFzIHRoZSBkb21haW4g Y29udHJvbGxlciBvcGVyYXRlcyBpdHMgcGh5c2ljYWwvYWN0dWFsIG5ldHdvcmtzLiBJcyB0aGlz IGFncmVlYWJsZT8gWW91IHNhaWQgYWJvdmUgdGhpcyBpbiBjKSBUaGUgYWJzdHJhY3QgdG9wb2xv Z3kgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQgaXMgY29tcGxldGVseSBkZWNvdXBsZWQgZnJvbSB0 aGUgcHJvdmlkZXKhr3MgYWN0dWFsIHRvcG9sb2d5Lg0KDQpOb3cgdGhlIFZOQyAobXVsdGktZG9t YWluIGNvb3JkaW5hdG9yKSBuZWVkcyB0byBjb29yZGluYXRlIHNpZ25hbGluZyBhY3Jvc3MgbXVs dGktZG9tYWluIGNvbnRyb2xsZXJzIChpbiB0ZXJtcyBvZiB0aGUgc2VxdWVuY2Ugb2YgdGhlIGVu ZC10by1lbmQgcGF0aCBhY3Jvc3MgbXVsdGlwbGUgZG9tYWlucykuIFRoaXMgaXMgYSBuZXcgZWxl bWVudCBJIGJlbGlldmUgQUNUTiB3aWxsIGhhdmUgdG8gZGV2ZWxvcC4gVGhpcyBpbnRlcmZhY2Ug QyAoVk5DLVBOQykgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBJbnRlcmZhY2UgQiAoQ05DLVZOQyku IFRoZXJlIGFyZSBvdGhlciBkaWZmZXJlbmNlcyAocGxlYXNlIHNlZSBTZWN0aW9uIDYuNSBvZiB0 aGUgZnJhbWV3b3JrIGRvY3VtZW50KS4gIEJ1dCBJIGFncmVlIHdpdGggeW91IHRoYXQgZnJvbSBh biBhYnN0cmFjdCB0b3BvbG9neSBzdGFuZHBvaW50LCBzaW1pbGFyIG1vZGVsIHdvcmtzIGZvciBJ bnRlcmZhY2VzIEIgYW5kIEMgYXMgeW91IHNhaWQgIGIpICAgICAgVGhlIHNhaWQgYWJzdHJhY3Qg dG9wb2xvZ3kgY291bGQgYmUgYXMgc2ltcGxlIChlLmcuIGEgc2luZ2xlIGFic3RyYWN0IG5vZGUp IG9yIGFzIGNvbXBsZXggKGUuZy4gTiBhYnN0cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBieSBN IGFic3RyYWN0IGxpbmtzKSBhcyB0aGUgY2xpZW50IHdhbnRzIGl0IHRvIGJlIChzdWJqZWN0IHRv IHRoZSBwcm92aWRlcqGvcyBhcHByb3ZhbCkuDQoNCkJlc3QgcmVnYXJkcywNCllvdW5nDQoNCg0K DQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0N ClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMywgMjAxNCA5OjE3IEFNDQpUbzogQkVMT1RUSSwgU0VS R0lPIChTRVJHSU8pOyBEYW5pZWxlIENlY2NhcmVsbGk7IEtpbmcsIERhbmllbDsgTGVleW91bmc7 IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRpZC5lczsgbHV5dWFuZkBnbWFpbC5jb20NCkNjOiBWYXJt YSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3 b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBTZXJnaW8sDQpBIGNvdXBsZSBvZiBjb21tZW50cyBp biBsaW5lLg0KDQpDaGVlcnMsDQpJZ29yDQoNCkZyb206IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lP KSBbbWFpbHRvOnNlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNvbV0NClNlbnQ6IE1vbmRh eSwgT2N0b2JlciAxMywgMjAxNCA5OjE1IEFNDQpUbzogSWdvciBCcnlza2luOyBEYW5pZWxlIENl Y2NhcmVsbGk7IEtpbmcsIERhbmllbDsgTGVleW91bmc7IGFjdG5AaWV0Zi5vcmc7IGRpZWdvQHRp ZC5lczsgbHV5dWFuZkBnbWFpbC5jb20NCkNjOiBWYXJtYSwgRXZlIEwgKEV2ZSk7IEJFTE9UVEks IFNFUkdJTyAoU0VSR0lPKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFt ZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIElnb3IsDQoNClBsZWFzZSwgc2VlIGluIGxpbmUN Cg0KUmVnYXJkcw0KU2VyZ2lvDQoNCg0KRnJvbTogSWdvciBCcnlza2luIFttYWlsdG86SUJyeXNr aW5AYWR2YW9wdGljYWwuY29tXQ0KU2VudDogdmVuZXJkqKwgMTAgb3R0b2JyZSAyMDE0IDIyOjM3 DQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBLaW5nLCBEYW5pZWw7IExlZXlvdW5nOyBCRUxPVFRJ LCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBk aWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0 bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJF OiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBE YW5pZWxlLA0KUGxlYXNlLCBzZWUgaW4gbGluZS4NCklnb3INCg0KRnJvbTogRGFuaWVsZSBDZWNj YXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbV0NClNlbnQ6IEZy aWRheSwgT2N0b2JlciAxMCwgMjAxNCAxOjI1IFBNDQpUbzogSWdvciBCcnlza2luOyBLaW5nLCBE YW5pZWw7IExlZXlvdW5nOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8 bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBkaWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47 IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNjOiBWYXJtYSwg RXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJFOiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3Jr LTAzLnR4dCBjb21tZW50cw0KDQpIaSBJZ29yLA0KDQpXaGF0IGRvIHlvdSBtZWFuIGJ5IGNsaWVu dCBoZXJlPyBUaGUgb25lIHRoYXQgaXMgdGhlIGRvY3VtZW50IGlzIGNhbGxlZCChsHNlcnZpY2Ug cHJvdmlkZXKhsSBvciB0aGUgb25lIHRoYXQgaXMgY2FsbGVkIKGwY2xpZW50obEgPyBGcm9tIHdo YXQgeW91IHNlbmQgSSB0ZW5kIHRvIHRoaW5rIHlvdSBhcmUgdGFsa2luZyBhYm91dCB0aGUgc2Vy dmljZSBwcm92aWRlciwgYnV0IEkgbWlnaHQgYmUgd3JvbmcsIHBsZWFzZSBjb3JyZWN0IG1lLg0K DQpJQj4+IEJ5IGNsaWVudCBJIG1lYW4gdGhlIGNsaWVudCBvZiBhIHRyYW5zcG9ydCBkb21haW4s IHRoZSBvbmUgd2hvIHNwZWFrcyBOZXRjb25mL1Jlc3Rjb25mIHRvIHRoZSB0cmFuc3BvcnQgZG9t YWluLiBUaGUgZ3V5IHdobyBzcGVha3MgZnJvbSB0aGUgb3RoZXIgZW5kIChpLmUuIG9uIGJlaGFs ZiBvZiB0aGUgdHJhbnNwb3J0IHNlcnZpY2UgcHJvdmlkZXIpICBpcyB0aGUgdHJhbnNwb3J0IGRv bWFpbqGvcyBIeXBlcnZpc29yLg0KDQpTQj4+PiBJdCBpcyBjbGVhciB3aGF0IHlvdSBpbnRlbmQg aGVyZSwgZXZlbiBpZiB3b3JkIGNsaWVudCBpdCBzZWVtcyB0byBtZSBtb3JlIHJlbGF0ZWQgdG8g YXBwbGljYXRpb24gdGhhbiB0byBhIHNlcnZpY2UgcHJvdmlkZXIuDQoNCklCPj4gSSBhbSB0YWxr aW5nIGFib3V0IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0cmFuc3BvcnQgZG9tYWluIHNlcnZlciBh bmQgIHRyYW5zcG9ydCBkb21haW4gY2xpZW50LiBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHZlcnkg c2FtZSBpbnRlcmZhY2UgY2FuIGJlIHVzZWQgYmV0d2VlbiBhIG11bHRpLWRvbWFpbiBwcm92aWRl ciAoZS5nLiBUZWxlZm9uaWthKSBhbmQgaXRzIGNsaWVudHMuIE5vdCBhbGwgc3VjaCBjbGllbnRz IGFyZSBkdW1iLCBhcyBEYW5pZWxlIGNsYWltcywgYW5kIG9ubHkgY2FyZSBhYm91dCChsGEgZ2l2 ZW4gYW1vdW50IG9mIEdicHMgZnJvbSBBIHRvIEKhsS4gSXQgaXMgZWFzeSB0byBlbnZpc2lvbiB0 aGF0IHNvbWUgb2YgdGhlIGNsaWVudHMgd291bGQgd2FudCBmcm9tIFRlbGVmb25pY2EgYSBjb3Vw bGUgb2YgU1JMRy1kaXNqb2ludCBhYnN0cmFjdCBsaW5rcywgc28gdGhhdCB0aGUgY2xpZW50cyBj YW4gaGF2ZSBhIHNheSBpbiB0aGUgcGxhY2VtZW50IG9mIHRoZWlyICBzZXJ2aWNlcyBhY3Jvc3Mg dGhlIFRlbGVmb25pa2EgbmV0d29yay4gVGhyZWUgcG9pbnRzIGhlcmU6DQoNCmEpICAgICAgVGhl IGNsaWVudCB3aWxsIGJlIGFibGUgdG8gY29uZmlndXJlIGZ1bGx5IG9yIHBhcnRpYWxseSB0aGUg YWJzdHJhY3QgdG9wb2xvZ3kgaGUgd2FudHMgdGhlIG5ldHdvcmsgdG8gcHJlc2VudCB0byBoaW07 DQoNCmIpICAgICAgVGhlIHNhaWQgYWJzdHJhY3QgdG9wb2xvZ3kgY291bGQgYmUgYXMgc2ltcGxl IChlLmcuIGEgc2luZ2xlIGFic3RyYWN0IG5vZGUpIG9yIGFzIGNvbXBsZXggKGUuZy4gTiBhYnN0 cmFjdCBub2RlcyBpbnRlcmNvbm5lY3RlZCBieSBNIGFic3RyYWN0IGxpbmtzKSBhcyB0aGUgY2xp ZW50IHdhbnRzIGl0IHRvIGJlIChzdWJqZWN0IHRvIHRoZSBwcm92aWRlcqGvcyBhcHByb3ZhbCkN Cg0KYykgICAgICBUaGUgYWJzdHJhY3QgdG9wb2xvZ3kgcHJlc2VudGVkIHRvIHRoZSBjbGllbnQg aXMgY29tcGxldGVseSBkZWNvdXBsZWQgZnJvbSB0aGUgcHJvdmlkZXKhr3MgYWN0dWFsIHRvcG9s b2d5Lg0KDQpUaGVyZWZvcmUgdGhlIHNhbWUgaW50ZXJmYWNlL3NldCBvZiBtb2RlbHMgY2FuIGJl IHVzZWQgYmV0d2VlbiBhbnkgdHJhbnNwb3J0IG5ldHdvcmsgcHJvdmlkZXIgYW5kIGl0cyBjbGll bnQuIEZ1cnRoZXJtb3JlLCB0aGUgaW50ZXJmYWNlIGNhbiBiZSB1c2VkIGluIHRoZSBoaWVyYXJj aGljYWwgd2F5LCB0aGF0IGlzLCBhIGNsaWVudCBvZiBhIHRyYW5zcG9ydCBkb21haW4gY2FuIHNl cnZlIGl0cyBvd24gY2xpZW50cyB1c2luZyB0aGUgc2FtZSBpbnRlcmZhY2UgYXMgaXQgdXNlcyB0 byB0YWxrIHRvIGl0cyBvd24gcHJvdmlkZXIocykNCg0KTW9yZW92ZXIgSSB3b3VsZCBhdm9pZCBp biB0aGlzIHBoYXNlIHRvIG1lbnRpb24gYW55IHJlZmVyZW5jZSB0byBwcm90b2NvbCBpbXBsZW1l bnRhdGlvbiAoZS5nLiBOZXRjb25mL1Jlc3Rjb25mKSA6IEkgdGhpbmsgd2UgYXJlIGluIHRoZSBw aGFzZSB0byB1bmRlcnN0YW5kIGFyY2hpdGVjdHVyZSwgd2hhdCBhcmUgdGhlIHJlbGV2YW50IGlu dGVyZmFjZXMsIGFuZCB3aGF0IGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdlZCBvdmVyIHRoZSByZWZl cmVuY2UgcG9pbnRzL2ludGVyZmFjZXMuIEkgZ3Vlc3MgdGhpcyBpcyBjbGVhcmx5IHN0YXRlZCBh bHNvIGluIHRoZSBjaGFydGVyIG9mIEJvRi4NCg0KSUI+PiBBZ3JlZS4gSSB1c2VkIE5ldGNvbmYv UmVzdGNvbmYgYXMgYW4gZXhhbXBsZSB0byBtYWtlIGl0IGNsZWFyIHdoYXQgaW50ZXJmYWNlIEkg d2FzIHRhbGtpbmcgYWJvdXQuDQoNCiBBdCBhbiBhcHByb3ByaWF0ZSB0aW1lIKhDIGNlcnRhaW5s eSBub3Qgbm93IKhDIHRoZSBuZXh0IHN0ZXAgaXMgdG8gY2hlY2sgd2l0aCBvdGhlciBTRE9zIG9u IHRoZSBhdmFpbGFiaWxpdHkgb2YgcmVsZXZhbnQgY29yZS90ZWNobm9sb2d5IHNwZWNpZmljL2Fw cGxpY2F0aW9uIHNwZWNpZmljIGluZm9ybWF0aW9uIG1vZGVsIKGwZnJhZ21lbnRzobEsIGFuZCB0 aGVuIGZpbmFsbHkgcHJvY2VlZCBvbiB0aGUgcGF0aCBvZiBwcnVuaW5nL3JlZmFjdG9yaW5nIGFu ZCBtYXBwaW5nIHRvIFJFU1QvSlNPTiwgTmV0Y29uZi9ZQU5HLCBhbmQgYW55IG90aGVyIHBvc3Np YmxlIGRhdGEgbW9kZWxpbmcgYW5kIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgZXhpc3RpbmcuIFRo aXMgaXMgbXkgdW5kZXJzdGFuZGluZyAgb2YgdGhlIEJvRiBzY29wZSAuDQoNCkkgZG9uoa90IHRo aW5rIHRoZSBjbGllbnQgb2YgdGhlIG11bHRpLWRvbWFpbiBuZXR3b3JrIHdhbnRzIHRvIGhhdmUg YSBzbyBkZXRhaWxlZCB2aWV3IG9mIHRoZSBuZXR3b3JrLCBoZSBkb2VzIG5vdCBjYXJlIGFib3V0 IGRvbWFpbnMsIGludGVyIGRvbWFpbiBsaW5rcyBvciB3aGF0ZXZlciwgSSB3b3VsZCBzYXkgaGUg b25seSBjYXJlcyBhYm91dCBhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBCIHdpdGgg YSBnaXZlbiBtYXggZGVsYXkgYW5kIHByb2JhYmx5IHNvbWUgZGl2ZXJzaXR5IHBhcmFtZXRlcnMu DQoNCklCPj4gQWdhaW4sIGJ5IGNsaWVudCBJIG1lYW4gbXVsdGktZG9tYWluIG5ldHdvcmsgY29u dHJvbGxlciAoZS5nLiBUZWxlZm9uaWNhIFNETiBjb250cm9sbGVyKSwgbm90IHRoZSBjbGllbnQg dXNpbmcgc2VydmljZXMgb2YgdGhlIG11bHRpLWRvbWFpbiBuZXR3b3JrIChpLmUuIG5vdCB0aGUg VGVsZWZvbmljYSBjbGllbnRzKS4gU3VjaCBjbGllbnQgdXNlcyAgdGhlIHRyYW5zcG9ydCBkb21h aW5zIGZvciBhIHJlYXNvbi4gobBhIGdpdmVuIGFtb3VudCBvZiBHYnBzIGZyb20gQSB0byBCobEg aXMgdG9vIGxvb3NlIGFuZCBsaXR0bGUgZm9yIHRoZSBjbGllbnQgdG8gZG8gdGhlIG5ldHdvcmsg cGxhbm5pbmcuIElNTyB0aGUgY2xpZW50IG5lZWRzIHRvICpwbGFuKiB0aGUgYWJzdHJhY3QgdG9w b2xvZ2llcyBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0IGRvbWFpbnMgdGhlIHNhbWUgb3Igc2lt aWxhciB3YXkgYXMgaGUgd291bGQgcGxhbiBoaXMgb3duIGFjdHVhbCB0b3BvbG9neS4NCg0KU0I+ Pj4geWVzLCBzdXJlLCBpbiB5b3UgdmlldyBvZiChsGNsaWVudKGxICwgdGhpcyBpcyB0aGUgc2Vy dmljZSBwcm92aWRlciBEYW5pZWxlIGlzIHRhbGtpbmcsIHNvIGFuIGFic3RyYWN0IHZpZXcgb2Yg d2hhdCBpcyB0aGUgcmVhbCB0cmFuc3BvcnQgbmV0d29yayBpcyBjb25zaWRlcmVkIGF0IHRoaXMg bGV2ZWwuIEFzIEkgc2FpZCB0byBZb3VuZywgaW4gbXkgcHJldmlvdXMgbWFpbCwgaW4gdGhlIGNh c2Ugb2YgYSBzaW5nbGUgZG9tYWluIHNjZW5hcmlvIFZOQyBhbmQgUE5DIGNvdWxkIGFsc28gY29p bmNpZGUgYnV0IGluIGNhc2Ugb2YgYSBtdWx0aS1kb21haW4gc2NlbmFyaW9zIHRoZSBzY29wZSBp cyB0byBwcm92aWRlIHRvIGFwcGxpY2F0aW9uIGxheWVyIGEgc2luZ2xlIHZpcnR1YWxpemVkIHZp ZXcgb2YgdGhlIHVuZGVybGluZSBtdWx0aSBkb21haW4gbmV0d29yay4NCg0KT24gdGhlIG90aGVy IHNpZGUsIHRoZSBvbmUgdGhhdCBjYXJlcyBhYm91dCBhbGwgb2YgdGhlIGlzc3VlcyB5b3UgbGlz dGVkIGlzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIChhcyBwZXIgYWN0dWFsIGRvY3VtZW50IHRlcm1p bm9sb2d5KS4gSG93ZXZlciBhbHNvIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGRvZXMgbm90IGdvIGlu dG8gcGh5c2ljYWwgaW1wYWlybWVudCBkZXRhaWxzLiBIZSBjYXJlcyBhYm91dCBjb25uZWN0aXZp dHkgYmV0d2VlbiB0aGUgYm9yZGVycyBvZiB0aGUgZG9tYWlucywgaW50ZXIgZG9tYWluIGxpbmtz LiBIb3cgc3VjaCBjb25uZWN0aXZpdHkgaXMgcHJvdmlzaW9uZWQvbWFuYWdlZCBpcyB0aGUgbmV0 d29yayBwcm92aWRlciBidXNpbmVzcy4gVGhlIG5ldHdvcmsgcHJvdmlkZXMgbWlnaHQgYmUgdXNp bmcgR01QTFMsIE5NUyBhbmQgT05GIGNvbnRyb2xsZXIgd2l0aCBPcGVuIEZsb3cgb3Igd2hhdGV2 ZXIgdG8gY29udHJvbCB0aGUgbmV0d29yay4gTWF5YmUgY2FsbGluZyBpdCBQTkMgaXMgY29uZnVz aW5nPyBUaGUgUE5DIGNhbiBiZSBhbnkgb2YgdGhlIHRoaW5ncyBJoa92ZSBsaXN0ZWQgYW5kIG11 Y2ggbW9yZS4NCg0KSUI+PiBJbiB0aGlzIGNhc2UgbXkgY2xpZW50IGlzIHlvdXIgc2VydmljZSBw cm92aWRlciA7PSkuIFlvdSBhcmNoaXRlY3R1cmFsbHkgc2VwYXJhdGUgY2xpZW50IGZyb20gdGhl IHNlcnZpY2UgcHJvdmlkZXIsIGJlY2F1c2UgeW91IHByb2JhYmx5IGJlbGlldmUgdGhhdCBpdCBp cyBwb3NzaWJsZSB0byBzdGFuZGFyZGl6ZSB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIHR3by4g SSBkaXNhZ3JlZSB3aXRoIHRoYXQgYW5kIGRvbqGvdCB0aGluayBBQ1ROIHNob3VsZCB3b3JrIG9u IHRoaXMuIEluIHRoZSBjb250ZXh0IG9mIEFDVE4gSSBzZWUgb25seSB0d28gY29uc3RydWN0czog VHJhbnNwb3J0IGRvbWFpbiBjb250cm9sbGVyICh0cmFuc3BvcnQgc2VydmljZSBwcm92aWRlcikg YW5kICBUcmFuc3BvcnQgY2xpZW50IGNvbnRyb2xsZXIgKHRyYW5zcG9ydCBzZXJ2aWNlIHVzZXIp Lg0KDQpTQj4+PiBBQ1ROIGhlcmUgaXMgbm90IHJlaW52ZW50aW5nIHRoZSB3aGVlbCAsIGluIG90 aGVyIFNETyBTRE4gc3BlY2lmaWMgaXMgY29uc2lkZXJlZCAgdGhlIGFwcGxpY2F0aW9uIGxheWVy ICwgYW5kIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBBTCBhbmQgU0ROIGNvbnRyb2xsZXIgKGluIHRo aXMgY2FzZSB0aGUgVk5DIG9mIEFDVE4pIC4gVGhpcyBpbnRlcmZhY2UgcGVybWl0IHRvIGFueSBj bGllbnQgdG8gZGlyZWN0bHkgaW1wYWN0IHRvIGhpcyBvd24gc2VydmljZXMgYW5kIGhpcyBvd24g obB2aXJ0dWFsaXplZKGxIHJlc291cmNlcyAuDQoNCg0KSGVuY2UgdGhlIGludGVyZmFjZXMgdG8g YmUgY29uc2lkZXJlZCBhcmUgdHdvLCBub3QgdGhyZWUgKGFzIERhbiBzYWlkKSBJIHRoaW5rIHRo aXMgcmVwbGllcyB0byBxdWVzdGlvbnMgMSBhbmQgMy4gSnVzdCB0byBhZGQgc29tZXRoaW5nIHJl Z2FyZGluZyAyLCBJIHdvdWxkIHNheSB0aGF0IHRoZXkgbmVlZCBqdXN0IGEgc2luZ2xlIGVudHJ5 IHBvaW50IHRvIHRoZSBuZXR3b3JrIGNvbnRyb2wgKGNvdWxkIGJlIGEgc21hbGwgcGllY2Ugb2Yg Y29kZSBydW5uaW5nIG9uIHRvcCBvZiB0aGUgUENFIG9mIHlvdXIgR01QTFMgZG9tYWluKSwgd2hp Y2ggYWN0cyBhcyBhbiBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgVk5DIGFuZCB0aGUgY29udHJvbCBw bGFuZSBvZiB5b3VyIG5ldHdvcmsgYW5kIHBlcmZvcm1zOiChsC0gTWFwcGluZyBvZiBwaHlzaWNh bCBhbmQgdmlydHVhbCByZXNvdXJjZXOhsSBhbmQgIKGwUmVxdWVzdHM6IHBhdGgsIHByb3Zpc2lv biwgbW9kaWZ5IGFuZCByZXN0b3JlobEuDQoNCklCPj4gQXMgSSBzYWlkLCB0aGlzIGlzIHRoZSB0 YXNrIG9mIHRoZSB0cmFuc3BvcnQgZG9tYWluIEh5cGVydmlzb3IsIHdob3NlIHJvbGUgaXMsIGVz c2VudGlhbGx5LCB0byB0cmFuc2xhdGUgYmFjayBhbmQgZm9ydGggYWJzdHJhY3QgPD0+IGFjdHVh bCB0b3BvbG9neSBlbGVtZW50cyBhbmQgc2VydmljZSByZXF1ZXN0cy9yZXNwb25zZXMgY29udGFp bmluZyB0aGUgYWJzdHJhY3QvYWN0dWFsIHRvcG9sb2d5IHBhdGhzLiBJIHRoaW5rIHRoYXQgdGhl IG5vcnRoL3NvdXRoIGludGVyZmFjZSBiZXR3ZWVuIHRoZSB0cmFuc3BvcnQgZG9tYWluIEh5cGVy dmlzb3IgYW5kIHRoZSBlbnRpdHkgcmVwcmVzZW50aW5nIHRoZSBjbGllbnQgb2YgdGhlIHRyYW5z cG9ydCBkb21haW4gKG5vIG1hdHRlciBob3cgeW91IGNhbGwgaXQpIGlzIHRoZSBvbmx5IGludGVy ZmFjZSBBQ1ROIGNhbiB3b3JrIG9uIHdpdGggdGhlIGhvcGUgdG8gcHJvZHVjZSBzb21ldGhpbmcg dXNlZnVsLg0KDQpDaGVlcnMNCkRhbmllbGUNCg0KDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFp bHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NClNlbnQ6IHZlbmVyZKisIDEwIG90dG9icmUg MjAxNCAwMzoxNg0KVG86IEtpbmcsIERhbmllbDsgTGVleW91bmc7IEJFTE9UVEksIFNFUkdJTyAo U0VSR0lPKTsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2Vj Y2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWls LmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEsIEV2ZSBMIChFdmUpDQpT dWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVu dHMNCg0KWW91bmcgYW5kIERhbiwNCg0KSXQgZG9lcyBub3QgbWF0dGVyIGhvdyB5b3UgY2FsbCBt ZSwgYW5kIGFzIEpvaG4gaXMgaGVscGZ1bGx5IGFwcGx5aW5nLCB5b3UgY2FuIGlnbm9yZSB3aGF0 IEkgYW0gc2F5aW5nLiBCdXQgbGV0IG1lIGV4cGxhaW4gaW4gc29tZSBtb3JlIGRldGFpbHMgd2hh dCBJIG1lYW50Lg0KDQpTdXBwb3NlIHdlIGhhdmUgYSBjbGllbnQgKHN1Y2ggYXMgVEZLKSBvZiBh IG11bHRpLWRvbWFpbiB0cmFuc3BvcnQgbmV0d29yaywgd2hvIHdhbnRzIHRvIHByb3Zpc2lvbiBh bmQgbWFuaXB1bGF0ZSBlMmUgdHJhbnNwb3J0IHNlcnZpY2VzIHRoZSB3YXkgaGUgd2FudHMgaXQg KGkuZS4gYXBwbHlpbmcgaGlzIHBvbGljaWVzKS4gV2hhdCB3b3VsZCBzdWNoIGNsaWVudCBuZWVk Pw0KDQoNCjEuICAgICBBbiBhY2Nlc3MgdG8gYSB1bmlmaWVkIG5ldHdvcmsgVEUgdG9wb2xvZ3kg dGhhdCBjb3VsZCBiZSB1bmRlcnN0b29kIGFuZCB1c2VkIGJ5IHRoZSBjbGllbnShr3MgcGF0aCBj b21wdXRlciB0byBzZWxlY3Qgc2VydmljZSBlMmUgcGF0aHMuIEhvdyBkb2VzIHRoZSBjbGllbnQg Z2V0IHN1Y2ggYSB0b3BvbG9neT8gVGhlIG5lY2Vzc2FyeSBvdmVybGF5IHRvcG9sb2d5IGNvbXBy aXNlcyBhYnN0cmFjdCB0b3BvbG9naWVzIHByZXNlbnRlZCBmb3IgdGhlIGNsaWVudCBieSBlYWNo IG9mIHRoZSB0cmFuc3BvcnQgZG9tYWlucyArIGludGVyLWRvbWFpbiBURSBsaW5rcy4gSGVuY2Ug d2UgYXJlIHRhbGtpbmcgYWJvdXQgaW50ZXJmYWNlICMxIChhbmQgZGF0YSBtb2RlbCAjMSkgYmV0 d2VlbiBhIHByb3ZpZGVyIGh5cGVydmlzb3IvVk5DIGFuZCB0aGUgY2xpZW50IGNvbnRyb2xsZXIg dG8gZXhwb3NlIGluIGEgdW5pZmllZCBhYnN0cmFjdCAgd2F5ICBpdHMgdG9wb2xvZ3kgb24gcGVy IGNsaWVudC90ZW5hbnQgYmFzaXMuIEZ1cnRoZXJtb3JlLCB0aGUgY2xpZW50IGNvbnRyb2xsZXIg Y2FuIHVzZSB0aGlzIGludGVyZmFjZSBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uIHRvIG1vZGlm eSB0aGUgc2FpZCBhYnN0cmFjdCB0b3BvbG9neSAoc3ViamVjdCB0byB0aGUgcHJvdmlkZXKhr3Mg IGFwcHJvdmFsKSwgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHRoZSBvbmx5IGd1eSB3aG8ga25vd3Mg aG93IHRoZSBhYnN0cmFjdCB0b3BvbG9neSBleHBvc2VkIHRvIGhpbSBzaG91bGQgbG9vayBsaWtl IHRvIGJlIHVzZWZ1bCAoZS5nLiB3aGljaCBhbmQgaG93IHRoZSBhYnN0cmFjdCBsaW5rcyBzaG91 bGQgYmUgZGlzam9pbnQgZnJvbSBlYWNoIG90aGVyLCBob3cgbWFueSBvZiB0aGVtIHNob3VsZCBi ZSBwcm92aWRlZCwgdGhlaXIgYXR0cmlidXRlcywgZGVzaXJlZCByZWNvdmVyeSBjYXBhYmlsaXRp ZXMsIGV0YywpLiBUaGlzIGtub3dsZWRnZSBpcyBzdXBwb3NlZCB0byBjb21lIGZyb20gdGhlIGNs aWVudKGvcyBuZXR3b3JrIHBsYW5uaW5nLg0KDQoyLiAgICAgQSB3YXkgdG8gcHJvdmlzaW9uL21v ZGlmeS9kZWxldGUgZTJlIHNlcnZpY2VzIHdpdGggdGhlIHVzZSBvZiBzbyBjb21wdXRlZCBlMmUg cGF0aHMuIFRoZSBjbGllbnShr3MgY29udHJvbGxlciBkb2VzIHRoYXQgYnkgY2hvcHBpbmcgdGhl IHBhdGhzIGludG8gcGVyLWRvbWFpbiBzZWdtZW50cyBhbmQgaW5zdHJ1Y3RzIHJlc3BlY3RpdmUg ZG9tYWluIFZOQ3MvSHlwZXJ2aXNvcnMgdG8gc2V0IHVwL21hbmlwdWxhdGUgc2VydmljZSByZXNw ZWN0aXZlIGNvbm5lY3Rpb24gc2VnbWVudHMuIEhlbmNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGlu dGVyZmFjZSAjMiAoZGF0YSBtb2RlbCAjMikgZm9yIHRoZSBzZXJ2aWNlIHNlZ21lbnQgbWFuaXB1 bGF0aW9uOw0KDQozLiAgICAgQSB3YXkgdG8gbW9uaXRvciwgdHJvdWJsZXNob290LCBjYXJyeSBv dXQgbWFpbnRlbmFuY2Ugb2YgdGhlIGFjdGl2ZSBlMmUgc2VydmljZXMuIFRoaXMgd291bGQgcmVx dWlyZSBpbnRlcmZhY2UgIzMgKGRhdGEgbW9kZWwgIzMpIGJldHdlZW4gdGhlIGNsaWVudKGvcyBj b250cm9sbGVyIGFuZCBkb21haW5zIFZOQ3MvSHlwZXJ2aXNvcnMgZm9yIHRoaXMgcHVycG9zZS4N Cg0KU28sIHdlIGFyZSB0YWxraW5nIDMgWWFuZyBtb2RlbHMgd2l0aCByZXF1aXJlZCBtb2RpZmlj YXRpb25zIHRvIG5laXRoZXIgTmV0Y29uZi9SZXN0Y29uZiwgbm9yICBUbyBhbnkgb3RoZXIgbWFu YWdlbWVudCwgcm91dGluZyBvciBzaWduYWxpbmcgcHJvdG9jb2wuDQoNCk5vdyBJIGhhdmUgYSBj b3VwbGUgb2YgcXVlc3Rpb25zIHRvIHlvdToNCg0KMS4gICAgIEluIHRoaXMgZXhhbXBsZSwgd2hh dCBlbHNlIChpbiBhZGRpdGlvbiB0byB0aGVzZSB0aHJlZSBtb2RlbHMpIHRoZSBjbGllbnQgc3Vj aCBhcyBURksgaW4geW91ciBvcGluaW9uIHdvdWxkIG5lZWQ/DQoNCjIuICAgICBXaGF0IGVsc2Ug dGhlIG5ldHdvcmsgcHJvdmlkZXJzIGFuZCB0aGVpciB2ZW5kb3JzIHN1Y2ggYXMgQURWQSBvciBD SUVOIHdvdWxkIG5lZWQ/DQoNCjMuICAgICBXaGF0IGlzIHRoZSBpbXBvcnRhbmNlIG9mIGEgY29u c3RydWN0IHN1Y2ggYXMgUE5DPw0KDQoNCk15IGFuc3dlciB0byAzLiChsElzIG5vdCBpbXBvcnRh bnQgYXQgYWxsLCBpcnJlbGV2YW50obEgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KYSkg ICAgIFdoYXQgaGFwcGVucyBiZXlvbmQgdGhlIFZOQy9IeXBlcnZpc29yIGluIHRoZSBwcm92aWRl ciBuZXR3b3JrIGlzIGNvbXBsZXRlbHkgcHJvcHJpZXRhcnkuDQoNCmIpICAgICBUaGVyZSBjb3Vs ZCBiZSBudW1lcm91cyB3YXlzIGFzIHRvIGhvdyB0aGUgcHJvdmlkZXIgbmV0d29yayBpcyBtYW5h Z2VkLiBFeGFtcGxlczogY2VudHJhbGl6ZWQgUE5DIChhcyB5b3UgY2FsbCBpdCksIEFEVkEgc3R5 bGUgR01QTFMgYmFzZWQgbmV0d29yayBpbnRlbGxpZ2VuY2UsIENJRU4gc3R5bGUgUE5OSSBiYXNl ZCBjb250cm9sIHBsYW5lLCBldGMuIFdoeSBpcyB0aGF0IG9mIEFDVE6hr3MgYnVzaW5lc3M/DQoN CkNoZWVycywNCklnb3INCg0KRnJvbTogS2luZywgRGFuaWVsIFttYWlsdG86ZC5raW5nQGxhbmNh c3Rlci5hYy51a10NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDQ6NTggUE0NClRv OiBMZWV5b3VuZzsgSWdvciBCcnlza2luOyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5A aWV0Zi5vcmc8bWFpbHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdv QHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1 eXVhbmZAZ21haWwuY29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRy YWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIEFsbCwg aW5jbHVkaW5nIKGwSWdub3KhsSA7LSkNCg0KVHlwaWNhbCBkaWNob3RvbXkgYmV0d2VlbiB3aGF0 IG9wZXJhdG9ycyB3YW50IGFuZCB3aGF0IHZlbmRvcnMgYXJlIGFjdHVhbGx5IHdpbGxpbmcgdG8g cHJvdmlkZSwgZ3JvdXAgY29uc2Vuc3VzIHdpbGwgZXZlbnR1YWxseSBoZWxwIHJlc29sdmUgdGhh dC4gRWl0aGVyIHdheSwgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBGcmFtZXdvcmsgSS1EIGlz IHRyeWluZyB0byBmb2N1cyBBQ1ROIGRpc2N1c3Npb24gYW5kIHNjb3BlIChpLmUuLCB0aGUgcHJv dG9jb2wgd29yaykgb24gdGhlIGludGVyZmFjZXMgd2hpY2ggYXJlIGluIHNjb3BlLCBuYW1lbHk6 DQoNCjEuIFRoZSBDTkMtVk5DIEludGVyZmFjZSAoQ1ZJKQ0KLSBDcmVhdGUsIG1vZGlmeSBhbmQg ZGVsZXRlIHZpcnR1YWwgbmV0d29yayBzZXJ2aWNlIGluc3RhbmNlcw0KLSBSZXNvdXJjZSBtb2Rl bA0KDQoyLiBUaGUgVk5DLVBOQyBJbnRlcmZhY2UgKFZQSSkNCi0gTWFwcGluZyBvZiBwaHlzaWNh bCBhbmQgdmlydHVhbCByZXNvdXJjZXMNCi0gUmVxdWVzdHM6IHBhdGgsIHByb3Zpc2lvbiwgbW9k aWZ5IGFuZCByZXN0b3JlDQoNCkFzIFlvdW5nIHN1Z2dlc3RzLCBpZiB0aGUgVk5DIHJlY2VpdmVk IHBoeXNpY2FsIHRvcG9sb2d5IGluZm8gaXQgd291bGQgYmUgcGVyZm9ybWluZyB0aGUgcm9sZSBv ZiB0aGUgUGh5c2ljYWwgTmV0d29yayBDb250cm9sbGVyIChQTkMpLCB3aGljaCBpcyBvYnZpb3Vz bHkgYSAoc29tZWhvdykgcmVxdWlyZWQgZnVuY3Rpb24sIGJ1dCB0aGUgaW50ZXJmYWNlIChkaXJl Y3QgcHJvdmlzaW9uaW5nIG9mIHRoZSBhY3R1YWwgcGh5c2ljYWwgbmV0d29yaykgaXMgb3V0IG9m IHNjb3BlIGZvciBBQ1ROLg0KDQpCciwgRGFuLg0KDQpGcm9tOiBBQ1ROIFttYWlsdG86YWN0bi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVleW91bmcNClNlbnQ6IDA5IE9jdG9iZXIg MjAxNCAyMTozMg0KVG86IElnb3IgQnJ5c2tpbjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBh Y3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBk aWVnb0B0aWQuZXM8bWFpbHRvOmRpZWdvQHRpZC5lcz47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0 bzpsdXl1YW5mQGdtYWlsLmNvbT4NCkNjOiBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJl OiBbQWN0bl0gZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMN Cg0KSGkgSWdub3IsDQoNClRoYW5rIHlvdSBmb3IgcHJvdmlkaW5nIHlvdXIgY29tbWVudCB0aGF0 IHBhdXNlcyB1cyB0byB0aGluayBtb3JlIGFuZCB1bmRlcnN0YW5kIG9uIHRoZSBzYW1lIGxldmVs LiBJIHRoaW5rIHlvdXIgY29tbWVudCB3aWxsIGNvbnRyaWJ1dGUgdG8gY3J5c3RhbGxpemUgdGhl IHNjb3BlIG9mIHdvcmsgaGVyZS4NCg0KRmlyc3Qgb2YgYWxsLCBJIHRoaW5rIHRoZXJlIHdhcyBh IG1pc3VuZGVyc3RhbmRpbmcgaGVyZS4gRmlyc3QsIHlvdXIgYXNzdW1wdGlvbiBvbiBWTkMgcmVj ZWl2aW5nIGFjdHVhbCB1bmRlcmx5aW5nIHRvcG9sb2d5IGlzIGluY29ycmVjdC4gSWYgVk5DIHdl cmUgdG8gaGF2ZSBhY3R1YWxseSB0b3BvbG9neSAoZS5nLiBURUQpIG9mIGEgbmV0d29yaywgdGhp cyB3b3VsZCBiZSBjYWxsZWQgYSBQTkMgYW5kIHRoaXMgaXMgb3V0IG9mIHNjb3BlIG9mIEFDVE4u IFRoaXMgYXNwZWN0IGhhcyBiZWVuIGRpc2N1c3NlZCBieSBlbWFpbCB0aHJlYWRzIERhbmllbGUg c3RhcnRlZCBhIGZldyB3ZWVrcyBhZ28uIENoZWNrIHRoZSBhcmNoaXZlIG9uIHRoYXQuIFRoZSBy ZWFzb24gdGhpcyBpcyBvdXQgb2Ygc2NvcGUgaXMgdGhhdCBQTkMgbXVsdGktZG9tYWluIGlzc3Vl IGlzIG5vIGRpZmZlcmVudCBmcm9tIHRvZGF5oa9zIEdNUExTL1BDRSBpc3N1ZSwgZXNwZWNpYWxs eSBpbiBsaWdodCBvZiBILVBDRS4gQUNUTiBkb2VzIG5vdCBzdGVwIG9uIHRob3NlIGFyZWFzLiBX aGF0IFZOQyByZWNlaXZlcyBmcm9tIGVhY2ggUE5DIChkb21haW4gY29udHJvbGxlcikgaXMgYW4g YWJzdHJhY3RlZCB0b3BvbG9neSB3aXRoIHZhcnlpbmcgZGVncmVlcyBmcm9tIGFjdHVhbCB1bmRl cmx5aW5nIHRvcG9sb2d5LiBUaGUgcmVhc29uIHdoeSB3ZSBkaXN0aW5ndWlzaCB0aGUgdGVybSBW TkMgZnJvbSBQTkMuDQoNCldoYXQgY2FuIGJlIGRlZmluZWQgb24gVk5DLVBOQyBpcyBhIHZlcnRp Y2FsIHNpZ25hbGluZyBjb29yZGluYXRpb24gZnJvbSBWTkMgdG8gZWFjaCBQTkMuIEFzIGxvbmcg YXMgdGhlIGRldGFpbGVkIHBhdGggY29tcHV0YXRpb24gYW5kIHNpZ25hbGluZyB3aXRoaW4gYSBk b21haW4gYXJlIGNvbXBsZXRlbHkgdXAgdG8gdGhlIGRvbWFpbiBQTkMuIFZOQyBpcyBub3QgdG8g YmUgb3BlcmF0ZWQgb24gdGhlIHNhbWUgbGV2ZWwgYXMgUE5DLiBJdHMgZW5kLXRvLWVuZCBwYXRo IGNvbXB1dGF0aW9uIGlzIGJhc2VkIG9uIHdoYXQgaXMgZXhwb3NlZCBmcm9tIFBOQ3MgdG8gVk5D LiBUaGUgYWN0dWFsIHRvcG9sb2d5IGluZm9ybWF0aW9uIGRldGFpbHMgaXMga2VwdCBieSBQTkNz IGFuZCB0aGUgUE5DcyBleHBvc2UgYWJzdHJhY3RlZCB0b3BvbG9neSB0aGF0IGNhbiBoaWRlIHRo ZSBleGFjdCBkZXRhaWxzIHdoaWxlIGV4cG9zaW5nIGEgbWluaW11bSBsZXZlbCBvZiBjb25zdHJh aW50cy4gRm9yIGluc3RhbmNlLCB0aGUgU1JMRyBvZiB2aXJ0dWFsIGxpbmtzICh3aGljaCBtYXkg YmUgY29uY2F0ZW5hdGVkIGFjdHVhbCBsaW5rcykgY2FuIGJlIGV4cG9zZWQgZm9yIGRpdmVyc2l0 eSByb3V0aW5nIGNhbGN1bGF0aW9uIGF0IHRoZSBWTkMuIFRoaXMgaXMgdmVyeSBkaWZmZXJlbnQg ZnJvbSBleHBvc2luZyB0aGUgYWN0dWFsIFRFIHRvcG9sb2d5LiBZb3UgY2FuIHZpZXcgdGhpcyBh cyB0d28gbGV2ZWwgb2YgcGF0aCBjb21wdXRhdGlvbi4gVk5DIGZpcnN0IGNvbXB1dGVzIGFuIGVu ZC10by1lbmQgcGF0aCAodXNpbmcgd2hhdGV2ZXIgY29uc3RyYWludCBpbmZvcm1hdGlvbiBpdCBo YXMpLCB0aGVuIGNvb3JkaW5hdGVzIHdpdGggZWFjaCBQTkMgKHRlbGxpbmcgdGhlIGJvcmRlciBu b2RlcyBpbmZvcm1hdGlvbiksIHRoZW4gZWFjaCBQTkMgY29tcHV0ZXMgdGhlIGRvbWFpbiBzcGVj aWZpYyBwYXRoLiBXaGVuIGEgUE5DIGNhbm5vdCBwcm92aWRlIGEgcGF0aCBzZWdtZW50IGluIGl0 cyBkb21haW4sIHRoZW4gdGhpcyBuZWVkcyB0byBiZSBzaWduYWxlZCB0byBWTkMgc28gdGhhdCB0 aGUgVk5DIHdvdWxkIGFycmFuZ2UgYW4gYWx0ZXJuYXRlIHBhdGggc2VnbWVudCB0byBiZSBhYmxl IHRvIGZpbmQgYSBmZWFzaWJsZSBlbmQtdG8tZW5kIHBhdGguICBJIHdvdWxkIHNheSB0aGlzIGlz IGEgobB0d28tcGhhc2WhsSBzaWduYWxpbmcgYW5kIHBhdGggY29tcHV0YXRpb24uIFRoZSBwb2lu dCBpcyB0aGF0IHRoZXJlIG11c3QgYmUgc29tZSBsZXZlbCBvZiBoaWRpbmcgb24gYWJzdHJhY3Qg dG9wb2xvZ3kgZXhwb3N1cmUgZnJvbSBQTkMgdG8gVk5DIGFuZCBwcm9wcmlldGFyeSBjaGFyYWN0 ZXJpc3RpY3Mgb2Ygb3B0aWNhbCBkZXZpY2VzIG5lZWQgdG8gYmUgZGVhbHQgb25seSB3aXRoIHRo ZSBjb3JyZXNwb25kaW5nIFBOQy4NCg0KUmVnYXJkaW5nIHRoZSB0ZXJtIFBOQyB2cy4gQU5DLCBJ IHdvdWxkbqGvdCBjb25jZXJuIHRvbyBtdWNoIGFib3V0IHRoZSB0ZXJtaW5vbG9neSB3aGljaGV2 ZXIgd29ya3MgYmV0dGVyLiBUaGFuayB5b3UgZm9yIHlvdXIgc3VnZ2VzdGlvbi4NCg0KTGFzdGx5 LCBwbGVhc2UgY2hlY2sgdGhlIHVzZS1jYXNlcyB3cml0dGVuIGJ5IG9wZXJhdG9ycyBpbiB0aGUg YmVsb3cgbGlua3MgdGhhdCBjb25zaXN0ZW50bHkgc2F5IHRoZXkgbmVlZCBhIHN0YW5kYXJkIGlu dGVyZmFjZSB0aGF0IGNhbiBjb29yZGluYXRlIHRoZWlyIG11bHRpLWRvbWFpbiBpc3N1ZXMuDQoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhbmctYWN0bi1tdWx0aWRv bWFpbi1kY2kvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rbGVlLWFj dG4tY29ubmVjdGl2aXR5LW11bHRpLXZlbmRvci1kb21haW5zLw0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQta3VtYWtpLWFjdG4tbXVsdGl0ZW5hbnQtdm5vLw0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotYWN0bi12bm8tbXVsdGlkb21h aW5zLw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hpbi1hY3RuLW12 bm8tbXVsdGktZG9tYWluLw0KDQpSZWdhcmRzLA0KWW91bmcNCg0KVGhhbmtzLA0KWW91bmcNCg0K DQpGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAwOSwgMjAxNCAxOjQ4IFBNDQpUbzogQkVMT1RUSSwgU0VS R0lPIChTRVJHSU8pOyBMZWV5b3VuZzsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9y Zz47IERhbmllbGUgQ2VjY2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+ OyBsdXl1YW5mQGdtYWlsLmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogVmFybWEs IEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBSRTogZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29y ay0wMy50eHQgY29tbWVudHMNCg0KSGkgWW91bmcsDQoNCkkgYmVsaWV2ZSBoYXZpbmcgdGhlIHNh bWUgaW5zdGFuY2Ugb2YgVk5DIHRhbGtpbmcgdG8gZGlmZmVyZW50IHZlbmRvciBkb21haW4gUE5D cyBpcyBhbiBleHRyZW1lbHkgIGlkZWFsaXN0aWMgdmlldy4NCg0KPT09PT4gQlRXIEkgZmluZCBQ TkMgaXMgYSBiYWQgdGVybSwgSSBsaWtlIG11Y2ggYmV0dGVyIEFjdHVhbCBOZXR3b3JrIENvbnRy b2xsZXIgIChBTkMpLiBWTkMgKGEuay5hLiBhIEh5cGVydmlzb3IpIGlzIG1hbmFnaW5nIGFic3Ry YWN0IHRvcG9sb2dpZXMsIGFuZCB0byBiZSBhYmxlIGRvIHRoYXQsIGl0IHRhbGtzIHRvIGEgQU5D LSBhIGNvbnRyb2xsZXIgd2hpY2ggaGFzIGFuIGFjY2VzcyBhbmQgbWFuYWdlcyBhY3R1YWwgcHJv dmlkZXIgbmV0d29yaykuDQoNCk9uZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBWTkMgbmVlZHMg dG8gdW5kZXJzdGFuZCB1bmRlcmx5aW5nIGFjdHVhbCB0b3BvbG9neSwgZm9yIGV4YW1wbGUsIHRv IGVuc3VyZSB0aGF0IHR3byBhYnN0cmFjdCBURSBsaW5rcyBhcmUgU1JMRyBkaXNqb2ludCBhcyBy ZXF1ZXN0ZWQuIEFjdHVhbCB0b3BvbG9neSBzZW1hbnRpY3MgKGVzcGVjaWFsbHkgaW4gV0RNIGxh eWVyKSBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHZlbmRvciB0byB2ZW5kb3IgYW5kIGNvbnRhaW5z IGEgZ3JlYXQgdmFyaWV0eSBvZiBwcm9wcmlldGFyeSBleHRlbnNpb25zLCBmYWlsaW5nIHRvIHVu ZGVyc3RhbmQgd2hpY2ggbGVhZHMgdG8gcHJvZHVjaW5nIHVucHJvdmlzaW9uYWJsZSBzZXJ2aWNl IHBhdGhzLiBEbyB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBhIHNpbmdsZSBWTkMgY2FuIHRhbGsg aW4gdGhlIHNhbWUgd2F5IHRvIEFEVkEsIElORk4sIEFMVSBhbmQgSHVhd2VpIEFOQ3M/IFRoaXMg aXMgZXF1aXZhbGVudCB0byBhc2sgYWxsIG9wdGljYWwgcHJvdmlkZXJzIHRvIHN3aXRjaCB0byBX U09OIDo9KS4NCg0KVGhpcyBpcyBub3QgdG8gc2F5IHRoYXQgeW91IGNhbm5vdCBidWlsZCBhIGhp ZXJhcmNoeSBvZiBWTkNzLCBidXQgaW4gdGhpcyBjYXNlIE5vcnRoIFZOQyBwbGF5cyByb2xlIG9m IGEgY2xpZW50IG5ldHdvcmsgY29udHJvbGxlciB3cnQgdG8gU291dGggVk5DLCB0aGF0IGlzLCB1 c2VzIHRoZSBzYW1lIFggaW50ZXJmYWNlLg0KSUhNTyB3aGVuZXZlciBhIFZOQyBoYXMgdG8gdGFs ayB0byBhIEFOQywgaXQgZG9lcyBzbyBpbiBhIHByb3ByaWV0YXJ5IHdheSwgaS5lLiBBRFZBLCBJ TkZOLCBBTFUgYW5kIEh1YXdlaSB3aWxsIGhhdmUgdGhlaXIgb3duIFZOQ3MgZXhwb3NpbmcgdGhl IHNhbWUgbm9ydGggYm91bmQgaW50ZXJmYWNlIHRvIHBvdGVudGlhbGx5IHRoZSBzYW1lIGNsaWVu dCAoZS5nLlRGSykuDQpJSE1PIGludGVyZmFjZSBYIGlzIHRoZSBvbmx5IGludGVyZmFjZSB0aGF0 IHRoZSBBQ1ROIGNhbiB3b3JrIG9uLg0KDQpDaGVlcnMsDQpJZ29yDQoNCkZyb206IEFDVE4gW21h aWx0bzphY3RuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCRUxPVFRJLCBTRVJHSU8g KFNFUkdJTykNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDE0IDU6NTkgQU0NClRvOiBM ZWV5b3VuZzsgYWN0bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2Vj Y2FyZWxsaTsgZGllZ29AdGlkLmVzPG1haWx0bzpkaWVnb0B0aWQuZXM+OyBsdXl1YW5mQGdtYWls LmNvbTxtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20+DQpDYzogQkVMT1RUSSwgU0VSR0lPIChTRVJH SU8pOyBWYXJtYSwgRXZlIEwgKEV2ZSkNClN1YmplY3Q6IFJlOiBbQWN0bl0gZHJhZnQtY2VjY2Fy ZWxsaS1hY3RuLWZyYW1ld29yay0wMy50eHQgY29tbWVudHMNCg0KSGkgWW91bmcsDQoNCnRoYW5r cyBhIGxvdCBmb3IgcmVwbHkgLCBwbGVhc2Ugc2VlIGluIGxpbmUganVzdCBzb21lIGZ1cnRoZXIg Y2xhcmlmaWNhdGlvbg0KDQpSZWdhcmRzDQpTZXJnaW8NCg0KDQoNCkZyb206IExlZXlvdW5nIFtt YWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0NClNlbnQ6IG1lcmNvbGVkqKwgOCBvdHRvYnJlIDIw MTQgMTc6MzUNClRvOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IGFjdG5AaWV0Zi5vcmc8bWFp bHRvOmFjdG5AaWV0Zi5vcmc+OyBEYW5pZWxlIENlY2NhcmVsbGk7IGRpZWdvQHRpZC5lczxtYWls dG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5jb208bWFpbHRvOmx1eXVhbmZAZ21haWwu Y29tPg0KQ2M6IFZhcm1hLCBFdmUgTCAoRXZlKQ0KU3ViamVjdDogUkU6IGRyYWZ0LWNlY2NhcmVs bGktYWN0bi1mcmFtZXdvcmstMDMudHh0IGNvbW1lbnRzDQoNCkhpIFNlcmdpbywNCg0KVGhhbmtz IGZvciB5b3VyIGZlZWRiYWNrIG9uIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQuIFBsZWFzZSBzZWUg aW4tbGluZSBmb3IgbXkgY29tbWVudC4NCg0KUmVnYXJkcywNCllvdW5nDQoNCkZyb206IEJFTE9U VEksIFNFUkdJTyAoU0VSR0lPKSBbbWFpbHRvOnNlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50 LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwOCwgMjAxNCA3OjM0IEFNDQpUbzogYWN0 bkBpZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz47IERhbmllbGUgQ2VjY2FyZWxsaTsgTGVl eW91bmc7IGRpZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsgbHV5dWFuZkBnbWFpbC5j b208bWFpbHRvOmx1eXVhbmZAZ21haWwuY29tPg0KQ2M6IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lP KTsgVmFybWEsIEV2ZSBMIChFdmUpDQpTdWJqZWN0OiBkcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJh bWV3b3JrLTAzLnR4dCBjb21tZW50cw0KDQpIaSBEYW5pZWxlICwgWW91bmcgYW5kIGFsbCBhdXRo b3JzLA0KDQpJIHJlYWQgeW91IEZyYW1ld29yayBkcmFmdCBhbmQgSSBoYXZlIHNvbWUgY29tbWVu dHMgb24gdGhhdC4gTW9zdCBhcmUgZWRpdG9yaWFsICwgb3RoZXIgcXVlc3Rpb25zIGZvciBjbGFy aWZpY2F0aW9ucy4NCg0KR2VuZXJhbCBxdWVzdGlvbjogaW4gdGhlIGRyYWZ0IHRoZSBjb25jZXB0 IG9mIFZOQyBpcyBpbiB0aGUgdmlldyBvZiBoaWVyYXJjaGljYWwgbGV2ZWwgb2YgY29udHJvbGxl cnMgb3IgbGlua2VkIHRvIHRoZSBtdWx0aS1kb21haW4gYXNwZWN0IHRoYXQgY29tcGVsIHRvIHBy b3ZpZGUgdG8gdGhlIGN1c3RvbWVyIGEgc2luZ2xlIHZpcnR1YWxpemVkIG5ldHdvcmsgZXZlbiBp ZiBjb21wb3NlZCBieSByZWFsIG11bHRpLWRvbWFpbiBtdWx0aS10ZWNobm9sb2d5IHN1Ym5ldHdv cmtzPyBJIG1lYW4sIHRoZSChsHZpcnR1YWxpemVyIGZ1bmN0aW9uobEgcHJvdmlkZWQgYnkgVk5D LCBpbiBjYXNlIG9mIGEgc2luZ2xlIGRvbWFpbiBjb250ZXh0IGNvdWxkIGJlIGluc2lkZSBkaXJl Y3RseSB0aGUgUE5DICwgY29ycmVjdD8NCg0KWU9VTkc+PiBZZXMuIFRoYXQgaXMgdGhlIGNvcnJl Y3QgdmlldyBvZiBWTkMuIEZvciBhIHNpbmdsZSBkb21haW4gY29udGV4dCwgdGhlIFZOQyBjYW4g YmUgaW50ZWdyYXRlZCB3aXRoIFBOQy4gQnV0IHdlIG5lZWQgdG8gZmFjdG9yIGluIG90aGVyIHNj ZW5hcmlvcyBzdWNoIGFzIDEpIFZOQyB2ZW5kb3IgbWF5IGJlIGRpZmZlcmVudCBmcm9tIFBOQyB2 ZW5kb3Igb3IgMikgVk5DIGlzIGEgc29mdHdhcmUgZnVuY3Rpb24gdGhhdCBvcGVyYXRvciBtYXkg d2FudCB0byBvcGVyYXRlIGFzIGl0cyBjb250cm9sLiBJbiBteSBvcGluaW9uLCBldmVuIGZvciBh IHNpbmdsZSBkb21haW4sIEkgdGhpbmsgdGhlcmUgaXMgYmVuZWZpdCB0byBkZWZpbmUgdGhpcyBp bnRlcmZhY2UgYXMgYSBzdGFuZGFyZCBpbnRlcmZhY2UuDQoNClNlY3Rpb24gMiAsIHBhZ2UgNDoN CmFic3RyYWN0aW9uIGRvZXMgbm90IGltcGx5IGF1dG9tYXRpY2FsbHkgdmlydHVhbGl6YXRpb24s d2hpbGUgdmlydHVhbGl6YXRpb24gaW1wbGllcyB0byBoYXZlIHN1cmVseSBhIGNlcnRhaW4gZm9y bSBvZiBhYnN0cmFjdGlvbi4gSSB3b3VsZCBzdWdnZXN0IHRvIGNvbnNpZGVyIGdvb2QgZGVmaW5p dGlvbiBjb250YWluZWQgaW50byBPTkYgU0ROIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBjaGFwdGVy IDIuMyBDb252ZW50aW9ucyBhYm91dCBhYnN0cmFjdGlvbiBhbmQgdmlydHVhbGl6YXRpb24uIEEg Z29vZCBkZWZpbml0aW9uIGNhbiBoZWxwIGFsbCB0aGUgcmVhZGluZy4NCg0KWU9VTkc+PiBBZ3Jl ZS4gV2Ugd2lsbCBsb29rIGludG8gdGhlIG1lbnRpb25lZCBkb2N1bWVudCBpZiB0aGUgdXNhZ2Ug b2YgdGVybXMgYXJlIGFsaWduZWQgd2l0aCB0aGlzIGRvY3VtZW50LiBJZiBub3QsIHdlIHdpbGwg Y2xhcmlmeSB0aGUgdGVybWlub2xvZ3kgbW9yZSBjbGVhcmx5Lg0KDQpTZWN0aW9uIDU6IEl0IHNl ZW1zIHRvIG1lIHlvdSBtaXhlZCBoZXJlIGFzcGVjdHMgdGhhdCBhcmUgbW9yZSByZWxhdGVkIHRv IHBvbGljeSBsaWtlIGFkbWlzc2lvbiBjb250cm9sICBhbmQgZ3VhcmFudGVlIG9mIGNsaWVudCBp c29sYXRpb24gd2l0aCByZWFsIGNvbXB1dGF0aW9uYWwgaXNzdWUgbGlrZSBDb21wdXRpbmcgdGlt ZSAsIHBhdGggY29uc3RyYWlucyBvciByZS1vcHRpbWl6YXRpb24gcHJvY2Vzcy4gTW9yZW92ZXIg dGhlIHRlcm0gVk5NIGZvciBWaXJ0dWFsIG5ldHdvcmsgbWFwcGluZyBpcyBhIGJpdCBtaXNsZWFk aW5nIHNpbmNlIHRoaXMgdGVybSBpbiBhbHJlYWR5IHVzZWQgZS5nLiBpbiBBQk5PIGFyY2hpdGVj dHVyZSBmb3IgVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIuDQoNCllPVU5HPj4gSW5kZWVkLiBJbiBT ZWN0aW9uIDUsIHdlIHdpbGwgcHV0IHNvbWUgbm90ZXMgb24gdGhlIGFzcGVjdCBvZiByZWFsLXRp bWUgcmVsYXRlZCBmcm9tIG5vbiByZWFsIHRpbWUgYXNwZWN0LiBWTk0gaXMgbm90IHRvIGJlIG1p eGVkIHdpdGggVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIuIEhlcmUgVk5NIGlzIGFuIGFsZ29yaXRo bSB3aGljaCBpcyBrbm93biBhcyBWaXJ0dWFsIE5ldHdvcmsgTWFwcGluZyB3aGljaCBpcyBhIHNv ZnR3YXJlIG1vZHVsZSB0aGF0IGNvbnZlcnRzIGNsaWVudCByZXF1ZXN0cyBpbnRvIGFjdHVhbCBu ZXR3b3Jrcy4gVmlydHVhbCBOZXR3b3JrIE1hbmFnZXIgaXMgQUJOTyBpbiBteSB1bmRlcnN0YW5k aW5nIGlzIGEgZGV2ZWxvcGVkIGNvbmNlcHQgZnJvbSBWTlRNLiBCdXQgRGFuIEtpbmcgYW5kIEkg d2lsbCBsb29rIGF0IHRoaXMgbW9yZSBjYXJlZnVsbHkgb24gdGhpcyBhc3BlY3Qgd2hhdCBWaXJ0 dWFsIE5ldHdvcmsgTWFuYWdlciBpcyBkb2luZy4NCg0KU0I+Pj4gSWYgSSB1bmRlcnN0b29kIGZv cm0gQWRyaWFuIGFuZCBEYW5pZWwgQUJOTyBkcmFmdCB0aGUgY29uY2VwdCwgDQpTQj4+PiBWTlRN IGlzIHN0cmljdGx5IHJlbGF0ZWQgdG8gcGxhbm5pbmcgZnVuY3Rpb24gc28gSSB0aGlzIGl0IGlz IHZlcnkgDQpTQj4+PiBpbXBvcnQgcG9pbnQgaW4gdGhlIGNvbnRleHQgb2YgUE5DICwgSSB3b3Vs ZCBzYXkNCg0KU2VjdGlvbiA2LjEgOiB3aGlsZSBpdCBpcyBjbGVhciB0aGUgc2NvcGUgb2YgdGhl IGRpZmZlcmVudCBjb250cm9sIGludGVyZmFjZSBwcmVzZW50ZWQgaW4gZmlndXJlIDUsIEmhr20g YSBiaXQgY29uZnVzZWQgYXMgdG8gd2hhdCBJL0YgRSBpcyCoQyBkYXRhIHBsYW5lIGludGVyZmFj ZSB0byBwcm92aWRlciBwaHlzaWNhbCBuZXR3b3JrPyBPciBpcyB0aGUgaW50ZW50aW9uIHRvIHBy b3ZpZGUgd2hhdCBjYW4gYmUgdGhlIHVuZGVybHlpbmcgbW9kZWwgb2YgcmVzb3VyY2VzIGFsbG9j YXRlZCB0byBhIGN1c3RvbWVyIGZyb20gbmV0d29yayBwcm92aWRlciBjb250cm9sbGVyLCBhbmQg dGhlIG1hcHBpbmcgdG8gcmVhbCBwaHlzaWNhbCByZXNvdXJjZXMgPyBOb3IgY2xlYXIgdG8gbWUg dGhlIGludGVudGlvbg0KDQpZT1VORz4+IEludGVyZmFjZSBFIGlzIG5vdCB3aGF0IEFDVE4gd2ls bCBmb2N1cyBvbi4gSXQgc2ltcGx5IHNob3dzICBhbiB1bmRlcmx5aW5nIG1vZGVsIG9mIHJlc291 cmNlcyBhbGxvY2F0ZWQgdG8gYSBjdXN0b21lciBmcm9tIG5ldHdvcmsgcHJvdmlkZXIgY29udHJv bGxlciwgYW5kIHRoZSBtYXBwaW5nIHRvIHJlYWwgcGh5c2ljYWwgcmVzb3VyY2VzLg0KDQpTQj4+ PiBTbyBpZiBJIGludGVycHJldGVkIGNvcnJlY3RseSB5b3VyIGFuc3dlciBpcyBtb3JlIGFuIGlu dGVybmFsIGludGVyZmFjZSB0byBQTkMgLCB0aGUgZmlndXJlIGlzIG1pc2xlYWRpbmcgc2luY2Ug aXQgc2VlbXMgbGlrZSBhIERQIGludGVyZmFjZSAuDQoNCg0KU2VjdGlvbiA2LjEsIGFsd2F5cyBm aWd1cmUgNTogSWYgYSByZXBvcnQgb2YgcG90ZW50aWFsIE5XIHRvcG9sb2d5IGJldHdlZW4gYSBW TkMgYW5kIGEgQ05DIGNhbiBiZSBxdWVyaWVkICwgdGhlIGFycm93IGluIHRoZSBkcmF3biBoYXMg dG8gYmUgYmlkaXJlY3Rpb25hbCBJIGd1ZXNzDQoNCllPVU5HPj4gWWVzLCBZb3UgYXJlIHJpZ2h0 LiBJdCB3aWxsIGJlIGZpeGVkLg0KDQpGaWd1cmUgOCBTZWN0aW9uIDYuNCxwYWdlIDI4OiChsFBD QSBhYnN0cmFjdHMgdGhlIHBoeXNpY2FsIG5ldHdvcmsgdG9wb2xvZ3kgaW50byBhbiBhYnN0cmFj dGVkIHRvcG9sb2d5obEgTG9va2luZyBhdCB0aGUgZGVzY3JpcHRpb24gb2YgVk5DIGNvbXBvbmVu dHMgaW4gNi4yLjIgaXQgaXMgdGhlIHJlc291cmNlIG1hbmFnZXIgZGV2b3RpbmcgdG8gcHJvdmlk ZSBhYnN0cmFjdCB0b3BvbG9neS4gRG9lcyBub3QgZXhpc3QgYW55IFBDQSBjb21wb25lbnQuDQoN Cg0KDQpZT1VORz4+IFNvcnJ5IGZvciBpbmNvbnNpc3RlbmN5LiBUaGUgaW50ZW50aW9uIHdhcyB0 aGUgUENBIGlzIHRoZSBzYW1lIGFzIHRoZSBSZXNvdXJjZSBNYW5hZ2VyIGluIFZOQy4gV2lsbCBt YWtlIHRoZSB0ZXJtIGNvbnNpc3RlbnQuIEdvb2QgY2F0Y2ghDQoNCg0KDQpGaWd1cmUgOCBTRWN0 aW9uIDYuNCwgOiBJbiB0aGUgcGljdHVyZSB0aGVyZSBpcyBubyBwaGFzZSA3LCBhbmQgdGhlcmUg YXJlIDIgcGhhc2UgOA0KDQpZT1VORz4+IFRoYW5rcy4gR29vZCBjYXRjaCENCg0KUGFnZSAzMCA6 IEl0IGlzIEludGVyZmFjZSBDIG5vdCBCICwgYmV0d2VlbiBWTkMgYW5kIFBOQw0KDQpZT1VORz4+ IElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIFNlY3Rpb24gNy4zIHdoZXJlOg0KDQogICBJbnRlcmZh Y2VzIHNob3VsZCBhbHNvIGJlIHNjYWxhYmxlIGFzIGEgbGFyZ2UgYW1vdW50IG9mIGRhdGEgbmVl ZHMNCg0KICAgdG8gYmUgdHJhbnNwb3J0ZWQgYWNyb3NzIGN1c3RvbWVycyB0byB2aXJ0dWFsIG5l dHdvcmsgY29udHJvbGxlcnMNCg0KICAgYW5kIGFjcm9zcyB2aXJ0dWFsIG5ldHdvcmsgY29udHJv bGxlcnMgYW5kIHBoeXNpY2FsIG5ldHdvcmsNCg0KICAgY29udHJvbGxlcnMuDQoNCg0KDQpJIHRo aW5rIHRoaXMgaW1wbGllcyBib3RoIGludGVyZmFjZXMgQiBhbmQgQyBhbHRob3VnaCBwcmltYXJp bHkgYmV0d2VlbiBWTkMtUE5DLg0KDQoNCg0KU0I+Pj4gU29ycnkgWW91bmcsIGlpdCBpcyBub3Qg cmVmZXJyZWQgdG8gNy4zICwgYnV0IGluIHRoZSBjaGFwdGVyIDYsNSAsIA0KU0I+Pj4gb24gSW50 ZXJmYWNlIGludGVyYWN0aW9uLCBhZnRlciBwb2ludCA2LCBpcyBpbmRpY2F0ZWQgSW50ZXJmYWNl IEIgDQpTQj4+PiBhcyBpbnRlcmZhY2UgYmV0d2VlbiBWTkMgYW5kIFBOQywgZmlndXJlIDUgc2F5 cyBpdCBpcyBJL0YgQw0KDQoNClRoYW5rcw0KDQpTZXJnaW8NCg0KDQpUaGFua3MNClNlcmdpbw0K From nobody Tue Oct 14 10:04:44 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 DE1351A8AF4 for ; Tue, 14 Oct 2014 10:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 KP287sEuxGvj for ; Tue, 14 Oct 2014 10:04:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DBA1A8A9C for ; Tue, 14 Oct 2014 10:03:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKN84090; Tue, 14 Oct 2014 17:03:41 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 18:03:40 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 10:03:34 -0700 From: Leeyoung To: Luyuan Fang , Dhruv Dhody , "actn@ietf.org" Thread-Topic: [Actn] Comments on draft-ceccarelli-actn-framework-03 Thread-Index: AQHP4yKQEHNwyIrIeEunMVCP20GPepwnEPuAgAi0kHA= Date: Tue, 14 Oct 2014 17:03:34 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3DE80@dfweml706-chm> References: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> In-Reply-To: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/cNCyHTwz9liRR44F6EOoH7MmHxM Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 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: Tue, 14 Oct 2014 17:04:42 -0000 Hi Dhruv, As Luyuan has agreed to incorporate your comments, I agree with Luyuan and = thank you for providing good comment. We will incorporate your comment in t= he upcoming revision. Here's some additional comment back to you in-line. Regards, Young -----Original Message----- From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Luyuan Fang Sent: Wednesday, October 08, 2014 2:49 PM To: Dhruv Dhody; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 Hi Dhruv, Appreciate for your feedback, very good comments, we should update the draf= t to align. And I'm good to replace the old text with the new text that you suggested i= n Sec 2. Introduction, it is better. Thanks, Luyuan -----Original Message----- From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Wednesday, October 8, 2014 2:06 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-03 (1) Sec 1. Terminology - We should state that the following terms are defined in this document. - We should also state which terms are borrowed from 4655 and 5440 - PCE, P= CC, PCEP etc (2) Sec 2. Introduction OLD: This implies that at least the following transport networks are in scope of the discussion of this draft: L1 optical networks (e.g., OTN and WDM), MPLS-TP, MPLS-TE, as well as other emerging connection-oriented networks such as Segment Routing (SR). NEW: This implies that at least the following transport networks are in scope of the discussion of this draft: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, Och/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior. Reason: to align with charter discussion. (3) Usage of the term 'virtual network element'; here it means generic elem= ent that could be a virtual node/link - The level of virtual control given to the customers can vary from a tunnel connecting two end- points to virtual network elements that consist of a set of virtual nodes and virtual links in a mesh network topology. Later, it is also used to mean only virtual nodes at - The level of topology abstraction is expressed in terms of the number of virtual network elements (VNEs) and virtual links (VLs). Also it is used for Virtual Network Embedding in section 5. This usage should be made uniform. YOUNG>> Yes, Virtual network elements ---> Virtual Nodes.=20 YOUNG>> VNE (Virtual Network Embedding) is a known terminology in research = circle, which I think stands as is.=20 (4) In section 3.1. Customers, it can be clearly stated that we are dealing= with the case of "advanced customers" only in ACTN. (5) In section 6.2.1. Customer Network Controller, it should be figure 6 and not figure 5 that shows an example physical network topology. (6) In section 6.2.2. Virtual Network Controller, s/consumer controller/cus= tomer controller/ (7) In section 6.2.3. Physical Network Controller, it says - PCE: This is the stateful PCE performing the path computation over the physical topology and that provides the vConnection agent with the network topology. is network topology correct? Or should it be network paths (LSPs)? Or both? YOUNG>> Both depending on the mode of operation.=20 s/network topology/network topology/network paths (LSPs) Note that in the previous section it says - vConnection Agent: This module is in charge of mapping VN setup commands into network provisioning requests to the PNC. which has no mention of network topology. YOUNG>> Resource Manager does that. I added this more clearly in Resource M= anager:=20 The resource manager is in charge of receiving VNS instantiation requests f= rom the Customer Network Controller and, as a consequence, triggering a con= current path computation request to the PCE in the PNC based on the traffic= matrix. The Resource manager is also in charge of generating the abstract = topology for the customer. It may request abstract network topology to PNC. Do you mean to suggest that the PCE needs to communicate raw or abstract to= pology to VNC as well? PCE does not expose such a interface right now. YOUNG>> Yes, through VNC Proxy in PNC.=20 Also note that in figure 8, vConnection Agent doesn't talk to PCE? YOUNG>> This only depicts VNV-PNC not meant to be specific flows between mo= dules within VNC/PNC.=20 (8) In section 6.3. Abstracted Topology Illustration, it should be figure 6= instead figure 2 is mentioned. (9) In section 6.4. Workflows of ACTN Control Modules for Virtual Network S= ervice, it should be figure 8 instead figure 5 is mentioned. Nits: - Suggest to follow the new RFC style guide [1] with respect to ordering of= sections etc. - Expand on first use OTN, WDM, MPLS-TP, MPLS-TE, PCE, TE, TDM.... - Reference to problem statement ID in section 3 is displayed as - [REF pro= bl stat] - s/ONC OAM handler/PNC OAM handler [page 21] Regards, Dhruv [1]: http://www.rfc-editor.org/rfc/rfc7322.txt _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn From nobody Tue Oct 14 11:06:48 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 9D8291A9236 for ; Tue, 14 Oct 2014 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 d8WONsG-8GgU for ; Tue, 14 Oct 2014 11:06:42 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7511A9308 for ; Tue, 14 Oct 2014 11:06:38 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so15691749igb.8 for ; Tue, 14 Oct 2014 11:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=suStJRVL9y6UMItG2vIAdTnpDYLbI9R4Bq5MKGiKAUE=; b=ZdiKwbASTy12YOMIfh8v8xngQWlB8+y2UvbSly94Ak+/mk7fmGXVj5OBZsH0hOEGWL QfOt8FtRlYUVT7DugHWQXX6lFu1jI4lkHmKB9F/DfX96+7bx9EfIGTIhWYIoFaZn2b3C 7Q/bCRKTtu7r5dslKWHhNMqjtxLaR0DVJm1TJShoQ72wV2l24VNiqW9Bd7iXEByL/VKu or2t612fkMDyrpds1OH4N/D/WfFS8g3rVxMUres0W9knbvlEBW6YMhv2jOMw/o6aRVgz 15bA09F4r9aEG+oMBDgakRARDEimC5YboymqTysPZcBJ6vRNBxA7AU+C/5xxR+zwFjZF FySg== MIME-Version: 1.0 X-Received: by 10.50.142.104 with SMTP id rv8mr8529883igb.23.1413309998207; Tue, 14 Oct 2014 11:06:38 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.164.131 with HTTP; Tue, 14 Oct 2014 11:06:38 -0700 (PDT) In-Reply-To: <20141014175311.4083.49198.idtracker@ietfa.amsl.com> References: <20141014175311.4083.49198.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 23:36:38 +0530 X-Google-Sender-Auth: 06jxYtbPfK1M-KHtlmEND4Yue3g Message-ID: From: Dhruv Dhody To: "actn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/gbanPnci6yUy5LmH8nqGcrGyMjo Subject: [Actn] Fwd: New Version Notification for draft-dhody-actn-poi-use-case-03.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: Tue, 14 Oct 2014 18:06:44 -0000 Hi, We have updated the POI use case document. The main changes are - - Sync with the updated ACTN framework document * Terminology of CNC/VNC/PNC through the document. - A new section on a typical POI workflow * Taking DC as a customer (CNC) * Multi-layer coordination via VNC * Multiple PNCs managing each layer Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-actn-poi-use-case-03 Any feedback/comments are most welcome. Dhruv ---------- Forwarded message ---------- From: Date: Tue, Oct 14, 2014 at 11:23 PM Subject: New Version Notification for draft-dhody-actn-poi-use-case-03.txt To: Daniele Ceccarelli , Oscar Gonzalez de Dios , Dhruv Dhody , Xian Zhang , Bin-Yeong Yoon A new version of I-D, draft-dhody-actn-poi-use-case-03.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhody-actn-poi-use-case Revision: 03 Title: Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN) Document date: 2014-10-14 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-dhody-actn-poi-use-case-03.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-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-actn-poi-use-case-03 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 From nobody Wed Oct 15 03:39:42 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 2EAF61A1A93 for ; Wed, 15 Oct 2014 03:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Xve24PUJC-YF for ; Wed, 15 Oct 2014 03:39:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028A51A1AC8 for ; Wed, 15 Oct 2014 03:39:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKO53228; Wed, 15 Oct 2014 10:39:01 +0000 (GMT) Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Oct 2014 11:38:49 +0100 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 18:38:40 +0800 From: Dhruv Dhody To: Leeyoung , Luyuan Fang , Dhruv Dhody , "actn@ietf.org" Thread-Topic: [Actn] Comments on draft-ceccarelli-actn-framework-03 Thread-Index: AQHP4yKPmt1G4waBWUiXdepIxV3HVZwmFYaAgAk/qwCAAaSKwA== Date: Wed, 15 Oct 2014 10:38:38 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8660833B@szxeml556-mbs.china.huawei.com> References: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3DE80@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3DE80@dfweml706-chm> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/5qncHodNDCUAzyTh9gX-FF3EsvQ Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 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, 15 Oct 2014 10:39:31 -0000 Hi Young,=20 (snip) =20 > (3) Usage of the term 'virtual network element'; here it means generic > element that could be a virtual node/link - >=20 > The level of virtual control > given to the customers can vary from a tunnel connecting two end- > points to virtual network elements that consist of a set of virtual > nodes and virtual links in a mesh network topology. >=20 > Later, it is also used to mean only virtual nodes at - >=20 > The level of topology abstraction is expressed in terms of > the number of virtual network elements (VNEs) and virtual links > (VLs). >=20 > Also it is used for Virtual Network Embedding in section 5. >=20 > This usage should be made uniform. >=20 > YOUNG>> Yes, Virtual network elements ---> Virtual Nodes. > YOUNG>> VNE (Virtual Network Embedding) is a known terminology in > research circle, which I think stands as is. [Dhruv]: In the terminology we have stated VNE as Virtual Network Element a= nd the most usage is for virtual nodes.=20 Thus it would be better to remove the first text above which makes 'virtual= network elements' a generic term including both virtual nodes and links.=20 Regarding Virtual Network Embedding, we can avoid using the short form VNE = here to avoid any confusion. And a reference can be found perhaps - http://= ieeexplore.ieee.org/xpls/icp.jsp?arnumber=3D6463372 (snip) >=20 > (7) In section 6.2.3. Physical Network Controller, it says - >=20 > PCE: This is the stateful PCE performing the path computation > over the physical topology and that provides the vConnection > agent with the network topology. >=20 > is network topology correct? Or should it be network paths (LSPs)? Or > both? >=20 > YOUNG>> Both depending on the mode of operation. > s/network topology/network topology/network paths (LSPs) [Dhruv]: IMO the relationships are -=20 Resource manager(VNC) ------- PCE (PNC) (for path computation) Resource manager(VNC) ------- VNC Proxy (PNC) (for abstract topology) vConnection Agent (VNC) ----- Provision Manager (PNC) (for provisioning) If this is correct, perhaps s/network topology/network paths (LSPs) is the = correct text? As the topology (abstract/raw) is through VNC proxy. >=20 >=20 > Note that in the previous section it says - >=20 > vConnection Agent: This module is in charge of mapping VN setup > commands into network provisioning requests to the PNC. >=20 > which has no mention of network topology. >=20 > YOUNG>> Resource Manager does that. I added this more clearly in > Resource Manager: > The resource manager is in charge of receiving VNS instantiation > requests from the Customer Network Controller and, as a consequence, > triggering a concurrent path computation request to the PCE in the PNC > based on the traffic matrix. The Resource manager is also in charge of > generating the abstract topology for the customer. It may request > abstract network topology to PNC. [Dhruv]: Ok, but see above.=20 >=20 >=20 > Do you mean to suggest that the PCE needs to communicate raw or > abstract topology to VNC as well? PCE does not expose such a interface > right now. >=20 > YOUNG>> Yes, through VNC Proxy in PNC. [Dhruv]: Okay, It's not the PCE module inside the PNC, As you point out bel= ow I assumed the flows are between the modules inside PNC/VNC. =20 >=20 > Also note that in figure 8, vConnection Agent doesn't talk to PCE? >=20 > YOUNG>> This only depicts VNV-PNC not meant to be specific flows > between modules within VNC/PNC. [Dhruv]: Can this be clarified in some way to avoid confusion? (snip) Regards, Dhruv From nobody Wed Oct 15 07:01:08 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 629D41A7018 for ; Wed, 15 Oct 2014 07:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 E1CaWmFJsu-i for ; Wed, 15 Oct 2014 07:01:04 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F411A701D for ; Wed, 15 Oct 2014 07:01:03 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9FE0qeD001006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 10:00:52 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 15 Oct 2014 10:00:52 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Wed, 15 Oct 2014 10:00:51 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Wed, 15 Oct 2014 10:00:51 -0400 From: Igor Bryskin To: Dhruv Dhody , Leeyoung , Luyuan Fang , Dhruv Dhody , "actn@ietf.org" Thread-Topic: [Actn] Comments on draft-ceccarelli-actn-framework-03 Thread-Index: AQHP4yKPrffCfg0AukaYi4GzYTinOJwm3rGAgAk/qwCAASbIAP//6+Qg Date: Wed, 15 Oct 2014 14:00:50 +0000 Message-ID: <24c2c25e7f3548109642ea03757643db@ATL-SRV-MBX1.advaoptical.com> References: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3DE80@dfweml706-chm> <23CE718903A838468A8B325B80962F9B8660833B@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8660833B@szxeml556-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-15_04:2014-10-15,2014-10-15,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/hTIQIK5viBDleal-ie21LO20J5M Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 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, 15 Oct 2014 14:01:07 -0000 Hello, In the ACTN context I suggest avoiding term "physical" topology, resources,= controller, etc. and replacing it with term "actual". Note that PCE always works with TE topology, which is not physical topology= , rather an abstraction that combines link/node configuration and auto-disc= overed parameters of physical network resources. Examples of physical resou= rces in WDM layer are: transponders, amplifiers, regenerators, multiplexers= , multi-degree roadms, directionless roadms, etc. PCE works with TE links and nodes that represent said physical resources in= the TE domain. I suggest using term "actual" topology elements (named in the provider nami= ng space and known internally and in entirety to the provider) vs.=20 "abstract" topology elements (named in client naming space and presented to= the client/tenant). Cheers, Igor -----Original Message----- From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Wednesday, October 15, 2014 6:39 AM To: Leeyoung; Luyuan Fang; Dhruv Dhody; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 Hi Young,=20 (snip) =20 > (3) Usage of the term 'virtual network element'; here it means generic=20 > element that could be a virtual node/link - >=20 > The level of virtual control > given to the customers can vary from a tunnel connecting two end- > points to virtual network elements that consist of a set of virtual > nodes and virtual links in a mesh network topology. >=20 > Later, it is also used to mean only virtual nodes at - >=20 > The level of topology abstraction is expressed in terms of > the number of virtual network elements (VNEs) and virtual links > (VLs). >=20 > Also it is used for Virtual Network Embedding in section 5. >=20 > This usage should be made uniform. >=20 > YOUNG>> Yes, Virtual network elements ---> Virtual Nodes. > YOUNG>> VNE (Virtual Network Embedding) is a known terminology in > research circle, which I think stands as is. [Dhruv]: In the terminology we have stated VNE as Virtual Network Element a= nd the most usage is for virtual nodes.=20 Thus it would be better to remove the first text above which makes 'virtual= network elements' a generic term including both virtual nodes and links.=20 Regarding Virtual Network Embedding, we can avoid using the short form VNE = here to avoid any confusion. And a reference can be found perhaps - http://= ieeexplore.ieee.org/xpls/icp.jsp?arnumber=3D6463372 (snip) >=20 > (7) In section 6.2.3. Physical Network Controller, it says - >=20 > PCE: This is the stateful PCE performing the path computation > over the physical topology and that provides the vConnection > agent with the network topology. >=20 > is network topology correct? Or should it be network paths (LSPs)? Or=20 > both? >=20 > YOUNG>> Both depending on the mode of operation. > s/network topology/network topology/network paths (LSPs) [Dhruv]: IMO the relationships are - Resource manager(VNC) ------- PCE (PNC) (for path computation) Resource man= ager(VNC) ------- VNC Proxy (PNC) (for abstract topology) vConnection Agent= (VNC) ----- Provision Manager (PNC) (for provisioning) If this is correct, perhaps s/network topology/network paths (LSPs) is the = correct text? As the topology (abstract/raw) is through VNC proxy. >=20 >=20 > Note that in the previous section it says - >=20 > vConnection Agent: This module is in charge of mapping VN setup > commands into network provisioning requests to the PNC. >=20 > which has no mention of network topology. >=20 > YOUNG>> Resource Manager does that. I added this more clearly in > Resource Manager: > The resource manager is in charge of receiving VNS instantiation=20 > requests from the Customer Network Controller and, as a consequence,=20 > triggering a concurrent path computation request to the PCE in the PNC=20 > based on the traffic matrix. The Resource manager is also in charge of=20 > generating the abstract topology for the customer. It may request=20 > abstract network topology to PNC. [Dhruv]: Ok, but see above.=20 >=20 >=20 > Do you mean to suggest that the PCE needs to communicate raw or=20 > abstract topology to VNC as well? PCE does not expose such a interface=20 > right now. >=20 > YOUNG>> Yes, through VNC Proxy in PNC. [Dhruv]: Okay, It's not the PCE module inside the PNC, As you point out bel= ow I assumed the flows are between the modules inside PNC/VNC. =20 >=20 > Also note that in figure 8, vConnection Agent doesn't talk to PCE? >=20 > YOUNG>> This only depicts VNV-PNC not meant to be specific flows > between modules within VNC/PNC. [Dhruv]: Can this be clarified in some way to avoid confusion? (snip) Regards, Dhruv _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn From nobody Wed Oct 15 13:22:36 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 2C86A1A70E2 for ; Wed, 15 Oct 2014 13:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 61tG8-AY5Xvf for ; Wed, 15 Oct 2014 13:22:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3951A6FCF for ; Wed, 15 Oct 2014 13:22:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKO97833; Wed, 15 Oct 2014 20:22:22 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Oct 2014 21:22:21 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 13:22:04 -0700 From: Leeyoung To: Dhruv Dhody , Luyuan Fang , Dhruv Dhody , "actn@ietf.org" Thread-Topic: [Actn] Comments on draft-ceccarelli-actn-framework-03 Thread-Index: AQHP4yKQEHNwyIrIeEunMVCP20GPepwnEPuAgAi0kHCAAbHkAIAAK7Og Date: Wed, 15 Oct 2014 20:22:03 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3E48B@dfweml706-chm> References: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3DE80@dfweml706-chm> <23CE718903A838468A8B325B80962F9B8660833B@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8660833B@szxeml556-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/sXnwD-z2WFkN6TcwGpLg2eyOykk Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 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, 15 Oct 2014 20:22:29 -0000 Hi Dhruv, Please see inline for my comment. Thanks, Young -----Original Message----- From: Dhruv Dhody=20 Sent: Wednesday, October 15, 2014 5:39 AM To: Leeyoung; Luyuan Fang; Dhruv Dhody; actn@ietf.org Subject: RE: [Actn] Comments on draft-ceccarelli-actn-framework-03 Hi Young,=20 (snip) =20 > (3) Usage of the term 'virtual network element'; here it means generic=20 > element that could be a virtual node/link - >=20 > The level of virtual control > given to the customers can vary from a tunnel connecting two end- > points to virtual network elements that consist of a set of virtual > nodes and virtual links in a mesh network topology. >=20 > Later, it is also used to mean only virtual nodes at - >=20 > The level of topology abstraction is expressed in terms of > the number of virtual network elements (VNEs) and virtual links > (VLs). >=20 > Also it is used for Virtual Network Embedding in section 5. >=20 > This usage should be made uniform. >=20 > YOUNG>> Yes, Virtual network elements ---> Virtual Nodes. > YOUNG>> VNE (Virtual Network Embedding) is a known terminology in > research circle, which I think stands as is. [Dhruv]: In the terminology we have stated VNE as Virtual Network Element a= nd the most usage is for virtual nodes.=20 Thus it would be better to remove the first text above which makes 'virtual= network elements' a generic term including both virtual nodes and links.=20 Regarding Virtual Network Embedding, we can avoid using the short form VNE = here to avoid any confusion. And a reference can be found perhaps - http://= ieeexplore.ieee.org/xpls/icp.jsp?arnumber=3D6463372 (snip) YOUNG>> Good idea. I will add the reference as well. >=20 > (7) In section 6.2.3. Physical Network Controller, it says - >=20 > PCE: This is the stateful PCE performing the path computation > over the physical topology and that provides the vConnection > agent with the network topology. >=20 > is network topology correct? Or should it be network paths (LSPs)? Or=20 > both? >=20 > YOUNG>> Both depending on the mode of operation. > s/network topology/network topology/network paths (LSPs) [Dhruv]: IMO the relationships are - Resource manager(VNC) ------- PCE (PNC) (for path computation) Resource man= ager(VNC) ------- VNC Proxy (PNC) (for abstract topology) vConnection Agent= (VNC) ----- Provision Manager (PNC) (for provisioning) YOUNG>> The relationships are correct. I will look at the text once more to= sort it out based on these relationships.=20 If this is correct, perhaps s/network topology/network paths (LSPs) is the = correct text? As the topology (abstract/raw) is through VNC proxy. >=20 >=20 > Note that in the previous section it says - >=20 > vConnection Agent: This module is in charge of mapping VN setup > commands into network provisioning requests to the PNC. >=20 > which has no mention of network topology. >=20 > YOUNG>> Resource Manager does that. I added this more clearly in > Resource Manager: > The resource manager is in charge of receiving VNS instantiation=20 > requests from the Customer Network Controller and, as a consequence,=20 > triggering a concurrent path computation request to the PCE in the PNC=20 > based on the traffic matrix. The Resource manager is also in charge of=20 > generating the abstract topology for the customer. It may request=20 > abstract network topology to PNC. [Dhruv]: Ok, but see above.=20 >=20 >=20 > Do you mean to suggest that the PCE needs to communicate raw or=20 > abstract topology to VNC as well? PCE does not expose such a interface=20 > right now. >=20 > YOUNG>> Yes, through VNC Proxy in PNC. [Dhruv]: Okay, It's not the PCE module inside the PNC, As you point out bel= ow I assumed the flows are between the modules inside PNC/VNC. =20 YOUNG>> Yes.=20 >=20 > Also note that in figure 8, vConnection Agent doesn't talk to PCE? >=20 > YOUNG>> This only depicts VNV-PNC not meant to be specific flows > between modules within VNC/PNC. [Dhruv]: Can this be clarified in some way to avoid confusion? YOUNG>> I will look into the draft to clarify this aspect.=20 (snip) Regards, Dhruv From nobody Wed Oct 15 13:41:47 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 C7C131ACD21 for ; Wed, 15 Oct 2014 13:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1oyH1ZIapIce for ; Wed, 15 Oct 2014 13:41:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8BA1ACCEA for ; Wed, 15 Oct 2014 13:41:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNR59283; Wed, 15 Oct 2014 20:41:30 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Oct 2014 21:41:28 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 13:41:15 -0700 From: Leeyoung To: Igor Bryskin , Dhruv Dhody , Luyuan Fang , Dhruv Dhody , "actn@ietf.org" Thread-Topic: [Actn] Comments on draft-ceccarelli-actn-framework-03 Thread-Index: AQHP4yKQEHNwyIrIeEunMVCP20GPepwnEPuAgAi0kHCAAbHkAIAAOH4A///1RrA= Date: Wed, 15 Oct 2014 20:41:15 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3E4D8@dfweml706-chm> References: <792aafe99cf649cda84ab8ec7e428d81@BL2PR03MB372.namprd03.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E1729C3DE80@dfweml706-chm> <23CE718903A838468A8B325B80962F9B8660833B@szxeml556-mbs.china.huawei.com> <24c2c25e7f3548109642ea03757643db@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <24c2c25e7f3548109642ea03757643db@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/3rlwtAvBFiEyHM5DmSyDLFS9JIk Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 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, 15 Oct 2014 20:41:44 -0000 Hi Igor, In regards to 'topology' passed between PNC and VNC, I agree with you that = we can start TE level topology with various degree of granularity. I would = not object calling TE topology as actual topology (with clear indication th= at this actual is TE level). And abstract topology is further abstraction f= rom 'actual topology.=20 In regards to PNC vs ANC, I prefer PNC over ANC. The reason is as follows: = PNC is termed as such to include control/management planes of various types= beyond GMPLS/PCE. SDN controllers and NMS are part of PNC. The degree of c= ontrol over the networks varies depending on which regime of control/manage= ment entities we are talking about. GMPLS/PCEP are constantly augmented to = do more on optical network resources control such as wavelengths, regenerat= ion configuration among others while NMS/SDN Controllers do more than TE le= vel control. I prefer PNC over ANC.=20 Or simply calling it NC (Network Controller) is another way to reach an agr= eement.=20 Regards, Young -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Wednesday, October 15, 2014 9:01 AM To: Dhruv Dhody; Leeyoung; Luyuan Fang; Dhruv Dhody; actn@ietf.org Subject: RE: [Actn] Comments on draft-ceccarelli-actn-framework-03 Hello, In the ACTN context I suggest avoiding term "physical" topology, resources,= controller, etc. and replacing it with term "actual". Note that PCE always works with TE topology, which is not physical topology= , rather an abstraction that combines link/node configuration and auto-disc= overed parameters of physical network resources. Examples of physical resou= rces in WDM layer are: transponders, amplifiers, regenerators, multiplexers= , multi-degree roadms, directionless roadms, etc. PCE works with TE links and nodes that represent said physical resources in= the TE domain. I suggest using term "actual" topology elements (named in the provider nami= ng space and known internally and in entirety to the provider) vs.=20 "abstract" topology elements (named in client naming space and presented to= the client/tenant). Cheers, Igor -----Original Message----- From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Wednesday, October 15, 2014 6:39 AM To: Leeyoung; Luyuan Fang; Dhruv Dhody; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-03 Hi Young,=20 (snip) =20 > (3) Usage of the term 'virtual network element'; here it means generic=20 > element that could be a virtual node/link - >=20 > The level of virtual control > given to the customers can vary from a tunnel connecting two end- > points to virtual network elements that consist of a set of virtual > nodes and virtual links in a mesh network topology. >=20 > Later, it is also used to mean only virtual nodes at - >=20 > The level of topology abstraction is expressed in terms of > the number of virtual network elements (VNEs) and virtual links > (VLs). >=20 > Also it is used for Virtual Network Embedding in section 5. >=20 > This usage should be made uniform. >=20 > YOUNG>> Yes, Virtual network elements ---> Virtual Nodes. > YOUNG>> VNE (Virtual Network Embedding) is a known terminology in > research circle, which I think stands as is. [Dhruv]: In the terminology we have stated VNE as Virtual Network Element a= nd the most usage is for virtual nodes.=20 Thus it would be better to remove the first text above which makes 'virtual= network elements' a generic term including both virtual nodes and links.=20 Regarding Virtual Network Embedding, we can avoid using the short form VNE = here to avoid any confusion. And a reference can be found perhaps - http://= ieeexplore.ieee.org/xpls/icp.jsp?arnumber=3D6463372 (snip) >=20 > (7) In section 6.2.3. Physical Network Controller, it says - >=20 > PCE: This is the stateful PCE performing the path computation > over the physical topology and that provides the vConnection > agent with the network topology. >=20 > is network topology correct? Or should it be network paths (LSPs)? Or=20 > both? >=20 > YOUNG>> Both depending on the mode of operation. > s/network topology/network topology/network paths (LSPs) [Dhruv]: IMO the relationships are - Resource manager(VNC) ------- PCE (PNC) (for path computation) Resource man= ager(VNC) ------- VNC Proxy (PNC) (for abstract topology) vConnection Agent= (VNC) ----- Provision Manager (PNC) (for provisioning) If this is correct, perhaps s/network topology/network paths (LSPs) is the = correct text? As the topology (abstract/raw) is through VNC proxy. >=20 >=20 > Note that in the previous section it says - >=20 > vConnection Agent: This module is in charge of mapping VN setup > commands into network provisioning requests to the PNC. >=20 > which has no mention of network topology. >=20 > YOUNG>> Resource Manager does that. I added this more clearly in > Resource Manager: > The resource manager is in charge of receiving VNS instantiation=20 > requests from the Customer Network Controller and, as a consequence,=20 > triggering a concurrent path computation request to the PCE in the PNC=20 > based on the traffic matrix. The Resource manager is also in charge of=20 > generating the abstract topology for the customer. It may request=20 > abstract network topology to PNC. [Dhruv]: Ok, but see above.=20 >=20 >=20 > Do you mean to suggest that the PCE needs to communicate raw or=20 > abstract topology to VNC as well? PCE does not expose such a interface=20 > right now. >=20 > YOUNG>> Yes, through VNC Proxy in PNC. [Dhruv]: Okay, It's not the PCE module inside the PNC, As you point out bel= ow I assumed the flows are between the modules inside PNC/VNC. =20 >=20 > Also note that in figure 8, vConnection Agent doesn't talk to PCE? >=20 > YOUNG>> This only depicts VNV-PNC not meant to be specific flows > between modules within VNC/PNC. [Dhruv]: Can this be clarified in some way to avoid confusion? (snip) Regards, Dhruv _______________________________________________ ACTN mailing list ACTN@ietf.org https://www.ietf.org/mailman/listinfo/actn From nobody Mon Oct 20 10:21:31 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 8B7D21A6F58 for ; Mon, 20 Oct 2014 10:21:27 -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 Cwzltgfqg5nI for ; Mon, 20 Oct 2014 10:21:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DA51A6F60 for ; Mon, 20 Oct 2014 10:19:36 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-00-54454426870d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9D.99.21334.62445445; Mon, 20 Oct 2014 19:19:34 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 19:19:34 +0200 From: Daniele Ceccarelli To: "actn@ietf.org" Thread-Topic: New Version Notification for draft-ceccarelli-actn-framework-04.txt Thread-Index: AQHP7IkVo//Qq8c24EG8t19XWzRMoJw5OUgw Date: Mon, 20 Oct 2014 17:19:33 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48127B2442@ESESSMB301.ericsson.se> References: <20141020170156.21930.36422.idtracker@ietfa.amsl.com> In-Reply-To: <20141020170156.21930.36422.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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja6ai2uIwZI2DYstPRfYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX7aDJaCVWIVLzsEGhgfiHYxcnJICJhInHv4iBnCFpO4cG89 WxcjF4eQwFFGiY27lrCBJIQEFjFKNG/V7WLk4GATsJJ4csgHJCwioCyx+PAfsBJhgSCJ/p+X 2CHiwRJz3jUwQthGEr+etLKA2CwCqhIbbs4Aq+EV8JU48v8YO8R4R4njG9eC1XMKOEls7FrN BGIzCshKTNi9CCzOLCAucevJfCaIOwUkluw5D3WzqMTLx/9YIWxFiZ1n25lBzmQW0JRYv0sf olVRYkr3Q6i1ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFxbrqRsV5qUWZycXF+ nl5easkmRmAsHNzyW3cH4+rXjocYBTgYlXh4F+S4hAixJpYVV+YeYpTmYFES5110bl6wkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYL+XkHvYNrTO8Vrl5R/KrlZpaOvcDpKxFntu1qP3PJ kVExPdN6ZfNXhca08pMzgxryLm9zLbi9/0tSl5r5GY8gsYnnutM/THt65teczgWBvYsCzhTp OGz+rCVw+/idZdzN7ldWrOmYOKvyi9TDv1YbhfbGii5LttDUubLPOsqzbtl80QPzhS2VWIoz Eg21mIuKEwEmceJaZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/SV-HxoNZL_ZX2bLbOqUgug4-1yQ Subject: [Actn] FW: New Version Notification for draft-ceccarelli-actn-framework-04.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: Mon, 20 Oct 2014 17:21:27 -0000 SGkgZm9sa3MsDQoNCndlIGp1c3QgdXBsb2FkZWQgdGhlIOKAk3YwNCB2ZXJzaW9uIG9mIHRoZSBm d2sgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmstMDQNCg0KTWFpbiB1cGRhdGVzOg0KLSBTZXJnaW8gYW5kIERhbiBqb2luZWQg YXMgY28tYXV0aG9ycw0KLSBSZWZlcmVuY2UgdG8gQUJOTyBhbmQgT05GIFNETiBhcmNoaXRlY3R1 cmVzIGFkZGVkDQotIFZOQyBhbmQgUE5DIGFyY2hpdGVjdHVyZXMganVzdCBsZWZ0IGFzIHJlZmVy ZW5jZS4gRGlzY2xhaW1lciBhZGRlZCB0aGF0IHRoZSBmdW5jdGlvbmFsIGJsb2NrcyBkbyBub3Qg aWRlbnRpZnkgdGhlIFBOQy9WTkMgYXJjaGl0ZWN0dXJlIGJ1dCBvbmx5ICB0aGUgZnVuY3Rpb25h bGl0aWVzIHJlcXVpcmVkIGJ5IHRoZSBBQ05UIGZyYW1ld29yay4gDQotIFNlY3Rpb24gNi41IEFj dG4gaW50ZXJmYWNlcyBpbnRlcmFjdGlvbiByZW1vdmVkIGF0IHRoZSB0aW1lIGJlaW5nDQotIFZh cmlvdXMgbml0cw0KDQpGdXJ0aGVyIHJldmlld2luZyBhbmQgZ29vZCBkaXNjdXNzaW9ucyBvbiB0 aGUgbGlzdCBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuDQoNCkJSDQpEYW5pZWxlICYgQ28tYXV0aG9y cw0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IGx1 bmVkw6wgMjAgb3R0b2JyZSAyMDE0IDE5OjAyDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBMdXl1 YW4gRmFuZzsgWW91bmcgTGVlOyBEYW5pZWwgS2luZzsgTHV5dWFuIEZhbmc7IERhbmllbGUgQ2Vj Y2FyZWxsaTsgRGFuaWVsIEtpbmc7IFlvdW5nIExlZTsgRGllZ28gUi4gTG9wZXo7IERpZWdvIExv cGV6OyBTZXJnaW8gQmVsb3R0aTsgU2VyZ2lvIEJlbG90dGkNClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wNC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29y ay0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFuaWVsZSBDZWNj YXJlbGxpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmsNClJldmlzaW9uOgkwNA0KVGl0bGU6CQlGcmFtZXdv cmsgZm9yIEFic3RyYWN0aW9uIGFuZCBDb250cm9sIG9mIFRyYW5zcG9ydCBOZXR3b3Jrcw0KRG9j dW1lbnQgZGF0ZToJMjAxNC0xMC0yMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOgkJMzENClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1jZWNjYXJlbGxpLWFjdG4tZnJhbWV3b3JrLTA0LnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNlY2NhcmVsbGktYWN0 bi1mcmFtZXdvcmsvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2VjY2FyZWxsaS1hY3RuLWZyYW1ld29yay0wNA0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdv cmstMDQNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZv ciBhYnN0cmFjdGlvbiBhbmQgY29udHJvbCBvZg0KICAgdHJhbnNwb3J0IG5ldHdvcmtzLg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Oct 21 15:44:16 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 2AE8A1A87BE for ; Tue, 21 Oct 2014 15:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 t95zwKQIwUbF for ; Tue, 21 Oct 2014 15:44:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C091A87A3 for ; Tue, 21 Oct 2014 15:44:11 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-d7-54468a1d48bf Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D4.BB.05330.D1A86445; Tue, 21 Oct 2014 18:30:21 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 18:44:09 -0400 From: Dave Hood To: "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQ== Date: Tue, 21 Oct 2014 22:44:09 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F538AEAeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXSPn65sl1uIwetVhhZbei6wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49e6PewF36IqOp5ENDB+8e1i5OSQEDCR+PfnOiuELSZx4d56 ti5GLg4hgaOMEpcnzGWBcJYzSjxY2cwIUsUmoCHx5NJkJhBbREBZYvHhP2wgtrCAucTTCw9Z IeI2En/XfYKq0ZOY/Xc3C4jNIqAqcWDaTmYQm1fAV2Lv30NgvYxAm7+fWgNWzywgLnHryXwm iIsEJJbsOc8MYYtKvHz8D+pSJYk5r68xQ9TnS8y5sJEVYqagxMmZT1gmMArNQjJqFpKyWUjK IOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGjtLi1LLcdCODTYzAwD8mwaa7g3HPS8tD jAIcjEo8vAt8XUOEWBPLiitzDzFKc7AoifPOqp0XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoGR/22QUkdrKcf0IJP5LCf6WF7+fdz8Q4xFcRvX3HkvL0/Msla7uPKXdvnrjP+sjBaS8yfJ e6ScWm9nMeP9gSUdCVOjC9xmnWx5ZncwWXlFZPqDE58eJMdOc5h35k+8FVfdnSdMl8qOvZHW imib+Fb6Yz5fQUftihcGt51fKSRNKFtYmbduZeB0JZbijERDLeai4kQA1UrFWF0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/actn/5XAj6N_Fm8szQojgskxXdK449cQ Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 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: Tue, 21 Oct 2014 22:44:15 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F538AEAeusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F538AEAeusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

Dave

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F538AEAeusaamb105erics_-- From nobody Wed Oct 22 19:34:12 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 DC0D91A87E6 for ; Wed, 22 Oct 2014 19:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZS5rNwZbbchp for ; Wed, 22 Oct 2014 19:34:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271C61A3BA3 for ; Wed, 22 Oct 2014 19:34:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKV53226; Thu, 23 Oct 2014 02:34:04 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Oct 2014 03:34:03 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 19:33:53 -0700 From: Leeyoung To: Dave Hood , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLg Date: Thu, 23 Oct 2014 02:33:52 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.250] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C3FD8Bdfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/c9h3qhzNLc-wgx2vMHQJrWVRufo Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 23 Oct 2014 02:34:12 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3FD8Bdfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_7AEB3D6833318045B4AE71C2C87E8E1729C3FD8Bdfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C3FD8Bdfweml706chm_-- From nobody Thu Oct 23 01:14: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 33BDE1A8907 for ; Thu, 23 Oct 2014 01:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 DOuH3S9dRMgs for ; Thu, 23 Oct 2014 01:14:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09F81A885B for ; Thu, 23 Oct 2014 01:14:27 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-a0-5448b8e1c51a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.FC.21334.1E8B8445; Thu, 23 Oct 2014 10:14:25 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 10:14:25 +0200 From: Daniele Ceccarelli To: Dave Hood , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQBKFq5A Date: Thu, 23 Oct 2014 08:14:24 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48127B7B8E@ESESSMB301.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> 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: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48127B7B8EESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7DHR4hBq+6tC229Fxgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtKPh9gL1kxgrPg5awFrA+OLqi5GTg4JAROJtgNnGCFsMYkL 99azdTFycQgJHGWUuPn4GBtIQkhgEaPE8U/WXYwcHGwCVhJPDvmAhEUE3CXe318EViIsYC2x bc9xZoi4jcTfdZ+YIGwjibn3NrGC2CwCqhL398xmAhnDK+Ar0TBVCGK6r8Sxq5fZQcKcAn4S R+44gYQZBWQlJuxeBHYZs4C4xK0n85kgrhSQWLLnPDOELSrx8vE/VghbUeLjq31Q9fkS/ffX gdXwCghKnJz5hGUCo8gsJKNmISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKv YhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMn4NbfuvuYFz92vEQowAHoxIPb8JMjxAh1sSy 4srcQ4zSHCxK4ryLzs0LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo9JS/7e11x5xYvltm X597eZdLFi1OXrKlZ5egVkhU7/Gm9zYtKt/vG31gatrc4Mdz+5u0UuOdggcry15lvVp9ZX7a nfaYmc/EDVrPbDbX0q9XbGI+5jil6zCTWhXjHbtnNd9Nfn53O53TyuL/Ldm9f/qdAyeLtdeY tG05EWv5pefuzte/XWYosRRnJBpqMRcVJwIAGWQCEYACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/actn/d8Bt5dIOqP_TrBDinKjtctb7N_I Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 23 Oct 2014 08:14:34 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48127B7B8EESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Adding some further comments in line. Thank a lot for the detailed review, much appreciated. BR Daniele From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: mercoled=EC 22 ottobre 2014 00:44 To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. [[DanCe]] I think what is missing here is that ACTN is not only SDN...it is= also SDN. I start to think that the PNC term is misleading. The PNC is not= necessarily an SDN controller, it is "something" that controls a network, = it can be an SDN controller, can be an NMS, can be a PCE+ on top of a GMPLS= network. The idea is to use the VNC as the enabler to put all of these sil= os together. I fully agree that the idea of the SDN is to break the silos, = but in my opinion the goal of ACTN is the one of take the existing silos an= d make them interwork. Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. [[DanCe]] there is parallel thread on that and we'll see the different appr= oaches being presented and discussed at the BoF. It will be interesting. Pe= r my previous comment I see the recursion between VNCs as the PNC could or = could not be an SDN controller. Maybe you could argue that in case the PNC = is an SDN controller it is not different from the VNC. The other thread on = the list regards interfaces (whether interfaces B and C are the same of dif= ferent ones). I think sorting that out could also help understand what are = the differences between the PNC SDN controller and the VNC...if any. Regarding domain boundaries I think the definition of boundary includes all= the nodes under the control of the same PNC (I could be also multiple GMPL= S domains, but all of them controlled by the same PNC). This is based on th= e assumption that a node can't be under the control of multiple PNC. It is= a strong assumption but I think reasonable, isn't it? The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. [[DanCe]]IMHO there is one PCE at PNC layer and a PCE at VNC layer. I've al= ways assumed the PCE inside the SDN controller but it is correct to assume = that is could also be outside. I see this architecture much alike the H-PCE= one. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) [[DanCe]] This is what is assumed to be done by the VNC proxy in both the P= NC and VNC. We can rename it manger to get aligned with the ONF-ARCH. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. Dave --_000_4A1562797D64E44993C5CBF38CF1BE48127B7B8EESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Adding some further co= mments in line.

 

Thank a lot for the de= tailed review, much appreciated.

 

BR
Daniele

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: mercoled=EC 22 ottobre 2014 00:44
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

[[DanCe]] I thin= k what is missing here is that ACTN is not only SDN…it is also SDN. I= start to think that the PNC term is misleading. The PNC is not necessarily= an SDN controller, it is “something” that controls a network, it can be an SDN controller, can be an NMS, can be a P= CE+ on top of a GMPLS network. The idea is to use the VNC as the enable= r to put all of these silos together. I fully agree that the idea of the SD= N is to break the silos, but in my opinion the goal of ACTN is the one of take the existing silos and make them inter= work.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

[[DanCe]] there = is parallel thread on that and we’ll see the different approaches bei= ng presented and discussed at the BoF. It will be interesting. Per my previ= ous comment I see the recursion between VNCs as the PNC could or could not be an SDN controller. Maybe you could argue = that in case the PNC is an SDN controller it is not different from the VNC.= The other thread on the list regards interfaces (whether interfaces B and = C are the same of different ones). I think sorting that out could also help understand what are the differenc= es between the PNC SDN controller and the VNC…if any.

 

Regarding domain= boundaries I think the definition of boundary includes all the nodes under= the control of the same PNC (I could be also multiple GMPLS domains, but a= ll of them controlled by the same PNC). This is based on the assumption that  a node can’t be under the= control of multiple PNC. It is a strong assumption but I think reasonable,= isn’t it?

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

[[DanCe]]IMHO th= ere is one PCE at PNC layer and a PCE at VNC layer. I’ve always assum= ed the PCE inside the SDN controller but it is correct to assume that is co= uld also be outside. I see this architecture much alike the H-PCE one.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

[[DanCe]] This i= s what is assumed to be done by the VNC proxy in both the PNC and VNC. We c= an rename it manger to get aligned with the ONF-ARCH.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

Dave

--_000_4A1562797D64E44993C5CBF38CF1BE48127B7B8EESESSMB301erics_-- From nobody Thu Oct 23 08:14:40 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 F11A41AC3B5 for ; Thu, 23 Oct 2014 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QfCFdvDFNy_0 for ; Thu, 23 Oct 2014 08:14:31 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840011AC3A2 for ; Thu, 23 Oct 2014 08:14:31 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-81-5448c3a32fef Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 48.D7.05330.3A3C8445; Thu, 23 Oct 2014 11:00:20 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:14:29 -0400 From: Dave Hood To: Leeyoung , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPA= Date: Thu, 23 Oct 2014 15:14:29 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F53C349eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPgu6Swx4hBr8XMFts6bnAZjFtnqsD k0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgyljVOpux4Nguxor2P1cYGxhPLmDsYuTkkBAw kXh9fAEzhC0mceHeerYuRi4OIYGjjBJnbm5mhXCWM0rcOXmKDaSKTUBD4smlyUwgtoiAs8SG 7UfBuoUFrCW27TnODBG3kfi77hNUjZXEkRf3WLoYOThYBFQlZr63AwnzCvhK9DXsZ4aY38Eo sXR6MytIglPAVaKxvR1sFyPQRd9PrQGbwywgLnHryXwmiEsFJJbsOQ91tajEy8f/WCFsJYlJ S8+xQtTnSzxcM58ZYpmgxMmZT1gmMIrMQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznw mAlZfAEj+ypGjtLi1LLcdCODTYzACDomwaa7g3HPS8tDjAIcjEo8vA80PEKEWBPLiitzDzFK c7AoifPOqp0XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxl3vu5qM/CrZIMl2P+FLts0g7 aVFTj5uu0PPYbVzPX97PWDtL0zY76V+F/foFZe1TL3e88FmV9W3n+s+fd6Ux3iv5faHkZNDH Q+7cM8ysNFaFxDnm3an+FbuKzdnz7GSZ5+nR6+U0ZzdNn8y9InFl5fFG/8uCuty6iWcnnT3n nGcw4fDd/t35SizFGYmGWsxFxYkAFnf0UYECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/actn/-1Vctz301zyZa57iO27W9evamC0 Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 23 Oct 2014 15:14:38 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53C349eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53C349eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F53C349eusaamb105erics_-- From nobody Fri Oct 24 08:58:40 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 241761A1B66 for ; Fri, 24 Oct 2014 08:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ihqrk_RqbxQe for ; Fri, 24 Oct 2014 08:58:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A6B1A1AAD for ; Fri, 24 Oct 2014 08:58:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNZ98398; Fri, 24 Oct 2014 15:58:02 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Oct 2014 16:57:54 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 08:57:48 -0700 From: Leeyoung To: Dave Hood , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkA== Date: Fri, 24 Oct 2014 15:57:48 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.195] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C403EFdfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/qc_3_U2NY-gtoTS4d9OQMtmxPSw Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 15:58:37 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C403EFdfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_7AEB3D6833318045B4AE71C2C87E8E1729C403EFdfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C403EFdfweml706chm_-- From nobody Fri Oct 24 09:19:13 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 D41311A6F22 for ; Fri, 24 Oct 2014 09:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 M-fjbPi8ZwAE for ; Fri, 24 Oct 2014 09:19:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4651A1B64 for ; Fri, 24 Oct 2014 09:18:29 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-76-544a21a6d3d3 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A8.26.25146.6A12A445; Fri, 24 Oct 2014 11:53:43 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 12:18:22 -0400 From: Dave Hood To: Leeyoung , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejg Date: Fri, 24 Oct 2014 16:18:22 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E408eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPgu5yRa8Qg98zmS229Fxgs5g2z9WB yaPlyFtWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZUz9856p4PIypoq1qxUaGCf9Y+xi5OSQEDCR OPduFROELSZx4d56ti5GLg4hgaOMEgteHoFyljNKrD8yEayKTUBD4smlyWC2iICzxIbtR5lB bGEBa4lte44zQ8RtJP6u+wRV4yYx68pcNhCbRUBVomn9PrDNvAK+Ele+zGeHWNDOJPF58hOw Ik4BV4mTT3aD2YxAJ30/tQZsELOAuMStJ/OhThWQWLLnPDOELSrx8vE/VghbSeLjb5ChIPX5 Er0HNzNDLBOUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2Bk X8XIUVqcWpabbmS4iREYQcck2Bx3MC74ZHmIUYCDUYmHV8HJM0SINbGsuDL3EKM0B4uSOK9m 9bxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzTD0/dvijFOvWw+dc2748PBaeKdL6cllVc IXQnmYmhpdLx28rfWbVzWxYxRbyuv+Wwcad1II/WV7tZCy4d+NzOFz7h90VJ1Y/xOtq3GWN2 1zs2rDQzXCO5NuvtGW+lWsuSnwq/dnsuVFGPEf3UezwtZaVP+qwtil9Ctfhm9Budsi685L22 5ZESS3FGoqEWc1FxIgAvnxsigQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/F53z85TanGU6PyTyvIlQvlsUoXI Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 16:19:12 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E408eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E408eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E408eusaamb105erics_-- From nobody Fri Oct 24 10:38:31 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 25A781A8906 for ; Fri, 24 Oct 2014 10:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 gSMnhKprvsWb for ; Fri, 24 Oct 2014 10:38:15 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D321A895A for ; Fri, 24 Oct 2014 10:38:14 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9OHc6jq016607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 13:38:07 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 13:38:06 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Fri, 24 Oct 2014 13:38:06 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Fri, 24 Oct 2014 13:38:06 -0400 From: Igor Bryskin To: Dave Hood , Leeyoung , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAKj5BA= Date: Fri, 24 Oct 2014 17:38:05 +0000 Message-ID: <0e0a5f5b107c455287171dd5d93e7d61@ATL-SRV-MBX1.advaoptical.com> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_0e0a5f5b107c455287171dd5d93e7d61ATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-24_06:2014-10-24,2014-10-24,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/HR96e9yh9VkbZU0LF_zRIxP6q4g Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 17:38:26 -0000 --_000_0e0a5f5b107c455287171dd5d93e7d61ATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I completely agree with you on the requirement that from the hierarchical S= DN point of view each provider layer must be fundamentally the same as its = client layer, so that the client can serve its own clients, and the server = can be a client of its own providers, etc. With this in mind would you agree with me that there is no fundamental diff= erence between the VNC and PNC, and between the interfaces B and C in the c= urrent ACTN architecture? Thanks, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Friday, October 24, 2014 12:18 PM To: Leeyoung; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_0e0a5f5b107c455287171dd5d93e7d61ATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Da= ve,

=  

I com= pletely agree with you on the requirement that from the hierarchical SDN po= int of view each provider layer must be fundamentally the same as its clien= t layer, so that the client can serve its own clients, and the server can be a client of its own providers, etc.=

With = this in mind would you agree with me that there is no fundamental differenc= e between the VNC and PNC, and between the interfaces B and C in the curren= t ACTN architecture?

=  

Thank= s,

Igor<= o:p>

=  

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of Dave Hood
Sent: Friday, October 24, 2014 12:18 PM
To: Leeyoung; actn@ietf.org
Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_0e0a5f5b107c455287171dd5d93e7d61ATLSRVMBX1advaopticalco_-- From nobody Fri Oct 24 10:40:57 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 DE7841A8982 for ; Fri, 24 Oct 2014 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hD0JsczXhxsK for ; Fri, 24 Oct 2014 10:40:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EC11A8952 for ; Fri, 24 Oct 2014 10:40:15 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-86-544a34d3ab18 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 08.4B.25146.3D43A445; Fri, 24 Oct 2014 13:15:31 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 13:40:12 -0400 From: Dave Hood To: Igor Bryskin , Leeyoung , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAKj5BAAALapoA== Date: Fri, 24 Oct 2014 17:40:11 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F53E815@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> <0e0a5f5b107c455287171dd5d93e7d61@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <0e0a5f5b107c455287171dd5d93e7d61@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E815eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPiO5lE68Qg4O/9Cy29FxgszjV085o MW2eqwOzx9kFf1g9Wo68ZfVYsuQnUwBzFJdNSmpOZllqkb5dAlfG7N6QguunmSr6t5xlbmD8 P4+pi5GTQ0LARKL5+R0WCFtM4sK99WxdjFwcQgJHGSV+r+thA0kICSxnlLgwzwvEZhPQkHhy aTJYs4hAnsTmT+/ZQWxhAWuJbXuOM0PEbST+rvsEVRMm8f/EHbAaFgFVibONPYwgNq+Ar8TT re3MEMt6mSWOLv4GtoxTwEdi+p77YEWMQBd9P7UGbBCzgLjErSfzoa4WkFiy5zwzhC0q8fLx P1YIW0li0tJzrBD1+RKdDW/YIJYJSpyc+YRlAqPILCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC 18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy3MQIjKljEmyOOxgXfLI8xCjAwajEw6vg5BkixJpY VlyZe4hRmoNFSZxXs3pesJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGwoSoi7q/3jHlLV29 tNF0y+d/8jFPymWi+UtUfK1tYntflpgcydFYVvNXf+rm5hjbBrd4Fv/vB/TlNYwPXX1hrV50 0bFzQVhUv6SeTc5mg5uLrxlmbXk1O9Fsl23nhjPfdq4qvRu8hlXoXMOEVq15sW/aWHNtJE1P /d9oMcFcVW6V2suVwW5KLMUZiYZazEXFiQD3KJKjigIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/G22-W33Ygfb0UoFoOTPJJCTucZ4 Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 17:40:55 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E815eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I would, Igor. They differ in granularity, probably in security consid= erations, but not fundamentally. Thanks, Dave From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, October 24, 2014 10:38 AM To: Dave Hood; Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, I completely agree with you on the requirement that from the hierarchical S= DN point of view each provider layer must be fundamentally the same as its = client layer, so that the client can serve its own clients, and the server = can be a client of its own providers, etc. With this in mind would you agree with me that there is no fundamental diff= erence between the VNC and PNC, and between the interfaces B and C in the c= urrent ACTN architecture? Thanks, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Friday, October 24, 2014 12:18 PM To: Leeyoung; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E815eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I would, Igor. = They differ in granularity, probably in security considerations, but not fu= ndamentally.

 

Thanks,

Dave

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Friday, October 24, 2014 10:38 AM
To: Dave Hood; Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Da= ve,

=  

I com= pletely agree with you on the requirement that from the hierarchical SDN po= int of view each provider layer must be fundamentally the same as its clien= t layer, so that the client can serve its own clients, and the server can be a client of its own providers, etc.=

With = this in mind would you agree with me that there is no fundamental differenc= e between the VNC and PNC, and between the interfaces B and C in the curren= t ACTN architecture?

=  

Thank= s,

Igor<= o:p>

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Friday, October 24, 2014 12:18 PM
To: Leeyoung; actn@ietf.org
Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F53E815eusaamb105erics_-- From nobody Fri Oct 24 12:08:12 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 BED2B1A1A90 for ; Fri, 24 Oct 2014 12:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 X7MemTfyYkYx for ; Fri, 24 Oct 2014 12:07:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C141A8F46 for ; Fri, 24 Oct 2014 12:07:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKX28922; Fri, 24 Oct 2014 19:07:46 +0000 (GMT) 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; Fri, 24 Oct 2014 20:07:42 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 12:07:33 -0700 From: Leeyoung To: Dave Hood , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAEXbaA= Date: Fri, 24 Oct 2014 19:07:33 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C404C6@dfweml706-chm> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.123] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C404C6dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/FkhSsHNwaQIgNCOB_hI6EqHDXVM Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 19:08:10 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C404C6dfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks. I think we are getting there. Please see inline for my comment. This is my personal view and other folks = (especially the co-authors of the framework draft) may address their views. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Friday, October 24, 2014 11:18 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. YOUNG>> I agree with you on this in principle, but with a caveat that when = we associate roles/functions with the type of controller, there are differe= nces we begin to observe. I think devil are in the details. As I elaborated= before and also in the later point, there are two main functions that need= to be performed by VNC: (i) virtualizer; (ii) multi-domain coordination/or= chestration. For (i), we can agree that the hierarchy of controllers (CNC, = VNC, PNC) all share this in different degrees. For (ii), if we were to assu= me this would happen in VNC, then this particular role has to be defined wh= ich is different than virtualizer function. If we can agree on this, that i= s great. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? YOUNG>> Yes, we are only considering an interface view between VNC and PNC.= We concerns not what PNC does for its domain technology control. I can env= ision the following needs to be supported in this interface so that the VNC= would perform the following (Interface C in the current framework). i. Creating an end-to-end virtual network topology base= d on the feed of each domain controllers input south of the VNC (i.e., PNCs= ). ii. It computes an end-to-end path (virtual path) iii. It signals to each domain controller (PNCs) and there = might be some signaling interaction (e.g., likes of crankbacks to reroute d= ue to network condition changes associated with domain networks) After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. YOUNG>> I agree. What "PNC" does underneath (interface D) is out of the sc= ope of ACTN, this includes GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or = anything else. Only thing in scope is the interface between PNC and VNC (a= nd interface CNC and VNC, which I still think a difference interface from P= NC-VNC interface although sharing some "virtualizer" functionality) and the= protocols on those interfaces, which is TDB by the solution works down the= road. Is this what you are saying, then we are in agreement on this point. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_7AEB3D6833318045B4AE71C2C87E8E1729C404C6dfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks. I think we are= getting there.

 

Please see inline for = my comment. This is my personal view and other folks (especially the co-aut= hors of the framework draft) may address their views.

 

Thanks,

Young

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com]
Sent: Friday, October 24, 2014 11:18 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

YOUNG>> I agree with you on this in princ= iple, but with a caveat that when we associate roles/functions with the typ= e of controller, there are differences we begin to observe. I think devil are in the details. As I elaborated before and also in the lat= er point, there are two main functions that need to be performed by VNC: (i= ) virtualizer; (ii) multi-domain coordination/orchestration. For (i), we ca= n agree that the hierarchy of controllers (CNC, VNC, PNC) all share this in different degrees. For (ii), if we were = to assume this would happen in VNC, then this particular role has to be def= ined which is different than virtualizer function. If we can agree on this,= that is great.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

YOUNG>> Yes, we are only considering an i= nterface view between VNC and PNC. We concerns not what PNC does for its do= main technology control. I can envision the following needs to be supported in this interface so that the VNC would perform the following= (Interface C in the current framework).

i.      = ;            &n= bsp;  Creating an end-to-end virtual network = topology based on the feed of each domain controllers input south of the VN= C (i.e., PNCs).

ii.     &nbs= p;             It computes an end-to-end path (virtual= path)

iii.     &= nbsp;           It signals to each domain controller (P= NCs) and there might be some signaling interaction (e.g., likes of crankbac= ks to reroute due to network condition changes associated with domain networks)

 

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

YOUNG>> I agree.  What “PNC= 221; does underneath (interface D) is out of the scope of ACTN, this includ= es GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or anything else.  Onl= y thing in scope is the interface between PNC and VNC (and interface CNC and VNC, whi= ch I still think a difference interface from PNC-VNC interface although sha= ring some “virtualizer” functionality) and the protocols on tho= se interfaces, which is TDB by the solution works down the road. Is this what you are saying, then we are in agreement= on this point.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C404C6dfweml706chm_-- From nobody Fri Oct 24 12:55:58 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 F1FE11A90FF for ; Fri, 24 Oct 2014 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 Mq1KJaPoxHzu for ; Fri, 24 Oct 2014 12:55:32 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33C11A90F4 for ; Fri, 24 Oct 2014 12:55:31 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s9OJsNWp023990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 15:54:23 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 15:54:22 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1044.5; Fri, 24 Oct 2014 15:54:22 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1044.003; Fri, 24 Oct 2014 15:54:22 -0400 From: Igor Bryskin To: Leeyoung , Dave Hood , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAEXbaAABl6awA== Date: Fri, 24 Oct 2014 19:54:22 +0000 Message-ID: References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C404C6@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C404C6@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_efcedc5b2b86498ca626f22b32a52092ATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-24_06:2014-10-24,2014-10-24,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/nbI4BJEBuIqlozhNj4MKQe2zUis Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 19:55:49 -0000 --_000_efcedc5b2b86498ca626f22b32a52092ATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, Consider the following use case: a provider of abstract topology (PNC as yo= u call) does it the following way: a) For a part of said topology (a subset of abstract nodes and links) i= t provides underlay directly, that is, talks to the actual network control = (NMS, Control Plane, PCE, etc.) b) For another part it uses abstract topologies presented by its own ch= ild domain providers In this case, when a segment of service is provisioned over the domain owne= d by said PNC, it will have to perform both the PNC function and the VNC mu= lti-domain coordination for the child domains. Note that such situation can= recur at each level of the transport SDN hierarchy. This is just another indication as to why there is no difference between VN= V and PNC. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Friday, October 24, 2014 3:08 PM To: Dave Hood; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks. I think we are getting there. Please see inline for my comment. This is my personal view and other folks = (especially the co-authors of the framework draft) may address their views. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Friday, October 24, 2014 11:18 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. YOUNG>> I agree with you on this in principle, but with a caveat that when = we associate roles/functions with the type of controller, there are differe= nces we begin to observe. I think devil are in the details. As I elaborated= before and also in the later point, there are two main functions that need= to be performed by VNC: (i) virtualizer; (ii) multi-domain coordination/or= chestration. For (i), we can agree that the hierarchy of controllers (CNC, = VNC, PNC) all share this in different degrees. For (ii), if we were to assu= me this would happen in VNC, then this particular role has to be defined wh= ich is different than virtualizer function. If we can agree on this, that i= s great. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? YOUNG>> Yes, we are only considering an interface view between VNC and PNC.= We concerns not what PNC does for its domain technology control. I can env= ision the following needs to be supported in this interface so that the VNC= would perform the following (Interface C in the current framework). i. Creating an end-to-end virtual network topology based on= the feed of each domain controllers input south of the VNC (i.e., PNCs). ii. It computes an end-to-end path (virtual path) iii. It signals to each domain controller (PNCs) and there mig= ht be some signaling interaction (e.g., likes of crankbacks to reroute due = to network condition changes associated with domain networks) After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. YOUNG>> I agree. What "PNC" does underneath (interface D) is out of the sc= ope of ACTN, this includes GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or = anything else. Only thing in scope is the interface between PNC and VNC (a= nd interface CNC and VNC, which I still think a difference interface from P= NC-VNC interface although sharing some "virtualizer" functionality) and the= protocols on those interfaces, which is TDB by the solution works down the= road. Is this what you are saying, then we are in agreement on this point. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_efcedc5b2b86498ca626f22b32a52092ATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yo= ung,

Consi= der the following use case: a provider of abstract topology (PNC as you cal= l) does it the following way:

a)     For a part of said topology (a subset of abstract nodes and links) it pr= ovides underlay directly, that is, talks to the actual network control (NMS= , Control Plane, PCE, etc.)

b)     For another part it uses abstract topologies presented by its own child = domain providers

=  

In th= is case, when a segment of service is provisioned over the domain owned by = said PNC, it will have to perform both the PNC function and the VNC multi-d= omain coordination for the child domains. Note that such situation can recur at each level of the transport SDN hier= archy.

This = is just another indication as to why there is no difference between VNV and= PNC.

=  

Cheer= s,

Igor<= o:p>

=  

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of Leeyoung
Sent: Friday, October 24, 2014 3:08 PM
To: Dave Hood; actn@ietf.org
Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks. I think we are= getting there.

 

Please see inline for = my comment. This is my personal view and other folks (especially the co-aut= hors of the framework draft) may address their views.

 

Thanks,

Young

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Friday, October 24, 2014 11:18 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

YOUNG>> I agree with you on this in princ= iple, but with a caveat that when we associate roles/functions with the typ= e of controller, there are differences we begin to observe. I think devil are in the details. As I elaborated before and also in the lat= er point, there are two main functions that need to be performed by VNC: (i= ) virtualizer; (ii) multi-domain coordination/orchestration. For (i), we ca= n agree that the hierarchy of controllers (CNC, VNC, PNC) all share this in different degrees. For (ii), if we were = to assume this would happen in VNC, then this particular role has to be def= ined which is different than virtualizer function. If we can agree on this,= that is great.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

YOUNG>> Yes, we are only considering an i= nterface view between VNC and PNC. We concerns not what PNC does for its do= main technology control. I can envision the following needs to be supported in this interface so that the VNC would perform the following= (Interface C in the current framework).

i.      = ;           Creating an end-to-end virtual network = topology based on the feed of each domain controllers input south of the VN= C (i.e., PNCs).

ii.     &nbs= p;          It computes an end-to-end path (virtual= path)

iii.     &= nbsp;        It signals to each domain controller (P= NCs) and there might be some signaling interaction (e.g., likes of crankbac= ks to reroute due to network condition changes associated with domain networks)

 

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

YOUNG>> I agree.  What “PNC= 221; does underneath (interface D) is out of the scope of ACTN, this includ= es GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or anything else.  Onl= y thing in scope is the interface between PNC and VNC (and interface CNC and VNC, whi= ch I still think a difference interface from PNC-VNC interface although sha= ring some “virtualizer” functionality) and the protocols on tho= se interfaces, which is TDB by the solution works down the road. Is this what you are saying, then we are in agreement= on this point.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_efcedc5b2b86498ca626f22b32a52092ATLSRVMBX1advaopticalco_-- From nobody Fri Oct 24 13:16:34 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 5DA961A0A6A for ; Fri, 24 Oct 2014 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mNMKUP3vBuSj for ; Fri, 24 Oct 2014 13:16:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649531A0248 for ; Fri, 24 Oct 2014 13:16:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKX31720; Fri, 24 Oct 2014 20:16:20 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Oct 2014 21:16:18 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 13:16:10 -0700 From: Leeyoung To: Igor Bryskin , Dave Hood , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAEXbaAABl6awAAAtgLg Date: Fri, 24 Oct 2014 20:16:09 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C40548@dfweml706-chm> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C404C6@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.123] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C40548dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/r3rR5ETL5VSLLgf2XtuMoM7Uifw Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 20:16:32 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C40548dfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, I would say we need to associate the role of the controller. I can see from= your example multi-domain coordination (let say the function is called 'md= ') can take place either VNC or PNC, or both. - If we were to place the 'md' funtion at VNC (which is a typical = case in the framework), we need to say it as VNC-md; - if we were to place this at PNC (in your example), we need to sa= y the PNC has two roles: for the direct controlled network control, it is P= NC; for child VNs' control, it is VNC-md. I think as Dave suggested, once we attach the role of the controller with i= ts name, then things begin to shed more light. Regards, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, October 24, 2014 2:54 PM To: Leeyoung; Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Young, Consider the following use case: a provider of abstract topology (PNC as yo= u call) does it the following way: a) For a part of said topology (a subset of abstract nodes and links) i= t provides underlay directly, that is, talks to the actual network control = (NMS, Control Plane, PCE, etc.) b) For another part it uses abstract topologies presented by its own ch= ild domain providers In this case, when a segment of service is provisioned over the domain owne= d by said PNC, it will have to perform both the PNC function and the VNC mu= lti-domain coordination for the child domains. Note that such situation can= recur at each level of the transport SDN hierarchy. This is just another indication as to why there is no difference between VN= V and PNC. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Friday, October 24, 2014 3:08 PM To: Dave Hood; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks. I think we are getting there. Please see inline for my comment. This is my personal view and other folks = (especially the co-authors of the framework draft) may address their views. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Friday, October 24, 2014 11:18 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. YOUNG>> I agree with you on this in principle, but with a caveat that when = we associate roles/functions with the type of controller, there are differe= nces we begin to observe. I think devil are in the details. As I elaborated= before and also in the later point, there are two main functions that need= to be performed by VNC: (i) virtualizer; (ii) multi-domain coordination/or= chestration. For (i), we can agree that the hierarchy of controllers (CNC, = VNC, PNC) all share this in different degrees. For (ii), if we were to assu= me this would happen in VNC, then this particular role has to be defined wh= ich is different than virtualizer function. If we can agree on this, that i= s great. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? YOUNG>> Yes, we are only considering an interface view between VNC and PNC.= We concerns not what PNC does for its domain technology control. I can env= ision the following needs to be supported in this interface so that the VNC= would perform the following (Interface C in the current framework). i. Creating an end-to-end virtual network topology based on= the feed of each domain controllers input south of the VNC (i.e., PNCs). ii. It computes an end-to-end path (virtual path) iii. It signals to each domain controller (PNCs) and there mig= ht be some signaling interaction (e.g., likes of crankbacks to reroute due = to network condition changes associated with domain networks) After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. YOUNG>> I agree. What "PNC" does underneath (interface D) is out of the sc= ope of ACTN, this includes GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or = anything else. Only thing in scope is the interface between PNC and VNC (a= nd interface CNC and VNC, which I still think a difference interface from P= NC-VNC interface although sharing some "virtualizer" functionality) and the= protocols on those interfaces, which is TDB by the solution works down the= road. Is this what you are saying, then we are in agreement on this point. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_7AEB3D6833318045B4AE71C2C87E8E1729C40548dfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

I would say we need to= associate the role of the controller. I can see from your example multi-do= main coordination (let say the function is called ‘md’) can tak= e place either VNC or PNC, or both.

 

-&nb= sp;         If we were to = place the ‘md’ funtion at VNC (which is a typical case in the f= ramework), we need to say it as VNC-md;

-&nb= sp;         if we were to = place this at PNC (in your example), we need to say the PNC has two roles: = for the direct controlled network control, it is PNC; for child VNs’ = control, it is VNC-md.  

 

I think as Dave sugges= ted, once we attach the role of the controller with its name, then things b= egin to shed more light.

 

Regards,

Young

 

From: Igor Bry= skin [mailto:IBryskin@advaoptical.com]
Sent: Friday, October 24, 2014 2:54 PM
To: Leeyoung; Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Yo= ung,

Consi= der the following use case: a provider of abstract topology (PNC as you cal= l) does it the following way:

a) =     For a part of said to= pology (a subset of abstract nodes and links) it provides underlay directly= , that is, talks to the actual network control (NMS, Control Plane, PCE, et= c.)

b) =     For another part it u= ses abstract topologies presented by its own child domain providers

=  

In th= is case, when a segment of service is provisioned over the domain owned by = said PNC, it will have to perform both the PNC function and the VNC multi-d= omain coordination for the child domains. Note that such situation can recur at each level of the transport SDN hier= archy.

This = is just another indication as to why there is no difference between VNV and= PNC.

=  

Cheer= s,

Igor<= o:p>

=  

From: ACTN [mailto:actn-bounces@ietf.org] = On Behalf Of Leeyoung
Sent: Friday, October 24, 2014 3:08 PM
To: Dave Hood; actn@ietf.org
Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks. I think we are= getting there.

 

Please see inline for = my comment. This is my personal view and other folks (especially the co-aut= hors of the framework draft) may address their views.

 

Thanks,

Young

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Friday, October 24, 2014 11:18 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

YOUNG>> I agree with you on this in princ= iple, but with a caveat that when we associate roles/functions with the typ= e of controller, there are differences we begin to observe. I think devil are in the details. As I elaborated before and also in the lat= er point, there are two main functions that need to be performed by VNC: (i= ) virtualizer; (ii) multi-domain coordination/orchestration. For (i), we ca= n agree that the hierarchy of controllers (CNC, VNC, PNC) all share this in different degrees. For (ii), if we were = to assume this would happen in VNC, then this particular role has to be def= ined which is different than virtualizer function. If we can agree on this,= that is great.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

YOUNG>> Yes, we are only considering an i= nterface view between VNC and PNC. We concerns not what PNC does for its do= main technology control. I can envision the following needs to be supported in this interface so that the VNC would perform the following= (Interface C in the current framework).

i.     &= nbsp;           Creating an end-to-end virtual network topology based on the fe= ed of each domain controllers input south of the VNC (i.e., PNCs).

ii.     =            It computes an end-to-end path (virtual path)

iii.     = ;         It signals to each domain controller (PNCs) and there might be = some signaling interaction (e.g., likes of crankbacks to reroute due to net= work condition changes associated with domain networks)

 

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

YOUNG>> I agree.  What “PNC= 221; does underneath (interface D) is out of the scope of ACTN, this includ= es GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or anything else.  Onl= y thing in scope is the interface between PNC and VNC (and interface CNC and VNC, whi= ch I still think a difference interface from PNC-VNC interface although sha= ring some “virtualizer” functionality) and the protocols on tho= se interfaces, which is TDB by the solution works down the road. Is this what you are saying, then we are in agreement= on this point.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C40548dfweml706chm_-- From nobody Fri Oct 24 13:42:21 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 770C71A9116 for ; Fri, 24 Oct 2014 13:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7V0mUDVUKxhH for ; Fri, 24 Oct 2014 13:42:08 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F131A0231 for ; Fri, 24 Oct 2014 13:42:08 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-63-544a5f73301f Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3B.66.25146.37F5A445; Fri, 24 Oct 2014 16:17:23 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 16:42:05 -0400 From: Dave Hood To: Leeyoung , Igor Bryskin , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAEXbaAABl6awAAAtgLgAAFz3nA= Date: Fri, 24 Oct 2014 20:42:05 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F53EF87@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C404C6@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C40548@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C40548@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F53EF87eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPlG5xvFeIQXujqcWWngtsFqd62hkt ps1zdWD2OLvgD6tHy5G3rB5LlvxkCmCO4rJJSc3JLEst0rdL4Mq49O0mY8HGc8wV7z+LNjCu n8DcxcjBISFgIrGgRaGLkRPIFJO4cG89WxcjF4eQwFFGiZt9fxkhnOWMEr17bzKBVLEJaEg8 uTQZzBYRyJNY8XA1C4gtLGAtsW3PcWaIuI3E33WfoGqSJB7cPskKYrMIqEos2/MdrIZXwFfi zYLlTBALmlkkVq2YwwiS4BRwldh0tB/MZgQ66fupNWCDmAXEJW49mc8EcaqAxJI955khbFGJ l4//sULYShKTlp5jhajPl3j3bj3UMkGJkzOfsExgFJmFZNQsJGWzkJRBxHUkFuz+xAZha0ss W/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnpRoabGIExdUyCzXEH44JPlocYBTgYlXh4FZw8Q4RY E8uKK3MPMUpzsCiJ82pWzwsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiw9sBZsbP35Evf MNo1SFawGrt1WV5pOaORqdIx+UlvkP++h5O3p/iuklW7sbrx20HHHUdN9SoWfJuQtTZsocXB JzNKcx32TXZ8s8ek+KUe65nZiskrS69nyMepTTq8+PqMSLWoNMbTr/4HXwnYZ1X6e1ayVS63 qcr/GTn3fp57fTPPdptByQ4lluKMREMt5qLiRAC9sTv+igIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/PJxQjrULaZ8U0YQgLQ4Q6Nt8Pdo Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 20:42:19 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53EF87eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, yes, we can multiply the granularity of the designations as much as w= e care to; the question is whether it is productive. In a previous exchange, I pointed out that domain is not well-defined; I be= lieve you use the term in the sense of network ownership/control. In that s= ense, I agree that the final lowest controller before the iron needs to be = in the same admin domain as the iron itself. But the SDN architecture just = regards same-domain as a special case of multi-domain. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 1:16 PM To: Igor Bryskin; Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Igor, I would say we need to associate the role of the controller. I can see from= your example multi-domain coordination (let say the function is called 'md= ') can take place either VNC or PNC, or both. - If we were to place the 'md' funtion at VNC (which is a typical = case in the framework), we need to say it as VNC-md; - if we were to place this at PNC (in your example), we need to sa= y the PNC has two roles: for the direct controlled network control, it is P= NC; for child VNs' control, it is VNC-md. I think as Dave suggested, once we attach the role of the controller with i= ts name, then things begin to shed more light. Regards, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, October 24, 2014 2:54 PM To: Leeyoung; Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Young, Consider the following use case: a provider of abstract topology (PNC as yo= u call) does it the following way: a) For a part of said topology (a subset of abstract nodes and links) i= t provides underlay directly, that is, talks to the actual network control = (NMS, Control Plane, PCE, etc.) b) For another part it uses abstract topologies presented by its own ch= ild domain providers In this case, when a segment of service is provisioned over the domain owne= d by said PNC, it will have to perform both the PNC function and the VNC mu= lti-domain coordination for the child domains. Note that such situation can= recur at each level of the transport SDN hierarchy. This is just another indication as to why there is no difference between VN= V and PNC. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Friday, October 24, 2014 3:08 PM To: Dave Hood; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks. I think we are getting there. Please see inline for my comment. This is my personal view and other folks = (especially the co-authors of the framework draft) may address their views. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Friday, October 24, 2014 11:18 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. YOUNG>> I agree with you on this in principle, but with a caveat that when = we associate roles/functions with the type of controller, there are differe= nces we begin to observe. I think devil are in the details. As I elaborated= before and also in the later point, there are two main functions that need= to be performed by VNC: (i) virtualizer; (ii) multi-domain coordination/or= chestration. For (i), we can agree that the hierarchy of controllers (CNC, = VNC, PNC) all share this in different degrees. For (ii), if we were to assu= me this would happen in VNC, then this particular role has to be defined wh= ich is different than virtualizer function. If we can agree on this, that i= s great. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? YOUNG>> Yes, we are only considering an interface view between VNC and PNC.= We concerns not what PNC does for its domain technology control. I can env= ision the following needs to be supported in this interface so that the VNC= would perform the following (Interface C in the current framework). i. Creating an end-to-end virtual network topology based on= the feed of each domain controllers input south of the VNC (i.e., PNCs). ii. It computes an end-to-end path (virtual path) iii. It signals to each domain controller (PNCs) and there mig= ht be some signaling interaction (e.g., likes of crankbacks to reroute due = to network condition changes associated with domain networks) After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. YOUNG>> I agree. What "PNC" does underneath (interface D) is out of the sc= ope of ACTN, this includes GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or = anything else. Only thing in scope is the interface between PNC and VNC (a= nd interface CNC and VNC, which I still think a difference interface from P= NC-VNC interface although sharing some "virtualizer" functionality) and the= protocols on those interfaces, which is TDB by the solution works down the= road. Is this what you are saying, then we are in agreement on this point. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F53EF87eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, yes, we can mu= ltiply the granularity of the designations as much as we care to; the quest= ion is whether it is productive.

 

In a previous exchan= ge, I pointed out that domain is not well-defined; I believe you use the te= rm in the sense of network ownership/control. In that sense, I agree that the final lowest controller before the iron needs to be in th= e same admin domain as the iron itself. But the SDN architecture just regar= ds same-domain as a special case of multi-domain.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 1:16 PM
To: Igor Bryskin; Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Igor,

 

I would say we need to= associate the role of the controller. I can see from your example multi-do= main coordination (let say the function is called ‘md’) can tak= e place either VNC or PNC, or both.

 

-&nb= sp;         If we were to = place the ‘md’ funtion at VNC (which is a typical case in the f= ramework), we need to say it as VNC-md;

-&nb= sp;         if we were to = place this at PNC (in your example), we need to say the PNC has two roles: = for the direct controlled network control, it is PNC; for child VNs’ = control, it is VNC-md.  

 

I think as Dave sugges= ted, once we attach the role of the controller with its name, then things b= egin to shed more light.

 

Regards,

Young

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, October 24, 2014 2:54 PM
To: Leeyoung; Dave Hood; actn@ietf.= org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Yo= ung,

Consi= der the following use case: a provider of abstract topology (PNC as you cal= l) does it the following way:

a) =     For a part of said to= pology (a subset of abstract nodes and links) it provides underlay directly= , that is, talks to the actual network control (NMS, Control Plane, PCE, et= c.)

b) =     For another part it u= ses abstract topologies presented by its own child domain providers

=  

In th= is case, when a segment of service is provisioned over the domain owned by = said PNC, it will have to perform both the PNC function and the VNC multi-d= omain coordination for the child domains. Note that such situation can recur at each level of the transport SDN hier= archy.

This = is just another indication as to why there is no difference between VNV and= PNC.

=  

Cheer= s,

Igor<= o:p>

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Friday, October 24, 2014 3:08 PM
To: Dave Hood; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks. I think we are= getting there.

 

Please see inline for = my comment. This is my personal view and other folks (especially the co-aut= hors of the framework draft) may address their views.

 

Thanks,

Young

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Friday, October 24, 2014 11:18 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

YOUNG>> I agree with you on this in princ= iple, but with a caveat that when we associate roles/functions with the typ= e of controller, there are differences we begin to observe. I think devil are in the details. As I elaborated before and also in the lat= er point, there are two main functions that need to be performed by VNC: (i= ) virtualizer; (ii) multi-domain coordination/orchestration. For (i), we ca= n agree that the hierarchy of controllers (CNC, VNC, PNC) all share this in different degrees. For (ii), if we were = to assume this would happen in VNC, then this particular role has to be def= ined which is different than virtualizer function. If we can agree on this,= that is great.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

YOUNG>> Yes, we are only considering an i= nterface view between VNC and PNC. We concerns not what PNC does for its do= main technology control. I can envision the following needs to be supported in this interface so that the VNC would perform the following= (Interface C in the current framework).

i.     &= nbsp;           Creating an end-to-end virtual network topology based on the fe= ed of each domain controllers input south of the VNC (i.e., PNCs).

ii.     =            It computes an end-to-end path (virtual path)

iii.     = ;         It signals to each domain controller (PNCs) and there might be = some signaling interaction (e.g., likes of crankbacks to reroute due to net= work condition changes associated with domain networks)

 

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

YOUNG>> I agree.  What “PNC= 221; does underneath (interface D) is out of the scope of ACTN, this includ= es GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or anything else.  Onl= y thing in scope is the interface between PNC and VNC (and interface CNC and VNC, whi= ch I still think a difference interface from PNC-VNC interface although sha= ring some “virtualizer” functionality) and the protocols on tho= se interfaces, which is TDB by the solution works down the road. Is this what you are saying, then we are in agreement= on this point.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F53EF87eusaamb105erics_-- From nobody Fri Oct 24 13:55:24 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 6728F1A0231 for ; Fri, 24 Oct 2014 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TlJlmjS3_wcq for ; Fri, 24 Oct 2014 13:55:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77F31A19EC for ; Fri, 24 Oct 2014 13:55:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKX33261; Fri, 24 Oct 2014 20:55:05 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Oct 2014 21:55:04 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 13:54:57 -0700 From: Leeyoung To: Dave Hood , Igor Bryskin , "actn@ietf.org" Thread-Topic: Comments on draft-ceccarelli-actn-framework-04 Thread-Index: Ac/tbea1DOR7hvbLT6q34yEim3G4lQA8lxLgAByrSPAAMwBfkAABRejgAAEXbaAABl6awAAAtgLgAAFz3nAAADhMAA== Date: Fri, 24 Oct 2014 20:54:56 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C40626@dfweml706-chm> References: <8D15A2BAF93E9C49AB037A0647E5FA643F538AEA@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C3FD8B@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53C349@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C403EF@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53E408@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C404C6@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C40548@dfweml706-chm> <8D15A2BAF93E9C49AB037A0647E5FA643F53EF87@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F53EF87@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.123] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C40626dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/VsfjGB_bx9zAwJ0BJSIw9Oc--jA Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 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, 24 Oct 2014 20:55:19 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C40626dfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your time to iron out many items in this thread. Well, I think = we have reached an agreement. We can always start with a base model to prod= uce something useful quickly, then think about variations later. It looks like terms need to be defined more clearly like domain, physical = control, virtual control, multi-domain coordination, etc. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Friday, October 24, 2014 3:42 PM To: Leeyoung; Igor Bryskin; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Well, yes, we can multiply the granularity of the designations as much as w= e care to; the question is whether it is productive. In a previous exchange, I pointed out that domain is not well-defined; I be= lieve you use the term in the sense of network ownership/control. In that s= ense, I agree that the final lowest controller before the iron needs to be = in the same admin domain as the iron itself. But the SDN architecture just = regards same-domain as a special case of multi-domain. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 1:16 PM To: Igor Bryskin; Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Igor, I would say we need to associate the role of the controller. I can see from= your example multi-domain coordination (let say the function is called 'md= ') can take place either VNC or PNC, or both. - If we were to place the 'md' funtion at VNC (which is a typical = case in the framework), we need to say it as VNC-md; - if we were to place this at PNC (in your example), we need to sa= y the PNC has two roles: for the direct controlled network control, it is P= NC; for child VNs' control, it is VNC-md. I think as Dave suggested, once we attach the role of the controller with i= ts name, then things begin to shed more light. Regards, Young From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Friday, October 24, 2014 2:54 PM To: Leeyoung; Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Young, Consider the following use case: a provider of abstract topology (PNC as yo= u call) does it the following way: a) For a part of said topology (a subset of abstract nodes and links) i= t provides underlay directly, that is, talks to the actual network control = (NMS, Control Plane, PCE, etc.) b) For another part it uses abstract topologies presented by its own ch= ild domain providers In this case, when a segment of service is provisioned over the domain owne= d by said PNC, it will have to perform both the PNC function and the VNC mu= lti-domain coordination for the child domains. Note that such situation can= recur at each level of the transport SDN hierarchy. This is just another indication as to why there is no difference between VN= V and PNC. Cheers, Igor From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Friday, October 24, 2014 3:08 PM To: Dave Hood; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks. I think we are getting there. Please see inline for my comment. This is my personal view and other folks = (especially the co-authors of the framework draft) may address their views. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Friday, October 24, 2014 11:18 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. Try the following proposal to see if it aligns our perspecti= ves: For either hierarchy or recursion, as used here, we need each successive la= yer to be fundamentally of the same type as the one above/below it, likewis= e for the interfaces. That's why the SDN architecture calls all of them SDN= controllers, and all of the interfaces CPIs (controller plane interfaces). I think we can align our views by introducing roles. The SDN architecture i= magines that we take the perspective of some given SDN controller, from whi= ch we see a (virtual) data plane to our south and a (virtual) applications = plane to our north. YOUNG>> I agree with you on this in principle, but with a caveat that when = we associate roles/functions with the type of controller, there are differe= nces we begin to observe. I think devil are in the details. As I elaborated= before and also in the later point, there are two main functions that need= to be performed by VNC: (i) virtualizer; (ii) multi-domain coordination/or= chestration. For (i), we can agree that the hierarchy of controllers (CNC, = VNC, PNC) all share this in different degrees. For (ii), if we were to assu= me this would happen in VNC, then this particular role has to be defined wh= ich is different than virtualizer function. If we can agree on this, that i= s great. >From the discussion on this thread, I think the ACTN framework steps outsid= e one particular SDN controller, and instead stands on the boundary between= a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications n= orth of the VNC; would it make sense to minimize the discussion of physical= functions further south of the PNC? YOUNG>> Yes, we are only considering an interface view between VNC and PNC.= We concerns not what PNC does for its domain technology control. I can env= ision the following needs to be supported in this interface so that the VNC= would perform the following (Interface C in the current framework). i. Creating an end-to-end virtual network topology based on= the feed of each domain controllers input south of the VNC (i.e., PNCs). ii. It computes an end-to-end path (virtual path) iii. It signals to each domain controller (PNCs) and there mig= ht be some signaling interaction (e.g., likes of crankbacks to reroute due = to network condition changes associated with domain networks) After all, if we really insist that the PNC talk to iron, we necessarily ca= re about boxes and circuit packs, redundant cooling shelves and power feeds= , hardware failure and repair, software upgrade.... If these are out of sco= pe for ACTN, and I believe they are, then we shouldn't really care whether = there is iron down there or a virtual network. YOUNG>> I agree. What "PNC" does underneath (interface D) is out of the sc= ope of ACTN, this includes GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or = anything else. Only thing in scope is the interface between PNC and VNC (a= nd interface CNC and VNC, which I still think a difference interface from P= NC-VNC interface although sharing some "virtualizer" functionality) and the= protocols on those interfaces, which is TDB by the solution works down the= road. Is this what you are saying, then we are in agreement on this point. What do you think? Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, October 24, 2014 8:58 AM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for your further comments. I found this thread very helpful to clari= fy different perspectives and some misunderstanding. The three-tier control hierarchy discussed in the ACTN framework is "zoomin= g" on the relationships across three entities (CNC, VNC, PNC). This does no= t necessarily limit that is above and below these entities. There may be ot= her hierarchy especially under PNCs. From this, I see neither contradiction= with nor reinventing the wheel of the notion of "recursive" relationships= among the controllers, which is one of the main points in your SDN archite= cture document. We used the term "hierarchy" (instead of "recursion") notin= g that there is a certain recursive nature in modeling abstraction while sp= ecifying some functional differences among the three-tier controllers. Your SDN architecture specifies a PCE function in each control layer, which= is also very consistent with ACTN framework. We might need further termino= logy alignment to avoid misunderstanding. In regards to controller name, as Daniele suggested we are open to rename t= hem if necessary. Igor has some idea as well on this. CNC, VNC and PNC are = tied with some control functions. We can continue to work on this. Perhaps = for IETF 91, we would stay with these terms and later if the work is warran= ted, we can revisit this issue. Please see inline for my responses. Thanks, Young From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Thursday, October 23, 2014 10:14 AM To: Leeyoung; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Thanks, Young. A couple of responses: The suggested SDN architecture that was developed in ONF includes the possi= bility that layers at either the top or bottom of the stack can be non-SDN = environments. An EMS or an NMS could equally support a classical environmen= t, supporting SDN interfaces on their north sides. Incremental deployment i= s certainly necessary, no question about it. YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain co= ntrol/management entity and with an added function to support "interface C"= , NMS/EMS can be empowered to participate in virtualization regime. 80% of = transport networks are controlled/managed by NMS/EMS today and enabling the= m with network virtualization layer/function is one of the key requirements= from operators. As to the ONF SDN architecture suggestion, be clear that there is no questi= on of demanding that anyone accept any particular input. The point was to c= all attention to existing work that can help avoid reinvention of wheels, t= o the purpose of adding new value to the discussion. YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN = architecture. I think by now many issues we discussed (e.g., hierarchy vs. = recursiveness; pce function in each control layer, etc) are more or less al= igned rather than being contradictory or re-inventing. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, October 22, 2014 7:34 PM To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04 Hi Dave, Thanks for providing your perspective. Please see in-line for my comment. Best regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Tuesday, October 21, 2014 5:44 PM To: actn@ietf.org Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04 I shared several comments on the new draft with the editors, but a few of t= hem are more than editorial, so I'm posting them for wider discussion. Operators have been trying to break silos for decades. It is okay to specia= lize the SDN architecture into a unique transport view, but we ought not cr= eate separate concepts, interfaces, or terminology unless there are strong = justifications to depart from other domains. We should make best efforts to= integrate transport SDN views seamlessly into the rest of the SDN space. W= e do not want to re-create silos in the SDN world. YOUNG>> I think you are talking about SDN from a green field perspective. T= -SDN could mean different things to different set of people including diffe= rent SDOs. It seems to me that you are prescribing ONF SDN view as the basi= s of discussion here. I respect ONF view, especially your SDN architecture = document produced mid this year. On the other hand, there are different vie= ws of what T-SDN means in other parts of the world. Therefore I think it wo= uld be a bit over bearing to demand other views to be subjected to one view= . Having said that, it is of course always the operator's option to deploy SD= N in separate technology silos according to its own practices. The architec= ture is general, but can be specialized in any number of particular ways. YOUNG>> Agree. Operators want to build on top of what they have deployed wh= ile pursuing new green field. One of the drivers for ACTN is to enable lega= cy control/management domains while allowing new domain control like ONF SD= N (openflow) control. An example of specialization is the proposed 3-tier model, in which hierarc= hy or recursion appears to be restricted to the VNC layer. Architecturally,= stacking is valid in any layer, and even the layer classification is to so= me extent pragmatic for each given instance. In the transport network, supp= ose we have a PNC, some of whose endpoints are tunneled ports provided by a= yet lower layer of SDN. In such a case, the same controller would act as a= PNC toward some of its resources, and a VNC toward others. (Necessarily VN= C because I'm told offline that only a VNC can span admin domains.) These d= istinctions do not seem like a useful rathole to enter. The controllers at = different levels differ in granularity and scope, but not in fundamentals; = better just to call them all SDN controllers. YOUNG>> I think there was a misunderstanding. In your particular example, i= f a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be a= nother hierarchy below that PNC. PNC may have several domains in itself and= indeed that PNC might function as a multi-domain coordination underneath i= ts control domain. So here we are not restricting what PNC does in its netw= ork control. This does not simply need not be known to what is above the PN= C. Each PNC represents a control of some network comprising an end to end n= etwork. It can be a single domain control or control multi domain. SDN cont= roller is one of the PNC in ACTN architecture. There may be other controlle= rs such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control. The framework suggests that the PCE lives in the PNC. Even if we assume a s= ingle well-defined PNC layer, this denies the more abstract layers the abil= ity to compute paths in their virtual networks. Note that paths in VNs are = constrained by the VN definition, and the PNC PCE has no way of knowing wha= t those constraints are. This is especially true if the VN is exported acro= ss a business boundary to a customer whose VN may be complex enough to just= ify its own PCE. I believe PCE is intended to be available at multiple leve= ls of virtualization: let it be available to anyone who needs it. YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. = Perhaps, there needs more clarification in the document. We used PCE means = to what PCE does in TE network control (as part of PNC), but in VNC we have= resource manager (which needs to compute paths based on virtual networks),= likewise CNC where customers want to compute their paths within the confin= es of VNs allocated to them. Arguably the major issue with the draft is that it does not recognize the i= mportance of the manager actor in the provider-customer relationship. The S= DN architecture explains that the provider's manager is necessarily respons= ible for creating a virtual network environment for the customer and for in= stalling policy in its SDN controller (at whatever hierarchical level) to b= oth protect the customer from other customers (privacy and QoS) and to prot= ect the provider's own resources from customer misbehaviour, whether intent= ional or otherwise. In particular, the draft refers to the customer app cre= ating VNs, whereas a customer cannot be trusted to create its own VN except= perhaps as a mere subnet of the "real" VN created under the auspices of a = business negotiation by the provider's manager. (And yes, the SDN architect= ure also describes how all of this can be done flexibly, for example if the= customer invokes a service provisioning portal with credentials that permi= t billing.) YOUNG>> Good point. This is one of the areas where ACTN needs to work on mo= re. Your contribution is welcome for this. Completeness, common concepts, interfaces and terminology could all be faci= litated by starting with the umbrella SDN architecture available at https:/= /www.opennetworking.org/images/stories/downloads/sdn-resources/technical-re= ports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it. YOUNG>> Good reference, I have to say, which the latest version included as= one of the references. Dave --_000_7AEB3D6833318045B4AE71C2C87E8E1729C40626dfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for your time t= o iron out many items in this thread.  Well, I think we have reached a= n agreement. We can always start with a base model to produce something use= ful quickly, then think about variations later.  

 

It looks  like te= rms need to be defined more clearly like domain, physical control, virtual = control, multi-domain coordination, etc.

 

Thanks,

Young

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com]
Sent: Friday, October 24, 2014 3:42 PM
To: Leeyoung; Igor Bryskin; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Well, yes, we can mu= ltiply the granularity of the designations as much as we care to; the quest= ion is whether it is productive.

 

In a previous exchan= ge, I pointed out that domain is not well-defined; I believe you use the te= rm in the sense of network ownership/control. In that sense, I agree that the final lowest controller before the iron needs to be in th= e same admin domain as the iron itself. But the SDN architecture just regar= ds same-domain as a special case of multi-domain.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 1:16 PM
To: Igor Bryskin; Dave Hood; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Igor,

 

I would say we need to= associate the role of the controller. I can see from your example multi-do= main coordination (let say the function is called ‘md’) can tak= e place either VNC or PNC, or both.

 

-&nb= sp;         If we were to = place the ‘md’ funtion at VNC (which is a typical case in the f= ramework), we need to say it as VNC-md;

-&nb= sp;         if we were to = place this at PNC (in your example), we need to say the PNC has two roles: = for the direct controlled network control, it is PNC; for child VNs’ = control, it is VNC-md.  

 

I think as Dave sugges= ted, once we attach the role of the controller with its name, then things b= egin to shed more light.

 

Regards,

Young

 

From: Igor Bry= skin [mailto:IBryskin@advaoptic= al.com]
Sent: Friday, October 24, 2014 2:54 PM
To: Leeyoung; Dave Hood; actn@ietf.= org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Yo= ung,

Consi= der the following use case: a provider of abstract topology (PNC as you cal= l) does it the following way:

a) =     For a part of said to= pology (a subset of abstract nodes and links) it provides underlay directly= , that is, talks to the actual network control (NMS, Control Plane, PCE, et= c.)

b) =     For another part it u= ses abstract topologies presented by its own child domain providers

=  

In th= is case, when a segment of service is provisioned over the domain owned by = said PNC, it will have to perform both the PNC function and the VNC multi-d= omain coordination for the child domains. Note that such situation can recur at each level of the transport SDN hier= archy.

This = is just another indication as to why there is no difference between VNV and= PNC.

=  

Cheer= s,

Igor<= o:p>

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Friday, October 24, 2014 3:08 PM
To: Dave Hood; actn@ietf.org Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks. I think we are= getting there.

 

Please see inline for = my comment. This is my personal view and other folks (especially the co-aut= hors of the framework draft) may address their views.

 

Thanks,

Young

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Friday, October 24, 2014 11:18 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. Try t= he following proposal to see if it aligns our perspectives:

 

For either hierarchy= or recursion, as used here, we need each successive layer to be fundamenta= lly of the same type as the one above/below it, likewise for the interfaces. That’s why the SDN architecture calls all of the= m SDN controllers, and all of the interfaces CPIs (controller plane interfa= ces).

 

I think we can align= our views by introducing roles. The SDN architecture imagines that we take= the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications pl= ane to our north.

 

YOUNG>> I agree with you on this in princ= iple, but with a caveat that when we associate roles/functions with the typ= e of controller, there are differences we begin to observe. I think devil are in the details. As I elaborated before and also in the lat= er point, there are two main functions that need to be performed by VNC: (i= ) virtualizer; (ii) multi-domain coordination/orchestration. For (i), we ca= n agree that the hierarchy of controllers (CNC, VNC, PNC) all share this in different degrees. For (ii), if we were = to assume this would happen in VNC, then this particular role has to be def= ined which is different than virtualizer function. If we can agree on this,= that is great.

 

From the discussion = on this thread, I think the ACTN framework steps outside one particular SDN= controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the o= ther of which plays the role VNC. If we think of it as a boundary or an int= erface view, we have reduced visibility, maybe no visibility, of what happe= ns further down or further up. We already omit discussion of applications north of the VNC; would it make se= nse to minimize the discussion of physical functions further south of the P= NC?

 

YOUNG>> Yes, we are only considering an i= nterface view between VNC and PNC. We concerns not what PNC does for its do= main technology control. I can envision the following needs to be supported in this interface so that the VNC would perform the following= (Interface C in the current framework).

i.     &= nbsp;           Creating an end-to-end virtual network topology based on the fe= ed of each domain controllers input south of the VNC (i.e., PNCs).

ii.     =            It computes an end-to-end path (virtual path)

iii.     = ;         It signals to each domain controller (PNCs) and there might be = some signaling interaction (e.g., likes of crankbacks to reroute due to net= work condition changes associated with domain networks)

 

 

After all, if we rea= lly insist that the PNC talk to iron, we necessarily care about boxes and c= ircuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade…. If these are out of = scope for ACTN, and I believe they are, then we shouldn’t really care= whether there is iron down there or a virtual network.

 

YOUNG>> I agree.  What “PNC= 221; does underneath (interface D) is out of the scope of ACTN, this includ= es GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or anything else.  Onl= y thing in scope is the interface between PNC and VNC (and interface CNC and VNC, whi= ch I still think a difference interface from PNC-VNC interface although sha= ring some “virtualizer” functionality) and the protocols on tho= se interfaces, which is TDB by the solution works down the road. Is this what you are saying, then we are in agreement= on this point.

 

What do you think?

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for your furthe= r comments. I found this thread very helpful to clarify different perspecti= ves and some misunderstanding.

 

The three-tier control= hierarchy discussed in the ACTN framework is “zooming” on the = relationships across three entities (CNC, VNC, PNC). This does not necessar= ily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neith= er contradiction with nor reinventing the wheel of the notion of  R= 20;recursive” relationships among the controllers, which is one of th= e main points in your SDN architecture document. We used the term “hierarchy” (instead of “recursion̶= 1;) noting that there is a certain recursive nature in modeling abstraction= while specifying some functional differences among the three-tier controll= ers.  

 

Your SDN architecture = specifies a PCE function in each control layer, which is also very consiste= nt with ACTN framework. We might need further terminology alignment to avoi= d misunderstanding.

 

In regards to controll= er name, as Daniele suggested we are open to rename them if necessary. Igor= has some idea as well on this. CNC, VNC and PNC are tied with some control= functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if = the work is warranted, we can revisit this issue.

 

Please see inline for = my responses.

 

Thanks,

Young

 

 

 

From: Dave Hoo= d [mailto:dave.hood@ericsson.com<= /a>]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; actn@ietf.org
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Thanks, Young. A cou= ple of responses:

 

The suggested SDN ar= chitecture that was developed in ONF includes the possibility that layers a= t either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting= SDN interfaces on their north sides. Incremental deployment is certainly n= ecessary, no question about it.

 

YOUNG>> Yes, t= his is important. In ACTN, we regard NMS/EMS as the domain control/manageme= nt entity and with an added function to support “interface C”, NMS/EMS can be empowered to participate in virtualization regime. 80% of t= ransport networks are controlled/managed by NMS/EMS today and enabling them= with network virtualization layer/function is one of the key requirements = from operators.   

 

As to the ONF SDN ar= chitecture suggestion, be clear that there is no question of demanding that= anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to t= he purpose of adding new value to the discussion.

 

YOUNG>> Thanks= for this clarification. I think ACTN can complement ONF SDN architecture. = I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather t= han being contradictory or re-inventing.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; actn@ietf.org Subject: RE: Comments on draft-ceccarelli-actn-framework-04

 

Hi Dave,

 

Thanks for providing y= our perspective. Please see in-line for my comment.

 

Best regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: actn@ietf.org
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04<= /o:p>

 

I shared several comments on the n= ew draft with the editors, but a few of them are more than editorial, so I&= #8217;m posting them for wider discussion.

 

Operators have been trying to brea= k silos for decades. It is okay to specialize the SDN architecture into a u= nique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depar= t from other domains. We should make best efforts to integrate transport SD= N views seamlessly into the rest of the SDN space. We do not want to re-cre= ate silos in the SDN world.

 

YOUNG>> I think you are talk= ing about SDN from a green field perspective. T-SDN could mean different th= ings to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion her= e. I respect ONF view, especially your SDN architecture document produced m= id this year. On the other hand, there are different views of what T-SDN me= ans in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to = be subjected to one view.

 

Having said that, it is of course = always the operator’s option to deploy SDN in separate technology sil= os according to its own practices. The architecture is general, but can be specialized in any number of particular ways.=

 

YOUNG>> Agree. Operators wan= t to build on top of what they have deployed while pursuing new green field= . One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.=

 

An example of specialization is th= e proposed 3-tier model, in which hierarchy or recursion appears to be rest= ricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmati= c for each given instance. In the transport network, suppose we have a PNC,= some of whose endpoints are tunneled ports provided by a yet lower layer o= f SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC towa= rd others. (Necessarily VNC because I’m told offline that only a VNC = can span admin domains.) These distinctions do not seem like a useful ratho= le to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better ju= st to call them all SDN controllers.

 

YOUNG>> I think there was a = misunderstanding. In your particular example, if a PNC is in charge of some= networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC= might function as a multi-domain coordination underneath its control domai= n. So here we are not restricting what PNC does in its network control. Thi= s does not simply need not be known to what is above the PNC. Each PNC represents a control of some network co= mprising an end to end network. It can be a single domain control or contro= l multi domain. SDN controller is one of the PNC in ACTN architecture. Ther= e may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

 

The framework suggests that the PC= E lives in the PNC. Even if we assume a single well-defined PNC layer, this= denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by= the VN definition, and the PNC PCE has no way of knowing what those constr= aints are. This is especially true if the VN is exported across a business = boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to= be available at multiple levels of virtualization: let it be available to = anyone who needs it.

 

YOUNG>> Actually there is al= ways PCE function in each of CNC, VNC and PNC. Perhaps, there needs more cl= arification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manage= r (which needs to compute paths based on virtual networks), likewise CNC wh= ere customers want to compute their paths within the confines of VNs alloca= ted to them.

 

 

Arguably the major issue with the = draft is that it does not recognize the importance of the manager actor in = the provider-customer relationship. The SDN architecture explains that the provider’s manager is necessarily responsible for = creating a virtual network environment for the customer and for installing = policy in its SDN controller (at whatever hierarchical level) to both prote= ct the customer from other customers (privacy and QoS) and to protect the provider’s own resources from customer m= isbehaviour, whether intentional or otherwise. In particular, the draft ref= ers to the customer app creating VNs, whereas a customer cannot be trusted = to create its own VN except perhaps as a mere subnet of the “real” VN created under the auspices of a= business negotiation by the provider’s manager. (And yes, the SDN ar= chitecture also describes how all of this can be done flexibly, for example= if the customer invokes a service provisioning portal with credentials that permit billing.)

 

YOUNG>> Good point. This is = one of the areas where ACTN needs to work on more. Your contribution is wel= come for this.

 

Completeness, common concepts, int= erfaces and terminology could all be facilitated by starting with the umbre= lla SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

 

YOUNG>> Good reference, I ha= ve to say, which the latest version included as one of the references.

 

Dave

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C40626dfweml706chm_-- From nobody Mon Oct 27 16:13:48 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 3C8261A6EE7 for ; Mon, 27 Oct 2014 16:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eSdd5FdO3HHl for ; Mon, 27 Oct 2014 16:13:28 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAF71A6F56 for ; Mon, 27 Oct 2014 16:13:23 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 399A3370456 for ; Tue, 28 Oct 2014 00:13:21 +0100 (CET) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 23281370443 for ; Tue, 28 Oct 2014 00:13:21 +0100 (CET) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 00:13:20 +0100 Received: from DB4PR06MB361.eurprd06.prod.outlook.com (10.141.234.141) by DB4PR06MB540.eurprd06.prod.outlook.com (10.242.230.156) with Microsoft SMTP Server (TLS) id 15.1.6.9; Mon, 27 Oct 2014 23:13:19 +0000 Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB361.eurprd06.prod.outlook.com (10.141.234.141) with Microsoft SMTP Server (TLS) id 15.1.6.9; Mon, 27 Oct 2014 23:13:18 +0000 Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.01.0006.000; Mon, 27 Oct 2014 23:13:13 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: "actn@ietf.org" Thread-Topic: New version submitted for draft-lopez-actn-vno-multidomains Thread-Index: Ac/yOu6ZubB+swrXRpiiD/WYq3MJAw== Date: Mon, 27 Oct 2014 23:13:13 +0000 Message-ID: <76263a9d36ef4a57b7c8a7814bb37794@DB4PR06MB576.eurprd06.prod.outlook.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [79.146.141.50] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB361;UriScan:; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(19580395003)(92566001)(2501002)(19580405001)(110136001)(20776003)(19609705001)(230783001)(19625215002)(101416001)(4396001)(15975445006)(21056001)(80022003)(31966008)(97736003)(74316001)(19300405004)(86362001)(46102003)(64706001)(33646002)(50986999)(66066001)(2351001)(87936001)(107046002)(120916001)(15202345003)(54356999)(99396003)(16236675004)(105586002)(106356001)(95666004)(76482002)(76576001)(40100003)(2656002)(122556002)(85852003)(229853001)(85306004)(108616004)(24736002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB361; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_76263a9d36ef4a57b7c8a7814bb37794DB4PR06MB576eurprd06pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB540; X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/actn/oDAudCZaZ3KRZpvfLWq9mJHPo1c Cc: VICTOR LOPEZ ALVAREZ Subject: [Actn] New version submitted for draft-lopez-actn-vno-multidomains 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: Mon, 27 Oct 2014 23:13:44 -0000 --_000_76263a9d36ef4a57b7c8a7814bb37794DB4PR06MB576eurprd06pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, We have just submitted a new version of draft-lopez-actn-vno-multidomains-0= 1. We continue completing the picture by adding some statements with regard= responsibilities for optimization, policy enforcement and accounting for e= ither the VNO coordinator and the Domain Control entities. Any comments are welcome Luis & Victor __________________________________ 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 F: +34 91 482 2785 luismiguel.contrerasmurillo@telefonica.com ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_76263a9d36ef4a57b7c8a7814bb37794DB4PR06MB576eurprd06pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

We have just submitted a new version of draft-lopez-= actn-vno-multidomains-01. We continue completing the picture by adding some= statements with regard responsibilities for optimization, policy enforceme= nt and accounting for either the VNO coordinator and the Domain Control entities.

 

Any comments are welcome

 

Luis & Victor

 

__________________________________

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=

&nb= sp;

F: +34 91 482 2785

luismiguel.contrerasmurillo@telefo= nica.com

 



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_76263a9d36ef4a57b7c8a7814bb37794DB4PR06MB576eurprd06pro_-- From nobody Tue Oct 28 10:23:07 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 86FE21A90CC for ; Tue, 28 Oct 2014 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XJ6kISp8KhPO for ; Tue, 28 Oct 2014 10:22:59 -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 B51FA1A9078 for ; Tue, 28 Oct 2014 10:22:58 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-23-544fd0f033fc Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.20.24955.0F0DF445; Tue, 28 Oct 2014 18:22:56 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 18:22:56 +0100 From: Daniele Ceccarelli To: "actn@ietf.org" Thread-Topic: ACTN BoF agenda Thread-Index: Ac/y0s9mFoJ9wGOHRkqgH0iaM3HPfQ== Date: Tue, 28 Oct 2014 17:22:55 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48127BF620@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48127BF620ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje6HC/4hBt+n61ls6bnAZvFiXbBF 99fV7A7MHi1H3rJ6LFnyk8nj1IH0AOYoLpuU1JzMstQifbsEroxfZ1YzFkwSq/h3dB9LA+ML 4S5GTg4JAROJY5uesUPYYhIX7q1n62Lk4hASOMIo8fnfNmYIZxGjRG/DUtYuRg4ONgEriSeH fEAaRASUJRYf/sMGEmYWyJaYNlEDJCwsICFx8XsnI0SJrMT/ozcZQUpEBPQk9lwSBQmzCKhK dF3ezwZi8wr4Sqyb9x/MZgQqn7B7EVgrs4C4xK0n85kgThOQWLLnPDOELSrx8vE/VghbSeLH hkssEPX5Eq8PdDNBzBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwce MyGLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGEsHt/xW3cF4+Y3jIUYBDkYlHt4N bP4hQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMakn9bNJ u9P21heXZyd1OvyZuPyo7TTWT8Z2t9Tt5sz4q+O1YsfCixxxG1tKww8yVp2U5piWc3WSs8Rr zcnfbzXEpRsxHP5wW1KMO8I1IKPY7U0jy8Gayt2tnV+z5jZcn//rEQ+ryLxtqyZHzHN4GLJv Z3dde2LVN6tgl4uNnGeWNJ781GwUpcRSnJFoqMVcVJwIAEhgg0aGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/J4sEXlLlJSAm-3d55YY2P6rz0FQ Cc: "King, Daniel \(d.king@lancaster.ac.uk\)" , "ylee@huawei.com" Subject: [Actn] ACTN BoF agenda 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: Tue, 28 Oct 2014 17:23:02 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48127BF620ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, the ACTN BoF agenda is now available, please have a look at the following l= ink: http://www.ietf.org/proceedings/91/agenda/agenda-91-actn Comments are welcome Daniele, Young, Dan --_000_4A1562797D64E44993C5CBF38CF1BE48127BF620ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

the ACTN BoF agenda is now available, please have a = look at the following link: http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-actn

 

Comments are welcome

 

Daniele, Young, Dan

 

 

--_000_4A1562797D64E44993C5CBF38CF1BE48127BF620ESESSMB301erics_--