From leeyoung@huawei.com  Mon Dec  2 11:22:01 2013
Return-Path: <leeyoung@huawei.com>
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 92C7C1ADE8A for <actn@ietfa.amsl.com>; Mon,  2 Dec 2013 11:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Level: 
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 QQfLAEK1pkk4 for <actn@ietfa.amsl.com>; Mon,  2 Dec 2013 11:21:59 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3E1E1ADEA0 for <actn@ietf.org>; Mon,  2 Dec 2013 11:21:58 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY09940; Mon, 02 Dec 2013 19:21:55 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:21:05 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:21:52 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 11:21:49 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "actn@ietf.org" <actn@ietf.org>
Thread-Topic: test
Thread-Index: Ac7vk77HPBnSnm0JSYSN1R+4EeLUGw==
Date: Mon, 2 Dec 2013 19:21:48 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9A622@dfweml510-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.149]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [Actn] test
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 19:22:01 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_--

From leeyoung@huawei.com  Mon Dec  2 11:35:03 2013
Return-Path: <leeyoung@huawei.com>
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 0E4B91AD8F3 for <actn@ietfa.amsl.com>; Mon,  2 Dec 2013 11:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level: 
X-Spam-Status: No, score=-3.201 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.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 Upe-XJ6pI_yz for <actn@ietfa.amsl.com>; Mon,  2 Dec 2013 11:35:00 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A30BB1ADEB5 for <actn@ietf.org>; Mon,  2 Dec 2013 11:34:59 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYN98055; Mon, 02 Dec 2013 19:34:56 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:34:12 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:34:54 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 11:34:52 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Introduction to ACTN mailing list
Thread-Index: Ac7vlZDuyRutGTQwSpeYEkHdFSpHbQ==
Date: Mon, 2 Dec 2013 19:34:50 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9A65E@dfweml510-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.149]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "King, Daniel" <d.king@lancaster.ac.uk>, 'Young Lee' <younglee.tx@gmail.com>
Subject: [Actn] Introduction to ACTN mailing list
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 19:35:03 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

This is to introduce the ACTN mailing list. ACTN stands for "Abstraction an=
d Control of Transport Networks" and it reads like "Action."
This mailing list is created as a result of a Bar BOF held in IETF 88 @ Van=
couver. The original Bar BOF was called "Network Control Function Virtualiz=
ation (NCFV)".


The purpose of the list:

Transport networks have a variety of mechanisms to facilitate separation of=
 data plane and control plane including distributed signaling for path setu=
p and protection, centralized path computation for planning and traffic eng=
ineering, and a range of management and provisioning protocols to configure=
 and activate network resources. These mechanisms represent key technologie=
s for enabling flexible and dynamic networking.



As transport networks evolve, the need to provide network abstraction has e=
merged as key requirement for operators; this is in effect virtualization o=
f network resources so that the network is "sliced" for different uses, app=
lications, services, and clients each being given a different partial view =
of the total topology and each considering that it is operating with or on =
a single, stand-alone and consistent network.



This virtualization is known as Abstraction and Control of Transport Networ=
k (ACTN) and facilitates:



- Abstraction of underlying network resources to higher-layer applications =
and users (clients);

- Slicing of network resources, to meet specific application and users requ=
irements;

- A computation scheme and virtual control capability, via an information m=
odel, to clients who request network connectivity and bandwidth;

- Coordination of underlying transport layers and presentation as an abstra=
cted topology to the client;



This mailing list is intended to enable discussion of the architecture, use=
-cases/applicability, and requirements that provide abstraction and virtual=
 control of transport networks to various applications/clients.


You can subscribe to the list at: https://www.ietf.org/mailman/listinfo/act=
n.

Wiki is created to keep track of the latest development and provide some ba=
ckground and useful information at: https://sites.google.com/site/actnbof/.

To post a message to all the list members, send email to actn@ietf.org<mail=
to:actn@ietf.org>.

Best Regards,
Young & Dan

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">Dear all,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">This is to introduce the ACTN mailing list. ACTN stands for &#8220;Abstra=
ction and Control of Transport Networks&#8221; and it reads like &#8220;Act=
ion.&#8221;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">This mailing list is created as a result of a Bar BOF held in IETF 88 @ V=
ancouver. The original Bar BOF was called &#8220;Network Control Function V=
irtualization (NCFV)&#8221;.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText">The purpose of the list:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p></o:p></p>
<p class=3D"MsoPlainText">Transport networks have a variety of mechanisms t=
o facilitate separation of data plane and control plane including distribut=
ed signaling for path setup and protection, centralized path computation fo=
r planning and traffic engineering,
 and a range of management and provisioning protocols to configure and acti=
vate network resources. These mechanisms represent key technologies for ena=
bling flexible and dynamic networking.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">As transport networks evolve, the need to provide=
 network abstraction has emerged as key requirement for operators; this is =
in effect virtualization of network resources so that the network is &quot;=
sliced&quot; for different uses, applications,
 services, and clients each being given a different partial view of the tot=
al topology and each considering that it is operating with or on a single, =
stand-alone and consistent network.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This virtualization is known as Abstraction and C=
ontrol of Transport Network (ACTN) and facilitates:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">- Abstraction of underlying network resources to =
higher-layer applications and users (clients);<o:p></o:p></p>
<p class=3D"MsoPlainText">- Slicing of network resources, to meet specific =
application and users requirements;<o:p></o:p></p>
<p class=3D"MsoPlainText">- A computation scheme and virtual control capabi=
lity, via an information model, to clients who request network connectivity=
 and bandwidth;<o:p></o:p></p>
<p class=3D"MsoPlainText">- Coordination of underlying transport layers and=
 presentation as an abstracted topology to the client;<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This mailing list is intended to enable discussio=
n of the architecture, use-cases/applicability, and requirements that provi=
de abstraction and virtual control of transport networks to various applica=
tions/clients.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">You can subscribe to the list at:
</span><span lang=3D"EN-GB" style=3D"font-size:10.5pt;font-family:Consolas;=
color:#00B0F0"><a href=3D"https://www.ietf.org/mailman/listinfo/actn"><span=
 style=3D"color:#00B0F0">https://www.ietf.org/mailman/listinfo/actn</span><=
/a></span><span lang=3D"EN-GB" style=3D"font-size:10.5pt;font-family:Consol=
as">.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><span lang=3D"EN-GB" style=3D"font-size:10.5pt;fo=
nt-family:Consolas"><o:p>&nbsp;</o:p></span></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:10.5pt;font-=
family:Consolas">Wiki is created to keep track of the latest development an=
d provide some background and useful information at:
<a href=3D"https://sites.google.com/site/actnbof/"><span style=3D"color:win=
dowtext">https://sites.google.com/site/actnbof/</span></a>.<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">To post a message to all the list members, send email to
<a href=3D"mailto:actn@ietf.org">actn@ietf.org</a>. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">Best Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas=
">Young &amp; Dan<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_--

From ietf-secretariat@ietf.org  Tue Dec  3 09:56:03 2013
Return-Path: <ietf-secretariat@ietf.org>
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 160911AE151; Tue,  3 Dec 2013 09:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 h9-b_qNjL-4G; Tue,  3 Dec 2013 09:56:01 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DE71AE18C; Tue,  3 Dec 2013 09:56:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IETF Secretariat <ietf-secretariat@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131203175601.13127.58364.idtracker@ietfa.amsl.com>
Date: Tue, 03 Dec 2013 09:56:01 -0800
X-Mailman-Approved-At: Tue, 03 Dec 2013 11:15:30 -0800
Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org
Subject: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 17:56:03 -0000

A new IETF non-working group email list has been created.

List address: actn@ietf.org
Archive: http://www.ietf.org/mail-archive/web/actn/
To subscribe: https://www.ietf.org/mailman/listinfo/actn

Purpose: Discussion of Abstraction and Control of Transport Networks =

(ACTN)

For additional information, please contact the list administrators.

From jmpolk@cisco.com  Tue Dec  3 11:41:18 2013
Return-Path: <jmpolk@cisco.com>
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 F1B0E1AE195; Tue,  3 Dec 2013 11:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kSF40iKl6qIQ; Tue,  3 Dec 2013 11:41:16 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3151ADBCE; Tue,  3 Dec 2013 11:41:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=523; q=dns/txt; s=iport; t=1386099673; x=1387309273; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=b27eN/U18syb6aJFIpPu+yQ8LQf6/ypnTK3VYx22Sig=; b=cxA8yN0SHW8F86EOIY6gna2a4KOBhsOLM2skQpG+F18ZK7PcmUwv3iqU 6pkeGmyjgW7knWPNgKjN+Z1uBdyP396VXL2500zvell7b0wZGjV7HXxIQ gGdrdEVoMTpsNwt3Phwt6kWsP9OjB+C0spaUM5vr1x+IcvfV4dfxCIHQ0 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAOYynlKtJXG9/2dsb2JhbABagwc4uTuBGxZ0giUBAQEEAQEBNQI0CxAHBBgJAxIQDwoOMAYBEgmHeA3BMBeOHBACAU8HhDMDiUKgZYFrgV0d
X-IronPort-AV: E=Sophos;i="4.93,819,1378857600";  d="scan'208";a="4053280"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 03 Dec 2013 19:41:13 +0000
Received: from jmpolk-WS.cisco.com ([10.89.12.165]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB3JfDcd004847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 19:41:13 GMT
Message-Id: <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 03 Dec 2013 13:41:12 -0600
To: <ietf@ietf.org>, IETF Announcement List <ietf-announce@ietf.org>
From: James Polk <jmpolk@cisco.com>
In-Reply-To: <20131203175601.13127.58364.idtracker@ietfa.amsl.com>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
X-Mailman-Approved-At: Tue, 03 Dec 2013 11:49:18 -0800
Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 19:41:18 -0000

Can this "purpose" have fewer words...?

come on, let us know what's really going on this new list

James

At 11:56 AM 12/3/2013, IETF Secretariat wrote:
>A new IETF non-working group email list has been created.
>
>List address: actn@ietf.org
>Archive: http://www.ietf.org/mail-archive/web/actn/
>To subscribe: https://www.ietf.org/mailman/listinfo/actn
>
>Purpose: Discussion of Abstraction and Control of Transport Networks
>(ACTN)
>
>For additional information, please contact the list administrators.


From derhoermi@gmx.net  Tue Dec  3 11:49:31 2013
Return-Path: <derhoermi@gmx.net>
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 34A051AE198 for <actn@ietfa.amsl.com>; Tue,  3 Dec 2013 11:49:31 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 NirygmOVkSG7 for <actn@ietfa.amsl.com>; Tue,  3 Dec 2013 11:49:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FD1ACC88 for <actn@ietf.org>; Tue,  3 Dec 2013 11:49:29 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.22.65]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MS5jy-1WBcy408Lq-00TDpE for <actn@ietf.org>; Tue, 03 Dec 2013 20:49:26 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: James Polk <jmpolk@cisco.com>
Date: Tue, 03 Dec 2013 20:49:26 +0100
Message-ID: <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>
In-Reply-To: <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:PtlY4M0l4BqSXEkUS9Ww+oSYe2LU6DmS1rD9dKyI1ocGb3SOT8A G8ie5X+42nvCz7vuGjt3CCC48UG82dgIjySqhXKFJne3fcvJ/dFleCQ+JS7bEx9hpKQD2np xFBOXfrVwtrT3EfWy7XpHq0y8XXj/4WYdwhmHPHl7GkY+6jRV2AA779AIqmauLLCBQ4d35u INahg3NBjNX3VkezCcNhg==
X-Mailman-Approved-At: Tue, 03 Dec 2013 11:56:09 -0800
Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, ietf@ietf.org, actn@ietf.org
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 19:49:31 -0000

* James Polk wrote:
>Can this "purpose" have fewer words...?
>
>come on, let us know what's really going on this new list

There is http://www.ietf.org/mail-archive/web/actn/current/msg00002.html
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From d.king@lancaster.ac.uk  Tue Dec  3 11:57:00 2013
Return-Path: <d.king@lancaster.ac.uk>
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 E47E91ACCDC for <actn@ietfa.amsl.com>; Tue,  3 Dec 2013 11:57:00 -0800 (PST)
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 A72xqYFpu0bS for <actn@ietfa.amsl.com>; Tue,  3 Dec 2013 11:56:59 -0800 (PST)
Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA6F1AC404 for <actn@ietf.org>; Tue,  3 Dec 2013 11:56:59 -0800 (PST)
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 <d.king@lancaster.ac.uk>) id 1Vnw5X-0006yW-4R; Tue, 03 Dec 2013 19:56:55 +0000
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.0158.001; Tue, 3 Dec 2013 19:56:54 +0000
From: "King, Daniel" <d.king@lancaster.ac.uk>
To: Bjoern Hoehrmann <derhoermi@gmx.net>, "jmpolk@cisco.com" <jmpolk@cisco.com>
Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
Thread-Index: AQHO8GDHeZUouMBhc0ygB4R8mvBWFJpC4PuA
Date: Tue, 3 Dec 2013 19:56:54 +0000
Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D20D6@EX-0-MB2.lancs.local>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de>
In-Reply-To: <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "actn@ietf.org" <actn@ietf.org>
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 19:57:01 -0000

Thanks Bjoern!

James, the list is rather new, we need folks to move their current discussi=
ons to the list.=20

In the meantime, did you review the slides from the BoF and/or initial I-Ds=
:

https://sites.google.com/site/actnbof/home/bar-bof-material
https://datatracker.ietf.org/doc/draft-lee-network-control-function-virtual=
ization/
https://datatracker.ietf.org/doc/draft-lee-pce-app-oriented-arch/

Any contribution as questions, or suggestions, would be most welcome.=20

Br, Dan.=20

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]=20
Sent: 03 December 2013 19:49
To: James Polk
Cc: ietf@ietf.org; King, Daniel; younglee.tx@gmail.com; leeyoung@huawei.com=
; actn@ietf.org
Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of Tr=
ansport Networks (ACTN)

* James Polk wrote:
>Can this "purpose" have fewer words...?
>
>come on, let us know what's really going on this new list

There is http://www.ietf.org/mail-archive/web/actn/current/msg00002.html
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma=
nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsw=
orld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20

From fred@cisco.com  Tue Dec  3 12:20:41 2013
Return-Path: <fred@cisco.com>
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 72E0D1AE1A1; Tue,  3 Dec 2013 12:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.502
X-Spam-Level: 
X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 JG-i9Axxrf0g; Tue,  3 Dec 2013 12:20:40 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA391AE198; Tue,  3 Dec 2013 12:20:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1518; q=dns/txt; s=iport; t=1386102037; x=1387311637; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FZpMOhQOFGqTvEWmmZBudL7qI1FawHBLzvL81q1jpI4=; b=H/rvDbf80ICnI1hnfCgC0RoZu164fgUxFRrQCtXC5J2eRhesWXH/BAYZ stmxL+MPfo/znzQePs8MgykePtdHN+KLgHpUiaX7T5Wv6kPZ7foDUu9Oi AVPfkBEhCvXl1DMYqhEAs9aK3n8kxEslda65BBSE+ObdzDF6mAzsW5pe4 E=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhMFAOY8nlKtJXHA/2dsb2JhbABagwc4U7hogRsWdIIlAQEBBG4LEAIBCA4KJwcyFBECBA4FCQWHYQMPDcEtF4xtgUABAU8CBQmDF4ETA5AxgTGGMoEwkGOBa4E+gXE5
X-IronPort-AV: E=Sophos;i="4.93,819,1378857600"; d="asc'?scan'208";a="4059667"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 03 Dec 2013 20:20:37 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB3KKbeH014716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 20:20:37 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 14:20:36 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
Thread-Index: AQHO8FEDY9UrnEdjo0G5rnh8NuMiHJpDQzEAgAACTQCAAAi1AA==
Date: Tue, 3 Dec 2013 20:20:36 +0000
Message-ID: <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de>
In-Reply-To: <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.123]
Content-Type: multipart/signed; boundary="Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 03 Dec 2013 12:25:59 -0800
Cc: "<actn@ietf.org>" <actn@ietf.org>, "<ietf@ietf.org>" <ietf@ietf.org>, "<leeyoung@huawei.com>" <leeyoung@huawei.com>, "<d.king@lancaster.ac.uk>" <d.king@lancaster.ac.uk>, "<younglee.tx@gmail.com>" <younglee.tx@gmail.com>, "James Polk \(jmpolk\)" <jmpolk@cisco.com>
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 20:20:41 -0000

--Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Dec 3, 2013, at 11:49 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * James Polk wrote:
>> Can this "purpose" have fewer words...?
>>=20
>> come on, let us know what's really going on this new list
>=20
> There is =
http://www.ietf.org/mail-archive/web/actn/current/msg00002.html

Great. Put that information into the list description so the next person =
doesn't have to ask the same question.

> --=20
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 =
http://bjoern.hoehrmann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 =
http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/=20

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.=20
   - Marshall McLuhan


--Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFSnj0UbjEdbHIsm0MRAjlNAKCgNtAmBbUkKhKFO1WiB+9OWCe0WwCdF1Oy
iJoIbLEJmLO7SecHe+4OXjU=
=nAx1
-----END PGP SIGNATURE-----

--Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C--

From d.king@lancaster.ac.uk  Tue Dec  3 12:30:29 2013
Return-Path: <d.king@lancaster.ac.uk>
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 D18781ADF2F for <actn@ietfa.amsl.com>; Tue,  3 Dec 2013 12:30:29 -0800 (PST)
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 tn-LuOP3JWiv for <actn@ietfa.amsl.com>; Tue,  3 Dec 2013 12:30:27 -0800 (PST)
Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 864A61ACCDE for <actn@ietf.org>; Tue,  3 Dec 2013 12:30:27 -0800 (PST)
Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from <d.king@lancaster.ac.uk>) id 1Vnwbu-0003ZI-3w; Tue, 03 Dec 2013 20:30:22 +0000
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.0158.001; Tue, 3 Dec 2013 20:30:21 +0000
From: "King, Daniel" <d.king@lancaster.ac.uk>
To: "Fred Baker (fred)" <fred@cisco.com>
Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
Thread-Index: AQHO8GUme2IK1F+NsEaz+yJ61vv6e5pC6+TQ
Date: Tue, 3 Dec 2013 20:30:21 +0000
Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D212D@EX-0-MB2.lancs.local>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com>
In-Reply-To: <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<actn@ietf.org>" <actn@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, "<younglee.tx@gmail.com>" <younglee.tx@gmail.com>, "James Polk \(jmpolk\)" <jmpolk@cisco.com>, "<leeyoung@huawei.com>" <leeyoung@huawei.com>
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 20:30:29 -0000

>Great. Put that information into the list description so the next person d=
oesn't have to ask the same question.

Done! Thanks.=20

Br, Dan.=20
-----Original Message-----
From: Fred Baker (fred) [mailto:fred@cisco.com]=20
Sent: 03 December 2013 20:21
To: Bjoern Hoehrmann
Cc: James Polk (jmpolk); King, Daniel; <younglee.tx@gmail.com>; <leeyoung@h=
uawei.com>; <ietf@ietf.org>; <actn@ietf.org>
Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of Tr=
ansport Networks (ACTN)


On Dec 3, 2013, at 11:49 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * James Polk wrote:
>> Can this "purpose" have fewer words...?
>>=20
>> come on, let us know what's really going on this new list
>=20
> There is=20
> http://www.ietf.org/mail-archive/web/actn/current/msg00002.html

Great. Put that information into the list description so the next person do=
esn't have to ask the same question.

> --
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20
> http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681=
=20
> =B7 http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20
> http://www.websitedev.de/

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.=20
   - Marshall McLuhan


From d3e3e3@gmail.com  Tue Dec  3 13:34:05 2013
Return-Path: <d3e3e3@gmail.com>
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 CC6D51A8032; Tue,  3 Dec 2013 13:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 KjpaIJaIoZXz; Tue,  3 Dec 2013 13:34:04 -0800 (PST)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 470B61ADED6; Tue,  3 Dec 2013 13:34:04 -0800 (PST)
Received: by mail-ob0-f178.google.com with SMTP id uz6so15086773obc.37 for <multiple recipients>; Tue, 03 Dec 2013 13:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dIOXm1tb9vetjbDbrA1cEv5Iz6e6YxoWMyBjAao3U88=; b=GbS7vmgvfEG46dauNu601GcWDp5woOuivDTuoQrl5jrMDQpEZK4oOnu35EPH5eS0BI vBOshTYZDNaf3wsW+bQTCDlOqVcXzMVIO1rxPvym5ZHVbO/sDI3xwq1MPElntr8/KTUd UrbIff5MAmbYfl8Fkr3mzS0aciEPLbAgtKR1KuUfr5KSwismQLb02oULPCi5KKO81F7Y /OTyQFw08DginYZMMfvhiYTuu01Hj55UL0kAA46/XIjeMwZTKgdNKNucyPn7C9w4f9kW WQqhS089pRimtAfqCOKlwRxeRJB+IbtivMOmJmsa3hZQlFK/1UYRSQdLhKyl84KKs11J QPqw==
X-Received: by 10.182.81.197 with SMTP id c5mr11593218oby.40.1386106441385; Tue, 03 Dec 2013 13:34:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.33.102 with HTTP; Tue, 3 Dec 2013 13:33:41 -0800 (PST)
In-Reply-To: <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 3 Dec 2013 16:33:41 -0500
Message-ID: <CAF4+nEGBrqpYO0g_GS=c47zYs5=VGz+L3c=qVWwk02TOEbxGrg@mail.gmail.com>
To: "<ietf@ietf.org>" <ietf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 03 Dec 2013 13:37:54 -0800
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, "<leeyoung@huawei.com>" <leeyoung@huawei.com>, "Fred Baker \(fred\)" <fred@cisco.com>, "<d.king@lancaster.ac.uk>" <d.king@lancaster.ac.uk>, "<younglee.tx@gmail.com>" <younglee.tx@gmail.com>, "<actn@ietf.org>" <actn@ietf.org>
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 21:34:06 -0000

Yes please. A plethora of non-wg mailing lists with cryptic
descriptions is a perennial problem. How about a *minimum* description
requirement of 50 words or something.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Tue, Dec 3, 2013 at 3:20 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>
> On Dec 3, 2013, at 11:49 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>
>> * James Polk wrote:
>>> Can this "purpose" have fewer words...?
>>>
>>> come on, let us know what's really going on this new list
>>
>> There is http://www.ietf.org/mail-archive/web/actn/current/msg00002.html
>
> Great. Put that information into the list description so the next person =
doesn't have to ask the same question.
>
>> --
>> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoeh=
rmann.de
>> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworl=
d.de
>> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitede=
v.de/
>
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially.
>    - Marshall McLuhan
>

From adrian@olddog.co.uk  Tue Dec  3 15:16:01 2013
Return-Path: <adrian@olddog.co.uk>
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 64C7D1AE1C6; Tue,  3 Dec 2013 15:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=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 tMrBgHzmnR2D; Tue,  3 Dec 2013 15:15:58 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4E1ADF28; Tue,  3 Dec 2013 15:15:58 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NFlKd024761; Tue, 3 Dec 2013 23:15:47 GMT
Received: from 950129200 (no-dns-yet.demon.co.uk [62.49.66.12] (may be forged)) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NFkO3024752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 23:15:46 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'James Polk'" <jmpolk@cisco.com>, <ietf@ietf.org>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>
In-Reply-To: <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>
Date: Tue, 3 Dec 2013 23:15:45 -0000
Message-ID: <0f5701cef07d$9926acf0$cb7406d0$@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: AQHzBhEBAL8QRPWOkmQwqhx5/2DF5gEh+IF7mfHekVA=
Content-Language: en-gb
Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
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\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 23:16:01 -0000

James,

I'm very sorry about that. I sent the Secretariat a long description when
requesting list creation. See it below.

I will follow up with the Executive Director to find out what happened.

Adrian

===

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: 26 November 2013 20:03
To: 'ietf-action@ietf.org'
Cc: iesg@ietf.org; King, Daniel (d.king@lancaster.ac.uk); leeyoung@huawei.com
Subject: FW: Please create and announce a new non-WG mailing list

Hi,

Please create the a new non-working group mailing list as follows...

Name and email address of the submitter:
Young Lee, leeyoung@huawei.com

The name of the list:
Abstraction and Control of Transport Networks (ACTN)
 
The URL or email address of the list:
actn@ietf.org
 
Name(s) and email address(es) of the list administrator(s):
Young Lee leeyoung@huawei.com
Daniel King d.king@lancaster.ac.uk

The IETF Area to which the list belongs:
Routing
 
The URL or other instructions for subscribing to the list:
https://www.ietf.org/mailman/listinfo/actn

The purpose of the list:
 
Transport networks have a variety of mechanisms to facilitate separation of data
plane and control plane including distributed signaling for path setup and
protection, centralized path computation for planning and traffic engineering,
and a range of management and provisioning protocols to configure and activate
network resources. These mechanisms represent key technologies for enabling
flexible and dynamic networking.

As transport networks evolve, the need to provide network abstraction has
emerged as key requirement for operators; this is in effect virtualization of
network resources so that the network is "sliced" for different uses,
applications, services, and clients each being given a different partial view of
the total topology and each considering that it is operating with or on a
single, stand-alone and consistent network.

This virtualization is known as Abstraction and Control of Transport Network
(ACTN) and facilitates:
- Abstraction of underlying network resources to higher-layer applications and
users (clients);
- Slicing of network resources, to meet specific application and users
requirements;
- A computation scheme and virtual control capability, via an information model,
to clients who request network connectivity and bandwidth;
- Coordination of underlying transport layers and presentation as an abstracted
topology to the client;

This mailing list is intended to enable discussion of the architecture,
use-cases/applicability, and requirements that provide abstraction and virtual
control of transport networks to various applications/clients.

> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of James Polk
> Sent: 03 December 2013 19:41
> To: ietf@ietf.org; IETF Announcement List
> Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com;
> actn@ietf.org
> Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of
> Transport Networks (ACTN)
> 
> Can this "purpose" have fewer words...?
> 
> come on, let us know what's really going on this new list
> 
> James
> 
> At 11:56 AM 12/3/2013, IETF Secretariat wrote:
> >A new IETF non-working group email list has been created.
> >
> >List address: actn@ietf.org
> >Archive: http://www.ietf.org/mail-archive/web/actn/
> >To subscribe: https://www.ietf.org/mailman/listinfo/actn
> >
> >Purpose: Discussion of Abstraction and Control of Transport Networks
> >(ACTN)
> >
> >For additional information, please contact the list administrators.


From adrian@olddog.co.uk  Tue Dec  3 15:17:42 2013
Return-Path: <adrian@olddog.co.uk>
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 AEBA71AE1CE; Tue,  3 Dec 2013 15:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=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 vji7JrrsueZe; Tue,  3 Dec 2013 15:17:40 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E112A1ADF59; Tue,  3 Dec 2013 15:17:39 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NHU3J027356; Tue, 3 Dec 2013 23:17:30 GMT
Received: from 950129200 (no-dns-yet.demon.co.uk [62.49.66.12] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NHSVI027326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 23:17:29 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'James Polk'" <jmpolk@cisco.com>, <ietf@ietf.org>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> 
In-Reply-To: 
Date: Tue, 3 Dec 2013 23:17:28 -0000
Message-ID: <0f5b01cef07d$d6212e00$82638a00$@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: AQHzBhEBAL8QRPWOkmQwqhx5/2DF5gEh+IF7mfHekVCAAAEPUA==
Content-Language: en-gb
Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
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\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 23:17:43 -0000

Actually, there is also...

https://www.ietf.org/mailman/listinfo/actn

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: 03 December 2013 23:16
> To: 'James Polk'; 'ietf@ietf.org'
> Cc: 'd.king@lancaster.ac.uk'; 'younglee.tx@gmail.com'; 'leeyoung@huawei.com';
> 'actn@ietf.org'
> Subject: RE: New Non-WG Mailing List: ACTN -- Abstraction and Control of
> Transport Networks (ACTN)
> 
> James,
> 
> I'm very sorry about that. I sent the Secretariat a long description when
> requesting list creation. See it below.
> 
> I will follow up with the Executive Director to find out what happened.
> 
> Adrian
> 
> ===
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: 26 November 2013 20:03
> To: 'ietf-action@ietf.org'
> Cc: iesg@ietf.org; King, Daniel (d.king@lancaster.ac.uk); leeyoung@huawei.com
> Subject: FW: Please create and announce a new non-WG mailing list
> 
> Hi,
> 
> Please create the a new non-working group mailing list as follows...
> 
> Name and email address of the submitter:
> Young Lee, leeyoung@huawei.com
> 
> The name of the list:
> Abstraction and Control of Transport Networks (ACTN)
> 
> The URL or email address of the list:
> actn@ietf.org
> 
> Name(s) and email address(es) of the list administrator(s):
> Young Lee leeyoung@huawei.com
> Daniel King d.king@lancaster.ac.uk
> 
> The IETF Area to which the list belongs:
> Routing
> 
> The URL or other instructions for subscribing to the list:
> https://www.ietf.org/mailman/listinfo/actn
> 
> The purpose of the list:
> 
> Transport networks have a variety of mechanisms to facilitate separation of
data
> plane and control plane including distributed signaling for path setup and
> protection, centralized path computation for planning and traffic engineering,
> and a range of management and provisioning protocols to configure and activate
> network resources. These mechanisms represent key technologies for enabling
> flexible and dynamic networking.
> 
> As transport networks evolve, the need to provide network abstraction has
> emerged as key requirement for operators; this is in effect virtualization of
> network resources so that the network is "sliced" for different uses,
applications,
> services, and clients each being given a different partial view of the total
topology
> and each considering that it is operating with or on a single, stand-alone and
> consistent network.
> 
> This virtualization is known as Abstraction and Control of Transport Network
> (ACTN) and facilitates:
> - Abstraction of underlying network resources to higher-layer applications and
> users (clients);
> - Slicing of network resources, to meet specific application and users
> requirements;
> - A computation scheme and virtual control capability, via an information
model,
> to clients who request network connectivity and bandwidth;
> - Coordination of underlying transport layers and presentation as an
abstracted
> topology to the client;
> 
> This mailing list is intended to enable discussion of the architecture, use-
> cases/applicability, and requirements that provide abstraction and virtual
control
> of transport networks to various applications/clients.
> 
> > -----Original Message-----
> > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of James Polk
> > Sent: 03 December 2013 19:41
> > To: ietf@ietf.org; IETF Announcement List
> > Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com;
> > actn@ietf.org
> > Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of
> > Transport Networks (ACTN)
> >
> > Can this "purpose" have fewer words...?
> >
> > come on, let us know what's really going on this new list
> >
> > James
> >
> > At 11:56 AM 12/3/2013, IETF Secretariat wrote:
> > >A new IETF non-working group email list has been created.
> > >
> > >List address: actn@ietf.org
> > >Archive: http://www.ietf.org/mail-archive/web/actn/
> > >To subscribe: https://www.ietf.org/mailman/listinfo/actn
> > >
> > >Purpose: Discussion of Abstraction and Control of Transport Networks
> > >(ACTN)
> > >
> > >For additional information, please contact the list administrators.


From l.wood@surrey.ac.uk  Tue Dec  3 16:42:43 2013
Return-Path: <l.wood@surrey.ac.uk>
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 DD2C81ADFC8; Tue,  3 Dec 2013 16:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=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 sZizR9rgIVbr; Tue,  3 Dec 2013 16:42:40 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED81ADE89; Tue,  3 Dec 2013 16:42:39 -0800 (PST)
Received: from [85.158.137.99:47914] by server-3.bemta-3.messagelabs.com id C6/C4-10658-C7A7E925; Wed, 04 Dec 2013 00:42:36 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-11.tower-217.messagelabs.com!1386117755!16865677!1
X-Originating-IP: [131.227.200.43]
X-StarScan-Received: 
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2207 invoked from network); 4 Dec 2013 00:42:36 -0000
Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-11.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 4 Dec 2013 00:42:36 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 4 Dec 2013 00:41:58 +0000
From: <l.wood@surrey.ac.uk>
To: <adrian@olddog.co.uk>, <jmpolk@cisco.com>, <ietf@ietf.org>
Date: Wed, 4 Dec 2013 00:40:38 +0000
Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
Thread-Index: AQHzBhEBAL8QRPWOkmQwqhx5/2DF5gEh+IF7mfHekVCAABhwNg==
Message-ID: <290E20B455C66743BE178C5C84F1240847E5103796@EXMB01CMS.surrey.ac.uk>
References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>, <0f5701cef07d$9926acf0$cb7406d0$@olddog.co.uk>
In-Reply-To: <0f5701cef07d$9926acf0$cb7406d0$@olddog.co.uk>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 03 Dec 2013 17:04:23 -0800
Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org
Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2013 00:42:44 -0000

Apply the inverted pyramid, as used in news articles.
http://en.wikipedia.org/wiki/Inverted_pyramid

The last paragraph of the description should have been first, as it is most=
 relevant.

Lloyd Wood
http://sat-net.com/L.Wood/


________________________________________
From: ietf [ietf-bounces@ietf.org] On Behalf Of Adrian Farrel [adrian@olddo=
g.co.uk]
Sent: 03 December 2013 23:15
To: 'James Polk'; ietf@ietf.org
Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com; act=
n@ietf.org
Subject: RE: New Non-WG Mailing List: ACTN -- Abstraction and Control of Tr=
ansport Networks (ACTN)

James,

I'm very sorry about that. I sent the Secretariat a long description when
requesting list creation. See it below.

I will follow up with the Executive Director to find out what happened.

Adrian

=3D=3D=3D

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: 26 November 2013 20:03
To: 'ietf-action@ietf.org'
Cc: iesg@ietf.org; King, Daniel (d.king@lancaster.ac.uk); leeyoung@huawei.c=
om
Subject: FW: Please create and announce a new non-WG mailing list

Hi,

Please create the a new non-working group mailing list as follows...

Name and email address of the submitter:
Young Lee, leeyoung@huawei.com

The name of the list:
Abstraction and Control of Transport Networks (ACTN)

The URL or email address of the list:
actn@ietf.org

Name(s) and email address(es) of the list administrator(s):
Young Lee leeyoung@huawei.com
Daniel King d.king@lancaster.ac.uk

The IETF Area to which the list belongs:
Routing

The URL or other instructions for subscribing to the list:
https://www.ietf.org/mailman/listinfo/actn

The purpose of the list:

Transport networks have a variety of mechanisms to facilitate separation of=
 data
plane and control plane including distributed signaling for path setup and
protection, centralized path computation for planning and traffic engineeri=
ng,
and a range of management and provisioning protocols to configure and activ=
ate
network resources. These mechanisms represent key technologies for enabling
flexible and dynamic networking.

As transport networks evolve, the need to provide network abstraction has
emerged as key requirement for operators; this is in effect virtualization =
of
network resources so that the network is "sliced" for different uses,
applications, services, and clients each being given a different partial vi=
ew of
the total topology and each considering that it is operating with or on a
single, stand-alone and consistent network.

This virtualization is known as Abstraction and Control of Transport Networ=
k
(ACTN) and facilitates:
- Abstraction of underlying network resources to higher-layer applications =
and
users (clients);
- Slicing of network resources, to meet specific application and users
requirements;
- A computation scheme and virtual control capability, via an information m=
odel,
to clients who request network connectivity and bandwidth;
- Coordination of underlying transport layers and presentation as an abstra=
cted
topology to the client;

This mailing list is intended to enable discussion of the architecture,
use-cases/applicability, and requirements that provide abstraction and virt=
ual
control of transport networks to various applications/clients.

> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of James Polk
> Sent: 03 December 2013 19:41
> To: ietf@ietf.org; IETF Announcement List
> Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com;
> actn@ietf.org
> Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of
> Transport Networks (ACTN)
>
> Can this "purpose" have fewer words...?
>
> come on, let us know what's really going on this new list
>
> James
>
> At 11:56 AM 12/3/2013, IETF Secretariat wrote:
> >A new IETF non-working group email list has been created.
> >
> >List address: actn@ietf.org
> >Archive: http://www.ietf.org/mail-archive/web/actn/
> >To subscribe: https://www.ietf.org/mailman/listinfo/actn
> >
> >Purpose: Discussion of Abstraction and Control of Transport Networks
> >(ACTN)
> >
> >For additional information, please contact the list administrators.


From d.king@lancaster.ac.uk  Thu Dec  5 12:57:18 2013
Return-Path: <d.king@lancaster.ac.uk>
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 AAFB81AE0D0 for <actn@ietfa.amsl.com>; Thu,  5 Dec 2013 12:57:18 -0800 (PST)
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 NyQWluE9096L for <actn@ietfa.amsl.com>; Thu,  5 Dec 2013 12:57:15 -0800 (PST)
Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 18BD81ACCDF for <actn@ietf.org>; Thu,  5 Dec 2013 12:57:15 -0800 (PST)
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 <d.king@lancaster.ac.uk>) id 1Vofyx-0007Hx-5T for actn@ietf.org; Thu, 05 Dec 2013 20:57:11 +0000
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.0158.001; Thu, 5 Dec 2013 20:57:10 +0000
From: "King, Daniel" <d.king@lancaster.ac.uk>
To: "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN
Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+Fg==
X-VoiceMessageDuration: 1
Date: Thu, 5 Dec 2013 20:57:09 +0000
Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local>
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_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_"
MIME-Version: 1.0
Subject: [Actn] Definition of "Transport Network" and requirements within the context of ACTN
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 20:57:18 -0000

--_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on =
the where we would apply ACTN, specifically which layer and subsequent tech=
nologies should be targeted/supported. Let's start with a few clarification=
s:

- By "transport network" do we mean server network that provides connectivi=
ty for higher-layer packet networks, clients and applications.

- A number of server network technologies exist at L1, L2, L3.

- Typically these server networks are run evenly to minimise operational ov=
erhead, but lack flexibility/adaptability and dynamic integration with clie=
nt layers/interfaces/applications.

Now let's review some high-level design goals:

- ACTN interfaces with clients/applications (Data Centers, Virtual Network =
Operators, et al.) to allow dynamic/automated connectivity and bandwidth re=
quest setup.

- ACTN provides an abstracted view of the network resources, i.e., the clie=
nt/application is agnostic of the underlying technology used within the tra=
nsport layer.

- ACTN should facilitate the slicing (allocation) of resources, for specifi=
c client interfaces and applications. The abstracted topology should also b=
e flexible (adaptable), and support adaptation as client/application bandwi=
dth and connectivity requirements may change.

Therefore, should we categorize ACTN transport networks as being Connection=
 Orientated (CO) and Traffic Engineered (TE):

- Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE)

- Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE)

And, do we exclude:

Connection-less Packet Switched (CL-PS)?
When we investigate and document use cases (technology or application speci=
fic) might we then focus discussions on ACTN supporting the following techn=
ologies:

- WSON
- OTN
- MPLS-TP
- MPLS-TE

And what about:

- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)

Also, would we need to define a new method, for resource description and re=
source abstraction for each technology. Or reuse something (information and=
 data models) that already exist?

Finally, do we discuss multi-layer scenarios with ACTN providing the capabi=
lity for a client/application to view/use a topology, and also request adap=
tations that are comprised of multiple layers? My concern is that the we do=
 not make the problem/solution search space too wide. At the same time, we =
need to make sure that the ACTN problem statement and proposed Charter incl=
udes near-term, and longer-term requirements.

Br, Dan.

--_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi All, <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">During the ACTN bar-BoF in Vancouver (IETF88) there =
was some discussion on the where we would apply ACTN, specifically which la=
yer and subsequent technologies should be targeted/supported. Let&#8217;s s=
tart with a few clarifications:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- By &#8220;transport network&#8221; do we mean serv=
er network that provides connectivity for higher-layer packet networks, cli=
ents and applications.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- A number of server network technologies exist at L=
1, L2, L3.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- Typically these server networks are run evenly to =
minimise operational overhead, but lack flexibility/adaptability and dynami=
c integration with client layers/interfaces/applications.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Now let&#8217;s review some high-level design goals:=
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- ACTN interfaces with clients/applications (Data Ce=
nters, Virtual Network Operators, et al.) to allow dynamic/automated connec=
tivity and bandwidth request setup.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- ACTN provides an abstracted view of the network re=
sources, i.e., the client/application is agnostic of the underlying technol=
ogy used within the transport layer.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- ACTN should facilitate the slicing (allocation) of=
 resources, for specific client interfaces and applications. The abstracted=
 topology should also be flexible (adaptable), and support adaptation as cl=
ient/application bandwidth and connectivity
 requirements may change. <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Therefore, should we categorize ACTN transport netwo=
rks as being Connection Orientated (CO) and Traffic Engineered (TE):<o:p></=
o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- Connection Oriented Circuit Switched (CO-CS) &amp;=
 Traffic Engineered (TE)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- Connection Oriented Packet Switched (CO-PS) &amp; =
Traffic Engineered (TE)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">And, do we exclude:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Connection-less Packet Switched (CL-PS)?<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">When we investigate and document use cases (technolo=
gy or application specific) might we then focus discussions on ACTN support=
ing the following technologies:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- WSON<o:p></o:p></p>
<p class=3D"MsoNormal">- OTN<o:p></o:p></p>
<p class=3D"MsoNormal">- MPLS-TP<o:p></o:p></p>
<p class=3D"MsoNormal">- MPLS-TE<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">And what about:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- OpenFlow (?)<o:p></o:p></p>
<p class=3D"MsoNormal">- ForCES (?)<o:p></o:p></p>
<p class=3D"MsoNormal">- Segment Routing (?)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Also, would we need to define a new method, for reso=
urce description and resource abstraction for each technology. Or reuse som=
ething (information and data models) that already exist? &nbsp;<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Finally, do we discuss multi-layer scenarios with AC=
TN providing the capability for a client/application to view/use a topology=
, and also request adaptations that are comprised of multiple layers? My co=
ncern is that the we do not make the
 problem/solution search space too wide. At the same time, we need to make =
sure that the ACTN problem statement and proposed Charter includes near-ter=
m, and longer-term requirements.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Br, Dan. <o:p></o:p></p>
</div>
</body>
</html>

--_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_--

From diego.caviglia@ericsson.com  Fri Dec  6 03:58:53 2013
Return-Path: <diego.caviglia@ericsson.com>
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 9A7DE1ADEBB for <actn@ietfa.amsl.com>; Fri,  6 Dec 2013 03:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 s3-vUge7PrOd for <actn@ietfa.amsl.com>; Fri,  6 Dec 2013 03:58:49 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAB1AE36E for <actn@ietf.org>; Fri,  6 Dec 2013 03:58:48 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-4b-52a1bbf4a265
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6B.05.23787.4FBB1A25; Fri,  6 Dec 2013 12:58:44 +0100 (CET)
Received: from ESESSMB103.ericsson.se ([169.254.3.33]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0347.000; Fri, 6 Dec 2013 12:58:43 +0100
From: Diego Caviglia <diego.caviglia@ericsson.com>
To: "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Abstraction and Control of Transport Networks ACTN
Thread-Index: Ac7ydDTEIVTJo/gYQr2jb18xFPX4fg==
Date: Fri, 6 Dec 2013 11:58:43 +0000
Message-ID: <4E9BAD336C18BD49A429157A855607F11C4D9977@ESESSMB103.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.20]
Content-Type: multipart/alternative; boundary="_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre6X3QuDDI5sErPY0nOBzeLFumAH Jo8lS34yeZw6kB7AFMVlk5Kak1mWWqRvl8CVcXL3ZPaC3mbGiu5dv9kaGH8XdTFyckgImEhs mtHJAmGLSVy4t56ti5GLQ0jgEKPEyVO/mUASQgKLGCW2P60AsdkEjCR2dcwEaxARUJZYfPgP G4jNLOAiceH1FbC4sIC1xMP2uawQNQ4S7Q0fmSBsPYld09aB2SwCKhKTnn8Dq+cV8JWYMO88 WJxRQFZiwu5FjBAzxSVuPZnPBHGcgMSSPeeZIWxRiZeP/7FC2IoSV6cvB6rhAKrPl9jzoBZi pKDEyZlPWCYwCs9CMmkWQtUsJFUQJToSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7Kkb23MTM nPRyw02MwOg4uOW37g7GU+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoEx0XNCRkRw6q0D6Wd62+39otxco9cEqV60ljAWXnRh8v4wvYl9sVImy1TnTYiUcNvAG+RS YXZnkeZt2asJy7isPv0IN7aQFLvzJS9TrucNq7DeJoFNfp5/GVi7y/m9/b92zfmp+DAxYc7t 2PAvi6SuRapf11ghPNWstbxRfW5d8CntoIyHfUosxRmJhlrMRcWJAId3aEhcAgAA
Cc: "King, Daniel \(d.king@lancaster.ac.uk\)" <d.king@lancaster.ac.uk>
Subject: [Actn] Abstraction and Control of Transport Networks ACTN
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 11:58:53 -0000

--_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all
           Some comments to the Dan list.

Ciao

D




Hi All,
During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on =
the where we would apply ACTN, specifically which layer and subsequent tech=
nologies should be targeted/supported. Let's start with a few clarification=
s:
- By "transport network" do we mean server network that provides connectivi=
ty for higher-layer packet networks, clients and applications.
[DC] Yes I think is a good definition; we need to promote this a little bit=
 if we would include L3, usually when someone says Transport people think t=
o L0/1
- A number of server network technologies exist at L1, L2, L3.
[DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2=
=3DEth etc etc, L3=3DIP/MPLS
- Typically these server networks are run evenly to minimize operational ov=
erhead, but lack flexibility/adaptability and dynamic integration with clie=
nt layers/interfaces/applications.
[DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di=
rectly driven by client layers/interface/applications but via intermediate =
system e.g. NMS or automated control planes but the "trigger" of the set-up=
 is always in the hand of a human been...well always is may be too strong m=
ost the time is human but very unlikely is linked to any applications
Now let's review some high-level design goals:
- ACTN interfaces with clients/applications (Data Centers, Virtual Network =
Operators, et al.) to allow dynamic/automated connectivity and bandwidth re=
quest setup.
[DC] I would add teardown and modification
- ACTN provides an abstracted view of the network resources, i.e., the clie=
nt/application is agnostic of the underlying technology used within the tra=
nsport layer.
[DC] yes we should define better what we mean with abstract here....won't b=
e easy.
- ACTN should facilitate the slicing (allocation) of resources, for specifi=
c client interfaces and applications. The abstracted topology should also b=
e flexible (adaptable), and support adaptation as client/application bandwi=
dth and connectivity requirements may change.

Therefore, should we categorize ACTN transport networks as being Connection=
 Orientated (CO) and Traffic Engineered (TE):
[DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp.  Sounds g=
ood
- Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE)
[DC] yes
- Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE)
[DC] I think here we'll avoid ATM, PBB-TE etc etc so basically is MPLS(-TP)=
 with RSVP-TE right?
And, do we exclude:
Connection-less Packet Switched (CL-PS)?
[DC] agreed
When we investigate and document use cases (technology or application speci=
fic) might we then focus discussions on ACTN supporting the following techn=
ologies:
- WSON
[DC] hmmm here WSON is a data plane plus a control plane....i would say DWD=
M with or without a GMPLS/PCE based control plane
- OTN
[DC] as above with or without a GMPLS/PCE based control plane
- MPLS-TP
[DC] just the data plane here
- MPLS-TE
[DC] as above, do we want to consider also segment routing here?
And what about:
- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)
[DC]- I2RS (?)
[DC]- PCEP (?)
Also, would we need to define a new method, for resource description and re=
source abstraction for each technology. Or reuse something (information and=
 data models) that already exist?
[DC] I think ONF is doing a lot of work here so we should have a look.
Finally, do we discuss multi-layer scenarios with ACTN providing the capabi=
lity for a client/application to view/use a topology, and also request adap=
tations that are comprised of multiple layers?
[DC] I think this is one of the key point we have to solve and this why I s=
aid the abstraction won't be easy

My concern is that the we do not make the problem/solution search space too=
 wide. At the same time, we need to make sure that the ACTN problem stateme=
nt and proposed Charter includes near-term, and longer-term requirements.
[DC] Yes
Br, Dan.


--_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi all<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Some comments to the Dan list.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Ciao<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">D<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Hi All,
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">During the ACTN bar-BoF in Vancouver (IETF88) ther=
e was some discussion on the where we would apply ACTN, specifically
 which layer and subsequent technologies should be targeted/supported. Let&=
#8217;s start with a few clarifications:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- By &#8220;transport network&#8221; do we mean se=
rver network that provides connectivity for higher-layer packet networks,
 clients and applications. <br>
[DC] Yes I think is a good definition; we need to promote this a little bit=
 if we would include L3, usually when someone says Transport people think t=
o L0/1<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- A number of server network technologies exist at=
 L1, L2, L3.
<br>
[DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2=
=3DEth etc etc, L3=3DIP/MPLS<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Typically these server networks are run evenly t=
o minimize operational overhead, but lack flexibility/adaptability
 and dynamic integration with client layers/interfaces/applications. <br>
[DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di=
rectly driven by client layers/interface/applications but via intermediate =
system e.g. NMS or automated control planes but the &#8220;trigger&#8221; o=
f the set-up is always in the hand of a human
 been&#8230;well always is may be too strong most the time is human but ver=
y unlikely is linked to any applications<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Now let&#8217;s review some high-level design goal=
s:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ACTN interfaces with clients/applications (Data =
Centers, Virtual Network Operators, et al.) to allow dynamic/automated
 connectivity and bandwidth request setup. <br>
[DC] I would add teardown and modification<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ACTN provides an abstracted view of the network =
resources, i.e., the client/application is agnostic of the
 underlying technology used within the transport layer. <br>
[DC] yes we should define better what we mean with abstract here&#8230;.won=
&#8217;t be easy.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ACTN should facilitate the slicing (allocation) =
of resources, for specific client interfaces and applications.
 The abstracted topology should also be flexible (adaptable), and support a=
daptation as client/application bandwidth and connectivity requirements may=
 change.
<br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Therefore, should we categorize ACTN transport net=
works as being Connection Orientated (CO) and Traffic Engineered
 (TE):<br>
[DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp.&nbsp; Sou=
nds good<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Connection Oriented Circuit Switched (CO-CS) &am=
p; Traffic Engineered (TE)<br>
[DC] yes<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Connection Oriented Packet Switched (CO-PS) &amp=
; Traffic Engineered (TE)<br>
[DC] I think here we&#8217;ll avoid ATM, PBB-TE etc etc so basically is MPL=
S(-TP) with RSVP-TE right?<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">And, do we exclude:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Connection-less Packet Switched (CL-PS)?<br>
[DC] agreed<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">When we investigate and document use cases (techno=
logy or application specific) might we then focus discussions
 on ACTN supporting the following technologies:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- WSON<br>
[DC] hmmm here WSON is a data plane plus a control plane&#8230;.i would say=
 DWDM with or without a GMPLS/PCE based control plane<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- OTN<br>
[DC] as above with or without a GMPLS/PCE based control plane<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- MPLS-TP<br>
[DC] just the data plane here<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- MPLS-TE<br>
[DC] as above, do we want to consider also segment routing here?<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">And what about:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- OpenFlow (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ForCES (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Segment Routing (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">[DC]- I2RS (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">[DC]- PCEP (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Also, would we need to define a new method, for re=
source description and resource abstraction for each technology.
 Or reuse something (information and data models) that already exist? <br>
[DC] I think ONF is doing a lot of work here so we should have a look.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Finally, do we discuss multi-layer scenarios with =
ACTN providing the capability for a client/application to
 view/use a topology, and also request adaptations that are comprised of mu=
ltiple layers?<br>
[DC] I think this is one of the key point we have to solve and this why I s=
aid the abstraction won&#8217;t be easy<br>
<br>
My concern is that the we do not make the problem/solution search space too=
 wide. At the same time, we need to make sure that the ACTN problem stateme=
nt and proposed Charter includes near-term, and longer-term requirements.
<br>
[DC] Yes<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Br, Dan.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"IT">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></span>=
</p>
</div>
</body>
</html>

--_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_--

From leeyoung@huawei.com  Fri Dec  6 07:54:35 2013
Return-Path: <leeyoung@huawei.com>
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 1E2C41ADFFB for <actn@ietfa.amsl.com>; Fri,  6 Dec 2013 07:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level: 
X-Spam-Status: No, score=-3.201 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.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 gOXujRJa9Rxt for <actn@ietfa.amsl.com>; Fri,  6 Dec 2013 07:54:30 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5D31ADA5D for <actn@ietf.org>; Fri,  6 Dec 2013 07:54:29 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR85244; Fri, 06 Dec 2013 15:54:24 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 15:53:28 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 15:54:20 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 07:54:18 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "King, Daniel" <d.king@lancaster.ac.uk>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN
Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+FgAmqF0A
Date: Fri, 6 Dec 2013 15:54:17 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com>
References: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local>
In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.134.96]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Actn] Definition of "Transport Network" and requirements within the context of ACTN
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 15:54:35 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dan,

I think this is very useful discussion. Here's my comment inline.

Thanks.
Young

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of King, Daniel
Sent: Thursday, December 05, 2013 2:57 PM
To: actn@ietf.org
Subject: [Actn] Definition of "Transport Network" and requirements within t=
he context of ACTN

Hi All,

During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on =
the where we would apply ACTN, specifically which layer and subsequent tech=
nologies should be targeted/supported. Let's start with a few clarification=
s:

- By "transport network" do we mean server network that provides connectivi=
ty for higher-layer packet networks, clients and applications.

- A number of server network technologies exist at L1, L2, L3.

- Typically these server networks are run evenly to minimise operational ov=
erhead, but lack flexibility/adaptability and dynamic integration with clie=
nt layers/interfaces/applications.

Now let's review some high-level design goals:

- ACTN interfaces with clients/applications (Data Centers, Virtual Network =
Operators, et al.) to allow dynamic/automated connectivity and bandwidth re=
quest setup.

- ACTN provides an abstracted view of the network resources, i.e., the clie=
nt/application is agnostic of the underlying technology used within the tra=
nsport layer.

- ACTN should facilitate the slicing (allocation) of resources, for specifi=
c client interfaces and applications. The abstracted topology should also b=
e flexible (adaptable), and support adaptation as client/application bandwi=
dth and connectivity requirements may change.

YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) =
network-wide abstracted topology and (ii) client-specific abstracted topolo=
gy. The former one is for general usage to include all end-points of the ne=
twork similar to ALTO topology map. Of course, the abstracted topology can =
have a graph form to give a bit more detail than just giving a tunnel view.=
 The latter one is specific to the client in terms of a set of limited clie=
nt-end points, client's objective function (this means client has a certain=
 service objective such as delay, bandwidth, reliability of paths, etc) as =
well as the abstraction level. Some client may want to see just a tunnel vi=
ew (similar to ALTO topology map) while other clients may want to see more =
detail than a tunnel view.

YOUNG>> Basically, the interface facing clients should be able to support t=
his programmable aspects of the client-specificity. As you said, this inter=
face and abstracted topology should be flexible/adaptable and there should =
a mechanism to support changes to topology from physical to abstracted. Thi=
s interaction makes this work very interesting, I think.

Therefore, should we categorize ACTN transport networks as being Connection=
 Orientated (CO) and Traffic Engineered (TE):

- Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE)

- Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE)

YOUNG>> I think this is a good starting point. The underlying transport net=
works should be able to "guarantee" network resource committed to the clien=
t when client makes use of them. From that angle, TE-based transport networ=
ks make sense as a starting point. Also when network releases abstract topo=
logy to the clients, the link characteristics should tell some resource inf=
ormation about the network. TE-metric is a good way to say that.

And, do we exclude:

Connection-less Packet Switched (CL-PS)?


When we investigate and document use cases (technology or application speci=
fic) might we then focus discussions on ACTN supporting the following techn=
ologies:

- WSON
- OTN
- MPLS-TP
- MPLS-TE

And what about:

- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)

YOUNG>>  As long as any of these can support traffic engineering principle,=
 we can include them, especially SR. I am not sure OF and ForCES as they ar=
e just protocols, not data plane technologies.

Also, would we need to define a new method, for resource description and re=
source abstraction for each technology. Or reuse something (information and=
 data models) that already exist?

YOUNG>> There is some work in ALTO area based on JSON encoding. If we can r=
e-use some existing framework.

Finally, do we discuss multi-layer scenarios with ACTN providing the capabi=
lity for a client/application to view/use a topology, and also request adap=
tations that are comprised of multiple layers? My concern is that the we do=
 not make the problem/solution search space too wide. At the same time, we =
need to make sure that the ACTN problem statement and proposed Charter incl=
udes near-term, and longer-term requirements.

YOUNG>> I agree.

Br, Dan.

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Dan,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I think this is very u=
seful discussion. Here&#8217;s my comment inline.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Young<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ACTN [ma=
ilto:actn-bounces@ietf.org]
<b>On Behalf Of </b>King, Daniel<br>
<b>Sent:</b> Thursday, December 05, 2013 2:57 PM<br>
<b>To:</b> actn@ietf.org<br>
<b>Subject:</b> [Actn] Definition of &quot;Transport Network&quot; and requ=
irements within the context of ACTN<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Hi All, <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">During the ACTN bar-BoF in Vanc=
ouver (IETF88) there was some discussion on the where we would apply ACTN, =
specifically which layer and subsequent technologies should be targeted/sup=
ported. Let&#8217;s start with a few clarifications:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- By &#8220;transport network&#=
8221; do we mean server network that provides connectivity for higher-layer=
 packet networks, clients and applications.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- A number of server network te=
chnologies exist at L1, L2, L3.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- Typically these server networ=
ks are run evenly to minimise operational overhead, but lack flexibility/ad=
aptability and dynamic integration with client layers/interfaces/applicatio=
ns.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Now let&#8217;s review some hig=
h-level design goals:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- ACTN interfaces with clients/=
applications (Data Centers, Virtual Network Operators, et al.) to allow dyn=
amic/automated connectivity and bandwidth request setup.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- ACTN provides an abstracted v=
iew of the network resources, i.e., the client/application is agnostic of t=
he underlying technology used within the transport layer.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- ACTN should facilitate the sl=
icing (allocation) of resources, for specific client interfaces and applica=
tions. The abstracted topology should also be flexible (adaptable), and sup=
port adaptation as client/application
 bandwidth and connectivity requirements may change. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes. The abstracted topology has two types generally speaking: (i) n=
etwork-wide abstracted topology and (ii) client-specific abstracted topolog=
y. The former one is for general usage to include
 all end-points of the network similar to ALTO topology map. Of course, the=
 abstracted topology can have a graph form to give a bit more detail than j=
ust giving a tunnel view. The latter one is specific to the client in terms=
 of a set of limited client-end
 points, client&#8217;s objective function (this means client has a certain=
 service objective such as delay, bandwidth, reliability of paths, etc) as =
well as the abstraction level. Some client may want to see just a tunnel vi=
ew (similar to ALTO topology map) while
 other clients may want to see more detail than a tunnel view. <o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Basically, the interface facing clients should be able to support th=
is programmable aspects of the client-specificity. As you said, this interf=
ace and abstracted topology should be flexible/adaptable
 and there should a mechanism to support changes to topology from physical =
to abstracted. This interaction makes this work very interesting, I think.<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Therefore, should we categorize=
 ACTN transport networks as being Connection Orientated (CO) and Traffic En=
gineered (TE):<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- Connection Oriented Circuit S=
witched (CO-CS) &amp; Traffic Engineered (TE)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- Connection Oriented Packet Sw=
itched (CO-PS) &amp; Traffic Engineered (TE)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">YOUNG&g=
t;&gt; I think this is a good starting point. The underlying transport netw=
orks should be able to &#8220;guarantee&#8221; network resource committed t=
o the client when client makes use of them. From that angle,
 TE-based transport networks make sense as a starting point. Also when netw=
ork releases abstract topology to the clients, the link characteristics sho=
uld tell some resource information about the network. TE-metric is a good w=
ay to say that.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">And, do we exclude:<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Connection-less Packet Switched=
 (CL-PS)?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#17365D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">When we investigate and documen=
t use cases (technology or application specific) might we then focus discus=
sions on ACTN supporting the following technologies:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- WSON<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- OTN<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- MPLS-TP<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- MPLS-TE<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">And what about:<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- OpenFlow (?)<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- ForCES (?)<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- Segment Routing (?)<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#17365D">YOUNG&g=
t;&gt; &nbsp;As long as any of these can support traffic engineering princi=
ple, we can include them, especially SR. I am not sure OF and ForCES as the=
y are just protocols, not data plane technologies.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#17365D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Also, would we need to define a=
 new method, for resource description and resource abstraction for each tec=
hnology. Or reuse something (information and data models) that already exis=
t? &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#17365D">YOUNG&g=
t;&gt; There is some work in ALTO area based on JSON encoding. If we can re=
-use some existing framework.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Finally, do we discuss multi-la=
yer scenarios with ACTN providing the capability for a client/application t=
o view/use a topology, and also request adaptations that are comprised of m=
ultiple layers? My concern is that the
 we do not make the problem/solution search space too wide. At the same tim=
e, we need to make sure that the ACTN problem statement and proposed Charte=
r includes near-term, and longer-term requirements.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#17365D">YOUNG&g=
t;&gt; I agree. <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Br, Dan. <o:p></o:p></span></p>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_--

From leeyoung@huawei.com  Fri Dec  6 09:25:54 2013
Return-Path: <leeyoung@huawei.com>
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 335F61ADF6E for <actn@ietfa.amsl.com>; Fri,  6 Dec 2013 09:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level: 
X-Spam-Status: No, score=-3.201 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.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 QslzrTyQtxUN for <actn@ietfa.amsl.com>; Fri,  6 Dec 2013 09:25:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 607E21AD83F for <actn@ietf.org>; Fri,  6 Dec 2013 09:25:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBC13827; Fri, 06 Dec 2013 17:25:43 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 17:24:49 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 17:25:42 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 09:25:39 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Diego Caviglia <diego.caviglia@ericsson.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Abstraction and Control of Transport Networks ACTN
Thread-Index: Ac7ydDTEIVTJo/gYQr2jb18xFPX4fgAKWN+A
Date: Fri, 6 Dec 2013 17:25:38 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9C23E@dfweml510-mbx.china.huawei.com>
References: <4E9BAD336C18BD49A429157A855607F11C4D9977@ESESSMB103.ericsson.se>
In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C4D9977@ESESSMB103.ericsson.se>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.134.96]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "King, Daniel \(d.king@lancaster.ac.uk\)" <d.king@lancaster.ac.uk>
Subject: Re: [Actn] Abstraction and Control of Transport Networks ACTN
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 17:25:54 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Diego,

Great discussion. Please see my comment inline.

Regards,
Young

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Diego Caviglia
Sent: Friday, December 06, 2013 5:59 AM
To: actn@ietf.org
Cc: King, Daniel (d.king@lancaster.ac.uk)
Subject: [Actn] Abstraction and Control of Transport Networks ACTN

Hi all
           Some comments to the Dan list.

Ciao

D




Hi All,
During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on =
the where we would apply ACTN, specifically which layer and subsequent tech=
nologies should be targeted/supported. Let's start with a few clarification=
s:
- By "transport network" do we mean server network that provides connectivi=
ty for higher-layer packet networks, clients and applications.
[DC] Yes I think is a good definition; we need to promote this a little bit=
 if we would include L3, usually when someone says Transport people think t=
o L0/1
YOUNG>>  "transport network" defined as connectivity for HL packet networks=
, clients and applications is a good definition, beyond just packet network=
s. Packet networks themselves can also be a server 'transport network' to c=
lients/applications. In that sense, we have a wider scope of what 'transpor=
t network' is. But we have to recognize the nature of applications/clients =
may differ as to what 'transport' service they choose. For best-effort appl=
ications, L3 transport may be adequate; for services/applications needing s=
tringent QoS and resource reservations/guarantee, TE-based transport may be=
 adequate.
The point is that the driver is the requirement of clients/applications.
- A number of server network technologies exist at L1, L2, L3.
[DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2=
=3DEth etc etc, L3=3DIP/MPLS
- Typically these server networks are run evenly to minimize operational ov=
erhead, but lack flexibility/adaptability and dynamic integration with clie=
nt layers/interfaces/applications.
[DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di=
rectly driven by client layers/interface/applications but via intermediate =
system e.g. NMS or automated control planes but the "trigger" of the set-up=
 is always in the hand of a human been...well always is may be too strong m=
ost the time is human but very unlikely is linked to any applications
YOUNG>> This is a good point. There is a need for an intermediate system su=
ch as "mediation layer" or "virtualization layer" between client/applicatio=
n and the transport network that can support programmable interfaces. This =
programmable intermediate system is neither NMS nor automated control plane=
s. This is 'shim' layer that facilitates the activity of NMS or automated c=
ontrol planes.
Now let's review some high-level design goals:
- ACTN interfaces with clients/applications (Data Centers, Virtual Network =
Operators, et al.) to allow dynamic/automated connectivity and bandwidth re=
quest setup.
[DC] I would add teardown and modification
YOUNG>> Agree. In addition to this, I see the value for monitoring/notifica=
tion between transport networks and clients/applications.
- ACTN provides an abstracted view of the network resources, i.e., the clie=
nt/application is agnostic of the underlying technology used within the tra=
nsport layer.
[DC] yes we should define better what we mean with abstract here....won't b=
e easy.
YOUNG>> Yes, this is one of the most important work items as to how to char=
acterize/define abstraction. There are two issues: (i) how to represent the=
 underlying resource into applications - this is information/data model; (i=
i) how to efficiently map between physical resources and virtual resources =
and how accurate the abstraction is --- this is about compute model and alg=
orithm. This aspect is a research item that needs to be worked out in paral=
lel with the info/data model. The compute model and algorithm work is perha=
ps addressed in SDN RG in parallel to ACTN.
- ACTN should facilitate the slicing (allocation) of resources, for specifi=
c client interfaces and applications. The abstracted topology should also b=
e flexible (adaptable), and support adaptation as client/application bandwi=
dth and connectivity requirements may change.
Therefore, should we categorize ACTN transport networks as being Connection=
 Orientated (CO) and Traffic Engineered (TE):
[DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp.  Sounds g=
ood
YOUNG>> I agree.
- Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE)
[DC] yes
- Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE)
[DC] I think here we'll avoid ATM, PBB-TE etc etc so basically is MPLS(-TP)=
 with RSVP-TE right?
And, do we exclude:
Connection-less Packet Switched (CL-PS)?
[DC] agreed
When we investigate and document use cases (technology or application speci=
fic) might we then focus discussions on ACTN supporting the following techn=
ologies:
- WSON
[DC] hmmm here WSON is a data plane plus a control plane....i would say DWD=
M with or without a GMPLS/PCE based control plane
- OTN
[DC] as above with or without a GMPLS/PCE based control plane
- MPLS-TP
[DC] just the data plane here
- MPLS-TE
[DC] as above, do we want to consider also segment routing here?
And what about:
- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)
[DC]- I2RS (?)
[DC]- PCEP (?)
Also, would we need to define a new method, for resource description and re=
source abstraction for each technology. Or reuse something (information and=
 data models) that already exist?
[DC] I think ONF is doing a lot of work here so we should have a look.
Finally, do we discuss multi-layer scenarios with ACTN providing the capabi=
lity for a client/application to view/use a topology, and also request adap=
tations that are comprised of multiple layers?
[DC] I think this is one of the key point we have to solve and this why I s=
aid the abstraction won't be easy
YOUNG>> Yes, we discussed this aspect earlier.

My concern is that the we do not make the problem/solution search space too=
 wide. At the same time, we need to make sure that the ACTN problem stateme=
nt and proposed Charter includes near-term, and longer-term requirements.
[DC] Yes
Br, Dan.


--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Diego,<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Great discussion. Plea=
se see my comment inline.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Regards,<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Young<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ACTN [ma=
ilto:actn-bounces@ietf.org]
<b>On Behalf Of </b>Diego Caviglia<br>
<b>Sent:</b> Friday, December 06, 2013 5:59 AM<br>
<b>To:</b> actn@ietf.org<br>
<b>Cc:</b> King, Daniel (d.king@lancaster.ac.uk)<br>
<b>Subject:</b> [Actn] Abstraction and Control of Transport Networks ACTN<o=
:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi all<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Some comments to the Dan list.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Ciao<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">D<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Hi All,
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">During the ACTN bar-BoF in Vancouver (IETF88) ther=
e was some discussion on the where we would apply ACTN, specifically
 which layer and subsequent technologies should be targeted/supported. Let&=
#8217;s start with a few clarifications:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- By &#8220;transport network&#8221; do we mean se=
rver network that provides connectivity for higher-layer packet networks,
 clients and applications. <br>
[DC] Yes I think is a good definition; we need to promote this a little bit=
 if we would include L3, usually when someone says Transport people think t=
o L0/1<span style=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">YOUNG&gt;&gt; &nbsp;&#8220;transport=
 network&#8221; defined as connectivity for HL packet networks, clients and=
 applications is a good definition, beyond just packet networks.
 Packet networks themselves can also be a server &#8216;transport network&#=
8217; to clients/applications. In that sense, we have a wider scope of what=
 &#8216;transport network&#8217; is. But we have to recognize the nature of=
 applications/clients may differ as to what &#8216;transport&#8217;
 service they choose. For best-effort applications, L3 transport may be ade=
quate; for services/applications needing stringent QoS and resource reserva=
tions/guarantee, TE-based transport may be adequate.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">The point is that the driver is the =
requirement of clients/applications.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- A number of server network technologies exist at=
 L1, L2, L3.
<br>
[DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2=
=3DEth etc etc, L3=3DIP/MPLS<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Typically these server networks are run evenly t=
o minimize operational overhead, but lack flexibility/adaptability
 and dynamic integration with client layers/interfaces/applications. <br>
[DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di=
rectly driven by client layers/interface/applications but via intermediate =
system e.g. NMS or automated control planes but the &#8220;trigger&#8221; o=
f the set-up is always in the hand of a human
 been&#8230;well always is may be too strong most the time is human but ver=
y unlikely is linked to any applications<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">YOUNG&gt;&gt; This is a good point. =
There is a need for an intermediate system such as &#8220;mediation layer&#=
8221; or &#8220;virtualization layer&#8221; between client/application
 and the transport network that can support programmable interfaces. This p=
rogrammable intermediate system is neither NMS nor automated control planes=
. This is &#8216;shim&#8217; layer that facilitates the activity of NMS or =
automated control planes.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Now let&#8217;s review some high-level design goal=
s:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ACTN interfaces with clients/applications (Data =
Centers, Virtual Network Operators, et al.) to allow dynamic/automated
 connectivity and bandwidth request setup. <br>
[DC] I would add teardown and modification<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Agree. In addition to =
this, I see the value for monitoring/notification between transport network=
s and clients/applications. &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ACTN provides an abstracted view of the network =
resources, i.e., the client/application is agnostic of the
 underlying technology used within the transport layer. <br>
[DC] yes we should define better what we mean with abstract here&#8230;.won=
&#8217;t be easy.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Yes, this is one of th=
e most important work items as to how to characterize/define abstraction. T=
here are two issues: (i) how to represent the
 underlying resource into applications &#8211; this is information/data mod=
el; (ii) how to efficiently map between physical resources and virtual reso=
urces and how accurate the abstraction is --- this is about compute model a=
nd algorithm. This aspect is a research
 item that needs to be worked out in parallel with the info/data model. The=
 compute model and algorithm work is perhaps addressed in SDN RG in paralle=
l to ACTN.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=
t"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&quot;,=
&quot;serif&quot;">- ACTN should facilitate the slicing (allocation) of res=
ources, for specific client interfaces and applications. The
 abstracted topology should also be flexible (adaptable), and support adapt=
ation as client/application bandwidth and connectivity requirements may cha=
nge.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Therefore, should we categorize ACTN transport net=
works as being Connection Orientated (CO) and Traffic Engineered
 (TE):<br>
[DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp.&nbsp; Sou=
nds good<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">YOUNG&gt;&gt; I agree.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Connection Oriented Circuit Switched (CO-CS) &am=
p; Traffic Engineered (TE)<br>
[DC] yes<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Connection Oriented Packet Switched (CO-PS) &amp=
; Traffic Engineered (TE)<br>
[DC] I think here we&#8217;ll avoid ATM, PBB-TE etc etc so basically is MPL=
S(-TP) with RSVP-TE right?<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">And, do we exclude:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Connection-less Packet Switched (CL-PS)?<br>
[DC] agreed<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">When we investigate and document use cases (techno=
logy or application specific) might we then focus discussions
 on ACTN supporting the following technologies:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- WSON<br>
[DC] hmmm here WSON is a data plane plus a control plane&#8230;.i would say=
 DWDM with or without a GMPLS/PCE based control plane<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- OTN<br>
[DC] as above with or without a GMPLS/PCE based control plane<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- MPLS-TP<br>
[DC] just the data plane here<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- MPLS-TE<br>
[DC] as above, do we want to consider also segment routing here?<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">And what about:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- OpenFlow (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- ForCES (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">- Segment Routing (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">[DC]- I2RS (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">[DC]- PCEP (?)<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Also, would we need to define a new method, for re=
source description and resource abstraction for each technology.
 Or reuse something (information and data models) that already exist? <br>
[DC] I think ONF is doing a lot of work here so we should have a look.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Finally, do we discuss multi-layer scenarios with =
ACTN providing the capability for a client/application to
 view/use a topology, and also request adaptations that are comprised of mu=
ltiple layers?<br>
[DC] I think this is one of the key point we have to solve and this why I s=
aid the abstraction won&#8217;t be easy<span style=3D"color:#1F497D"><o:p><=
/o:p></span></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Yes, we discussed this=
 aspect earlier.
</span><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&qu=
ot;,&quot;serif&quot;"><br>
<br>
My concern is that the we do not make the problem/solution search space too=
 wide. At the same time, we need to make sure that the ACTN problem stateme=
nt and proposed Charter includes near-term, and longer-term requirements.
<br>
[DC] Yes</span><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&=
quot;,&quot;serif&quot;">Br, Dan.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"IT">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></span>=
</p>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_--

From dhruv.dhody@huawei.com  Sun Dec  8 20:03:01 2013
Return-Path: <dhruv.dhody@huawei.com>
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 BD24B1AC7F1 for <actn@ietfa.amsl.com>; Sun,  8 Dec 2013 20:03:01 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 caYU5yRRpjjE for <actn@ietfa.amsl.com>; Sun,  8 Dec 2013 20:02:59 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97C1AE1C7 for <actn@ietf.org>; Sun,  8 Dec 2013 20:02:58 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT33775; Mon, 09 Dec 2013 04:02:53 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 04:02:49 +0000
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 04:02:51 +0000
Received: from szxeml556-mbs.china.huawei.com ([169.254.4.227]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 12:02:39 +0800
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Leeyoung <leeyoung@huawei.com>, "King, Daniel" <d.king@lancaster.ac.uk>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN
Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+FgAmqF0AAH7pHMA=
Date: Mon, 9 Dec 2013 04:02:38 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B52143CB7@szxeml556-mbs.china.huawei.com>
References: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.146.248]
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Actn] Definition of "Transport Network" and requirements within the context of ACTN
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 04:03:01 -0000

--_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Young,

(snip)

- ACTN should facilitate the slicing (allocation) of resources, for specifi=
c client interfaces and applications. The abstracted topology should also b=
e flexible (adaptable), and support adaptation as client/application bandwi=
dth and connectivity requirements may change.

YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) =
network-wide abstracted topology and (ii) client-specific abstracted topolo=
gy. The former one is for general usage to include all end-points of the ne=
twork similar to ALTO topology map. Of course, the abstracted topology can =
have a graph form to give a bit more detail than just giving a tunnel view.=
 The latter one is specific to the client in terms of a set of limited clie=
nt-end points, client's objective function (this means client has a certain=
 service objective such as delay, bandwidth, reliability of paths, etc) as =
well as the abstraction level. Some client may want to see just a tunnel vi=
ew (similar to ALTO topology map) while other clients may want to see more =
detail than a tunnel view.

[DD] Is (i) network-wide abstracted topology in scope of ACTN? Do you have =
some use-case in mind for this?
Conceptually I think (i) is just a special case of (ii) with all end-points=
 in network and no specific constraints.

(snip)

Regards,
Dhruv

--_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Candara;
	panose-1:2 14 5 2 3 3 3 2 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Candara","sans-serif";
	color:#993366;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Candara&quot;,&quot=
;sans-serif&quot;;color:#993366">Hi Young,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Candara&quot;,&quot=
;sans-serif&quot;;color:#993366"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Candara&quot;,&quot=
;sans-serif&quot;;color:#993366">(snip)<o:p></o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- ACTN should facilitate the sl=
icing (allocation) of resources, for specific client interfaces and applica=
tions. The abstracted topology should also be flexible (adaptable), and sup=
port adaptation as client/application
 bandwidth and connectivity requirements may change. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes. The abstracted topology has two types generally speaking: (i) n=
etwork-wide abstracted topology and (ii) client-specific abstracted topolog=
y. The former one is for general usage to include
 all end-points of the network similar to ALTO topology map. Of course, the=
 abstracted topology can have a graph form to give a bit more detail than j=
ust giving a tunnel view. The latter one is specific to the client in terms=
 of a set of limited client-end
 points, client&#8217;s objective function (this means client has a certain=
 service objective such as delay, bandwidth, reliability of paths, etc) as =
well as the abstraction level. Some client may want to see just a tunnel vi=
ew (similar to ALTO topology map) while
 other clients may want to see more detail than a tunnel view. <o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#993366"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-GB" style=3D"font-family:&quo=
t;Candara&quot;,&quot;sans-serif&quot;;color:#993366">[DD] Is (i) network-w=
ide abstracted topology in scope of ACTN? Do you have some use-case in mind=
 for this?
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-GB" style=3D"font-family:&quo=
t;Candara&quot;,&quot;sans-serif&quot;;color:#993366">Conceptually I think =
(i) is just a special case of (ii) with all end-points in network and no sp=
ecific constraints.
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366">(snip)<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366">Regards,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366">Dhruv<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_--

From leeyoung@huawei.com  Mon Dec  9 08:23:34 2013
Return-Path: <leeyoung@huawei.com>
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 1349F1AE313 for <actn@ietfa.amsl.com>; Mon,  9 Dec 2013 08:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level: 
X-Spam-Status: No, score=-3.201 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.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 R77lNtC_8cVi for <actn@ietfa.amsl.com>; Mon,  9 Dec 2013 08:23:29 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4E1AE2C0 for <actn@ietf.org>; Mon,  9 Dec 2013 08:23:28 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYU01754; Mon, 09 Dec 2013 16:23:22 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 16:23:17 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 16:23:21 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 08:23:12 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>, "King, Daniel" <d.king@lancaster.ac.uk>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN
Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+FgAmqF0AAH7pHMAAGWAHoA==
Date: Mon, 9 Dec 2013 16:23:12 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA2042@dfweml510-mbx.china.huawei.com>
References: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com> <23CE718903A838468A8B325B80962F9B52143CB7@szxeml556-mbs.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B52143CB7@szxeml556-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.236]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Actn] Definition of "Transport Network" and requirements within the context of ACTN
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 16:23:34 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dhruv,

What I was envisioning on a network-wide abstracted topology is a repositor=
y of the baseline network resource view which derives from physical network=
 resource view. As you said, there is no specific constraints on this topol=
ogy with all end-points.

Perhaps, client-specific abstracted topology is a special of this general n=
etwork-wide abstracted topology.

>From this network-wide abstracted topology, each client-specific abstracted=
 topology is derived. As network resource is sliced to the list of clients,=
 this network-wide abstracted topology is updated so that it gives the holi=
stic network resource availability.

If the client is a packet network administration/controller which  has the =
same administrative domain as the optical transport network, then the packe=
t network administrator may want inquire the network-wide abstracted topolo=
gy for its operation.  There may be other cases where this network-wide abs=
tracted topology may be useful to share under policy and security constrain=
ts.

Please note that this network-wide abstracted topology is different from a =
physical network topology. The virtual network controller needs to maintain=
 this "master" DB to administer its virtual network control capability to i=
ts clients.

Regards,
Young

From: Dhruv Dhody
Sent: Sunday, December 08, 2013 10:03 PM
To: Leeyoung; King, Daniel; actn@ietf.org
Subject: RE: Definition of "Transport Network" and requirements within the =
context of ACTN

Hi Young,

(snip)

- ACTN should facilitate the slicing (allocation) of resources, for specifi=
c client interfaces and applications. The abstracted topology should also b=
e flexible (adaptable), and support adaptation as client/application bandwi=
dth and connectivity requirements may change.

YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) =
network-wide abstracted topology and (ii) client-specific abstracted topolo=
gy. The former one is for general usage to include all end-points of the ne=
twork similar to ALTO topology map. Of course, the abstracted topology can =
have a graph form to give a bit more detail than just giving a tunnel view.=
 The latter one is specific to the client in terms of a set of limited clie=
nt-end points, client's objective function (this means client has a certain=
 service objective such as delay, bandwidth, reliability of paths, etc) as =
well as the abstraction level. Some client may want to see just a tunnel vi=
ew (similar to ALTO topology map) while other clients may want to see more =
detail than a tunnel view.

[DD] Is (i) network-wide abstracted topology in scope of ACTN? Do you have =
some use-case in mind for this?
Conceptually I think (i) is just a special case of (ii) with all end-points=
 in network and no specific constraints.

(snip)

Regards,
Dhruv

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Candara;
	panose-1:2 14 5 2 3 3 3 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Candara","sans-serif";
	color:#993366;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Dhruv,<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">What I was envisioning=
 on a network-wide abstracted topology is a repository of the baseline netw=
ork resource view which derives from physical network resource view. As you=
 said, there is no specific constraints
 on this topology with all end-points. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Perhaps, client-specif=
ic abstracted topology is a special of this general network-wide abstracted=
 topology.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">From this network-wide=
 abstracted topology, each client-specific abstracted topology is derived. =
As network resource is sliced to the list of clients, this network-wide abs=
tracted topology is updated so that
 it gives the holistic network resource availability. <o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">If the client is a pac=
ket network administration/controller which &nbsp;has the same administrati=
ve domain as the optical transport network, then the packet network adminis=
trator may want inquire the network-wide
 abstracted topology for its operation.&nbsp; There may be other cases wher=
e this network-wide abstracted topology may be useful to share under policy=
 and security constraints.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Please note that this =
network-wide abstracted topology is different from a physical network topol=
ogy. The virtual network controller needs to maintain this &#8220;master&#8=
221; DB to administer its virtual network control
 capability to its clients.&nbsp; <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Regards,<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Young<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Dhruv Dh=
ody
<br>
<b>Sent:</b> Sunday, December 08, 2013 10:03 PM<br>
<b>To:</b> Leeyoung; King, Daniel; actn@ietf.org<br>
<b>Subject:</b> RE: Definition of &quot;Transport Network&quot; and require=
ments within the context of ACTN<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Candara&quot;,&quot=
;sans-serif&quot;;color:#993366">Hi Young,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Candara&quot;,&quot=
;sans-serif&quot;;color:#993366"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Candara&quot;,&quot=
;sans-serif&quot;;color:#993366">(snip)<o:p></o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">- ACTN should facilitate the sl=
icing (allocation) of resources, for specific client interfaces and applica=
tions. The abstracted topology should also be flexible (adaptable), and sup=
port adaptation as client/application
 bandwidth and connectivity requirements may change. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes. The abstracted topology has two types generally speaking: (i) n=
etwork-wide abstracted topology and (ii) client-specific abstracted topolog=
y. The former one is for general usage to include
 all end-points of the network similar to ALTO topology map. Of course, the=
 abstracted topology can have a graph form to give a bit more detail than j=
ust giving a tunnel view. The latter one is specific to the client in terms=
 of a set of limited client-end
 points, client&#8217;s objective function (this means client has a certain=
 service objective such as delay, bandwidth, reliability of paths, etc) as =
well as the abstraction level. Some client may want to see just a tunnel vi=
ew (similar to ALTO topology map) while
 other clients may want to see more detail than a tunnel view. <o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#993366"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-GB" style=3D"font-family:&quo=
t;Candara&quot;,&quot;sans-serif&quot;;color:#993366">[DD] Is (i) network-w=
ide abstracted topology in scope of ACTN? Do you have some use-case in mind=
 for this?
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-GB" style=3D"font-family:&quo=
t;Candara&quot;,&quot;sans-serif&quot;;color:#993366">Conceptually I think =
(i) is just a special case of (ii) with all end-points in network and no sp=
ecific constraints.
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366">(snip)<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366">Regards,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-family:&quot;Cand=
ara&quot;,&quot;sans-serif&quot;;color:#993366">Dhruv<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_--

From leeyoung@huawei.com  Tue Dec 17 08:34:32 2013
Return-Path: <leeyoung@huawei.com>
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 BD2491AE1B6 for <actn@ietfa.amsl.com>; Tue, 17 Dec 2013 08:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable
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 pt7PFTXdHORd for <actn@ietfa.amsl.com>; Tue, 17 Dec 2013 08:34:29 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBFCF1AE1C7 for <actn@ietf.org>; Tue, 17 Dec 2013 08:34:26 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC49490; Tue, 17 Dec 2013 16:34:25 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 16:33:58 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 16:34:24 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 08:34:20 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "actn@ietf.org" <actn@ietf.org>
Thread-Topic: virtual network mapping/embedding (VNM/VNE)  problem 
Thread-Index: Ac77RdTjI/gEkOJNRuyLHsDiwda0eQ==
Date: Tue, 17 Dec 2013 16:34:19 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.236]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "sdn@irtf.org" <sdn@irtf.org>
Subject: [Actn] virtual network mapping/embedding (VNM/VNE)  problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 16:34:33 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Related to the ACTN work, there has been active research termed "virtual ne=
twork mapping/embedding (VNM/VNE)":

Here's some pointer to key papers:

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and=
 path migration)
http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf=
 (survivable VNE)
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef=
ficient VNE)

The focus of ACTN perhaps does not have a direct bearing with these papers =
as they are concerned about the VNM/VNE algorithms; however, these bring so=
me key issues and constraints for virtual network path computation. These i=
ssues and constraints should be of interest of the ACTN work that may impac=
t on the design, information models and interface/protocol extensions (if n=
ecessary).  Some of the issues such as efficiency of algorithm are perhaps =
better fit to SDN RG,  some of key issues and constraints for virtual netwo=
rk path computation related to VNM/VNE are as follows:

-   Request Processing
This is concerned about whether a set of client requests for VN creation ca=
n be dealt with simultaneously or not. This depends on the nature of applic=
ations the client support. If the client does not require real-time instant=
iation of VN creation, the computation engine can process a set of VN creat=
ion requests simultaneously to improve network efficiency.

-   Types of Network Resources
When client makes a VN creation request to the substrate network, what kind=
 of network resources is consumed is of concern of both the client and netw=
ork providers. It depends on the application. For transport network virtual=
ization, the network resource consumed by the client is primarily network b=
andwidth that the paths would occupy on the physical link. However, there m=
ay be other resource types such as CPU and memory that need to be considere=
d for certain applications. These resource types are a part of the client's=
 VN request.

-   Accuracy of Network Resource Representation
As the underlying transport network in itself may consists of layered struc=
ture, it is a challenge how to represent these underlying physical network =
resources and topology into a form that can be reliably used by the computa=
tion engine that assigns the client requests into the physical network reso=
urce and topology.

-   Resource Efficiency
Related to the accuracy of network resource representation is resource effi=
ciency. As a set of independent client VN is created and mapped onto physic=
al network resources, the overall network resource utilization is of the pr=
imary concern of the infrastructure provider.

-   Guarantee of Client Isolation
While network resource sharing across a set of clients for efficient utiliz=
ation is important aspect of network virtualization, client isolation has t=
o be guaranteed. Admissions of new client requests or any changes of other =
existing clients' VNs must not affect any particular client in terms of res=
ource guarantee, security constraints, and other performance constraints.

-   Computing Time
Depending on the nature of applications, how quickly a VN is instantiated f=
rom the time of request is an important factor. For dynamic applications th=
at require instantaneous VN creation, the computation model/algorithm shoul=
d support this constraint.

-   Admission Control
To coordinate the request process of multiple clients, an admission control=
 will help maximize an overall efficiency.

-   Path Constraints
There may be some factors of path constraints that can affect the overall e=
fficiency. Path Split can lower VN request blocking if the underlying netwo=
rk can support such capability. Packet-based TE network can support path sp=
lit while circuit-based transport may have a limitation.  Path migration is=
 a technique that allows changes of nodes or links assignment of the establ=
ished paths in an effort to accommodate new requests which would not be acc=
epted without path migration. This can improve overall efficiency, yet addi=
tional care needs to be applied to avoid any adverse impacts associated wit=
h changing the existing paths.
Re-optimization is a global process to re-shuffle all existing path assignm=
ent to minimize network resource fragmentation. Again, an extra care needs =
to be applied for re-optimization.



--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-link:"Heading 1 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level1 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h2
	{mso-style-link:"Heading 2 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level2 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h3
	{mso-style-link:"Heading 3 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:80.1pt;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level3 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h4
	{mso-style-link:"Heading 4 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level4 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h5
	{mso-style-link:"Heading 5 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level5 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h6
	{mso-style-link:"Heading 6 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level6 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-link:"Heading 7 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level7 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-link:"Heading 8 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level8 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-link:"Heading 9 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level9 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-link:"Heading 1";
	font-family:"Courier New";}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-link:"Heading 2";
	font-family:"Courier New";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-link:"Heading 3";
	font-family:"Courier New";}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-link:"Heading 4";
	font-family:"Courier New";}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-link:"Heading 5";
	font-family:"Courier New";}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-link:"Heading 6";
	font-family:"Courier New";}
span.Heading7Char
	{mso-style-name:"Heading 7 Char";
	mso-style-link:"Heading 7";
	font-family:"Courier New";}
span.Heading8Char
	{mso-style-name:"Heading 8 Char";
	mso-style-link:"Heading 8";
	font-family:"Courier New";}
span.Heading9Char
	{mso-style-name:"Heading 9 Char";
	mso-style-link:"Heading 9";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:730737984;
	mso-list-template-ids:-1479607216;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-suffix:none;
	mso-level-text:"%1\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;
	mso-bidi-font-family:"Times New Roman";
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-bidi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level3
	{mso-level-style-link:"Heading 3";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:179.1pt;
	text-indent:-.3in;
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level4
	{mso-level-style-link:"Heading 4";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level5
	{mso-level-style-link:"Heading 5";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level6
	{mso-level-style-link:"Heading 6";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level7
	{mso-level-style-link:"Heading 7";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level8
	{mso-level-style-link:"Heading 8";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level9
	{mso-level-style-link:"Heading 9";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1
	{mso-list-id:927732023;
	mso-list-type:hybrid;
	mso-list-template-ids:644488524 1422297056 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-fareast-font-family:Batang;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Related to the ACTN work, there has been active rese=
arch termed &#8220;virtual network mapping/embedding (VNM/VNE)&#8221;:<o:p>=
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Here&#8217;s some pointer to key papers:<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://www-bcf.usc.edu/~minlanyu/writeup/=
CCR08.pdf">http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf</a> (VNE with=
 path split and path migration)<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://nsm1.cs.uwaterloo.ca/rboutaba/Pape=
rs/Conferences/2010/Muntasir10.pdf">http://nsm1.cs.uwaterloo.ca/rboutaba/Pa=
pers/Conferences/2010/Muntasir10.pdf</a> (survivable VNE)<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://ieeexplore.ieee.org/xpls/abs_all.j=
sp?arnumber=3D5616527">http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=
=3D5616527</a> (Resource Efficient VNE)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The focus of ACTN perhaps does not have a direct bea=
ring with these papers as they are concerned about the VNM/VNE algorithms; =
however, these bring some key issues and constraints for virtual network pa=
th computation. These issues and constraints
 should be of interest of the ACTN work that may impact on the design, info=
rmation models and interface/protocol extensions (if necessary). &nbsp;Some=
 of the issues such as efficiency of algorithm are perhaps better fit to SD=
N RG, &nbsp;some of key issues and constraints
 for virtual network path computation related to VNM/VNE are as follows: <o=
:p></o:p></p>
<h2 style=3D"mso-list:none"><a name=3D"_Toc374709103"><o:p>&nbsp;</o:p></a>=
</h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Request Processing<o:p></o:p></h2>
<p class=3D"MsoNormal">This is concerned about whether a set of client requ=
ests for VN creation can be dealt with simultaneously or not. This depends =
on the nature of applications the client support. If the client does not re=
quire real-time instantiation of VN
 creation, the computation engine can process a set of VN creation requests=
 simultaneously to improve network efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
a name=3D"_Toc374709104"><![if !supportLists]><span style=3D"mso-list:Ignor=
e">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Types of Network Resources</a><o:p></o:p></h2>
<p class=3D"MsoNormal">When client makes a VN creation request to the subst=
rate network, what kind of network resources is consumed is of concern of b=
oth the client and network providers. It depends on the application. For tr=
ansport network virtualization, the
 network resource consumed by the client is primarily network bandwidth tha=
t the paths would occupy on the physical link. However, there may be other =
resource types such as CPU and memory that need to be considered for certai=
n applications. These resource types
 are a part of the client&#8217;s VN request. <a name=3D"_Toc374709105"><o:=
p></o:p></a></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Accuracy of Network Resource Representation <o:p></=
o:p></h2>
<p class=3D"MsoNormal">As the underlying transport network in itself may co=
nsists of layered structure, it is a challenge how to represent these under=
lying physical network resources and topology into a form that can be relia=
bly used by the computation engine
 that assigns the client requests into the physical network resource and to=
pology.
<a name=3D"_Toc374709106"><o:p></o:p></a></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Resource Efficiency<o:p></o:p></h2>
<p class=3D"MsoNormal">Related to the accuracy of network resource represen=
tation is resource efficiency. As a set of independent client VN is created=
 and mapped onto physical network resources, the overall network resource u=
tilization is of the primary concern
 of the infrastructure provider. <o:p></o:p></p>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><a name=3D"_Toc=
374709107"><o:p>&nbsp;</o:p></a></h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Guarantee of Client Isolation<o:p></o:p></h2>
<p class=3D"MsoNormal">While network resource sharing across a set of clien=
ts for efficient utilization is important aspect of network virtualization,=
 client isolation has to be guaranteed. Admissions of new client requests o=
r any changes of other existing clients&#8217;
 VNs must not affect any particular client in terms of resource guarantee, =
security constraints, and other performance constraints.&nbsp;
<o:p></o:p></p>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><a name=3D"_Toc=
374709108"><o:p>&nbsp;</o:p></a></h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Computing Time<o:p></o:p></h2>
<p class=3D"MsoNormal">Depending on the nature of applications, how quickly=
 a VN is instantiated from the time of request is an important factor. For =
dynamic applications that require instantaneous VN creation, the computatio=
n model/algorithm should support this
 constraint. <o:p></o:p></p>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><a name=3D"_Toc=
374709109"><o:p>&nbsp;</o:p></a></h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Admission Control<o:p></o:p></h2>
<p class=3D"MsoNormal">To coordinate the request process of multiple client=
s, an admission control will help maximize an overall efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo2"><=
a name=3D"_Toc374709110"><![if !supportLists]><span style=3D"mso-list:Ignor=
e">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Path Constraints</a><o:p></o:p></h2>
<p class=3D"MsoNormal">There may be some factors of path constraints that c=
an affect the overall efficiency. Path Split can lower VN request blocking =
if the underlying network can support such capability. Packet-based TE netw=
ork can support path split while circuit-based
 transport may have a limitation. &nbsp;Path migration is a technique that =
allows changes of nodes or links assignment of the established paths in an =
effort to accommodate new requests which would not be accepted without path=
 migration. This can improve overall
 efficiency, yet additional care needs to be applied to avoid any adverse i=
mpacts associated with changing the existing paths.
<o:p></o:p></p>
<p class=3D"MsoNormal">Re-optimization is a global process to re-shuffle al=
l existing path assignment to minimize network resource fragmentation. Agai=
n, an extra care needs to be applied for re-optimization.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_--

From daniele.ceccarelli@ericsson.com  Fri Dec 20 02:30:50 2013
Return-Path: <daniele.ceccarelli@ericsson.com>
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 B72EB1AE1B6 for <actn@ietfa.amsl.com>; Fri, 20 Dec 2013 02:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 sA71F09ReBaI for <actn@ietfa.amsl.com>; Fri, 20 Dec 2013 02:30:46 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8A11AE1B9 for <actn@ietf.org>; Fri, 20 Dec 2013 02:30:45 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-fb-52b41c52f09d
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.77.23787.25C14B25; Fri, 20 Dec 2013 11:30:42 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.140]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0347.000; Fri, 20 Dec 2013 11:30:17 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Leeyoung <leeyoung@huawei.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Actn] virtual network mapping/embedding (VNM/VNE)  problem
Thread-Index: Ac77RdTjI/gEkOJNRuyLHsDiwda0eQBgPBxw
Date: Fri, 20 Dec 2013 10:30:17 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.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.20]
Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvrW6QzJYgg38n1Sy29Fxgs5g2z9Xi /ILnLA7MHi1H3rJ6LFnyk8lj8sbDbAHMUVw2Kak5mWWpRfp2CVwZr1pWMhZ0f2CsWHD/AUsD 48vzjF2MnBwSAiYSJ67uZYawxSQu3FvP1sXIxSEkcIhR4ub8l1DOEkaJv9tWsnYxcnCwCVhJ PDnkA9IgIuAssWH7UbBmZgFFiRPPn4ENFRbwkLjef4IZosZTYu7Gh4wQtpHE5NZZYDaLgKrE yTVn2UFsXgFfiSuHdoDVCwmESqyce5wJxOYUCJP4cus6mM0oICsxYfciRohd4hK3nsxngjha QGLJnvNQD4hKvHz8jxXCVpS4On05E0R9vsTal51MELsEJU7OfMIygVF0FpJRs5CUzUJSBhHX k7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGy5yZm5qSXG25iBEbawS2/dXcwnjoncohR moNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MKQ/0F3+fJVz1VVxqwr49Wece rz5w8ueDd/PZrLy1Nmgs+h/4SsGCaVnZq00dHs9+R05yW7367a+yU/2SD7Rs7nme17YvF22Z LiAYt9GC/WiHxnuDs2tvTTK43rNv9bGHl55Grsx63uU+JdTr1k/uFA+b5Iyf59XXXDu09cpu a8n/u3bcvLlg3z8lluKMREMt5qLiRADPxci6ggIAAA==
Cc: "sdn@irtf.org" <sdn@irtf.org>
Subject: Re: [Actn] virtual network mapping/embedding (VNM/VNE)  problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 10:30:50 -0000

--_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Young,

Thanks for the pointers and the list of issues.

Please find in line some loud thinking from my side.

BR
Daniele

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: marted=EC 17 dicembre 2013 17:34
To: actn@ietf.org
Cc: sdn@irtf.org
Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem

Related to the ACTN work, there has been active research termed "virtual ne=
twork mapping/embedding (VNM/VNE)":

Here's some pointer to key papers:

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and=
 path migration)
http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf=
 (survivable VNE)
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef=
ficient VNE)

The focus of ACTN perhaps does not have a direct bearing with these papers =
as they are concerned about the VNM/VNE algorithms; however, these bring so=
me key issues and constraints for virtual network path computation. These i=
ssues and constraints should be of interest of the ACTN work that may impac=
t on the design, information models and interface/protocol extensions (if n=
ecessary).  Some of the issues such as efficiency of algorithm are perhaps =
better fit to SDN RG,  some of key issues and constraints for virtual netwo=
rk path computation related to VNM/VNE are as follows:

-   Request Processing
This is concerned about whether a set of client requests for VN creation ca=
n be dealt with simultaneously or not. This depends on the nature of applic=
ations the client support. If the client does not require real-time instant=
iation of VN creation, the computation engine can process a set of VN creat=
ion requests simultaneously to improve network efficiency.
[[DC]] I think here we can assume that VN creation requests are non real ti=
me. Instantiation of services and bandwidth might be real time (and hence c=
oncurrency needs to be managed) but I would say this is not the case of VN =
creation.

-   Types of Network Resources
When client makes a VN creation request to the substrate network, what kind=
 of network resources is consumed is of concern of both the client and netw=
ork providers. It depends on the application. For transport network virtual=
ization, the network resource consumed by the client is primarily network b=
andwidth that the paths would occupy on the physical link. However, there m=
ay be other resource types such as CPU and memory that need to be considere=
d for certain applications. These resource types are a part of the client's=
 VN request.
[[DC]] Here the issue is thorny. The point is: a given resource is dedicate=
d to a given VN or shared among different ones? We should start considering=
 network resources partitioning issues...

-   Accuracy of Network Resource Representation
As the underlying transport network in itself may consists of layered struc=
ture, it is a challenge how to represent these underlying physical network =
resources and topology into a form that can be reliably used by the computa=
tion engine that assigns the client requests into the physical network reso=
urce and topology.
[[DC]] Damnly true

-   Resource Efficiency
Related to the accuracy of network resource representation is resource effi=
ciency. As a set of independent client VN is created and mapped onto physic=
al network resources, the overall network resource utilization is of the pr=
imary concern of the infrastructure provider.
[[DC]] This issue is pretty much linked to the one above (types of network =
resources)

-   Guarantee of Client Isolation
While network resource sharing across a set of clients for efficient utiliz=
ation is important aspect of network virtualization, client isolation has t=
o be guaranteed. Admissions of new client requests or any changes of other =
existing clients' VNs must not affect any particular client in terms of res=
ource guarantee, security constraints, and other performance constraints.
[[DC]] Again linked to issues above. If network resources are dedicated to =
each VN, this is true, but if they (or part of them) are shared, the instan=
tiation of a service from a given client would impact the VN seen by others=
. On the other side, aspects like security o performances should not be imp=
acted in any of the two cases.

-   Computing Time
Depending on the nature of applications, how quickly a VN is instantiated f=
rom the time of request is an important factor. For dynamic applications th=
at require instantaneous VN creation, the computation model/algorithm shoul=
d support this constraint.
[[DC]] I would say that timing constraints need to be met for service provi=
sioning (i.e. upon client requests on a given VN) but I think VN instantiat=
ion could be also a non real time procedure. I might be wrong...are there u=
se cases for real time and timing constrained VN creation requrests?

-   Admission Control
To coordinate the request process of multiple clients, an admission control=
 will help maximize an overall efficiency.
[[DC]] Yes. To understand where is the best place to do that. Cline control=
? VNC?

-   Path Constraints
There may be some factors of path constraints that can affect the overall e=
fficiency. Path Split can lower VN request blocking if the underlying netwo=
rk can support such capability. Packet-based TE network can support path sp=
lit while circuit-based transport may have a limitation.  Path migration is=
 a technique that allows changes of nodes or links assignment of the establ=
ished paths in an effort to accommodate new requests which would not be acc=
epted without path migration. This can improve overall efficiency, yet addi=
tional care needs to be applied to avoid any adverse impacts associated wit=
h changing the existing paths.
Re-optimization is a global process to re-shuffle all existing path assignm=
ent to minimize network resource fragmentation. Again, an extra care needs =
to be applied for re-optimization.
[[DC]] True. With path constraints I think we should include something more=
. When a client needs to setup a service/LSP there might be TE constraints =
associated to the request. Whan the VN needs to include is not only reachab=
ility information but in many cases is should be TE-reachability informatio=
n. In this case we could leverage on the overlay work being done e.g. in CC=
AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-=
exchange-02).



--_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-priority:9;
	mso-style-link:"Heading 1 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:80.1pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level3 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h4
	{mso-style-priority:9;
	mso-style-link:"Heading 4 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level4 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h5
	{mso-style-priority:9;
	mso-style-link:"Heading 5 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level5 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h6
	{mso-style-priority:9;
	mso-style-link:"Heading 6 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level6 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-priority:9;
	mso-style-link:"Heading 7 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level7 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-priority:9;
	mso-style-link:"Heading 8 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level8 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-priority:9;
	mso-style-link:"Heading 9 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level9 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 1";
	font-family:"Courier New";}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Courier New";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Courier New";}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Courier New";}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 5";
	font-family:"Courier New";}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 6";
	font-family:"Courier New";}
span.Heading7Char
	{mso-style-name:"Heading 7 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 7";
	font-family:"Courier New";}
span.Heading8Char
	{mso-style-name:"Heading 8 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 8";
	font-family:"Courier New";}
span.Heading9Char
	{mso-style-name:"Heading 9 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 9";
	font-family:"Courier New";}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle27
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:730737984;
	mso-list-template-ids:-1479607216;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-suffix:none;
	mso-level-text:"%1\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	mso-bidi-font-family:"Times New Roman";
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-bidi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level3
	{mso-level-style-link:"Heading 3";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:179.1pt;
	text-indent:-21.6pt;
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level4
	{mso-level-style-link:"Heading 4";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level5
	{mso-level-style-link:"Heading 5";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level6
	{mso-level-style-link:"Heading 6";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level7
	{mso-level-style-link:"Heading 7";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level8
	{mso-level-style-link:"Heading 8";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level9
	{mso-level-style-link:"Heading 9";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1
	{mso-list-id:927732023;
	mso-list-type:hybrid;
	mso-list-template-ids:644488524 1422297056 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Batang;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Young,<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for the pointer=
s and the list of issues.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Please find in line so=
me loud thinking from my side.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">BR<br>
Daniele<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ACTN [ma=
ilto:actn-bounces@ietf.org]
<b>On Behalf Of </b>Leeyoung<br>
<b>Sent:</b> marted=EC 17 dicembre 2013 17:34<br>
<b>To:</b> actn@ietf.org<br>
<b>Cc:</b> sdn@irtf.org<br>
<b>Subject:</b> [Actn] virtual network mapping/embedding (VNM/VNE) problem<=
o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Related to the ACTN work, there has been active rese=
arch termed &#8220;virtual network mapping/embedding (VNM/VNE)&#8221;:<o:p>=
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Here&#8217;s some pointer to key papers:<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://www-bcf.usc.edu/~minlanyu/writeup/=
CCR08.pdf">http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf</a> (VNE with=
 path split and path migration)<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://nsm1.cs.uwaterloo.ca/rboutaba/Pape=
rs/Conferences/2010/Muntasir10.pdf">http://nsm1.cs.uwaterloo.ca/rboutaba/Pa=
pers/Conferences/2010/Muntasir10.pdf</a> (survivable VNE)<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://ieeexplore.ieee.org/xpls/abs_all.j=
sp?arnumber=3D5616527">http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=
=3D5616527</a> (Resource Efficient VNE)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The focus of ACTN perhaps does not have a direct bea=
ring with these papers as they are concerned about the VNM/VNE algorithms; =
however, these bring some key issues and constraints for virtual network pa=
th computation. These issues and constraints
 should be of interest of the ACTN work that may impact on the design, info=
rmation models and interface/protocol extensions (if necessary). &nbsp;Some=
 of the issues such as efficiency of algorithm are perhaps better fit to SD=
N RG, &nbsp;some of key issues and constraints
 for virtual network path computation related to VNM/VNE are as follows: <o=
:p></o:p></p>
<h2 style=3D"mso-list:none"><a name=3D"_Toc374709103"></a><o:p>&nbsp;</o:p>=
</h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Request Processing<o:p></o:p></h2>
<p class=3D"MsoNormal">This is concerned about whether a set of client requ=
ests for VN creation can be dealt with simultaneously or not. This depends =
on the nature of applications the client support. If the client does not re=
quire real-time instantiation of VN
 creation, the computation engine can process a set of VN creation requests=
 simultaneously to improve network efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] I think h=
ere we can assume that VN creation requests are non real time. Instantiatio=
n of services and bandwidth might be real time (and hence concurrency needs=
 to be managed) but I would say this
 is not the case of VN creation.</span></i></b><span style=3D"color:#1F497D=
"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><a name=3D"_Toc374709104"><![if !supportLists]><span style=3D"mso-list:Ig=
nore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Types of Network Resources</a><o:p></o:p></h2>
<p class=3D"MsoNormal">When client makes a VN creation request to the subst=
rate network, what kind of network resources is consumed is of concern of b=
oth the client and network providers. It depends on the application. For tr=
ansport network virtualization, the
 network resource consumed by the client is primarily network bandwidth tha=
t the paths would occupy on the physical link. However, there may be other =
resource types such as CPU and memory that need to be considered for certai=
n applications. These resource types
 are a part of the client&#8217;s VN request. <a name=3D"_Toc374709105"></a=
><o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Here the =
issue is thorny. The point is: a given resource is dedicated to a given VN =
or shared among different ones? We should start considering network resourc=
es partitioning issues&#8230;</span></i></b><span style=3D"color:#1F497D"><=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Accuracy of Network Resource Representation <o:p></=
o:p></h2>
<p class=3D"MsoNormal">As the underlying transport network in itself may co=
nsists of layered structure, it is a challenge how to represent these under=
lying physical network resources and topology into a form that can be relia=
bly used by the computation engine
 that assigns the client requests into the physical network resource and to=
pology.
<a name=3D"_Toc374709106"></a><o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Damnly tr=
ue</span></i></b><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Resource Efficiency<o:p></o:p></h2>
<p class=3D"MsoNormal">Related to the accuracy of network resource represen=
tation is resource efficiency. As a set of independent client VN is created=
 and mapped onto physical network resources, the overall network resource u=
tilization is of the primary concern
 of the infrastructure provider. <o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] This issu=
e is pretty much linked to the one above (types of network resources)</span=
></i></b><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709107"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Guarantee of Client Isolation<o:p></o:p></h2>
<p class=3D"MsoNormal">While network resource sharing across a set of clien=
ts for efficient utilization is important aspect of network virtualization,=
 client isolation has to be guaranteed. Admissions of new client requests o=
r any changes of other existing clients&#8217;
 VNs must not affect any particular client in terms of resource guarantee, =
security constraints, and other performance constraints.&nbsp;
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Again lin=
ked to issues above. If network resources are dedicated to each VN, this is=
 true, but if they (or part of them) are shared, the instantiation of a ser=
vice from a given client would impact
 the VN seen by others. On the other side, aspects like security o performa=
nces should not be impacted in any of the two cases.</span></i></b><span st=
yle=3D"color:#1F497D"><o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709108"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Computing Time<o:p></o:p></h2>
<p class=3D"MsoNormal">Depending on the nature of applications, how quickly=
 a VN is instantiated from the time of request is an important factor. For =
dynamic applications that require instantaneous VN creation, the computatio=
n model/algorithm should support this
 constraint. <o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] I would s=
ay that timing constraints need to be met for service provisioning (i.e. up=
on client requests on a given VN) but I think VN instantiation could be als=
o a non real time procedure. I might
 be wrong&#8230;are there use cases for real time and timing constrained VN=
 creation requrests?</span></i></b><span style=3D"color:#1F497D"><o:p></o:p=
></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709109"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Admission Control<o:p></o:p></h2>
<p class=3D"MsoNormal">To coordinate the request process of multiple client=
s, an admission control will help maximize an overall efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Yes. To u=
nderstand where is the best place to do that. Cline control? VNC?</span></i=
></b><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><a name=3D"_Toc374709110"><![if !supportLists]><span style=3D"mso-list:Ig=
nore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Path Constraints</a><o:p></o:p></h2>
<p class=3D"MsoNormal">There may be some factors of path constraints that c=
an affect the overall efficiency. Path Split can lower VN request blocking =
if the underlying network can support such capability. Packet-based TE netw=
ork can support path split while circuit-based
 transport may have a limitation. &nbsp;Path migration is a technique that =
allows changes of nodes or links assignment of the established paths in an =
effort to accommodate new requests which would not be accepted without path=
 migration. This can improve overall
 efficiency, yet additional care needs to be applied to avoid any adverse i=
mpacts associated with changing the existing paths.
<o:p></o:p></p>
<p class=3D"MsoNormal">Re-optimization is a global process to re-shuffle al=
l existing path assignment to minimize network resource fragmentation. Agai=
n, an extra care needs to be applied for re-optimization.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] True. Wit=
h path constraints I think we should include something more. When a client =
needs to setup a service/LSP there might be TE constraints associated to th=
e request. Whan the VN needs to include
 is not only reachability information but in many cases is should be TE-rea=
chability information. In this case we could leverage on the overlay work b=
eing done e.g. in CCAMP and in (</span></i></b><a href=3D"http://tools.ietf=
.org/html/draft-farrel-interconnected-te-info-exchange-02">http://tools.iet=
f.org/html/draft-farrel-interconnected-te-info-exchange-02</a>).<span style=
=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_--

From leeyoung@huawei.com  Fri Dec 20 11:12:32 2013
Return-Path: <leeyoung@huawei.com>
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 1985D1AE111 for <actn@ietfa.amsl.com>; Fri, 20 Dec 2013 11:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable
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 3_owhQ5YshZq for <actn@ietfa.amsl.com>; Fri, 20 Dec 2013 11:12:25 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF3B1AE101 for <actn@ietf.org>; Fri, 20 Dec 2013 11:12:24 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZF47078; Fri, 20 Dec 2013 19:12:20 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 19:11:45 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 19:12:04 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 20 Dec 2013 11:12:00 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Actn] virtual network mapping/embedding (VNM/VNE)  problem
Thread-Index: AQHO/W6RDeEpEZPP50m1uop4SSQtEppdaWyQ
Date: Fri, 20 Dec 2013 19:11:59 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.142.97]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "sdn@irtf.org" <sdn@irtf.org>
Subject: Re: [Actn] virtual network mapping/embedding (VNM/VNE)  problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 19:12:32 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Daniele,

Thanks for your feedback and comments. Please see inline for my reply.

Thanks.
Young

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Friday, December 20, 2013 4:30 AM
To: Leeyoung; actn@ietf.org
Cc: sdn@irtf.org
Subject: RE: [Actn] virtual network mapping/embedding (VNM/VNE) problem

Hi Young,

Thanks for the pointers and the list of issues.

Please find in line some loud thinking from my side.

BR
Daniele

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: marted=EC 17 dicembre 2013 17:34
To: actn@ietf.org<mailto:actn@ietf.org>
Cc: sdn@irtf.org<mailto:sdn@irtf.org>
Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem

Related to the ACTN work, there has been active research termed "virtual ne=
twork mapping/embedding (VNM/VNE)":

Here's some pointer to key papers:

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and=
 path migration)
http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf=
 (survivable VNE)
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef=
ficient VNE)

The focus of ACTN perhaps does not have a direct bearing with these papers =
as they are concerned about the VNM/VNE algorithms; however, these bring so=
me key issues and constraints for virtual network path computation. These i=
ssues and constraints should be of interest of the ACTN work that may impac=
t on the design, information models and interface/protocol extensions (if n=
ecessary).  Some of the issues such as efficiency of algorithm are perhaps =
better fit to SDN RG,  some of key issues and constraints for virtual netwo=
rk path computation related to VNM/VNE are as follows:

-   Request Processing
This is concerned about whether a set of client requests for VN creation ca=
n be dealt with simultaneously or not. This depends on the nature of applic=
ations the client support. If the client does not require real-time instant=
iation of VN creation, the computation engine can process a set of VN creat=
ion requests simultaneously to improve network efficiency.
[[DC]] I think here we can assume that VN creation requests are non real ti=
me. Instantiation of services and bandwidth might be real time (and hence c=
oncurrency needs to be managed) but I would say this is not the case of VN =
creation.

YOUNG>> Good point.  I was loose on the term 'VN creation".  There are cert=
ainly negotiation aspects of VN creation which can be viewed as non-real ti=
me as the client endpoints need to be negotiated with network provider(s) b=
efore service creation. Yes, in that sense, I agree with you. Here what I m=
eant to say was when there are multiple service requests  to setup virtual =
connections that need not be instantiated real-time, (in other words, if so=
me request can be queued for a delay scheduling), then a batch processing o=
f multiple requests would be more optimal in general from a network efficie=
ncy perspective than sequential processing.


-   Types of Network Resources
When client makes a VN creation request to the substrate network, what kind=
 of network resources is consumed is of concern of both the client and netw=
ork providers. It depends on the application. For transport network virtual=
ization, the network resource consumed by the client is primarily network b=
andwidth that the paths would occupy on the physical link. However, there m=
ay be other resource types such as CPU and memory that need to be considere=
d for certain applications. These resource types are a part of the client's=
 VN request.
[[DC]] Here the issue is thorny. The point is: a given resource is dedicate=
d to a given VN or shared among different ones? We should start considering=
 network resources partitioning issues...

YOUNG>>  A given resource is "virtually" dedicated to a particular client; =
yet this does not mean a particular client occupies a particular port (say =
ODU port 1 vs 2).  As long as resource is guaranteed for use to the client,=
 it is fine for the Working Path at least; however for 1:N kind of protecti=
on case, there is a level of sharing backup path resource for multiple clie=
nts.

-   Accuracy of Network Resource Representation
As the underlying transport network in itself may consists of layered struc=
ture, it is a challenge how to represent these underlying physical network =
resources and topology into a form that can be reliably used by the computa=
tion engine that assigns the client requests into the physical network reso=
urce and topology.
[[DC]] Damnly true

-   Resource Efficiency
Related to the accuracy of network resource representation is resource effi=
ciency. As a set of independent client VN is created and mapped onto physic=
al network resources, the overall network resource utilization is of the pr=
imary concern of the infrastructure provider.
[[DC]] This issue is pretty much linked to the one above (types of network =
resources)

YOUNG>> Yes.

-   Guarantee of Client Isolation
While network resource sharing across a set of clients for efficient utiliz=
ation is important aspect of network virtualization, client isolation has t=
o be guaranteed. Admissions of new client requests or any changes of other =
existing clients' VNs must not affect any particular client in terms of res=
ource guarantee, security constraints, and other performance constraints.
[[DC]] Again linked to issues above. If network resources are dedicated to =
each VN, this is true, but if they (or part of them) are shared, the instan=
tiation of a service from a given client would impact the VN seen by others=
. On the other side, aspects like security o performances should not be imp=
acted in any of the two cases.

YOUNG>> Agree.  So I guess we need to be clear on resource partitioning and=
 sharing issue clearly --- I think some application/client requires a hard =
dedicated resource while for some others it is fluid.

-   Computing Time
Depending on the nature of applications, how quickly a VN is instantiated f=
rom the time of request is an important factor. For dynamic applications th=
at require instantaneous VN creation, the computation model/algorithm shoul=
d support this constraint.
[[DC]] I would say that timing constraints need to be met for service provi=
sioning (i.e. upon client requests on a given VN) but I think VN instantiat=
ion could be also a non real time procedure. I might be wrong...are there u=
se cases for real time and timing constrained VN creation requrests?

YOUNG>>  Again here what I meant was service request. I need to be clear on=
 the terminology.  If we were to define VN creation as the process of negot=
iation (similar to SLA negotiation), the initial VN creation is always off-=
line (static and non-real time). Once the initial VN creation negotiation i=
s done, then there might be cases where VN can be re-negotiated on the fly =
(e.g., changing some b/w or service objectives, or some physical failures s=
uch as fiber cut). But this is not VN creation; we need to distinguish this=
 from VN re-negotiation.
-   Admission Control
To coordinate the request process of multiple clients, an admission control=
 will help maximize an overall efficiency.
[[DC]] Yes. To understand where is the best place to do that. Cline control=
? VNC?

YOUNG>> As there are many clients that the VNC needs to support, I assume V=
NC has to have admission control module at the least. Client Controller, ho=
wever, may have its own admission control for supporting multiple applicati=
ons. We need to recognize a recursive client-server relationship. As long a=
s controller is a server controller of any sort, then admission control fun=
ction would help to coordinate its clients.

-   Path Constraints
There may be some factors of path constraints that can affect the overall e=
fficiency. Path Split can lower VN request blocking if the underlying netwo=
rk can support such capability. Packet-based TE network can support path sp=
lit while circuit-based transport may have a limitation.  Path migration is=
 a technique that allows changes of nodes or links assignment of the establ=
ished paths in an effort to accommodate new requests which would not be acc=
epted without path migration. This can improve overall efficiency, yet addi=
tional care needs to be applied to avoid any adverse impacts associated wit=
h changing the existing paths.
Re-optimization is a global process to re-shuffle all existing path assignm=
ent to minimize network resource fragmentation. Again, an extra care needs =
to be applied for re-optimization.
[[DC]] True. With path constraints I think we should include something more=
. When a client needs to setup a service/LSP there might be TE constraints =
associated to the request. Whan the VN needs to include is not only reachab=
ility information but in many cases is should be TE-reachability informatio=
n. In this case we could leverage on the overlay work being done e.g. in CC=
AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-=
exchange-02).

YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN =
scope, then  the TE-reacheability needs to be known/advertised by the serve=
r network to clients as 'capability' attribute.

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-priority:9;
	mso-style-link:"Heading 1 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:80.1pt;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level3 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h4
	{mso-style-priority:9;
	mso-style-link:"Heading 4 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level4 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h5
	{mso-style-priority:9;
	mso-style-link:"Heading 5 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level5 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h6
	{mso-style-priority:9;
	mso-style-link:"Heading 6 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level6 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-priority:9;
	mso-style-link:"Heading 7 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level7 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-priority:9;
	mso-style-link:"Heading 8 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level8 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-priority:9;
	mso-style-link:"Heading 9 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level9 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 1";
	font-family:"Courier New";}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Courier New";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Courier New";}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Courier New";}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 5";
	font-family:"Courier New";}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 6";
	font-family:"Courier New";}
span.Heading7Char
	{mso-style-name:"Heading 7 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 7";
	font-family:"Courier New";}
span.Heading8Char
	{mso-style-name:"Heading 8 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 8";
	font-family:"Courier New";}
span.Heading9Char
	{mso-style-name:"Heading 9 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 9";
	font-family:"Courier New";}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle30
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:730737984;
	mso-list-template-ids:-1479607216;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-suffix:none;
	mso-level-text:"%1\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;
	mso-bidi-font-family:"Times New Roman";
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-bidi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level3
	{mso-level-style-link:"Heading 3";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:179.1pt;
	text-indent:-.3in;
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level4
	{mso-level-style-link:"Heading 4";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level5
	{mso-level-style-link:"Heading 5";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level6
	{mso-level-style-link:"Heading 6";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level7
	{mso-level-style-link:"Heading 7";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level8
	{mso-level-style-link:"Heading 8";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level9
	{mso-level-style-link:"Heading 9";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1
	{mso-list-id:927732023;
	mso-list-type:hybrid;
	mso-list-template-ids:644488524 1422297056 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-fareast-font-family:Batang;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Daniele,<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for your feedba=
ck and comments. Please see inline for my reply.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Young<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Daniele =
Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
<br>
<b>Sent:</b> Friday, December 20, 2013 4:30 AM<br>
<b>To:</b> Leeyoung; actn@ietf.org<br>
<b>Cc:</b> sdn@irtf.org<br>
<b>Subject:</b> RE: [Actn] virtual network mapping/embedding (VNM/VNE) prob=
lem<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Young,<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for the pointer=
s and the list of issues.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Please find in line so=
me loud thinking from my side.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">BR<br>
Daniele<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ACTN [<a=
 href=3D"mailto:actn-bounces@ietf.org">mailto:actn-bounces@ietf.org</a>]
<b>On Behalf Of </b>Leeyoung<br>
<b>Sent:</b> marted=EC 17 dicembre 2013 17:34<br>
<b>To:</b> <a href=3D"mailto:actn@ietf.org">actn@ietf.org</a><br>
<b>Cc:</b> <a href=3D"mailto:sdn@irtf.org">sdn@irtf.org</a><br>
<b>Subject:</b> [Actn] virtual network mapping/embedding (VNM/VNE) problem<=
o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Related to the ACTN work, there has been active rese=
arch termed &#8220;virtual network mapping/embedding (VNM/VNE)&#8221;:<o:p>=
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Here&#8217;s some pointer to key papers:<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://www-bcf.usc.edu/~minlanyu/writeup/=
CCR08.pdf">http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf</a> (VNE with=
 path split and path migration)<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://nsm1.cs.uwaterloo.ca/rboutaba/Pape=
rs/Conferences/2010/Muntasir10.pdf">http://nsm1.cs.uwaterloo.ca/rboutaba/Pa=
pers/Conferences/2010/Muntasir10.pdf</a> (survivable VNE)<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://ieeexplore.ieee.org/xpls/abs_all.j=
sp?arnumber=3D5616527">http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=
=3D5616527</a> (Resource Efficient VNE)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The focus of ACTN perhaps does not have a direct bea=
ring with these papers as they are concerned about the VNM/VNE algorithms; =
however, these bring some key issues and constraints for virtual network pa=
th computation. These issues and constraints
 should be of interest of the ACTN work that may impact on the design, info=
rmation models and interface/protocol extensions (if necessary). &nbsp;Some=
 of the issues such as efficiency of algorithm are perhaps better fit to SD=
N RG, &nbsp;some of key issues and constraints
 for virtual network path computation related to VNM/VNE are as follows: <o=
:p></o:p></p>
<h2 style=3D"mso-list:none"><a name=3D"_Toc374709103"></a><o:p>&nbsp;</o:p>=
</h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Request Processing<o:p></o:p></h2>
<p class=3D"MsoNormal">This is concerned about whether a set of client requ=
ests for VN creation can be dealt with simultaneously or not. This depends =
on the nature of applications the client support. If the client does not re=
quire real-time instantiation of VN
 creation, the computation engine can process a set of VN creation requests=
 simultaneously to improve network efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] I think h=
ere we can assume that VN creation requests are non real time. Instantiatio=
n of services and bandwidth might be real time (and hence concurrency needs=
 to be managed) but I would say this
 is not the case of VN creation.</span></i></b><span style=3D"color:#1F497D=
"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Good poi=
nt. &nbsp;I was loose on the term &#8216;VN creation&#8221;.&nbsp; There ar=
e certainly negotiation aspects of VN creation which can be viewed as non-r=
eal time as the client endpoints need to be negotiated with network
 provider(s) before service creation. Yes, in that sense, I agree with you.=
 Here what I meant to say was when there are multiple service requests &nbs=
p;to setup virtual connections that need not be instantiated real-time, (in=
 other words, if some request can be
 queued for a delay scheduling), then a batch processing of multiple reques=
ts would be more optimal in general from a network efficiency perspective t=
han sequential processing.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
a name=3D"_Toc374709104"><![if !supportLists]><span style=3D"mso-list:Ignor=
e">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Types of Network Resources</a><o:p></o:p></h2>
<p class=3D"MsoNormal">When client makes a VN creation request to the subst=
rate network, what kind of network resources is consumed is of concern of b=
oth the client and network providers. It depends on the application. For tr=
ansport network virtualization, the
 network resource consumed by the client is primarily network bandwidth tha=
t the paths would occupy on the physical link. However, there may be other =
resource types such as CPU and memory that need to be considered for certai=
n applications. These resource types
 are a part of the client&#8217;s VN request. <a name=3D"_Toc374709105"></a=
><o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Here the =
issue is thorny. The point is: a given resource is dedicated to a given VN =
or shared among different ones? We should start considering network resourc=
es partitioning issues&#8230;<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt;&nbsp; A =
given resource is &#8220;virtually&#8221; dedicated to a particular client;=
 yet this does not mean a particular client occupies a particular port (say=
 ODU port 1 vs 2).&nbsp; As long as resource is guaranteed for use
 to the client, it is fine for the Working Path at least; however for 1:N k=
ind of protection case, there is a level of sharing backup path resource fo=
r multiple clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Accuracy of Network Resource Representation <o:p></=
o:p></h2>
<p class=3D"MsoNormal">As the underlying transport network in itself may co=
nsists of layered structure, it is a challenge how to represent these under=
lying physical network resources and topology into a form that can be relia=
bly used by the computation engine
 that assigns the client requests into the physical network resource and to=
pology.
<a name=3D"_Toc374709106"></a><o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Damnly tr=
ue</span></i></b><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Resource Efficiency<o:p></o:p></h2>
<p class=3D"MsoNormal">Related to the accuracy of network resource represen=
tation is resource efficiency. As a set of independent client VN is created=
 and mapped onto physical network resources, the overall network resource u=
tilization is of the primary concern
 of the infrastructure provider. <o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] This issu=
e is pretty much linked to the one above (types of network resources)<o:p><=
/o:p></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Yes. <o:=
p></o:p></span></p>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><a name=3D"_Toc=
374709107"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Guarantee of Client Isolation<o:p></o:p></h2>
<p class=3D"MsoNormal">While network resource sharing across a set of clien=
ts for efficient utilization is important aspect of network virtualization,=
 client isolation has to be guaranteed. Admissions of new client requests o=
r any changes of other existing clients&#8217;
 VNs must not affect any particular client in terms of resource guarantee, =
security constraints, and other performance constraints.&nbsp;
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Again lin=
ked to issues above. If network resources are dedicated to each VN, this is=
 true, but if they (or part of them) are shared, the instantiation of a ser=
vice from a given client would impact
 the VN seen by others. On the other side, aspects like security o performa=
nces should not be impacted in any of the two cases.<o:p></o:p></span></i><=
/b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Agree.&n=
bsp; So I guess we need to be clear on resource partitioning and sharing is=
sue clearly --- I think some application/client requires a hard dedicated r=
esource while for some others it is fluid.&nbsp;
<o:p></o:p></span></p>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><a name=3D"_Toc=
374709108"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Computing Time<o:p></o:p></h2>
<p class=3D"MsoNormal">Depending on the nature of applications, how quickly=
 a VN is instantiated from the time of request is an important factor. For =
dynamic applications that require instantaneous VN creation, the computatio=
n model/algorithm should support this
 constraint. <o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] I would s=
ay that timing constraints need to be met for service provisioning (i.e. up=
on client requests on a given VN) but I think VN instantiation could be als=
o a non real time procedure. I might
 be wrong&#8230;are there use cases for real time and timing constrained VN=
 creation requrests?</span></i></b><span style=3D"color:#1F497D"><o:p></o:p=
></span></p>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><a name=3D"_Toc=
374709109"></a><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:0in;text-indent:0in;mso-list:none"><span style=3D"=
font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;col=
or:#1F497D">YOUNG&gt;&gt; &nbsp;Again here what I meant was service request=
. I need to be clear on the terminology.&nbsp; If we were to define VN crea=
tion
 as the process of negotiation (similar to SLA negotiation), the initial VN=
 creation is always off-line (static and non-real time). Once the initial V=
N creation negotiation is done, then there might be cases where VN can be r=
e-negotiated on the fly (e.g., changing
 some b/w or service objectives, or some physical failures such as fiber cu=
t). But this is not VN creation; we need to distinguish this from VN re-neg=
otiation.
<o:p></o:p></span></h2>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7.=
0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Admission Control<o:p></o:p></h2>
<p class=3D"MsoNormal">To coordinate the request process of multiple client=
s, an admission control will help maximize an overall efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Yes. To u=
nderstand where is the best place to do that. Cline control? VNC?<o:p></o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; As there=
 are many clients that the VNC needs to support, I assume VNC has to have a=
dmission control module at the least. Client Controller, however, may have =
its own admission control for supporting multiple
 applications. We need to recognize a recursive client-server relationship.=
 As long as controller is a server controller of any sort, then admission c=
ontrol function would help to coordinate its clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo4"><=
a name=3D"_Toc374709110"><![if !supportLists]><span style=3D"mso-list:Ignor=
e">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Path Constraints</a><o:p></o:p></h2>
<p class=3D"MsoNormal">There may be some factors of path constraints that c=
an affect the overall efficiency. Path Split can lower VN request blocking =
if the underlying network can support such capability. Packet-based TE netw=
ork can support path split while circuit-based
 transport may have a limitation. &nbsp;Path migration is a technique that =
allows changes of nodes or links assignment of the established paths in an =
effort to accommodate new requests which would not be accepted without path=
 migration. This can improve overall
 efficiency, yet additional care needs to be applied to avoid any adverse i=
mpacts associated with changing the existing paths.
<o:p></o:p></p>
<p class=3D"MsoNormal">Re-optimization is a global process to re-shuffle al=
l existing path assignment to minimize network resource fragmentation. Agai=
n, an extra care needs to be applied for re-optimization.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] True. Wit=
h path constraints I think we should include something more. When a client =
needs to setup a service/LSP there might be TE constraints associated to th=
e request. Whan the VN needs to include
 is not only reachability information but in many cases is should be TE-rea=
chability information. In this case we could leverage on the overlay work b=
eing done e.g. in CCAMP and in (</span></i></b><a href=3D"http://tools.ietf=
.org/html/draft-farrel-interconnected-te-info-exchange-02">http://tools.iet=
f.org/html/draft-farrel-interconnected-te-info-exchange-02</a>).<span style=
=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Yes, if =
we include non-TE underlying transport as part of the ACTN scope, then &nbs=
p;the TE-reacheability needs to be known/advertised by the server network t=
o clients as &#8216;capability&#8217; attribute. &nbsp;</span><o:p></o:p></=
p>
</div>
</div>
</body>
</html>

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_--


From diego.caviglia@ericsson.com  Mon Dec 23 00:02:02 2013
Return-Path: <diego.caviglia@ericsson.com>
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 D1DA91AD7C1 for <actn@ietfa.amsl.com>; Mon, 23 Dec 2013 00:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable
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 QiLRIlXDQ3Tg for <actn@ietfa.amsl.com>; Mon, 23 Dec 2013 00:01:56 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 706151AD83F for <actn@ietf.org>; Mon, 23 Dec 2013 00:01:55 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-d5-52b7edee3a16
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 07.1D.03802.EEDE7B25; Mon, 23 Dec 2013 09:01:50 +0100 (CET)
Received: from ESESSMB103.ericsson.se ([169.254.3.125]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0347.000; Mon, 23 Dec 2013 09:01:48 +0100
From: Diego Caviglia <diego.caviglia@ericsson.com>
To: Leeyoung <leeyoung@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem
Thread-Index: AQHO/bdeyrxcXYsoskm9e7JN2Y4fJJphautg
Date: Mon, 23 Dec 2013 08:01:48 +0000
Message-ID: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.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_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvre67t9uDDJb2W1ps6bnAZjFtnqvF +QXPWRyYPVqOvGX1WLLkJ5PH5I2H2QKYo7hsUlJzMstSi/TtErgypvXtZy2YMI2pYnXXfKYG xqfvGLsYOTkkBEwkFvX/ZoWwxSQu3FvP1sXIxSEkcIhR4tPcaYwQzhJGiSPvr7ODVLEJGEns 6pjJAmKLCFRLrPpxDaybWUBR4sTzZ0ANHBzCAr4Sm3tcIEoCJP7+m84EYRtJNPVPAWtlEVCV WLZ5JdhIXqDyeVPOMUPsesoosezeRTaQBKdAmMSGhxfA5jMKyEpM2L2IEWKXuMStJ/OZIK4W kFiy5zwzhC0q8fLxP1aQGySA7lneLwdRni+xoOUz1C5BiZMzn7BMYBSdhWTSLCRls5CUQcR1 JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM7LmJmTnp5UabGIGRdnDLb9UdjHfOiRxilOZg URLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0Pt9nN3up+3cweuPbPKrdfh9KRy K25lyUtfnK2m2546kHxj+fdcvSXiv3gkd3VwPGL20tx4jUlezLO9+4bNZK4NjZtCP09auJ19 q0PMu22N0zcdOOspoXygZMGpuZm3NoX+Xf+Pb5uk+Pvafd/EuTiPudgcWBxj8dVM/JXG3R3y H2tT0uSqbiuxFGckGmoxFxUnAgA4aS9/ggIAAA==
Cc: "sdn@irtf.org" <sdn@irtf.org>
Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2013 08:02:03 -0000

--_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all some more thought with some cleaning

BR and Season greetings!

D



-   Request Processing
This is concerned about whether a set of client requests for VN creation ca=
n be dealt with simultaneously or not. This depends on the nature of applic=
ations the client support. If the client does not require real-time instant=
iation of VN creation, the computation engine can process a set of VN creat=
ion requests simultaneously to improve network efficiency.
[[DC]] I think here we can assume that VN creation requests are non real ti=
me. Instantiation of services and bandwidth might be real time (and hence c=
oncurrency needs to be managed) but I would say this is not the case of VN =
creation.

YOUNG>> Good point.  I was loose on the term 'VN creation".  There are cert=
ainly negotiation aspects of VN creation which can be viewed as non-real ti=
me as the client endpoints need to be negotiated with network provider(s) b=
efore service creation. Yes, in that sense, I agree with you. Here what I m=
eant to say was when there are multiple service requests  to setup virtual =
connections that need not be instantiated real-time, (in other words, if so=
me request can be queued for a delay scheduling), then a batch processing o=
f multiple requests would be more optimal in general from a network efficie=
ncy perspective than sequential processing.
[DC] yes and this is one of the biggest advantage of a centralized approach=
 versus a distributed one, that is the possibility to compute the optimal s=
olution of a bunch of requests


-   Types of Network Resources
When client makes a VN creation request to the substrate network, what kind=
 of network resources is consumed is of concern of both the client and netw=
ork providers. It depends on the application. For transport network virtual=
ization, the network resource consumed by the client is primarily network b=
andwidth that the paths would occupy on the physical link. However, there m=
ay be other resource types such as CPU and memory that need to be considere=
d for certain applications. These resource types are a part of the client's=
 VN request.
[[DC]] Here the issue is thorny. The point is: a given resource is dedicate=
d to a given VN or shared among different ones? We should start considering=
 network resources partitioning issues...

YOUNG>>  A given resource is "virtually" dedicated to a particular client; =
yet this does not mean a particular client occupies a particular port (say =
ODU port 1 vs 2).  As long as resource is guaranteed for use to the client,=
 it is fine for the Working Path at least; however for 1:N kind of protecti=
on case, there is a level of sharing backup path resource for multiple clie=
nts.
[DC] well at least tributary port can't be virtual I need to nail it to a p=
hysical numbering to physically connect the HW, for the rest I agree.

-   Accuracy of Network Resource Representation
As the underlying transport network in itself may consists of layered struc=
ture, it is a challenge how to represent these underlying physical network =
resources and topology into a form that can be reliably used by the computa=
tion engine that assigns the client requests into the physical network reso=
urce and topology.
[[DC]] Damnly true
[DC] I vote for a KISS approach :)

-   Resource Efficiency
Related to the accuracy of network resource representation is resource effi=
ciency. As a set of independent client VN is created and mapped onto physic=
al network resources, the overall network resource utilization is of the pr=
imary concern of the infrastructure provider.
[[DC]] This issue is pretty much linked to the one above (types of network =
resources)

YOUNG>> Yes.

-   Guarantee of Client Isolation
While network resource sharing across a set of clients for efficient utiliz=
ation is important aspect of network virtualization, client isolation has t=
o be guaranteed. Admissions of new client requests or any changes of other =
existing clients' VNs must not affect any particular client in terms of res=
ource guarantee, security constraints, and other performance constraints.
[[DC]] Again linked to issues above. If network resources are dedicated to =
each VN, this is true, but if they (or part of them) are shared, the instan=
tiation of a service from a given client would impact the VN seen by others=
. On the other side, aspects like security o performances should not be imp=
acted in any of the two cases.

YOUNG>> Agree.  So I guess we need to be clear on resource partitioning and=
 sharing issue clearly --- I think some application/client requires a hard =
dedicated resource while for some others it is fluid.
[DC] yes and this will give to the carriers the possibility to differentiat=
e their service offering, do you want guaranteed bandwidth in case of multi=
ple failures? Then you have to pay more.

-   Computing Time
Depending on the nature of applications, how quickly a VN is instantiated f=
rom the time of request is an important factor. For dynamic applications th=
at require instantaneous VN creation, the computation model/algorithm shoul=
d support this constraint.
[[DC]] I would say that timing constraints need to be met for service provi=
sioning (i.e. upon client requests on a given VN) but I think VN instantiat=
ion could be also a non real time procedure. I might be wrong...are there u=
se cases for real time and timing constrained VN creation requrests?

YOUNG>>  Again here what I meant was service request. I need to be clear on=
 the terminology.  If we were to define VN creation as the process of negot=
iation (similar to SLA negotiation), the initial VN creation is always off-=
line (static and non-real time). Once the initial VN creation negotiation i=
s done, then there might be cases where VN can be re-negotiated on the fly =
(e.g., changing some b/w or service objectives, or some physical failures s=
uch as fiber cut). But this is not VN creation; we need to distinguish this=
 from VN re-negotiation.
-   Admission Control
To coordinate the request process of multiple clients, an admission control=
 will help maximize an overall efficiency.
[[DC]] Yes. To understand where is the best place to do that. Cline control=
? VNC?

YOUNG>> As there are many clients that the VNC needs to support, I assume V=
NC has to have admission control module at the least. Client Controller, ho=
wever, may have its own admission control for supporting multiple applicati=
ons. We need to recognize a recursive client-server relationship. As long a=
s controller is a server controller of any sort, then admission control fun=
ction would help to coordinate its clients.

-   Path Constraints
There may be some factors of path constraints that can affect the overall e=
fficiency. Path Split can lower VN request blocking if the underlying netwo=
rk can support such capability. Packet-based TE network can support path sp=
lit while circuit-based transport may have a limitation.  Path migration is=
 a technique that allows changes of nodes or links assignment of the establ=
ished paths in an effort to accommodate new requests which would not be acc=
epted without path migration. This can improve overall efficiency, yet addi=
tional care needs to be applied to avoid any adverse impacts associated wit=
h changing the existing paths.
Re-optimization is a global process to re-shuffle all existing path assignm=
ent to minimize network resource fragmentation. Again, an extra care needs =
to be applied for re-optimization.
[[DC]] True. With path constraints I think we should include something more=
. When a client needs to setup a service/LSP there might be TE constraints =
associated to the request. Whan the VN needs to include is not only reachab=
ility information but in many cases is should be TE-reachability informatio=
n. In this case we could leverage on the overlay work being done e.g. in CC=
AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-=
exchange-02).

YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN =
scope, then  the TE-reacheability needs to be known/advertised by the serve=
r network to clients as 'capability' attribute.

--_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-priority:9;
	mso-style-link:"Heading 1 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:80.1pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level3 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h4
	{mso-style-priority:9;
	mso-style-link:"Heading 4 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level4 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h5
	{mso-style-priority:9;
	mso-style-link:"Heading 5 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level5 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h6
	{mso-style-priority:9;
	mso-style-link:"Heading 6 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level6 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-priority:9;
	mso-style-link:"Heading 7 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level7 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-priority:9;
	mso-style-link:"Heading 8 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level8 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-priority:9;
	mso-style-link:"Heading 9 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level9 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 1";
	font-family:"Courier New";}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Courier New";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Courier New";}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Courier New";}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 5";
	font-family:"Courier New";}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 6";
	font-family:"Courier New";}
span.Heading7Char
	{mso-style-name:"Heading 7 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 7";
	font-family:"Courier New";}
span.Heading8Char
	{mso-style-name:"Heading 8 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 8";
	font-family:"Courier New";}
span.Heading9Char
	{mso-style-name:"Heading 9 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 9";
	font-family:"Courier New";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle28
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle29
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle30
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle31
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:730737984;
	mso-list-template-ids:-1479607216;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-suffix:none;
	mso-level-text:"%1\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	mso-bidi-font-family:"Times New Roman";
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-bidi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level3
	{mso-level-style-link:"Heading 3";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:179.1pt;
	text-indent:-21.6pt;
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level4
	{mso-level-style-link:"Heading 4";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level5
	{mso-level-style-link:"Heading 5";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level6
	{mso-level-style-link:"Heading 6";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level7
	{mso-level-style-link:"Heading 7";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level8
	{mso-level-style-link:"Heading 8";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level9
	{mso-level-style-link:"Heading 9";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1
	{mso-list-id:927732023;
	mso-list-type:hybrid;
	mso-list-template-ids:644488524 1422297056 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Batang;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi all some more thoug=
ht with some cleaning<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">BR and Season greeting=
s!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">D<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<h2 style=3D"mso-list:none"><a name=3D"_Toc374709103"></a><o:p>&nbsp;</o:p>=
</h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Request Processing<o:p></o:p></h2>
<p class=3D"MsoNormal">This is concerned about whether a set of client requ=
ests for VN creation can be dealt with simultaneously or not. This depends =
on the nature of applications the client support. If the client does not re=
quire real-time instantiation of VN
 creation, the computation engine can process a set of VN creation requests=
 simultaneously to improve network efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] I think h=
ere we can assume that VN creation requests are non real time. Instantiatio=
n of services and bandwidth might be real time (and hence concurrency needs=
 to be managed) but I would say this
 is not the case of VN creation.</span></i></b><span style=3D"color:#1F497D=
"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Good poi=
nt. &nbsp;I was loose on the term &#8216;VN creation&#8221;.&nbsp; There ar=
e certainly negotiation aspects of VN creation which can be viewed as non-r=
eal time as the client endpoints need to be negotiated with network
 provider(s) before service creation. Yes, in that sense, I agree with you.=
 Here what I meant to say was when there are multiple service requests &nbs=
p;to setup virtual connections that need not be instantiated real-time, (in=
 other words, if some request can be
 queued for a delay scheduling), then a batch processing of multiple reques=
ts would be more optimal in general from a network efficiency perspective t=
han sequential processing.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[DC] yes and thi=
s is one of the biggest advantage of a centralized approach versus a distri=
buted one, that is the possibility to compute the optimal solution of a bun=
ch of requests</span></i></b><span style=3D"color:#1F497D"><o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><a name=3D"_Toc374709104"><![if !supportLists]><span style=3D"mso-list:Ig=
nore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Types of Network Resources</a><o:p></o:p></h2>
<p class=3D"MsoNormal">When client makes a VN creation request to the subst=
rate network, what kind of network resources is consumed is of concern of b=
oth the client and network providers. It depends on the application. For tr=
ansport network virtualization, the
 network resource consumed by the client is primarily network bandwidth tha=
t the paths would occupy on the physical link. However, there may be other =
resource types such as CPU and memory that need to be considered for certai=
n applications. These resource types
 are a part of the client&#8217;s VN request. <a name=3D"_Toc374709105"></a=
><o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Here the =
issue is thorny. The point is: a given resource is dedicated to a given VN =
or shared among different ones? We should start considering network resourc=
es partitioning issues&#8230;<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt;&nbsp; A =
given resource is &#8220;virtually&#8221; dedicated to a particular client;=
 yet this does not mean a particular client occupies a particular port (say=
 ODU port 1 vs 2).&nbsp; As long as resource is guaranteed for use
 to the client, it is fine for the Working Path at least; however for 1:N k=
ind of protection case, there is a level of sharing backup path resource fo=
r multiple clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[DC] well at lea=
st tributary port can&#8217;t be virtual I need to nail it to a physical nu=
mbering to physically connect the HW, for the rest I agree.&nbsp;
</span></i></b><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Accuracy of Network Resource Representation <o:p></=
o:p></h2>
<p class=3D"MsoNormal">As the underlying transport network in itself may co=
nsists of layered structure, it is a challenge how to represent these under=
lying physical network resources and topology into a form that can be relia=
bly used by the computation engine
 that assigns the client requests into the physical network resource and to=
pology.
<a name=3D"_Toc374709106"></a><o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Damnly tr=
ue<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[DC] I vote for =
a KISS approach
</span></i></b><b><i><span style=3D"font-family:Wingdings;color:#1F497D">J<=
/span></i></b><span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Resource Efficiency<o:p></o:p></h2>
<p class=3D"MsoNormal">Related to the accuracy of network resource represen=
tation is resource efficiency. As a set of independent client VN is created=
 and mapped onto physical network resources, the overall network resource u=
tilization is of the primary concern
 of the infrastructure provider. <o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] This issu=
e is pretty much linked to the one above (types of network resources)<o:p><=
/o:p></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Yes. <o:=
p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709107"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Guarantee of Client Isolation<o:p></o:p></h2>
<p class=3D"MsoNormal">While network resource sharing across a set of clien=
ts for efficient utilization is important aspect of network virtualization,=
 client isolation has to be guaranteed. Admissions of new client requests o=
r any changes of other existing clients&#8217;
 VNs must not affect any particular client in terms of resource guarantee, =
security constraints, and other performance constraints.&nbsp;
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Again lin=
ked to issues above. If network resources are dedicated to each VN, this is=
 true, but if they (or part of them) are shared, the instantiation of a ser=
vice from a given client would impact
 the VN seen by others. On the other side, aspects like security o performa=
nces should not be impacted in any of the two cases.<o:p></o:p></span></i><=
/b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Agree.&n=
bsp; So I guess we need to be clear on resource partitioning and sharing is=
sue clearly --- I think some application/client requires a hard dedicated r=
esource while for some others it is fluid.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[DC] yes and thi=
s will give to the carriers the possibility to differentiate their service =
offering, do you want guaranteed bandwidth in case of multiple failures? Th=
en you have to pay more.</span></i></b><span style=3D"color:#1F497D"><o:p><=
/o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709108"></a><o:p>&nbsp;</o:p></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Computing Time<o:p></o:p></h2>
<p class=3D"MsoNormal">Depending on the nature of applications, how quickly=
 a VN is instantiated from the time of request is an important factor. For =
dynamic applications that require instantaneous VN creation, the computatio=
n model/algorithm should support this
 constraint. <o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] I would s=
ay that timing constraints need to be met for service provisioning (i.e. up=
on client requests on a given VN) but I think VN instantiation could be als=
o a non real time procedure. I might
 be wrong&#8230;are there use cases for real time and timing constrained VN=
 creation requrests?</span></i></b><span style=3D"color:#1F497D"><o:p></o:p=
></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709109"></a><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><span style=3D"=
font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;col=
or:#1F497D">YOUNG&gt;&gt; &nbsp;Again here what I meant was service request=
. I need to be clear on the terminology.&nbsp; If we were to define VN crea=
tion
 as the process of negotiation (similar to SLA negotiation), the initial VN=
 creation is always off-line (static and non-real time). Once the initial V=
N creation negotiation is done, then there might be cases where VN can be r=
e-negotiated on the fly (e.g., changing
 some b/w or service objectives, or some physical failures such as fiber cu=
t). But this is not VN creation; we need to distinguish this from VN re-neg=
otiation.
<o:p></o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font=
:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Admission Control<o:p></o:p></h2>
<p class=3D"MsoNormal">To coordinate the request process of multiple client=
s, an admission control will help maximize an overall efficiency.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] Yes. To u=
nderstand where is the best place to do that. Cline control? VNC?<o:p></o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; As there=
 are many clients that the VNC needs to support, I assume VNC has to have a=
dmission control module at the least. Client Controller, however, may have =
its own admission control for supporting multiple
 applications. We need to recognize a recursive client-server relationship.=
 As long as controller is a server controller of any sort, then admission c=
ontrol function would help to coordinate its clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><a name=3D"_Toc374709110"><![if !supportLists]><span style=3D"mso-list:Ig=
nore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span><![endif]>Path Constraints</a><o:p></o:p></h2>
<p class=3D"MsoNormal">There may be some factors of path constraints that c=
an affect the overall efficiency. Path Split can lower VN request blocking =
if the underlying network can support such capability. Packet-based TE netw=
ork can support path split while circuit-based
 transport may have a limitation. &nbsp;Path migration is a technique that =
allows changes of nodes or links assignment of the established paths in an =
effort to accommodate new requests which would not be accepted without path=
 migration. This can improve overall
 efficiency, yet additional care needs to be applied to avoid any adverse i=
mpacts associated with changing the existing paths.
<o:p></o:p></p>
<p class=3D"MsoNormal">Re-optimization is a global process to re-shuffle al=
l existing path assignment to minimize network resource fragmentation. Agai=
n, an extra care needs to be applied for re-optimization.
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D">[[DC]] True. Wit=
h path constraints I think we should include something more. When a client =
needs to setup a service/LSP there might be TE constraints associated to th=
e request. Whan the VN needs to include
 is not only reachability information but in many cases is should be TE-rea=
chability information. In this case we could leverage on the overlay work b=
eing done e.g. in CCAMP and in (</span></i></b><a href=3D"http://tools.ietf=
.org/html/draft-farrel-interconnected-te-info-exchange-02">http://tools.iet=
f.org/html/draft-farrel-interconnected-te-info-exchange-02</a>).<span style=
=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">YOUNG&gt;&gt; Yes, if =
we include non-TE underlying transport as part of the ACTN scope, then &nbs=
p;the TE-reacheability needs to be known/advertised by the server network t=
o clients as &#8216;capability&#8217; attribute. &nbsp;</span><o:p></o:p></=
p>
</div>
</div>
</div>
</body>
</html>

--_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_--

From zhangfatai@huawei.com  Mon Dec 23 01:15:08 2013
Return-Path: <zhangfatai@huawei.com>
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 6DF8C1AC82A for <actn@ietfa.amsl.com>; Mon, 23 Dec 2013 01:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 oiqMAqqtfeiH for <actn@ietfa.amsl.com>; Mon, 23 Dec 2013 01:15:01 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7D0C1A1F78 for <actn@ietf.org>; Mon, 23 Dec 2013 01:15:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBS22461; Mon, 23 Dec 2013 09:14:55 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 09:14:07 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 09:14:52 +0000
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.231]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 17:14:42 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Diego Caviglia <diego.caviglia@ericsson.com>, Leeyoung <leeyoung@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem
Thread-Index: AQHO/7VORIr9tYTDQkCiAjaniNYAJZphfwIA
Date: Mon, 23 Dec 2013 09:14:41 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CAA93B1@SZXEMA504-MBS.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se>
In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.72.159]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "sdn@irtf.org" <sdn@irtf.org>
Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2013 09:15:08 -0000

--_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Open my eyes to look for Diego, but see another [DC], :)

Merry Charismas: My major comment, :)




Best Regards

Fatai

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Diego Caviglia
Sent: Monday, December 23, 2013 4:02 PM
To: Leeyoung; Daniele Ceccarelli; actn@ietf.org
Cc: sdn@irtf.org
Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) probl=
em

Hi all some more thought with some cleaning

BR and Season greetings!

D



-   Request Processing
This is concerned about whether a set of client requests for VN creation ca=
n be dealt with simultaneously or not. This depends on the nature of applic=
ations the client support. If the client does not require real-time instant=
iation of VN creation, the computation engine can process a set of VN creat=
ion requests simultaneously to improve network efficiency.
[[DC]] I think here we can assume that VN creation requests are non real ti=
me. Instantiation of services and bandwidth might be real time (and hence c=
oncurrency needs to be managed) but I would say this is not the case of VN =
creation.

YOUNG>> Good point.  I was loose on the term 'VN creation".  There are cert=
ainly negotiation aspects of VN creation which can be viewed as non-real ti=
me as the client endpoints need to be negotiated with network provider(s) b=
efore service creation. Yes, in that sense, I agree with you. Here what I m=
eant to say was when there are multiple service requests  to setup virtual =
connections that need not be instantiated real-time, (in other words, if so=
me request can be queued for a delay scheduling), then a batch processing o=
f multiple requests would be more optimal in general from a network efficie=
ncy perspective than sequential processing.
[DC] yes and this is one of the biggest advantage of a centralized approach=
 versus a distributed one, that is the possibility to compute the optimal s=
olution of a bunch of requests


-   Types of Network Resources
When client makes a VN creation request to the substrate network, what kind=
 of network resources is consumed is of concern of both the client and netw=
ork providers. It depends on the application. For transport network virtual=
ization, the network resource consumed by the client is primarily network b=
andwidth that the paths would occupy on the physical link. However, there m=
ay be other resource types such as CPU and memory that need to be considere=
d for certain applications. These resource types are a part of the client's=
 VN request.
[[DC]] Here the issue is thorny. The point is: a given resource is dedicate=
d to a given VN or shared among different ones? We should start considering=
 network resources partitioning issues...

YOUNG>>  A given resource is "virtually" dedicated to a particular client; =
yet this does not mean a particular client occupies a particular port (say =
ODU port 1 vs 2).  As long as resource is guaranteed for use to the client,=
 it is fine for the Working Path at least; however for 1:N kind of protecti=
on case, there is a level of sharing backup path resource for multiple clie=
nts.
[DC] well at least tributary port can't be virtual I need to nail it to a p=
hysical numbering to physically connect the HW, for the rest I agree.

-   Accuracy of Network Resource Representation
As the underlying transport network in itself may consists of layered struc=
ture, it is a challenge how to represent these underlying physical network =
resources and topology into a form that can be reliably used by the computa=
tion engine that assigns the client requests into the physical network reso=
urce and topology.
[[DC]] Damnly true
[DC] I vote for a KISS approach :)

-   Resource Efficiency
Related to the accuracy of network resource representation is resource effi=
ciency. As a set of independent client VN is created and mapped onto physic=
al network resources, the overall network resource utilization is of the pr=
imary concern of the infrastructure provider.
[[DC]] This issue is pretty much linked to the one above (types of network =
resources)

YOUNG>> Yes.

-   Guarantee of Client Isolation
While network resource sharing across a set of clients for efficient utiliz=
ation is important aspect of network virtualization, client isolation has t=
o be guaranteed. Admissions of new client requests or any changes of other =
existing clients' VNs must not affect any particular client in terms of res=
ource guarantee, security constraints, and other performance constraints.
[[DC]] Again linked to issues above. If network resources are dedicated to =
each VN, this is true, but if they (or part of them) are shared, the instan=
tiation of a service from a given client would impact the VN seen by others=
. On the other side, aspects like security o performances should not be imp=
acted in any of the two cases.

YOUNG>> Agree.  So I guess we need to be clear on resource partitioning and=
 sharing issue clearly --- I think some application/client requires a hard =
dedicated resource while for some others it is fluid.
[DC] yes and this will give to the carriers the possibility to differentiat=
e their service offering, do you want guaranteed bandwidth in case of multi=
ple failures? Then you have to pay more.

-   Computing Time
Depending on the nature of applications, how quickly a VN is instantiated f=
rom the time of request is an important factor. For dynamic applications th=
at require instantaneous VN creation, the computation model/algorithm shoul=
d support this constraint.
[[DC]] I would say that timing constraints need to be met for service provi=
sioning (i.e. upon client requests on a given VN) but I think VN instantiat=
ion could be also a non real time procedure. I might be wrong...are there u=
se cases for real time and timing constrained VN creation requrests?

YOUNG>>  Again here what I meant was service request. I need to be clear on=
 the terminology.  If we were to define VN creation as the process of negot=
iation (similar to SLA negotiation), the initial VN creation is always off-=
line (static and non-real time). Once the initial VN creation negotiation i=
s done, then there might be cases where VN can be re-negotiated on the fly =
(e.g., changing some b/w or service objectives, or some physical failures s=
uch as fiber cut). But this is not VN creation; we need to distinguish this=
 from VN re-negotiation.
-   Admission Control
To coordinate the request process of multiple clients, an admission control=
 will help maximize an overall efficiency.
[[DC]] Yes. To understand where is the best place to do that. Cline control=
? VNC?

YOUNG>> As there are many clients that the VNC needs to support, I assume V=
NC has to have admission control module at the least. Client Controller, ho=
wever, may have its own admission control for supporting multiple applicati=
ons. We need to recognize a recursive client-server relationship. As long a=
s controller is a server controller of any sort, then admission control fun=
ction would help to coordinate its clients.

-   Path Constraints
There may be some factors of path constraints that can affect the overall e=
fficiency. Path Split can lower VN request blocking if the underlying netwo=
rk can support such capability. Packet-based TE network can support path sp=
lit while circuit-based transport may have a limitation.  Path migration is=
 a technique that allows changes of nodes or links assignment of the establ=
ished paths in an effort to accommodate new requests which would not be acc=
epted without path migration. This can improve overall efficiency, yet addi=
tional care needs to be applied to avoid any adverse impacts associated wit=
h changing the existing paths.
Re-optimization is a global process to re-shuffle all existing path assignm=
ent to minimize network resource fragmentation. Again, an extra care needs =
to be applied for re-optimization.
[[DC]] True. With path constraints I think we should include something more=
. When a client needs to setup a service/LSP there might be TE constraints =
associated to the request. Whan the VN needs to include is not only reachab=
ility information but in many cases is should be TE-reachability informatio=
n. In this case we could leverage on the overlay work being done e.g. in CC=
AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-=
exchange-02).

YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN =
scope, then  the TE-reacheability needs to be known/advertised by the serve=
r network to clients as 'capability' attribute.

--_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 1 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h2
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 2 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h3
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 3 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:80.1pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level3 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h4
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 4 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level4 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h5
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 5 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level5 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h6
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 6 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level6 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 7 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level7 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 8 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level8 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-priority:9;
	mso-style-link:"\6807\9898 9 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l0 level9 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"\6279\6CE8\6846\6587\672C Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.1Char
	{mso-style-name:"\6807\9898 1 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 1";
	font-family:"Calibri","sans-serif";
	font-weight:bold;}
span.2Char
	{mso-style-name:"\6807\9898 2 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 2";
	font-family:"Cambria","serif";
	font-weight:bold;}
span.3Char
	{mso-style-name:"\6807\9898 3 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 3";
	font-family:"Calibri","sans-serif";
	font-weight:bold;}
span.4Char
	{mso-style-name:"\6807\9898 4 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 4";
	font-family:"Cambria","serif";
	font-weight:bold;}
span.5Char
	{mso-style-name:"\6807\9898 5 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 5";
	font-family:"Calibri","sans-serif";
	font-weight:bold;}
span.6Char
	{mso-style-name:"\6807\9898 6 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 6";
	font-family:"Cambria","serif";
	font-weight:bold;}
span.7Char
	{mso-style-name:"\6807\9898 7 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 7";
	font-family:"Calibri","sans-serif";
	font-weight:bold;}
span.8Char
	{mso-style-name:"\6807\9898 8 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 8";
	font-family:"Cambria","serif";}
span.9Char
	{mso-style-name:"\6807\9898 9 Char";
	mso-style-priority:9;
	mso-style-link:"\6807\9898 9";
	font-family:"Cambria","serif";}
span.Char
	{mso-style-name:"\6279\6CE8\6846\6587\672C Char";
	mso-style-priority:99;
	mso-style-link:\6279\6CE8\6846\6587\672C;
	font-family:"Calibri","sans-serif";}
p.Heading1, li.Heading1, div.Heading1
	{mso-style-name:"Heading 1";
	mso-style-link:"Heading 1 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 1";
	font-family:"Courier New";}
p.Heading2, li.Heading2, div.Heading2
	{mso-style-name:"Heading 2";
	mso-style-link:"Heading 2 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Courier New";}
p.Heading3, li.Heading3, div.Heading3
	{mso-style-name:"Heading 3";
	mso-style-link:"Heading 3 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Courier New";}
p.Heading4, li.Heading4, div.Heading4
	{mso-style-name:"Heading 4";
	mso-style-link:"Heading 4 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Courier New";}
p.Heading5, li.Heading5, div.Heading5
	{mso-style-name:"Heading 5";
	mso-style-link:"Heading 5 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 5";
	font-family:"Courier New";}
p.Heading6, li.Heading6, div.Heading6
	{mso-style-name:"Heading 6";
	mso-style-link:"Heading 6 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 6";
	font-family:"Courier New";}
p.Heading7, li.Heading7, div.Heading7
	{mso-style-name:"Heading 7";
	mso-style-link:"Heading 7 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading7Char
	{mso-style-name:"Heading 7 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 7";
	font-family:"Courier New";}
p.Heading8, li.Heading8, div.Heading8
	{mso-style-name:"Heading 8";
	mso-style-link:"Heading 8 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading8Char
	{mso-style-name:"Heading 8 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 8";
	font-family:"Courier New";}
p.Heading9, li.Heading9, div.Heading9
	{mso-style-name:"Heading 9";
	mso-style-link:"Heading 9 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading9Char
	{mso-style-name:"Heading 9 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 9";
	font-family:"Courier New";}
p.BalloonText, li.BalloonText, div.BalloonText
	{mso-style-name:"Balloon Text";
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle48
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle49
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle50
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle51
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle52
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:730737984;
	mso-list-template-ids:-1479607216;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-suffix:none;
	mso-level-text:"%1\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	mso-bidi-font-family:"Times New Roman";
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-bidi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level3
	{mso-level-style-link:"Heading 3";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:179.1pt;
	text-indent:-21.6pt;
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l0:level4
	{mso-level-style-link:"Heading 4";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level5
	{mso-level-style-link:"Heading 5";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level6
	{mso-level-style-link:"Heading 6";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level7
	{mso-level-style-link:"Heading 7";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level8
	{mso-level-style-link:"Heading 8";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level9
	{mso-level-style-link:"Heading 9";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1
	{mso-list-id:927732023;
	mso-list-type:hybrid;
	mso-list-template-ids:644488524 1422297056 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Batang;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">Open my eyes to look for Diego, but see another [DC],
</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Wingdings=
;color:#1F497D">J</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;colo=
r:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">Merry Charismas: My major comment,
</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Wingdings=
;color:#1F497D">J</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;colo=
r:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D">Best Re=
gards<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D">Fatai<o=
:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> sdn [mailto:sdn-bounces@irtf.org]
<b>On Behalf Of </b>Diego Caviglia<br>
<b>Sent:</b> Monday, December 23, 2013 4:02 PM<br>
<b>To:</b> Leeyoung; Daniele Ceccarelli; actn@ietf.org<br>
<b>Cc:</b> sdn@irtf.org<br>
<b>Subject:</b> Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE=
) problem<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">Hi all =
some more thought with some cleaning<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">BR and =
Season greetings!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">D<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<h2 style=3D"mso-list:none"><a name=3D"_Toc374709103"></a><span lang=3D"EN-=
US"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Request Processing<o:p>=
</o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">This is concerned about whether=
 a set of client requests for VN creation can be dealt with simultaneously =
or not. This depends on the nature of applications the client support. If t=
he client does not require real-time
 instantiation of VN creation, the computation engine can process a set of =
VN creation requests simultaneously to improve network efficiency.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] I think here we can assume that VN creation requests are non real tim=
e. Instantiation of services and bandwidth might be real time (and hence co=
ncurrency needs to be managed) but I would
 say this is not the case of VN creation.</span></i></b><span lang=3D"EN-US=
" style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Good point. &nbsp;I was loose on the term &#8216;VN creation&#8221;.=
&nbsp; There are certainly negotiation aspects of VN creation which can be =
viewed as non-real time as the client endpoints need to be negotiated
 with network provider(s) before service creation. Yes, in that sense, I ag=
ree with you. Here what I meant to say was when there are multiple service =
requests &nbsp;to setup virtual connections that need not be instantiated r=
eal-time, (in other words, if some request
 can be queued for a delay scheduling), then a batch processing of multiple=
 requests would be more optimal in general from a network efficiency perspe=
ctive than sequential processing.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] yes and this is one of the biggest advantage of a centralized approach =
versus a distributed one, that is the possibility to compute the optimal so=
lution of a bunch of requests</span></i></b><span lang=3D"EN-US" style=3D"c=
olor:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><a name=3D"_Toc374709104"><![if !supportLists]><span lang=3D"EN-US"><span=
 style=3D"mso-list:Ignore">-<span style=3D"font:7.0pt &quot;Times New Roman=
&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Types of Network Resour=
ces</span></a><span lang=3D"EN-US"><o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">When client makes a VN creation=
 request to the substrate network, what kind of network resources is consum=
ed is of concern of both the client and network providers. It depends on th=
e application. For transport network
 virtualization, the network resource consumed by the client is primarily n=
etwork bandwidth that the paths would occupy on the physical link. However,=
 there may be other resource types such as CPU and memory that need to be c=
onsidered for certain applications.
 These resource types are a part of the client&#8217;s VN request. <a name=
=3D"_Toc374709105">
</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Here the issue is thorny. The point is: a given resource is dedicated=
 to a given VN or shared among different ones? We should start considering =
network resources partitioning issues&#8230;<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt;&nbsp; A given resource is &#8220;virtually&#8221; dedicated to a par=
ticular client; yet this does not mean a particular client occupies a parti=
cular port (say ODU port 1 vs 2).&nbsp; As long as resource is guaranteed
 for use to the client, it is fine for the Working Path at least; however f=
or 1:N kind of protection case, there is a level of sharing backup path res=
ource for multiple clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] well at least tributary port can&#8217;t be virtual I need to nail it t=
o a physical numbering to physically connect the HW, for the rest I agree.&=
nbsp;
</span></i></b><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Accuracy of Network Res=
ource Representation
<o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">As the underlying transport net=
work in itself may consists of layered structure, it is a challenge how to =
represent these underlying physical network resources and topology into a f=
orm that can be reliably used by the
 computation engine that assigns the client requests into the physical netw=
ork resource and topology.
<a name=3D"_Toc374709106"></a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Damnly true<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] I vote for a KISS approach
</span></i></b><b><i><span lang=3D"EN-US" style=3D"font-family:Wingdings;co=
lor:#1F497D">J</span></i></b><span lang=3D"EN-US" style=3D"color:#1F497D"><=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Resource Efficiency<o:p=
></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Related to the accuracy of netw=
ork resource representation is resource efficiency. As a set of independent=
 client VN is created and mapped onto physical network resources, the overa=
ll network resource utilization is of
 the primary concern of the infrastructure provider. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] This issue is pretty much linked to the one above (types of network r=
esources)<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes. <o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709107"></a><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Guarantee of Client Iso=
lation<o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">While network resource sharing =
across a set of clients for efficient utilization is important aspect of ne=
twork virtualization, client isolation has to be guaranteed. Admissions of =
new client requests or any changes of
 other existing clients&#8217; VNs must not affect any particular client in=
 terms of resource guarantee, security constraints, and other performance c=
onstraints.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Again linked to issues above. If network resources are dedicated to e=
ach VN, this is true, but if they (or part of them) are shared, the instant=
iation of a service from a given client
 would impact the VN seen by others. On the other side, aspects like securi=
ty o performances should not be impacted in any of the two cases.<o:p></o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Agree.&nbsp; So I guess we need to be clear on resource partitioning=
 and sharing issue clearly --- I think some application/client requires a h=
ard dedicated resource while for some others it is
 fluid.&nbsp; <o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] yes and this will give to the carriers the possibility to differentiate=
 their service offering, do you want guaranteed bandwidth in case of multip=
le failures? Then you have to pay more.</span></i></b><span lang=3D"EN-US" =
style=3D"color:#1F497D"><o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709108"></a><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Computing Time<o:p></o:=
p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Depending on the nature of appl=
ications, how quickly a VN is instantiated from the time of request is an i=
mportant factor. For dynamic applications that require instantaneous VN cre=
ation, the computation model/algorithm
 should support this constraint. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] I would say that timing constraints need to be met for service provis=
ioning (i.e. upon client requests on a given VN) but I think VN instantiati=
on could be also a non real time procedure.
 I might be wrong&#8230;are there use cases for real time and timing constr=
ained VN creation requrests?</span></i></b><span lang=3D"EN-US" style=3D"co=
lor:#1F497D"><o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709109"></a><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&nbsp;</o:=
p></span></h2>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><span lang=3D"E=
N-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">YOUNG&gt;&gt; &nbsp;Again here what I meant was =
service request. I need to be clear on the terminology.&nbsp; If we were to
 define VN creation as the process of negotiation (similar to SLA negotiati=
on), the initial VN creation is always off-line (static and non-real time).=
 Once the initial VN creation negotiation is done, then there might be case=
s where VN can be re-negotiated
 on the fly (e.g., changing some b/w or service objectives, or some physica=
l failures such as fiber cut). But this is not VN creation; we need to dist=
inguish this from VN re-negotiation.
<o:p></o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Admission Control<o:p><=
/o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">To coordinate the request proce=
ss of multiple clients, an admission control will help maximize an overall =
efficiency.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Yes. To understand where is the best place to do that. Cline control?=
 VNC?<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; As there are many clients that the VNC needs to support, I assume VN=
C has to have admission control module at the least. Client Controller, how=
ever, may have its own admission control for
 supporting multiple applications. We need to recognize a recursive client-=
server relationship. As long as controller is a server controller of any so=
rt, then admission control function would help to coordinate its clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo4=
"><a name=3D"_Toc374709110"><![if !supportLists]><span lang=3D"EN-US"><span=
 style=3D"mso-list:Ignore">-<span style=3D"font:7.0pt &quot;Times New Roman=
&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Path Constraints</span>=
</a><span lang=3D"EN-US"><o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">There may be some factors of pa=
th constraints that can affect the overall efficiency. Path Split can lower=
 VN request blocking if the underlying network can support such capability.=
 Packet-based TE network can support
 path split while circuit-based transport may have a limitation. &nbsp;Path=
 migration is a technique that allows changes of nodes or links assignment =
of the established paths in an effort to accommodate new requests which wou=
ld not be accepted without path migration.
 This can improve overall efficiency, yet additional care needs to be appli=
ed to avoid any adverse impacts associated with changing the existing paths=
.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Re-optimization is a global pro=
cess to re-shuffle all existing path assignment to minimize network resourc=
e fragmentation. Again, an extra care needs to be applied for re-optimizati=
on.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] True. With path constraints I think we should include something more.=
 When a client needs to setup a service/LSP there might be TE constraints a=
ssociated to the request. Whan the VN
 needs to include is not only reachability information but in many cases is=
 should be TE-reachability information. In this case we could leverage on t=
he overlay work being done e.g. in CCAMP and in (</span></i></b><span lang=
=3D"EN-US"><a href=3D"http://tools.ietf.org/html/draft-farrel-interconnecte=
d-te-info-exchange-02">http://tools.ietf.org/html/draft-farrel-interconnect=
ed-te-info-exchange-02</a>).<span style=3D"color:#1F497D"><o:p></o:p></span=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes, if we include non-TE underlying transport as part of the ACTN s=
cope, then &nbsp;the TE-reacheability needs to be known/advertised by the s=
erver network to clients as &#8216;capability&#8217; attribute.
 &nbsp;</span><span lang=3D"EN-US"><o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_--


From zhang.xian@huawei.com  Tue Dec 31 01:02:02 2013
Return-Path: <zhang.xian@huawei.com>
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 13AD81AE145 for <actn@ietfa.amsl.com>; Tue, 31 Dec 2013 01:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.038
X-Spam-Level: 
X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 vtGso3V6Wkn2 for <actn@ietfa.amsl.com>; Tue, 31 Dec 2013 01:01:56 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D1F811AD6D1 for <actn@ietf.org>; Tue, 31 Dec 2013 01:01:55 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZM99019; Tue, 31 Dec 2013 09:01:48 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 09:01:38 +0000
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 09:01:46 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.167]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 31 Dec 2013 17:01:38 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Diego Caviglia <diego.caviglia@ericsson.com>, Leeyoung <leeyoung@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem
Thread-Index: AQHO/7VO+OStUqH2F06tUPCRN9xKhppuCJqQ
Date: Tue, 31 Dec 2013 09:01:37 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98@SZXEMA512-MBS.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se>
In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.104.209]
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "sdn@irtf.org" <sdn@irtf.org>
Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Dec 2013 09:02:02 -0000

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQogICBTb21lIGZ1cnRoZXIgdGhvdWdodHMgb24gc29tZSBvZiB0aGUgaXNzdWVz
Lg0KDQogICBCVFcsIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkIHRvIHNlZSB0aGUgc3RhdHVzIHF1
byBvZiBWTkUgcmVzZWFyY2gsIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUgYSBnb29kIHN0YXJ0aW5n
IHBvaW50Og0KDQpodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1LmRlL2ZpbGVhZG1pbi9maWxlcy9s
ZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2NoZXIyMDEzYS5wZGYNCg0KSGFwcHkg
bmV3IHllYXIsDQoNClhpYW4NCg0KRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5v
cmddIE9uIEJlaGFsZiBPZiBEaWVnbyBDYXZpZ2xpYQ0KU2VudDogMjAxM8TqMTLUwjIzyNUgMTY6
MDINClRvOiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBhY3RuQGlldGYub3JnDQpDYzog
c2RuQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW1Nkbl0gW0FjdG5dIHZpcnR1YWwgbmV0d29yayBt
YXBwaW5nL2VtYmVkZGluZyAoVk5NL1ZORSkgcHJvYmxlbQ0KDQpIaSBhbGwgc29tZSBtb3JlIHRo
b3VnaHQgd2l0aCBzb21lIGNsZWFuaW5nDQoNCkJSIGFuZCBTZWFzb24gZ3JlZXRpbmdzIQ0KDQpE
DQoNCg0KDQotICAgUmVxdWVzdCBQcm9jZXNzaW5nDQpUaGlzIGlzIGNvbmNlcm5lZCBhYm91dCB3
aGV0aGVyIGEgc2V0IG9mIGNsaWVudCByZXF1ZXN0cyBmb3IgVk4gY3JlYXRpb24gY2FuIGJlIGRl
YWx0IHdpdGggc2ltdWx0YW5lb3VzbHkgb3Igbm90LiBUaGlzIGRlcGVuZHMgb24gdGhlIG5hdHVy
ZSBvZiBhcHBsaWNhdGlvbnMgdGhlIGNsaWVudCBzdXBwb3J0LiBJZiB0aGUgY2xpZW50IGRvZXMg
bm90IHJlcXVpcmUgcmVhbC10aW1lIGluc3RhbnRpYXRpb24gb2YgVk4gY3JlYXRpb24sIHRoZSBj
b21wdXRhdGlvbiBlbmdpbmUgY2FuIHByb2Nlc3MgYSBzZXQgb2YgVk4gY3JlYXRpb24gcmVxdWVz
dHMgc2ltdWx0YW5lb3VzbHkgdG8gaW1wcm92ZSBuZXR3b3JrIGVmZmljaWVuY3kuDQpbW0RDXV0g
SSB0aGluayBoZXJlIHdlIGNhbiBhc3N1bWUgdGhhdCBWTiBjcmVhdGlvbiByZXF1ZXN0cyBhcmUg
bm9uIHJlYWwgdGltZS4gSW5zdGFudGlhdGlvbiBvZiBzZXJ2aWNlcyBhbmQgYmFuZHdpZHRoIG1p
Z2h0IGJlIHJlYWwgdGltZSAoYW5kIGhlbmNlIGNvbmN1cnJlbmN5IG5lZWRzIHRvIGJlIG1hbmFn
ZWQpIGJ1dCBJIHdvdWxkIHNheSB0aGlzIGlzIG5vdCB0aGUgY2FzZSBvZiBWTiBjcmVhdGlvbi4N
Cg0KWU9VTkc+PiBHb29kIHBvaW50LiAgSSB3YXMgbG9vc2Ugb24gdGhlIHRlcm0goa5WTiBjcmVh
dGlvbqGxLiAgVGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3RzIG9mIFZOIGNy
ZWF0aW9uIHdoaWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0aGUgY2xpZW50
IGVuZHBvaW50cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQgd2l0aCBuZXR3b3JrIHByb3ZpZGVyKHMp
IGJlZm9yZSBzZXJ2aWNlIGNyZWF0aW9uLiBZZXMsIGluIHRoYXQgc2Vuc2UsIEkgYWdyZWUgd2l0
aCB5b3UuIEhlcmUgd2hhdCBJIG1lYW50IHRvIHNheSB3YXMgd2hlbiB0aGVyZSBhcmUgbXVsdGlw
bGUgc2VydmljZSByZXF1ZXN0cyAgdG8gc2V0dXAgdmlydHVhbCBjb25uZWN0aW9ucyB0aGF0IG5l
ZWQgbm90IGJlIGluc3RhbnRpYXRlZCByZWFsLXRpbWUsIChpbiBvdGhlciB3b3JkcywgaWYgc29t
ZSByZXF1ZXN0IGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2NoZWR1bGluZyksIHRoZW4gYSBi
YXRjaCBwcm9jZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdvdWxkIGJlIG1vcmUgb3B0aW1h
bCBpbiBnZW5lcmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kgcGVyc3BlY3RpdmUgdGhhbiBz
ZXF1ZW50aWFsIHByb2Nlc3NpbmcuDQpbRENdIHllcyBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlIGJp
Z2dlc3QgYWR2YW50YWdlIG9mIGEgY2VudHJhbGl6ZWQgYXBwcm9hY2ggdmVyc3VzIGEgZGlzdHJp
YnV0ZWQgb25lLCB0aGF0IGlzIHRoZSBwb3NzaWJpbGl0eSB0byBjb21wdXRlIHRoZSBvcHRpbWFs
IHNvbHV0aW9uIG9mIGEgYnVuY2ggb2YgcmVxdWVzdHMNCg0KW1hpYW5dIEkgdGhpbmsgd2UgaGF2
ZSBhIHByZXR0eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSBhbmQgYXMgSSB1bmRlcnN0YW5k
LCB0aGUgcG9pbnRzIHJlbGF0ZWQgdG8gQUNUTiB3b3VsZCBpbmNsdWRlIGF0IGxlYXN0ICgxKSB3
aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIHBhc3NlZCBmcm9tIGNsaWVudCB0byB2aXJ0dWFs
IG5ldHdvcmsgcHJvdmlkZXI/OyAoMikgd2hhdCBjb25zdHJhaW50cyAgdGhlIGNsaWVudCBjYW4g
YWNjZXB0ICh0aW1lIG1pZ2h0IGJlIGEgY29uc3RyYWludHMpLiAgSWYgdGhlcmUgaXMgbW9yZSwg
cGxlYXNlIGFtZW5kLg0KDQotICAgVHlwZXMgb2YgTmV0d29yayBSZXNvdXJjZXMNCldoZW4gY2xp
ZW50IG1ha2VzIGEgVk4gY3JlYXRpb24gcmVxdWVzdCB0byB0aGUgc3Vic3RyYXRlIG5ldHdvcmss
IHdoYXQga2luZCBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBjb25zdW1lZCBpcyBvZiBjb25jZXJu
IG9mIGJvdGggdGhlIGNsaWVudCBhbmQgbmV0d29yayBwcm92aWRlcnMuIEl0IGRlcGVuZHMgb24g
dGhlIGFwcGxpY2F0aW9uLiBGb3IgdHJhbnNwb3J0IG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIHRo
ZSBuZXR3b3JrIHJlc291cmNlIGNvbnN1bWVkIGJ5IHRoZSBjbGllbnQgaXMgcHJpbWFyaWx5IG5l
dHdvcmsgYmFuZHdpZHRoIHRoYXQgdGhlIHBhdGhzIHdvdWxkIG9jY3VweSBvbiB0aGUgcGh5c2lj
YWwgbGluay4gSG93ZXZlciwgdGhlcmUgbWF5IGJlIG90aGVyIHJlc291cmNlIHR5cGVzIHN1Y2gg
YXMgQ1BVIGFuZCBtZW1vcnkgdGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgZm9yIGNlcnRhaW4g
YXBwbGljYXRpb25zLiBUaGVzZSByZXNvdXJjZSB0eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGll
bnShr3MgVk4gcmVxdWVzdC4NCltbRENdXSBIZXJlIHRoZSBpc3N1ZSBpcyB0aG9ybnkuIFRoZSBw
b2ludCBpczogYSBnaXZlbiByZXNvdXJjZSBpcyBkZWRpY2F0ZWQgdG8gYSBnaXZlbiBWTiBvciBz
aGFyZWQgYW1vbmcgZGlmZmVyZW50IG9uZXM/IFdlIHNob3VsZCBzdGFydCBjb25zaWRlcmluZyBu
ZXR3b3JrIHJlc291cmNlcyBwYXJ0aXRpb25pbmcgaXNzdWVzoa0NCg0KWU9VTkc+PiAgQSBnaXZl
biByZXNvdXJjZSBpcyChsHZpcnR1YWxseaGxIGRlZGljYXRlZCB0byBhIHBhcnRpY3VsYXIgY2xp
ZW50OyB5ZXQgdGhpcyBkb2VzIG5vdCBtZWFuIGEgcGFydGljdWxhciBjbGllbnQgb2NjdXBpZXMg
YSBwYXJ0aWN1bGFyIHBvcnQgKHNheSBPRFUgcG9ydCAxIHZzIDIpLiAgQXMgbG9uZyBhcyByZXNv
dXJjZSBpcyBndWFyYW50ZWVkIGZvciB1c2UgdG8gdGhlIGNsaWVudCwgaXQgaXMgZmluZSBmb3Ig
dGhlIFdvcmtpbmcgUGF0aCBhdCBsZWFzdDsgaG93ZXZlciBmb3IgMTpOIGtpbmQgb2YgcHJvdGVj
dGlvbiBjYXNlLCB0aGVyZSBpcyBhIGxldmVsIG9mIHNoYXJpbmcgYmFja3VwIHBhdGggcmVzb3Vy
Y2UgZm9yIG11bHRpcGxlIGNsaWVudHMuDQpbRENdIHdlbGwgYXQgbGVhc3QgdHJpYnV0YXJ5IHBv
cnQgY2Fuoa90IGJlIHZpcnR1YWwgSSBuZWVkIHRvIG5haWwgaXQgdG8gYSBwaHlzaWNhbCBudW1i
ZXJpbmcgdG8gcGh5c2ljYWxseSBjb25uZWN0IHRoZSBIVywgZm9yIHRoZSByZXN0IEkgYWdyZWUu
DQoNCltYaWFuXSBJIHRoaW5rIFlvdW5nIG1lYW50IHRoZSBwaHlzaWNhbCByZXNvdXJjZSBjYW4g
YmUgc2hhcmVkIGJ5IG11bHRpcGxlIGNsaWVudHMsIHByb2JhYmx5IGJ5IGFzc2lnbmluZyB0aGUg
c2FtZSBwaHlzaWNhbCBudW1iZXJpbmcgdG8gdGhlIGRpZmZlcmVudCBjbGllbnRzLiBUaGUgcG9p
bnQgdGhhdCB3b3J0aCBub3RpbmcgaXMgdGhhdCB3aGV0aGVyIHRoaXMga2luZCBvZiBzaGFyaW5n
IGNhbiBtYWtlIHN1cmUgbm8gY29uZmxpY3Qgd291bGQgYXJpc2Ugb3IgaWYgc28sIHdoZXRoZXIg
aXQgaXMgYWNjZXB0YWJsZS4NCg0KLSAgIEFjY3VyYWN5IG9mIE5ldHdvcmsgUmVzb3VyY2UgUmVw
cmVzZW50YXRpb24NCkFzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBuZXR3b3JrIGluIGl0c2Vs
ZiBtYXkgY29uc2lzdHMgb2YgbGF5ZXJlZCBzdHJ1Y3R1cmUsIGl0IGlzIGEgY2hhbGxlbmdlIGhv
dyB0byByZXByZXNlbnQgdGhlc2UgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNl
cyBhbmQgdG9wb2xvZ3kgaW50byBhIGZvcm0gdGhhdCBjYW4gYmUgcmVsaWFibHkgdXNlZCBieSB0
aGUgY29tcHV0YXRpb24gZW5naW5lIHRoYXQgYXNzaWducyB0aGUgY2xpZW50IHJlcXVlc3RzIGlu
dG8gdGhlIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2UgYW5kIHRvcG9sb2d5Lg0KW1tEQ11dIERh
bW5seSB0cnVlDQpbRENdIEkgdm90ZSBmb3IgYSBLSVNTIGFwcHJvYWNoIDopDQpbWGlhbl1DYW5u
b3QgYWdyZWUgd2l0aCBEaWVnbyBtb3JlLCA6RC4NCg0KLSAgIFJlc291cmNlIEVmZmljaWVuY3kN
ClJlbGF0ZWQgdG8gdGhlIGFjY3VyYWN5IG9mIG5ldHdvcmsgcmVzb3VyY2UgcmVwcmVzZW50YXRp
b24gaXMgcmVzb3VyY2UgZWZmaWNpZW5jeS4gQXMgYSBzZXQgb2YgaW5kZXBlbmRlbnQgY2xpZW50
IFZOIGlzIGNyZWF0ZWQgYW5kIG1hcHBlZCBvbnRvIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2Vz
LCB0aGUgb3ZlcmFsbCBuZXR3b3JrIHJlc291cmNlIHV0aWxpemF0aW9uIGlzIG9mIHRoZSBwcmlt
YXJ5IGNvbmNlcm4gb2YgdGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLg0KW1tEQ11dIFRoaXMg
aXNzdWUgaXMgcHJldHR5IG11Y2ggbGlua2VkIHRvIHRoZSBvbmUgYWJvdmUgKHR5cGVzIG9mIG5l
dHdvcmsgcmVzb3VyY2VzKQ0KDQpZT1VORz4+IFllcy4NCltYaWFuXSBUaGlzIHByb2JhYmx5IGlz
IG1vcmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFkIG9mIEFDVE4sIGJ1dCBmb3Igc3Vy
ZSBhbiBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KLSAgIEd1
YXJhbnRlZSBvZiBDbGllbnQgSXNvbGF0aW9uDQpXaGlsZSBuZXR3b3JrIHJlc291cmNlIHNoYXJp
bmcgYWNyb3NzIGEgc2V0IG9mIGNsaWVudHMgZm9yIGVmZmljaWVudCB1dGlsaXphdGlvbiBpcyBp
bXBvcnRhbnQgYXNwZWN0IG9mIG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIGNsaWVudCBpc29sYXRp
b24gaGFzIHRvIGJlIGd1YXJhbnRlZWQuIEFkbWlzc2lvbnMgb2YgbmV3IGNsaWVudCByZXF1ZXN0
cyBvciBhbnkgY2hhbmdlcyBvZiBvdGhlciBleGlzdGluZyBjbGllbnRzoa8gVk5zIG11c3Qgbm90
IGFmZmVjdCBhbnkgcGFydGljdWxhciBjbGllbnQgaW4gdGVybXMgb2YgcmVzb3VyY2UgZ3VhcmFu
dGVlLCBzZWN1cml0eSBjb25zdHJhaW50cywgYW5kIG90aGVyIHBlcmZvcm1hbmNlIGNvbnN0cmFp
bnRzLg0KW1tEQ11dIEFnYWluIGxpbmtlZCB0byBpc3N1ZXMgYWJvdmUuIElmIG5ldHdvcmsgcmVz
b3VyY2VzIGFyZSBkZWRpY2F0ZWQgdG8gZWFjaCBWTiwgdGhpcyBpcyB0cnVlLCBidXQgaWYgdGhl
eSAob3IgcGFydCBvZiB0aGVtKSBhcmUgc2hhcmVkLCB0aGUgaW5zdGFudGlhdGlvbiBvZiBhIHNl
cnZpY2UgZnJvbSBhIGdpdmVuIGNsaWVudCB3b3VsZCBpbXBhY3QgdGhlIFZOIHNlZW4gYnkgb3Ro
ZXJzLiBPbiB0aGUgb3RoZXIgc2lkZSwgYXNwZWN0cyBsaWtlIHNlY3VyaXR5IG8gcGVyZm9ybWFu
Y2VzIHNob3VsZCBub3QgYmUgaW1wYWN0ZWQgaW4gYW55IG9mIHRoZSB0d28gY2FzZXMuDQoNCllP
VU5HPj4gQWdyZWUuICBTbyBJIGd1ZXNzIHdlIG5lZWQgdG8gYmUgY2xlYXIgb24gcmVzb3VyY2Ug
cGFydGl0aW9uaW5nIGFuZCBzaGFyaW5nIGlzc3VlIGNsZWFybHkgLS0tIEkgdGhpbmsgc29tZSBh
cHBsaWNhdGlvbi9jbGllbnQgcmVxdWlyZXMgYSBoYXJkIGRlZGljYXRlZCByZXNvdXJjZSB3aGls
ZSBmb3Igc29tZSBvdGhlcnMgaXQgaXMgZmx1aWQuDQpbRENdIHllcyBhbmQgdGhpcyB3aWxsIGdp
dmUgdG8gdGhlIGNhcnJpZXJzIHRoZSBwb3NzaWJpbGl0eSB0byBkaWZmZXJlbnRpYXRlIHRoZWly
IHNlcnZpY2Ugb2ZmZXJpbmcsIGRvIHlvdSB3YW50IGd1YXJhbnRlZWQgYmFuZHdpZHRoIGluIGNh
c2Ugb2YgbXVsdGlwbGUgZmFpbHVyZXM/IFRoZW4geW91IGhhdmUgdG8gcGF5IG1vcmUuDQoNCi0g
ICBDb21wdXRpbmcgVGltZQ0KRGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgYXBwbGljYXRpb25z
LCBob3cgcXVpY2tseSBhIFZOIGlzIGluc3RhbnRpYXRlZCBmcm9tIHRoZSB0aW1lIG9mIHJlcXVl
c3QgaXMgYW4gaW1wb3J0YW50IGZhY3Rvci4gRm9yIGR5bmFtaWMgYXBwbGljYXRpb25zIHRoYXQg
cmVxdWlyZSBpbnN0YW50YW5lb3VzIFZOIGNyZWF0aW9uLCB0aGUgY29tcHV0YXRpb24gbW9kZWwv
YWxnb3JpdGhtIHNob3VsZCBzdXBwb3J0IHRoaXMgY29uc3RyYWludC4NCltbRENdXSBJIHdvdWxk
IHNheSB0aGF0IHRpbWluZyBjb25zdHJhaW50cyBuZWVkIHRvIGJlIG1ldCBmb3Igc2VydmljZSBw
cm92aXNpb25pbmcgKGkuZS4gdXBvbiBjbGllbnQgcmVxdWVzdHMgb24gYSBnaXZlbiBWTikgYnV0
IEkgdGhpbmsgVk4gaW5zdGFudGlhdGlvbiBjb3VsZCBiZSBhbHNvIGEgbm9uIHJlYWwgdGltZSBw
cm9jZWR1cmUuIEkgbWlnaHQgYmUgd3JvbmehrWFyZSB0aGVyZSB1c2UgY2FzZXMgZm9yIHJlYWwg
dGltZSBhbmQgdGltaW5nIGNvbnN0cmFpbmVkIFZOIGNyZWF0aW9uIHJlcXVyZXN0cz8NCg0KWU9V
Tkc+PiAgQWdhaW4gaGVyZSB3aGF0IEkgbWVhbnQgd2FzIHNlcnZpY2UgcmVxdWVzdC4gSSBuZWVk
IHRvIGJlIGNsZWFyIG9uIHRoZSB0ZXJtaW5vbG9neS4gIElmIHdlIHdlcmUgdG8gZGVmaW5lIFZO
IGNyZWF0aW9uIGFzIHRoZSBwcm9jZXNzIG9mIG5lZ290aWF0aW9uIChzaW1pbGFyIHRvIFNMQSBu
ZWdvdGlhdGlvbiksIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIGlzIGFsd2F5cyBvZmYtbGluZSAo
c3RhdGljIGFuZCBub24tcmVhbCB0aW1lKS4gT25jZSB0aGUgaW5pdGlhbCBWTiBjcmVhdGlvbiBu
ZWdvdGlhdGlvbiBpcyBkb25lLCB0aGVuIHRoZXJlIG1pZ2h0IGJlIGNhc2VzIHdoZXJlIFZOIGNh
biBiZSByZS1uZWdvdGlhdGVkIG9uIHRoZSBmbHkgKGUuZy4sIGNoYW5naW5nIHNvbWUgYi93IG9y
IHNlcnZpY2Ugb2JqZWN0aXZlcywgb3Igc29tZSBwaHlzaWNhbCBmYWlsdXJlcyBzdWNoIGFzIGZp
YmVyIGN1dCkuIEJ1dCB0aGlzIGlzIG5vdCBWTiBjcmVhdGlvbjsgd2UgbmVlZCB0byBkaXN0aW5n
dWlzaCB0aGlzIGZyb20gVk4gcmUtbmVnb3RpYXRpb24uDQotICAgQWRtaXNzaW9uIENvbnRyb2wN
ClRvIGNvb3JkaW5hdGUgdGhlIHJlcXVlc3QgcHJvY2VzcyBvZiBtdWx0aXBsZSBjbGllbnRzLCBh
biBhZG1pc3Npb24gY29udHJvbCB3aWxsIGhlbHAgbWF4aW1pemUgYW4gb3ZlcmFsbCBlZmZpY2ll
bmN5Lg0KW1tEQ11dIFllcy4gVG8gdW5kZXJzdGFuZCB3aGVyZSBpcyB0aGUgYmVzdCBwbGFjZSB0
byBkbyB0aGF0LiBDbGluZSBjb250cm9sPyBWTkM/DQoNCllPVU5HPj4gQXMgdGhlcmUgYXJlIG1h
bnkgY2xpZW50cyB0aGF0IHRoZSBWTkMgbmVlZHMgdG8gc3VwcG9ydCwgSSBhc3N1bWUgVk5DIGhh
cyB0byBoYXZlIGFkbWlzc2lvbiBjb250cm9sIG1vZHVsZSBhdCB0aGUgbGVhc3QuIENsaWVudCBD
b250cm9sbGVyLCBob3dldmVyLCBtYXkgaGF2ZSBpdHMgb3duIGFkbWlzc2lvbiBjb250cm9sIGZv
ciBzdXBwb3J0aW5nIG11bHRpcGxlIGFwcGxpY2F0aW9ucy4gV2UgbmVlZCB0byByZWNvZ25pemUg
YSByZWN1cnNpdmUgY2xpZW50LXNlcnZlciByZWxhdGlvbnNoaXAuIEFzIGxvbmcgYXMgY29udHJv
bGxlciBpcyBhIHNlcnZlciBjb250cm9sbGVyIG9mIGFueSBzb3J0LCB0aGVuIGFkbWlzc2lvbiBj
b250cm9sIGZ1bmN0aW9uIHdvdWxkIGhlbHAgdG8gY29vcmRpbmF0ZSBpdHMgY2xpZW50cy4NCg0K
LSAgIFBhdGggQ29uc3RyYWludHMNClRoZXJlIG1heSBiZSBzb21lIGZhY3RvcnMgb2YgcGF0aCBj
b25zdHJhaW50cyB0aGF0IGNhbiBhZmZlY3QgdGhlIG92ZXJhbGwgZWZmaWNpZW5jeS4gUGF0aCBT
cGxpdCBjYW4gbG93ZXIgVk4gcmVxdWVzdCBibG9ja2luZyBpZiB0aGUgdW5kZXJseWluZyBuZXR3
b3JrIGNhbiBzdXBwb3J0IHN1Y2ggY2FwYWJpbGl0eS4gUGFja2V0LWJhc2VkIFRFIG5ldHdvcmsg
Y2FuIHN1cHBvcnQgcGF0aCBzcGxpdCB3aGlsZSBjaXJjdWl0LWJhc2VkIHRyYW5zcG9ydCBtYXkg
aGF2ZSBhIGxpbWl0YXRpb24uICBQYXRoIG1pZ3JhdGlvbiBpcyBhIHRlY2huaXF1ZSB0aGF0IGFs
bG93cyBjaGFuZ2VzIG9mIG5vZGVzIG9yIGxpbmtzIGFzc2lnbm1lbnQgb2YgdGhlIGVzdGFibGlz
aGVkIHBhdGhzIGluIGFuIGVmZm9ydCB0byBhY2NvbW1vZGF0ZSBuZXcgcmVxdWVzdHMgd2hpY2gg
d291bGQgbm90IGJlIGFjY2VwdGVkIHdpdGhvdXQgcGF0aCBtaWdyYXRpb24uIFRoaXMgY2FuIGlt
cHJvdmUgb3ZlcmFsbCBlZmZpY2llbmN5LCB5ZXQgYWRkaXRpb25hbCBjYXJlIG5lZWRzIHRvIGJl
IGFwcGxpZWQgdG8gYXZvaWQgYW55IGFkdmVyc2UgaW1wYWN0cyBhc3NvY2lhdGVkIHdpdGggY2hh
bmdpbmcgdGhlIGV4aXN0aW5nIHBhdGhzLg0KUmUtb3B0aW1pemF0aW9uIGlzIGEgZ2xvYmFsIHBy
b2Nlc3MgdG8gcmUtc2h1ZmZsZSBhbGwgZXhpc3RpbmcgcGF0aCBhc3NpZ25tZW50IHRvIG1pbmlt
aXplIG5ldHdvcmsgcmVzb3VyY2UgZnJhZ21lbnRhdGlvbi4gQWdhaW4sIGFuIGV4dHJhIGNhcmUg
bmVlZHMgdG8gYmUgYXBwbGllZCBmb3IgcmUtb3B0aW1pemF0aW9uLg0KW1tEQ11dIFRydWUuIFdp
dGggcGF0aCBjb25zdHJhaW50cyBJIHRoaW5rIHdlIHNob3VsZCBpbmNsdWRlIHNvbWV0aGluZyBt
b3JlLiBXaGVuIGEgY2xpZW50IG5lZWRzIHRvIHNldHVwIGEgc2VydmljZS9MU1AgdGhlcmUgbWln
aHQgYmUgVEUgY29uc3RyYWludHMgYXNzb2NpYXRlZCB0byB0aGUgcmVxdWVzdC4gV2hhbiB0aGUg
Vk4gbmVlZHMgdG8gaW5jbHVkZSBpcyBub3Qgb25seSByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24g
YnV0IGluIG1hbnkgY2FzZXMgaXMgc2hvdWxkIGJlIFRFLXJlYWNoYWJpbGl0eSBpbmZvcm1hdGlv
bi4gSW4gdGhpcyBjYXNlIHdlIGNvdWxkIGxldmVyYWdlIG9uIHRoZSBvdmVybGF5IHdvcmsgYmVp
bmcgZG9uZSBlLmcuIGluIENDQU1QIGFuZCBpbiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtZmFycmVsLWludGVyY29ubmVjdGVkLXRlLWluZm8tZXhjaGFuZ2UtMDIpLg0KDQpZT1VO
Rz4+IFllcywgaWYgd2UgaW5jbHVkZSBub24tVEUgdW5kZXJseWluZyB0cmFuc3BvcnQgYXMgcGFy
dCBvZiB0aGUgQUNUTiBzY29wZSwgdGhlbiAgdGhlIFRFLXJlYWNoZWFiaWxpdHkgbmVlZHMgdG8g
YmUga25vd24vYWR2ZXJ0aXNlZCBieSB0aGUgc2VydmVyIG5ldHdvcmsgdG8gY2xpZW50cyBhcyCh
rmNhcGFiaWxpdHmhryBhdHRyaWJ1dGUuDQpbWGlhbl0gSGF2ZSB3ZSBhbHJlYWR5IGNvbmZpbmVk
IHRoZSBzY29wZSB0byBURSB0cmFuc3BvcnQgbmV0d29yayBvbmx5Pw0KDQpJIHRoaW5rIHdoZXRo
ZXIgdGhlIFRFIGluZm9ybWF0aW9uIGlzIGNvbnZleWVkIHRvIHRoZSBjbGllbnQgZGVwZW5kcyBv
biB0aGUgZGV0YWlscyB0aGUgY2xpZW50IHdhbnRzIHRvIGtub3cuIEZyb20gQUNUTiB3b3JrIHBv
aW50IG9mIHZpZXcsIGl0IHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIHBhcnQgb2YgdGhlIGNvbnN0
cmFpbnRzIHdvcnRoIGNvbnNpZGVyaW5nLg0K

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-priority:9;
	mso-style-link:"Heading 1 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level1 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level2 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:80.1pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level3 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h4
	{mso-style-priority:9;
	mso-style-link:"Heading 4 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level4 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h5
	{mso-style-priority:9;
	mso-style-link:"Heading 5 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level5 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
h6
	{mso-style-priority:9;
	mso-style-link:"Heading 6 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level6 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";
	font-weight:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-priority:9;
	mso-style-link:"Heading 7 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level7 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-priority:9;
	mso-style-link:"Heading 8 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level8 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-priority:9;
	mso-style-link:"Heading 9 Char";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	page-break-after:avoid;
	mso-list:l1 level9 lfo2;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin:0cm;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 1";
	font-family:"Courier New";}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Courier New";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Courier New";}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Courier New";}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 5";
	font-family:"Courier New";}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 6";
	font-family:"Courier New";}
span.Heading7Char
	{mso-style-name:"Heading 7 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 7";
	font-family:"Courier New";}
span.Heading8Char
	{mso-style-name:"Heading 8 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 8";
	font-family:"Courier New";}
span.Heading9Char
	{mso-style-name:"Heading 9 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 9";
	font-family:"Courier New";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle28
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle29
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle30
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle31
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle32
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:265621679;
	mso-list-type:hybrid;
	mso-list-template-ids:-1862489838 -1402436780 67698713 67698715 67698703 6=
7698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:730737984;
	mso-list-template-ids:-1479607216;}
@list l1:level1
	{mso-level-style-link:"Heading 1";
	mso-level-suffix:none;
	mso-level-text:"%1\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	mso-bidi-font-family:"Times New Roman";
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-bidi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l1:level2
	{mso-level-style-link:"Heading 2";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1:level3
	{mso-level-style-link:"Heading 3";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:179.1pt;
	text-indent:-21.6pt;
	font-variant:normal !important;
	mso-text-animation:none;
	mso-hide:none;
	text-transform:none;
	position:relative;
	top:0pt;
	mso-text-raise:0pt;
	letter-spacing:0pt;
	mso-font-kerning:0pt;
	text-effect:none;
	text-shadow:none;
	text-effect:none;
	text-effect:none;
	font-emphasize:none;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;
	mso-no-proof:no;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;
	vertical-align:baseline;}
@list l1:level4
	{mso-level-style-link:"Heading 4";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1:level5
	{mso-level-style-link:"Heading 5";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1:level6
	{mso-level-style-link:"Heading 6";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1:level7
	{mso-level-style-link:"Heading 7";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1:level8
	{mso-level-style-link:"Heading 8";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l1:level9
	{mso-level-style-link:"Heading 9";
	mso-level-suffix:none;
	mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\. ";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l2
	{mso-list-id:927732023;
	mso-list-type:hybrid;
	mso-list-template-ids:644488524 1422297056 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Batang;}
@list l2:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">Hi all,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">&nbsp;&nbsp; Some further thoughts on some of the issues.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">&nbsp; &nbsp;BTW, if anyone is interested to see the status quo o=
f VNE research, the following might be a good starting point:<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><a href=3D"http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl=
/meer/publications/pdf/Fischer2013a.pdf">http://www.fim.uni-passau.de/filea=
dmin/files/lehrstuhl/meer/publications/pdf/Fischer2013a.pdf</a><o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">Happy new year,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D">Xian<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> sdn [mailto:sdn-bounces@irtf.org]
<b>On Behalf Of </b>Diego Caviglia<br>
<b>Sent:</b> 2013</span><span style=3D"font-size:10.0pt;font-family:=CB=CE=
=CC=E5">=C4=EA</span><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-fa=
mily:&quot;Tahoma&quot;,&quot;sans-serif&quot;">12</span><span style=3D"fon=
t-size:10.0pt;font-family:=CB=CE=CC=E5">=D4=C2</span><span lang=3D"EN-US" s=
tyle=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&qu=
ot;">23</span><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5">=C8=
=D5</span><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;=
Tahoma&quot;,&quot;sans-serif&quot;">
 16:02<br>
<b>To:</b> Leeyoung; Daniele Ceccarelli; actn@ietf.org<br>
<b>Cc:</b> sdn@irtf.org<br>
<b>Subject:</b> Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE=
) problem<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">Hi all =
some more thought with some cleaning<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">BR and =
Season greetings!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">D<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<h2 style=3D"mso-list:none"><a name=3D"_Toc374709103"></a><span lang=3D"EN-=
US"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Request Processing<o:p>=
</o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">This is concerned about whether=
 a set of client requests for VN creation can be dealt with simultaneously =
or not. This depends on the nature of applications the client support. If t=
he client does not require real-time
 instantiation of VN creation, the computation engine can process a set of =
VN creation requests simultaneously to improve network efficiency.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] I think here we can assume that VN creation requests are non real tim=
e. Instantiation of services and bandwidth might be real time (and hence co=
ncurrency needs to be managed) but I would
 say this is not the case of VN creation.</span></i></b><span lang=3D"EN-US=
" style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Good point. &nbsp;I was loose on the term =A1=AEVN creation=A1=B1.&n=
bsp; There are certainly negotiation aspects of VN creation which can be vi=
ewed as non-real time as the client endpoints need to be negotiated
 with network provider(s) before service creation. Yes, in that sense, I ag=
ree with you. Here what I meant to say was when there are multiple service =
requests &nbsp;to setup virtual connections that need not be instantiated r=
eal-time, (in other words, if some request
 can be queued for a delay scheduling), then a batch processing of multiple=
 requests would be more optimal in general from a network efficiency perspe=
ctive than sequential processing.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] yes and this is one of the biggest advantage of a centralized approach =
versus a distributed one, that is the possibility to compute the optimal so=
lution of a bunch of requests</span></i></b><span lang=3D"EN-US" style=3D"c=
olor:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue">[Xian] I think we have a pretty understanding of the issue and as I =
understand, the points related to ACTN would include at least (1) what info=
rmation needs to be passed from client
 to virtual network provider?; (2) what constraints&nbsp; the client can ac=
cept (time might be a constraints).&nbsp; If there is more, please amend.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><a name=3D"_Toc374709104"><![if !supportLists]><span lang=3D"EN-US"><span=
 style=3D"mso-list:Ignore">-<span style=3D"font:7.0pt &quot;Times New Roman=
&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Types of Network Resour=
ces</span></a><span lang=3D"EN-US"><o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">When client makes a VN creation=
 request to the substrate network, what kind of network resources is consum=
ed is of concern of both the client and network providers. It depends on th=
e application. For transport network
 virtualization, the network resource consumed by the client is primarily n=
etwork bandwidth that the paths would occupy on the physical link. However,=
 there may be other resource types such as CPU and memory that need to be c=
onsidered for certain applications.
 These resource types are a part of the client=A1=AFs VN request. <a name=
=3D"_Toc374709105">
</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Here the issue is thorny. The point is: a given resource is dedicated=
 to a given VN or shared among different ones? We should start considering =
network resources partitioning issues=A1=AD<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt;&nbsp; A given resource is =A1=B0virtually=A1=B1 dedicated to a parti=
cular client; yet this does not mean a particular client occupies a particu=
lar port (say ODU port 1 vs 2).&nbsp; As long as resource is guaranteed
 for use to the client, it is fine for the Working Path at least; however f=
or 1:N kind of protection case, there is a level of sharing backup path res=
ource for multiple clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] well at least tributary port can=A1=AFt be virtual I need to nail it to=
 a physical numbering to physically connect the HW, for the rest I agree.&n=
bsp;
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue">[Xian] I think Young meant the physical resource can be shared by mu=
ltiple clients, probably by assigning the same physical numbering to the di=
fferent clients. The point that worth
 noting is that whether this kind of sharing can make sure no conflict woul=
d arise or if so, whether it is acceptable.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Accuracy of Network Res=
ource Representation
<o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">As the underlying transport net=
work in itself may consists of layered structure, it is a challenge how to =
represent these underlying physical network resources and topology into a f=
orm that can be reliably used by the
 computation engine that assigns the client requests into the physical netw=
ork resource and topology.
<a name=3D"_Toc374709106"></a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Damnly true<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] I vote for a KISS approach
</span></i></b><b><i><span lang=3D"EN-US" style=3D"font-family:Wingdings;co=
lor:#1F497D">J<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue">[Xian]Cannot agree with Diego more, :D.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Resource Efficiency<o:p=
></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Related to the accuracy of netw=
ork resource representation is resource efficiency. As a set of independent=
 client VN is created and mapped onto physical network resources, the overa=
ll network resource utilization is of
 the primary concern of the infrastructure provider. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] This issue is pretty much linked to the one above (types of network r=
esources)<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue">[Xian] This probably is more VNE algorithm related, instead of ACTN,=
 but for sure an important aspect for the overall solution.
<o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709107"></a><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Guarantee of Client Iso=
lation<o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">While network resource sharing =
across a set of clients for efficient utilization is important aspect of ne=
twork virtualization, client isolation has to be guaranteed. Admissions of =
new client requests or any changes of
 other existing clients=A1=AF VNs must not affect any particular client in =
terms of resource guarantee, security constraints, and other performance co=
nstraints.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Again linked to issues above. If network resources are dedicated to e=
ach VN, this is true, but if they (or part of them) are shared, the instant=
iation of a service from a given client
 would impact the VN seen by others. On the other side, aspects like securi=
ty o performances should not be impacted in any of the two cases.<o:p></o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Agree.&nbsp; So I guess we need to be clear on resource partitioning=
 and sharing issue clearly --- I think some application/client requires a h=
ard dedicated resource while for some others it is
 fluid.&nbsp; <o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
DC] yes and this will give to the carriers the possibility to differentiate=
 their service offering, do you want guaranteed bandwidth in case of multip=
le failures? Then you have to pay more.</span></i></b><span lang=3D"EN-US" =
style=3D"color:#1F497D"><o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709108"></a><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Computing Time<o:p></o:=
p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Depending on the nature of appl=
ications, how quickly a VN is instantiated from the time of request is an i=
mportant factor. For dynamic applications that require instantaneous VN cre=
ation, the computation model/algorithm
 should support this constraint. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] I would say that timing constraints need to be met for service provis=
ioning (i.e. upon client requests on a given VN) but I think VN instantiati=
on could be also a non real time procedure.
 I might be wrong=A1=ADare there use cases for real time and timing constra=
ined VN creation requrests?</span></i></b><span lang=3D"EN-US" style=3D"col=
or:#1F497D"><o:p></o:p></span></p>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><a name=3D"_Toc=
374709109"></a><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&nbsp;</o:=
p></span></h2>
<h2 style=3D"margin-left:0cm;text-indent:0cm;mso-list:none"><span lang=3D"E=
N-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">YOUNG&gt;&gt; &nbsp;Again here what I meant was =
service request. I need to be clear on the terminology.&nbsp; If we were to
 define VN creation as the process of negotiation (similar to SLA negotiati=
on), the initial VN creation is always off-line (static and non-real time).=
 Once the initial VN creation negotiation is done, then there might be case=
s where VN can be re-negotiated
 on the fly (e.g., changing some b/w or service objectives, or some physica=
l failures such as fiber cut). But this is not VN creation; we need to dist=
inguish this from VN re-negotiation.
<o:p></o:p></span></h2>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore"=
>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Admission Control<o:p><=
/o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">To coordinate the request proce=
ss of multiple clients, an admission control will help maximize an overall =
efficiency.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] Yes. To understand where is the best place to do that. Cline control?=
 VNC?<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; As there are many clients that the VNC needs to support, I assume VN=
C has to have admission control module at the least. Client Controller, how=
ever, may have its own admission control for
 supporting multiple applications. We need to recognize a recursive client-=
server relationship. As long as controller is a server controller of any so=
rt, then admission control function would help to coordinate its clients.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<h2 style=3D"margin-left:36.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4=
"><a name=3D"_Toc374709110"><![if !supportLists]><span lang=3D"EN-US"><span=
 style=3D"mso-list:Ignore">-<span style=3D"font:7.0pt &quot;Times New Roman=
&quot;">&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US">Path Constraints</span>=
</a><span lang=3D"EN-US"><o:p></o:p></span></h2>
<p class=3D"MsoNormal"><span lang=3D"EN-US">There may be some factors of pa=
th constraints that can affect the overall efficiency. Path Split can lower=
 VN request blocking if the underlying network can support such capability.=
 Packet-based TE network can support
 path split while circuit-based transport may have a limitation. &nbsp;Path=
 migration is a technique that allows changes of nodes or links assignment =
of the established paths in an effort to accommodate new requests which wou=
ld not be accepted without path migration.
 This can improve overall efficiency, yet additional care needs to be appli=
ed to avoid any adverse impacts associated with changing the existing paths=
.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Re-optimization is a global pro=
cess to re-shuffle all existing path assignment to minimize network resourc=
e fragmentation. Again, an extra care needs to be applied for re-optimizati=
on.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span lang=3D"EN-US" style=3D"color:#1F497D">[=
[DC]] True. With path constraints I think we should include something more.=
 When a client needs to setup a service/LSP there might be TE constraints a=
ssociated to the request. Whan the VN
 needs to include is not only reachability information but in many cases is=
 should be TE-reachability information. In this case we could leverage on t=
he overlay work being done e.g. in CCAMP and in (</span></i></b><span lang=
=3D"EN-US"><a href=3D"http://tools.ietf.org/html/draft-farrel-interconnecte=
d-te-info-exchange-02">http://tools.ietf.org/html/draft-farrel-interconnect=
ed-te-info-exchange-02</a>).<span style=3D"color:#1F497D"><o:p></o:p></span=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">YOUNG&g=
t;&gt; Yes, if we include non-TE underlying transport as part of the ACTN s=
cope, then &nbsp;the TE-reacheability needs to be known/advertised by the s=
erver network to clients as =A1=AEcapability=A1=AF attribute.
 &nbsp;</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue">[Xian] Have we already confined the scope to TE transport network on=
ly?&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;color=
:blue">I think whether the TE information is conveyed to the client depends=
 on the details the client wants to know. From ACTN work point of view, it =
should be considered as part of the constraints
 worth considering. <o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_--


From matta@bu.edu  Tue Dec 31 08:06:13 2013
Return-Path: <matta@bu.edu>
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 7CC551AE1D5; Tue, 31 Dec 2013 08:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 afLjP2QMzw6v; Tue, 31 Dec 2013 08:06:09 -0800 (PST)
Received: from relay67.bu.edu (relay67.bu.edu [128.197.228.67]) by ietfa.amsl.com (Postfix) with ESMTP id BAD451AE01F; Tue, 31 Dec 2013 08:06:07 -0800 (PST)
X-Envelope-From: matta@bu.edu
X-BU-AUTH: ist-ex10hub-2.bu.edu [10.231.8.45]
Received: from BU-AUTH (localhost.localdomain [127.0.0.1]) by relay67.bu.edu (8.14.3/8.13.8) with ESMTP id rBVG3hlh024140;  Tue, 31 Dec 2013 11:03:43 -0500
Received: from IST-EX10MBX-1.ad.bu.edu ([fe80::d9cd:e5be:f6e3:104a]) by IST-EX10HUB-2.ad.bu.edu ([fe80::28b2:ee45:cbfd:5915%12]) with mapi id 14.02.0342.003; Tue, 31 Dec 2013 11:03:43 -0500
From: "Matta, Abraham I" <matta@bu.edu>
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>, Diego Caviglia <diego.caviglia@ericsson.com>, Leeyoung <leeyoung@huawei.com>, "Daniele Ceccarelli" <daniele.ceccarelli@ericsson.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem
Thread-Index: AQHO/befd9ha2IsnEUaqfiiqSR+BPJphwtcAgAyjXYCAACIRAA==
Date: Tue, 31 Dec 2013 16:03:42 +0000
Message-ID: <CEE853F7.430D5%matta@bu.edu>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> <C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98@SZXEMA512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.231.8.171]
Content-Type: multipart/alternative; boundary="_000_CEE853F7430D5mattabuedu_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 31 Dec 2013 08:20:26 -0800
Cc: Flavio Esposito <flavio.esposito@gmail.com>, "sdn@irtf.org" <sdn@irtf.org>
Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Dec 2013 16:06:14 -0000

--_000_CEE853F7430D5mattabuedu_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QW5vdGhlciBzdXJ2ZXk6DQoNCmh0dHA6Ly93d3cuY3MuYnUuZWR1L3RlY2hyZXBvcnRzL3BkZi8y
MDExLTAyNS1zbGljZS1lbWJlZGRpbmcucGRmDQoNCg0KRi4gRXNwb3NpdG8sIEkuIE1hdHRhLCBh
bmQgVi4gSXNoYWtpYW4uIFNsaWNlIEVtYmVkZGluZyBTb2x1dGlvbnMgZm9yDQoNCkRpc3RyaWJ1
dGVkIFNlcnZpY2UgQXJjaGl0ZWN0dXJlcy4gQUNNIENvbXB1dGluZyBTdXJ2ZXlzLCBBY2NlcHRl
ZA0KDQpOb3ZlbWJlciAyMDEyICh0byBhcHBlYXIgaW4gVm9sdW1lIDQ2LCBJc3N1ZSAxLCBNYXJj
aCAyMDE0KS4NCg0KQmVzdCwNCmlicmFoaW0NCg0KRnJvbTogIlpoYW5neGlhbiAoWGlhbikiIDx6
aGFuZy54aWFuQGh1YXdlaS5jb208bWFpbHRvOnpoYW5nLnhpYW5AaHVhd2VpLmNvbT4+DQpEYXRl
OiBUdWVzZGF5LCBEZWNlbWJlciAzMSwgMjAxMyA0OjAxIEFNDQpUbzogRGllZ28gQ2F2aWdsaWEg
PGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTxtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nz
b24uY29tPj4sIExlZXlvdW5nIDxsZWV5b3VuZ0BodWF3ZWkuY29tPG1haWx0bzpsZWV5b3VuZ0Bo
dWF3ZWkuY29tPj4sIERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz
c29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4+LCAiYWN0bkBp
ZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz4iIDxhY3RuQGlldGYub3JnPG1haWx0bzphY3Ru
QGlldGYub3JnPj4NCkNjOiAic2RuQGlydGYub3JnPG1haWx0bzpzZG5AaXJ0Zi5vcmc+IiA8c2Ru
QGlydGYub3JnPG1haWx0bzpzZG5AaXJ0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtTZG5dIFtBY3Ru
XSB2aXJ0dWFsIG5ldHdvcmsgbWFwcGluZy9lbWJlZGRpbmcgKFZOTS9WTkUpIHByb2JsZW0NCg0K
SGkgYWxsLA0KDQogICBTb21lIGZ1cnRoZXIgdGhvdWdodHMgb24gc29tZSBvZiB0aGUgaXNzdWVz
Lg0KDQogICBCVFcsIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkIHRvIHNlZSB0aGUgc3RhdHVzIHF1
byBvZiBWTkUgcmVzZWFyY2gsIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUgYSBnb29kIHN0YXJ0aW5n
IHBvaW50Og0KDQpodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1LmRlL2ZpbGVhZG1pbi9maWxlcy9s
ZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2NoZXIyMDEzYS5wZGYNCg0KSGFwcHkg
bmV3IHllYXIsDQoNClhpYW4NCg0KRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5v
cmddIE9uIEJlaGFsZiBPZiBEaWVnbyBDYXZpZ2xpYQ0KU2VudDogMjAxM+W5tDEy5pyIMjPml6Ug
MTY6MDINClRvOiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBhY3RuQGlldGYub3JnPG1h
aWx0bzphY3RuQGlldGYub3JnPg0KQ2M6IHNkbkBpcnRmLm9yZzxtYWlsdG86c2RuQGlydGYub3Jn
Pg0KU3ViamVjdDogUmU6IFtTZG5dIFtBY3RuXSB2aXJ0dWFsIG5ldHdvcmsgbWFwcGluZy9lbWJl
ZGRpbmcgKFZOTS9WTkUpIHByb2JsZW0NCg0KSGkgYWxsIHNvbWUgbW9yZSB0aG91Z2h0IHdpdGgg
c29tZSBjbGVhbmluZw0KDQpCUiBhbmQgU2Vhc29uIGdyZWV0aW5ncyENCg0KRA0KDQoNCg0KLSAg
IFJlcXVlc3QgUHJvY2Vzc2luZw0KVGhpcyBpcyBjb25jZXJuZWQgYWJvdXQgd2hldGhlciBhIHNl
dCBvZiBjbGllbnQgcmVxdWVzdHMgZm9yIFZOIGNyZWF0aW9uIGNhbiBiZSBkZWFsdCB3aXRoIHNp
bXVsdGFuZW91c2x5IG9yIG5vdC4gVGhpcyBkZXBlbmRzIG9uIHRoZSBuYXR1cmUgb2YgYXBwbGlj
YXRpb25zIHRoZSBjbGllbnQgc3VwcG9ydC4gSWYgdGhlIGNsaWVudCBkb2VzIG5vdCByZXF1aXJl
IHJlYWwtdGltZSBpbnN0YW50aWF0aW9uIG9mIFZOIGNyZWF0aW9uLCB0aGUgY29tcHV0YXRpb24g
ZW5naW5lIGNhbiBwcm9jZXNzIGEgc2V0IG9mIFZOIGNyZWF0aW9uIHJlcXVlc3RzIHNpbXVsdGFu
ZW91c2x5IHRvIGltcHJvdmUgbmV0d29yayBlZmZpY2llbmN5Lg0KW1tEQ11dIEkgdGhpbmsgaGVy
ZSB3ZSBjYW4gYXNzdW1lIHRoYXQgVk4gY3JlYXRpb24gcmVxdWVzdHMgYXJlIG5vbiByZWFsIHRp
bWUuIEluc3RhbnRpYXRpb24gb2Ygc2VydmljZXMgYW5kIGJhbmR3aWR0aCBtaWdodCBiZSByZWFs
IHRpbWUgKGFuZCBoZW5jZSBjb25jdXJyZW5jeSBuZWVkcyB0byBiZSBtYW5hZ2VkKSBidXQgSSB3
b3VsZCBzYXkgdGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgVk4gY3JlYXRpb24uDQoNCllPVU5HPj4g
R29vZCBwb2ludC4gIEkgd2FzIGxvb3NlIG9uIHRoZSB0ZXJtIOKAmFZOIGNyZWF0aW9u4oCdLiAg
VGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3RzIG9mIFZOIGNyZWF0aW9uIHdo
aWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0aGUgY2xpZW50IGVuZHBvaW50
cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQgd2l0aCBuZXR3b3JrIHByb3ZpZGVyKHMpIGJlZm9yZSBz
ZXJ2aWNlIGNyZWF0aW9uLiBZZXMsIGluIHRoYXQgc2Vuc2UsIEkgYWdyZWUgd2l0aCB5b3UuIEhl
cmUgd2hhdCBJIG1lYW50IHRvIHNheSB3YXMgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgc2Vydmlj
ZSByZXF1ZXN0cyAgdG8gc2V0dXAgdmlydHVhbCBjb25uZWN0aW9ucyB0aGF0IG5lZWQgbm90IGJl
IGluc3RhbnRpYXRlZCByZWFsLXRpbWUsIChpbiBvdGhlciB3b3JkcywgaWYgc29tZSByZXF1ZXN0
IGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2NoZWR1bGluZyksIHRoZW4gYSBiYXRjaCBwcm9j
ZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdvdWxkIGJlIG1vcmUgb3B0aW1hbCBpbiBnZW5l
cmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kgcGVyc3BlY3RpdmUgdGhhbiBzZXF1ZW50aWFs
IHByb2Nlc3NpbmcuDQpbRENdIHllcyBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlIGJpZ2dlc3QgYWR2
YW50YWdlIG9mIGEgY2VudHJhbGl6ZWQgYXBwcm9hY2ggdmVyc3VzIGEgZGlzdHJpYnV0ZWQgb25l
LCB0aGF0IGlzIHRoZSBwb3NzaWJpbGl0eSB0byBjb21wdXRlIHRoZSBvcHRpbWFsIHNvbHV0aW9u
IG9mIGEgYnVuY2ggb2YgcmVxdWVzdHMNCg0KW1hpYW5dIEkgdGhpbmsgd2UgaGF2ZSBhIHByZXR0
eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSBhbmQgYXMgSSB1bmRlcnN0YW5kLCB0aGUgcG9p
bnRzIHJlbGF0ZWQgdG8gQUNUTiB3b3VsZCBpbmNsdWRlIGF0IGxlYXN0ICgxKSB3aGF0IGluZm9y
bWF0aW9uIG5lZWRzIHRvIGJlIHBhc3NlZCBmcm9tIGNsaWVudCB0byB2aXJ0dWFsIG5ldHdvcmsg
cHJvdmlkZXI/OyAoMikgd2hhdCBjb25zdHJhaW50cyAgdGhlIGNsaWVudCBjYW4gYWNjZXB0ICh0
aW1lIG1pZ2h0IGJlIGEgY29uc3RyYWludHMpLiAgSWYgdGhlcmUgaXMgbW9yZSwgcGxlYXNlIGFt
ZW5kLg0KDQotICAgVHlwZXMgb2YgTmV0d29yayBSZXNvdXJjZXMNCldoZW4gY2xpZW50IG1ha2Vz
IGEgVk4gY3JlYXRpb24gcmVxdWVzdCB0byB0aGUgc3Vic3RyYXRlIG5ldHdvcmssIHdoYXQga2lu
ZCBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBjb25zdW1lZCBpcyBvZiBjb25jZXJuIG9mIGJvdGgg
dGhlIGNsaWVudCBhbmQgbmV0d29yayBwcm92aWRlcnMuIEl0IGRlcGVuZHMgb24gdGhlIGFwcGxp
Y2F0aW9uLiBGb3IgdHJhbnNwb3J0IG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIHRoZSBuZXR3b3Jr
IHJlc291cmNlIGNvbnN1bWVkIGJ5IHRoZSBjbGllbnQgaXMgcHJpbWFyaWx5IG5ldHdvcmsgYmFu
ZHdpZHRoIHRoYXQgdGhlIHBhdGhzIHdvdWxkIG9jY3VweSBvbiB0aGUgcGh5c2ljYWwgbGluay4g
SG93ZXZlciwgdGhlcmUgbWF5IGJlIG90aGVyIHJlc291cmNlIHR5cGVzIHN1Y2ggYXMgQ1BVIGFu
ZCBtZW1vcnkgdGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgZm9yIGNlcnRhaW4gYXBwbGljYXRp
b25zLiBUaGVzZSByZXNvdXJjZSB0eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGllbnTigJlzIFZO
IHJlcXVlc3QuDQpbW0RDXV0gSGVyZSB0aGUgaXNzdWUgaXMgdGhvcm55LiBUaGUgcG9pbnQgaXM6
IGEgZ2l2ZW4gcmVzb3VyY2UgaXMgZGVkaWNhdGVkIHRvIGEgZ2l2ZW4gVk4gb3Igc2hhcmVkIGFt
b25nIGRpZmZlcmVudCBvbmVzPyBXZSBzaG91bGQgc3RhcnQgY29uc2lkZXJpbmcgbmV0d29yayBy
ZXNvdXJjZXMgcGFydGl0aW9uaW5nIGlzc3Vlc+KApg0KDQpZT1VORz4+ICBBIGdpdmVuIHJlc291
cmNlIGlzIOKAnHZpcnR1YWxseeKAnSBkZWRpY2F0ZWQgdG8gYSBwYXJ0aWN1bGFyIGNsaWVudDsg
eWV0IHRoaXMgZG9lcyBub3QgbWVhbiBhIHBhcnRpY3VsYXIgY2xpZW50IG9jY3VwaWVzIGEgcGFy
dGljdWxhciBwb3J0IChzYXkgT0RVIHBvcnQgMSB2cyAyKS4gIEFzIGxvbmcgYXMgcmVzb3VyY2Ug
aXMgZ3VhcmFudGVlZCBmb3IgdXNlIHRvIHRoZSBjbGllbnQsIGl0IGlzIGZpbmUgZm9yIHRoZSBX
b3JraW5nIFBhdGggYXQgbGVhc3Q7IGhvd2V2ZXIgZm9yIDE6TiBraW5kIG9mIHByb3RlY3Rpb24g
Y2FzZSwgdGhlcmUgaXMgYSBsZXZlbCBvZiBzaGFyaW5nIGJhY2t1cCBwYXRoIHJlc291cmNlIGZv
ciBtdWx0aXBsZSBjbGllbnRzLg0KW0RDXSB3ZWxsIGF0IGxlYXN0IHRyaWJ1dGFyeSBwb3J0IGNh
buKAmXQgYmUgdmlydHVhbCBJIG5lZWQgdG8gbmFpbCBpdCB0byBhIHBoeXNpY2FsIG51bWJlcmlu
ZyB0byBwaHlzaWNhbGx5IGNvbm5lY3QgdGhlIEhXLCBmb3IgdGhlIHJlc3QgSSBhZ3JlZS4NCg0K
W1hpYW5dIEkgdGhpbmsgWW91bmcgbWVhbnQgdGhlIHBoeXNpY2FsIHJlc291cmNlIGNhbiBiZSBz
aGFyZWQgYnkgbXVsdGlwbGUgY2xpZW50cywgcHJvYmFibHkgYnkgYXNzaWduaW5nIHRoZSBzYW1l
IHBoeXNpY2FsIG51bWJlcmluZyB0byB0aGUgZGlmZmVyZW50IGNsaWVudHMuIFRoZSBwb2ludCB0
aGF0IHdvcnRoIG5vdGluZyBpcyB0aGF0IHdoZXRoZXIgdGhpcyBraW5kIG9mIHNoYXJpbmcgY2Fu
IG1ha2Ugc3VyZSBubyBjb25mbGljdCB3b3VsZCBhcmlzZSBvciBpZiBzbywgd2hldGhlciBpdCBp
cyBhY2NlcHRhYmxlLg0KDQotICAgQWNjdXJhY3kgb2YgTmV0d29yayBSZXNvdXJjZSBSZXByZXNl
bnRhdGlvbg0KQXMgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IG5ldHdvcmsgaW4gaXRzZWxmIG1h
eSBjb25zaXN0cyBvZiBsYXllcmVkIHN0cnVjdHVyZSwgaXQgaXMgYSBjaGFsbGVuZ2UgaG93IHRv
IHJlcHJlc2VudCB0aGVzZSB1bmRlcmx5aW5nIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2VzIGFu
ZCB0b3BvbG9neSBpbnRvIGEgZm9ybSB0aGF0IGNhbiBiZSByZWxpYWJseSB1c2VkIGJ5IHRoZSBj
b21wdXRhdGlvbiBlbmdpbmUgdGhhdCBhc3NpZ25zIHRoZSBjbGllbnQgcmVxdWVzdHMgaW50byB0
aGUgcGh5c2ljYWwgbmV0d29yayByZXNvdXJjZSBhbmQgdG9wb2xvZ3kuDQpbW0RDXV0gRGFtbmx5
IHRydWUNCltEQ10gSSB2b3RlIGZvciBhIEtJU1MgYXBwcm9hY2gg4pi6DQpbWGlhbl1DYW5ub3Qg
YWdyZWUgd2l0aCBEaWVnbyBtb3JlLCA6RC4NCg0KLSAgIFJlc291cmNlIEVmZmljaWVuY3kNClJl
bGF0ZWQgdG8gdGhlIGFjY3VyYWN5IG9mIG5ldHdvcmsgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24g
aXMgcmVzb3VyY2UgZWZmaWNpZW5jeS4gQXMgYSBzZXQgb2YgaW5kZXBlbmRlbnQgY2xpZW50IFZO
IGlzIGNyZWF0ZWQgYW5kIG1hcHBlZCBvbnRvIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2VzLCB0
aGUgb3ZlcmFsbCBuZXR3b3JrIHJlc291cmNlIHV0aWxpemF0aW9uIGlzIG9mIHRoZSBwcmltYXJ5
IGNvbmNlcm4gb2YgdGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLg0KW1tEQ11dIFRoaXMgaXNz
dWUgaXMgcHJldHR5IG11Y2ggbGlua2VkIHRvIHRoZSBvbmUgYWJvdmUgKHR5cGVzIG9mIG5ldHdv
cmsgcmVzb3VyY2VzKQ0KDQpZT1VORz4+IFllcy4NCltYaWFuXSBUaGlzIHByb2JhYmx5IGlzIG1v
cmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFkIG9mIEFDVE4sIGJ1dCBmb3Igc3VyZSBh
biBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KLSAgIEd1YXJh
bnRlZSBvZiBDbGllbnQgSXNvbGF0aW9uDQpXaGlsZSBuZXR3b3JrIHJlc291cmNlIHNoYXJpbmcg
YWNyb3NzIGEgc2V0IG9mIGNsaWVudHMgZm9yIGVmZmljaWVudCB1dGlsaXphdGlvbiBpcyBpbXBv
cnRhbnQgYXNwZWN0IG9mIG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIGNsaWVudCBpc29sYXRpb24g
aGFzIHRvIGJlIGd1YXJhbnRlZWQuIEFkbWlzc2lvbnMgb2YgbmV3IGNsaWVudCByZXF1ZXN0cyBv
ciBhbnkgY2hhbmdlcyBvZiBvdGhlciBleGlzdGluZyBjbGllbnRz4oCZIFZOcyBtdXN0IG5vdCBh
ZmZlY3QgYW55IHBhcnRpY3VsYXIgY2xpZW50IGluIHRlcm1zIG9mIHJlc291cmNlIGd1YXJhbnRl
ZSwgc2VjdXJpdHkgY29uc3RyYWludHMsIGFuZCBvdGhlciBwZXJmb3JtYW5jZSBjb25zdHJhaW50
cy4NCltbRENdXSBBZ2FpbiBsaW5rZWQgdG8gaXNzdWVzIGFib3ZlLiBJZiBuZXR3b3JrIHJlc291
cmNlcyBhcmUgZGVkaWNhdGVkIHRvIGVhY2ggVk4sIHRoaXMgaXMgdHJ1ZSwgYnV0IGlmIHRoZXkg
KG9yIHBhcnQgb2YgdGhlbSkgYXJlIHNoYXJlZCwgdGhlIGluc3RhbnRpYXRpb24gb2YgYSBzZXJ2
aWNlIGZyb20gYSBnaXZlbiBjbGllbnQgd291bGQgaW1wYWN0IHRoZSBWTiBzZWVuIGJ5IG90aGVy
cy4gT24gdGhlIG90aGVyIHNpZGUsIGFzcGVjdHMgbGlrZSBzZWN1cml0eSBvIHBlcmZvcm1hbmNl
cyBzaG91bGQgbm90IGJlIGltcGFjdGVkIGluIGFueSBvZiB0aGUgdHdvIGNhc2VzLg0KDQpZT1VO
Rz4+IEFncmVlLiAgU28gSSBndWVzcyB3ZSBuZWVkIHRvIGJlIGNsZWFyIG9uIHJlc291cmNlIHBh
cnRpdGlvbmluZyBhbmQgc2hhcmluZyBpc3N1ZSBjbGVhcmx5IC0tLSBJIHRoaW5rIHNvbWUgYXBw
bGljYXRpb24vY2xpZW50IHJlcXVpcmVzIGEgaGFyZCBkZWRpY2F0ZWQgcmVzb3VyY2Ugd2hpbGUg
Zm9yIHNvbWUgb3RoZXJzIGl0IGlzIGZsdWlkLg0KW0RDXSB5ZXMgYW5kIHRoaXMgd2lsbCBnaXZl
IHRvIHRoZSBjYXJyaWVycyB0aGUgcG9zc2liaWxpdHkgdG8gZGlmZmVyZW50aWF0ZSB0aGVpciBz
ZXJ2aWNlIG9mZmVyaW5nLCBkbyB5b3Ugd2FudCBndWFyYW50ZWVkIGJhbmR3aWR0aCBpbiBjYXNl
IG9mIG11bHRpcGxlIGZhaWx1cmVzPyBUaGVuIHlvdSBoYXZlIHRvIHBheSBtb3JlLg0KDQotICAg
Q29tcHV0aW5nIFRpbWUNCkRlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIGFwcGxpY2F0aW9ucywg
aG93IHF1aWNrbHkgYSBWTiBpcyBpbnN0YW50aWF0ZWQgZnJvbSB0aGUgdGltZSBvZiByZXF1ZXN0
IGlzIGFuIGltcG9ydGFudCBmYWN0b3IuIEZvciBkeW5hbWljIGFwcGxpY2F0aW9ucyB0aGF0IHJl
cXVpcmUgaW5zdGFudGFuZW91cyBWTiBjcmVhdGlvbiwgdGhlIGNvbXB1dGF0aW9uIG1vZGVsL2Fs
Z29yaXRobSBzaG91bGQgc3VwcG9ydCB0aGlzIGNvbnN0cmFpbnQuDQpbW0RDXV0gSSB3b3VsZCBz
YXkgdGhhdCB0aW1pbmcgY29uc3RyYWludHMgbmVlZCB0byBiZSBtZXQgZm9yIHNlcnZpY2UgcHJv
dmlzaW9uaW5nIChpLmUuIHVwb24gY2xpZW50IHJlcXVlc3RzIG9uIGEgZ2l2ZW4gVk4pIGJ1dCBJ
IHRoaW5rIFZOIGluc3RhbnRpYXRpb24gY291bGQgYmUgYWxzbyBhIG5vbiByZWFsIHRpbWUgcHJv
Y2VkdXJlLiBJIG1pZ2h0IGJlIHdyb25n4oCmYXJlIHRoZXJlIHVzZSBjYXNlcyBmb3IgcmVhbCB0
aW1lIGFuZCB0aW1pbmcgY29uc3RyYWluZWQgVk4gY3JlYXRpb24gcmVxdXJlc3RzPw0KDQpZT1VO
Rz4+ICBBZ2FpbiBoZXJlIHdoYXQgSSBtZWFudCB3YXMgc2VydmljZSByZXF1ZXN0LiBJIG5lZWQg
dG8gYmUgY2xlYXIgb24gdGhlIHRlcm1pbm9sb2d5LiAgSWYgd2Ugd2VyZSB0byBkZWZpbmUgVk4g
Y3JlYXRpb24gYXMgdGhlIHByb2Nlc3Mgb2YgbmVnb3RpYXRpb24gKHNpbWlsYXIgdG8gU0xBIG5l
Z290aWF0aW9uKSwgdGhlIGluaXRpYWwgVk4gY3JlYXRpb24gaXMgYWx3YXlzIG9mZi1saW5lIChz
dGF0aWMgYW5kIG5vbi1yZWFsIHRpbWUpLiBPbmNlIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIG5l
Z290aWF0aW9uIGlzIGRvbmUsIHRoZW4gdGhlcmUgbWlnaHQgYmUgY2FzZXMgd2hlcmUgVk4gY2Fu
IGJlIHJlLW5lZ290aWF0ZWQgb24gdGhlIGZseSAoZS5nLiwgY2hhbmdpbmcgc29tZSBiL3cgb3Ig
c2VydmljZSBvYmplY3RpdmVzLCBvciBzb21lIHBoeXNpY2FsIGZhaWx1cmVzIHN1Y2ggYXMgZmli
ZXIgY3V0KS4gQnV0IHRoaXMgaXMgbm90IFZOIGNyZWF0aW9uOyB3ZSBuZWVkIHRvIGRpc3Rpbmd1
aXNoIHRoaXMgZnJvbSBWTiByZS1uZWdvdGlhdGlvbi4NCi0gICBBZG1pc3Npb24gQ29udHJvbA0K
VG8gY29vcmRpbmF0ZSB0aGUgcmVxdWVzdCBwcm9jZXNzIG9mIG11bHRpcGxlIGNsaWVudHMsIGFu
IGFkbWlzc2lvbiBjb250cm9sIHdpbGwgaGVscCBtYXhpbWl6ZSBhbiBvdmVyYWxsIGVmZmljaWVu
Y3kuDQpbW0RDXV0gWWVzLiBUbyB1bmRlcnN0YW5kIHdoZXJlIGlzIHRoZSBiZXN0IHBsYWNlIHRv
IGRvIHRoYXQuIENsaW5lIGNvbnRyb2w/IFZOQz8NCg0KWU9VTkc+PiBBcyB0aGVyZSBhcmUgbWFu
eSBjbGllbnRzIHRoYXQgdGhlIFZOQyBuZWVkcyB0byBzdXBwb3J0LCBJIGFzc3VtZSBWTkMgaGFz
IHRvIGhhdmUgYWRtaXNzaW9uIGNvbnRyb2wgbW9kdWxlIGF0IHRoZSBsZWFzdC4gQ2xpZW50IENv
bnRyb2xsZXIsIGhvd2V2ZXIsIG1heSBoYXZlIGl0cyBvd24gYWRtaXNzaW9uIGNvbnRyb2wgZm9y
IHN1cHBvcnRpbmcgbXVsdGlwbGUgYXBwbGljYXRpb25zLiBXZSBuZWVkIHRvIHJlY29nbml6ZSBh
IHJlY3Vyc2l2ZSBjbGllbnQtc2VydmVyIHJlbGF0aW9uc2hpcC4gQXMgbG9uZyBhcyBjb250cm9s
bGVyIGlzIGEgc2VydmVyIGNvbnRyb2xsZXIgb2YgYW55IHNvcnQsIHRoZW4gYWRtaXNzaW9uIGNv
bnRyb2wgZnVuY3Rpb24gd291bGQgaGVscCB0byBjb29yZGluYXRlIGl0cyBjbGllbnRzLg0KDQot
ICAgUGF0aCBDb25zdHJhaW50cw0KVGhlcmUgbWF5IGJlIHNvbWUgZmFjdG9ycyBvZiBwYXRoIGNv
bnN0cmFpbnRzIHRoYXQgY2FuIGFmZmVjdCB0aGUgb3ZlcmFsbCBlZmZpY2llbmN5LiBQYXRoIFNw
bGl0IGNhbiBsb3dlciBWTiByZXF1ZXN0IGJsb2NraW5nIGlmIHRoZSB1bmRlcmx5aW5nIG5ldHdv
cmsgY2FuIHN1cHBvcnQgc3VjaCBjYXBhYmlsaXR5LiBQYWNrZXQtYmFzZWQgVEUgbmV0d29yayBj
YW4gc3VwcG9ydCBwYXRoIHNwbGl0IHdoaWxlIGNpcmN1aXQtYmFzZWQgdHJhbnNwb3J0IG1heSBo
YXZlIGEgbGltaXRhdGlvbi4gIFBhdGggbWlncmF0aW9uIGlzIGEgdGVjaG5pcXVlIHRoYXQgYWxs
b3dzIGNoYW5nZXMgb2Ygbm9kZXMgb3IgbGlua3MgYXNzaWdubWVudCBvZiB0aGUgZXN0YWJsaXNo
ZWQgcGF0aHMgaW4gYW4gZWZmb3J0IHRvIGFjY29tbW9kYXRlIG5ldyByZXF1ZXN0cyB3aGljaCB3
b3VsZCBub3QgYmUgYWNjZXB0ZWQgd2l0aG91dCBwYXRoIG1pZ3JhdGlvbi4gVGhpcyBjYW4gaW1w
cm92ZSBvdmVyYWxsIGVmZmljaWVuY3ksIHlldCBhZGRpdGlvbmFsIGNhcmUgbmVlZHMgdG8gYmUg
YXBwbGllZCB0byBhdm9pZCBhbnkgYWR2ZXJzZSBpbXBhY3RzIGFzc29jaWF0ZWQgd2l0aCBjaGFu
Z2luZyB0aGUgZXhpc3RpbmcgcGF0aHMuDQpSZS1vcHRpbWl6YXRpb24gaXMgYSBnbG9iYWwgcHJv
Y2VzcyB0byByZS1zaHVmZmxlIGFsbCBleGlzdGluZyBwYXRoIGFzc2lnbm1lbnQgdG8gbWluaW1p
emUgbmV0d29yayByZXNvdXJjZSBmcmFnbWVudGF0aW9uLiBBZ2FpbiwgYW4gZXh0cmEgY2FyZSBu
ZWVkcyB0byBiZSBhcHBsaWVkIGZvciByZS1vcHRpbWl6YXRpb24uDQpbW0RDXV0gVHJ1ZS4gV2l0
aCBwYXRoIGNvbnN0cmFpbnRzIEkgdGhpbmsgd2Ugc2hvdWxkIGluY2x1ZGUgc29tZXRoaW5nIG1v
cmUuIFdoZW4gYSBjbGllbnQgbmVlZHMgdG8gc2V0dXAgYSBzZXJ2aWNlL0xTUCB0aGVyZSBtaWdo
dCBiZSBURSBjb25zdHJhaW50cyBhc3NvY2lhdGVkIHRvIHRoZSByZXF1ZXN0LiBXaGFuIHRoZSBW
TiBuZWVkcyB0byBpbmNsdWRlIGlzIG5vdCBvbmx5IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBi
dXQgaW4gbWFueSBjYXNlcyBpcyBzaG91bGQgYmUgVEUtcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9u
LiBJbiB0aGlzIGNhc2Ugd2UgY291bGQgbGV2ZXJhZ2Ugb24gdGhlIG92ZXJsYXkgd29yayBiZWlu
ZyBkb25lIGUuZy4gaW4gQ0NBTVAgYW5kIGluIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1mYXJyZWwtaW50ZXJjb25uZWN0ZWQtdGUtaW5mby1leGNoYW5nZS0wMikuDQoNCllPVU5H
Pj4gWWVzLCBpZiB3ZSBpbmNsdWRlIG5vbi1URSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBhcyBwYXJ0
IG9mIHRoZSBBQ1ROIHNjb3BlLCB0aGVuICB0aGUgVEUtcmVhY2hlYWJpbGl0eSBuZWVkcyB0byBi
ZSBrbm93bi9hZHZlcnRpc2VkIGJ5IHRoZSBzZXJ2ZXIgbmV0d29yayB0byBjbGllbnRzIGFzIOKA
mGNhcGFiaWxpdHnigJkgYXR0cmlidXRlLg0KW1hpYW5dIEhhdmUgd2UgYWxyZWFkeSBjb25maW5l
ZCB0aGUgc2NvcGUgdG8gVEUgdHJhbnNwb3J0IG5ldHdvcmsgb25seT8NCg0KSSB0aGluayB3aGV0
aGVyIHRoZSBURSBpbmZvcm1hdGlvbiBpcyBjb252ZXllZCB0byB0aGUgY2xpZW50IGRlcGVuZHMg
b24gdGhlIGRldGFpbHMgdGhlIGNsaWVudCB3YW50cyB0byBrbm93LiBGcm9tIEFDVE4gd29yayBw
b2ludCBvZiB2aWV3LCBpdCBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSBjb25z
dHJhaW50cyB3b3J0aCBjb25zaWRlcmluZy4NCg==

--_000_CEE853F7430D5mattabuedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <C8A5296CF4D3444497E0C64533773A03@adr.bu.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgIj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwg
c2Fucy1zZXJpZjsgIj5Bbm90aGVyIHN1cnZleTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6
ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PGJyPg0KPC9kaXY+
DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyAiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY3MuYnUuZWR1L3RlY2hyZXBvcnRzL3BkZi8y
MDExLTAyNS1zbGljZS1lbWJlZGRpbmcucGRmIj5odHRwOi8vd3d3LmNzLmJ1LmVkdS90ZWNocmVw
b3J0cy9wZGYvMjAxMS0wMjUtc2xpY2UtZW1iZWRkaW5nLnBkZjwvYT4mbmJzcDs8L2Rpdj4NCjxk
aXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7ICI+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFy
Z2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgZm9u
dDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOHB4L25vcm1hbCBIZWx2ZXRpY2E7ICI+DQo8Zm9udCBj
bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Ri4gRXNwb3Np
dG8sIEkuIE1hdHRhLCBhbmQgVi4gSXNoYWtpYW4uIFNsaWNlIEVtYmVkZGluZyBTb2x1dGlvbnMg
Zm9yPC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDog
MHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IGZvbnQ6IG5vcm1hbCBu
b3JtYWwgbm9ybWFsIDhweC9ub3JtYWwgSGVsdmV0aWNhOyAiPg0KPGZvbnQgY2xhc3M9IkFwcGxl
LXN0eWxlLXNwYW4iIGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPkRpc3RyaWJ1dGVkIFNlcnZpY2Ug
QXJjaGl0ZWN0dXJlcy4gQUNNIENvbXB1dGluZyBTdXJ2ZXlzLCBBY2NlcHRlZDwvZm9udD48L3A+
DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJv
dHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCA4
cHgvbm9ybWFsIEhlbHZldGljYTsgIj4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBm
YWNlPSJDYWxpYnJpIiBzaXplPSIzIj5Ob3ZlbWJlciAyMDEyICh0byBhcHBlYXIgaW4gVm9sdW1l
IDQ2LCBJc3N1ZSAxLCBNYXJjaCAyMDE0KS48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl
PSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxi
cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsgIj5CZXN0LDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5
bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+
aWJyYWhpbTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP
RFlfU0VDVElPTiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmks
IHNhbnMtc2VyaWY7ICI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp
emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk
aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg
UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk
ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtaaGFu
Z3hpYW4gKFhpYW4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86emhhbmcueGlhbkBodWF3ZWku
Y29tIj56aGFuZy54aWFuQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250
LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMzEsIDIwMTMgNDow
MSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkRpZWdv
IENhdmlnbGlhICZsdDs8YSBocmVmPSJtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29t
Ij5kaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb208L2E+Jmd0OywgTGVleW91bmcgJmx0OzxhIGhy
ZWY9Im1haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIj5sZWV5b3VuZ0BodWF3ZWkuY29tPC9hPiZn
dDssIERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2Fy
ZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0
OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86YWN0bkBpZXRmLm9yZyI+YWN0bkBpZXRmLm9yZzwv
YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphY3RuQGlldGYub3JnIj5hY3RuQGlldGYub3Jn
PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4m
cXVvdDs8YSBocmVmPSJtYWlsdG86c2RuQGlydGYub3JnIj5zZG5AaXJ0Zi5vcmc8L2E+JnF1b3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86c2RuQGlydGYub3JnIj5zZG5AaXJ0Zi5vcmc8L2E+Jmd0Ozxi
cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtT
ZG5dIFtBY3RuXSB2aXJ0dWFsIG5ldHdvcmsgbWFwcGluZy9lbWJlZGRpbmcgKFZOTS9WTkUpIHBy
b2JsZW08YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9InVybjpz
Y2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt
Y29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOndvcmQiIHhtbG5zOng9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmV4Y2Vs
IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29t
bWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9
IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSki
Pg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpCYXRhbmc7DQoJcGFub3NlLTE6MiAzIDYgMCAwIDEgMSAx
IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEg
NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIg
MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBCYXRhbmci
Ow0KCXBhbm9zZS0xOjIgMyA2IDAgMCAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj
bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbWFyZ2luLXRvcDowY207DQoJ
bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEyLjBwdDsNCgltYXJnaW4tbGVmdDoy
MS42cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDsNCglsaW5lLWhlaWdodDoxMi4wcHQ7DQoJbXNv
LWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseTsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1z
by1saXN0OmwxIGxldmVsMSBsZm8yOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpub3JtYWw7fQ0KaDINCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFyIjsNCgltYXJnaW4tdG9w
OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdp
bi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBw
dDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZv
aWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQpoMw0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENoYXIiOw0KCW1h
cmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbToxMi4wcHQ7
DQoJbWFyZ2luLWxlZnQ6ODAuMXB0Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7DQoJbGluZS1oZWln
aHQ6MTIuMHB0Ow0KCW1zby1saW5lLWhlaWdodC1ydWxlOmV4YWN0bHk7DQoJcGFnZS1icmVhay1h
ZnRlcjphdm9pZDsNCgltc28tbGlzdDpsMSBsZXZlbDMgbGZvMjsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJZm9udC13ZWlnaHQ6bm9ybWFsO30NCmg0
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQgQ2hh
ciI7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t
OjEyLjBwdDsNCgltYXJnaW4tbGVmdDoyMS42cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDsNCgls
aW5lLWhlaWdodDoxMi4wcHQ7DQoJbXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseTsNCglwYWdl
LWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1saXN0OmwxIGxldmVsNCBsZm8yOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpub3Jt
YWw7fQ0KaDUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRp
bmcgNSBDaGFyIjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp
bi1ib3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEu
NnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5
Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw1IGxmbzI7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2Vp
Z2h0Om5vcm1hbDt9DQpoNg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu
azoiSGVhZGluZyA2IENoYXIiOw0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbWFyZ2luLWJvdHRvbToxMi4wcHQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRleHQtaW5k
ZW50Oi0yMS42cHQ7DQoJbGluZS1oZWlnaHQ6MTIuMHB0Ow0KCW1zby1saW5lLWhlaWdodC1ydWxl
OmV4YWN0bHk7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCgltc28tbGlzdDpsMSBsZXZlbDYg
bGZvMjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ
Zm9udC13ZWlnaHQ6bm9ybWFsO30NCnAuTXNvSGVhZGluZzcsIGxpLk1zb0hlYWRpbmc3LCBkaXYu
TXNvSGVhZGluZzcNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Ikhl
YWRpbmcgNyBDaGFyIjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h
cmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDot
MjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFj
dGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw3IGxmbzI7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv
SGVhZGluZzgsIGxpLk1zb0hlYWRpbmc4LCBkaXYuTXNvSGVhZGluZzgNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgOCBDaGFyIjsNCgltYXJnaW4tdG9w
OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdp
bi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBw
dDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZv
aWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw4IGxmbzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvSGVhZGluZzksIGxpLk1zb0hlYWRpbmc5LCBk
aXYuTXNvSGVhZGluZzkNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6
IkhlYWRpbmcgOSBDaGFyIjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K
CW1hcmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVu
dDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpl
eGFjdGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw5IGxm
bzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCmE6
bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv
SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl
dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z
LXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N
c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSGVh
ZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxl
LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVh
ZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJI
ZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IZWFkaW5nM0No
YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp
dHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToiQ291cmll
ciBOZXciO30NCnNwYW4uSGVhZGluZzRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQg
Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcg
NCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmc1Q2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiSGVhZGluZyA1IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0K
CW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDUiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0Kc3Bhbi5IZWFkaW5nNkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNiBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA2IjsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSGVhZGluZzdDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiJIZWFkaW5nIDcgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0
eWxlLWxpbms6IkhlYWRpbmcgNyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu
LkhlYWRpbmc4Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA4IENoYXIiOw0KCW1zby1z
dHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDgiOw0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IZWFkaW5nOUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IkhlYWRpbmcgOSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu
azoiSGVhZGluZyA5IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFsbG9v
blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg
NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoy
NjU2MjE2Nzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz
Oi0xODYyNDg5ODM4IC0xNDAyNDM2NzgwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4
NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVs
MQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjczMDczNzk4NDsN
Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0Nzk2MDcyMTY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ
e21zby1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9u
ZTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiAiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMS42cHQ7DQoJ
dGV4dC1pbmRlbnQ6LTIxLjZwdDsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJbXNvLXRleHQtYW5pbWF0
aW9uOm5vbmU7DQoJbXNvLWhpZGU6bm9uZTsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXBvc2l0
aW9uOnJlbGF0aXZlOw0KCXRvcDowcHQ7DQoJbXNvLXRleHQtcmFpc2U6MHB0Ow0KCWxldHRlci1z
cGFjaW5nOjBwdDsNCgltc28tZm9udC1rZXJuaW5nOjBwdDsNCgl0ZXh0LWVmZmVjdDpub25lOw0K
CXRleHQtc2hhZG93Om5vbmU7DQoJdGV4dC1lZmZlY3Q6bm9uZTsNCgl0ZXh0LWVmZmVjdDpub25l
Ow0KCWZvbnQtZW1waGFzaXplOm5vbmU7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6bm9ybWFsOw0K
CW1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbDsNCgltc28tYW5zaS1mb250LXN0eWxlOm5vcm1h
bDsNCgltc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbDsNCgltc28tbm8tcHJvb2Y6bm87DQoJdGV4
dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRlY29yYXRp
b246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3VnaDpub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2Vs
aW5lO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAy
IjsNCgltc28tbGV2ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuICI7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0O30NCkBsaXN0
IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCgltc28tbGV2
ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiAiOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt
YXJnaW4tbGVmdDoxNzkuMXB0Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7DQoJZm9udC12YXJpYW50
Om5vcm1hbCAhaW1wb3J0YW50Ow0KCW1zby10ZXh0LWFuaW1hdGlvbjpub25lOw0KCW1zby1oaWRl
Om5vbmU7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCglwb3NpdGlvbjpyZWxhdGl2ZTsNCgl0b3A6
MHB0Ow0KCW1zby10ZXh0LXJhaXNlOjBwdDsNCglsZXR0ZXItc3BhY2luZzowcHQ7DQoJbXNvLWZv
bnQta2VybmluZzowcHQ7DQoJdGV4dC1lZmZlY3Q6bm9uZTsNCgl0ZXh0LXNoYWRvdzpub25lOw0K
CXRleHQtZWZmZWN0Om5vbmU7DQoJdGV4dC1lZmZlY3Q6bm9uZTsNCglmb250LWVtcGhhc2l6ZTpu
b25lOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0Om5vcm1hbDsNCgltc28tYW5zaS1mb250LXN0eWxl
Om5vcm1hbDsNCgltc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbDsNCgltc28tbm8tcHJvb2Y6bm87
DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRl
Y29yYXRpb246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3VnaDpub25lOw0KCXZlcnRpY2FsLWFsaWdu
OmJhc2VsaW5lO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVh
ZGluZyA0IjsNCgltc28tbGV2ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4l
MlwuJTNcLiU0XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRleHQtaW5kZW50Oi0y
MS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5n
IDUiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4l
M1wuJTRcLiU1XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRleHQtaW5kZW50Oi0y
MS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5n
IDYiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4l
M1wuJTRcLiU1XC4lNlwuICI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVu
dDotMjEuNnB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVh
ZGluZyA3IjsNCgltc28tbGV2ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4l
MlwuJTNcLiU0XC4lNVwuJTZcLiU3XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRl
eHQtaW5kZW50Oi0yMS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1zdHlsZS1s
aW5rOiJIZWFkaW5nIDgiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4
dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MjEuNnB0Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s
ZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDkiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCglt
c28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4XC4lOVwuICI7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0O30NCkBsaXN0IGwy
DQoJe21zby1saXN0LWlkOjkyNzczMjAyMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6NjQ0NDg4NTI0IDE0MjIyOTcwNTYgNjc2OTg2OTEgNjc2OTg2OTMg
Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K
QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6QmF0YW5nO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIu
MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu
MHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA
bGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6
bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNg0K
CXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxl
dmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC10YWIt
c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0
LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4
LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj
bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLA0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgU29t
ZSBmdXJ0aGVyIHRob3VnaHRzIG9uIHNvbWUgb2YgdGhlIGlzc3Vlcy4NCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwO0JUVywgaWYgYW55b25lIGlz
IGludGVyZXN0ZWQgdG8gc2VlIHRoZSBzdGF0dXMgcXVvIG9mIFZORSByZXNlYXJjaCwgdGhlIGZv
bGxvd2luZyBtaWdodCBiZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQ6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1
LmRlL2ZpbGVhZG1pbi9maWxlcy9sZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2No
ZXIyMDEzYS5wZGYiPmh0dHA6Ly93d3cuZmltLnVuaS1wYXNzYXUuZGUvZmlsZWFkbWluL2ZpbGVz
L2xlaHJzdHVobC9tZWVyL3B1YmxpY2F0aW9ucy9wZGYvRmlzY2hlcjIwMTNhLnBkZjwvYT48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkhhcHB5IG5ldyB5ZWFyLA0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5YaWFuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p
bHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy
aWY7ICI+IHNkbiBbPGEgaHJlZj0ibWFpbHRvOnNkbi1ib3VuY2VzQGlydGYub3JnIj5tYWlsdG86
c2RuLWJvdW5jZXNAaXJ0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EaWVnbyBDYXZp
Z2xpYTxicj4NCjxiPlNlbnQ6PC9iPiAyMDEzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAi
PjEyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9
kyI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm
b250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjIzPC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5pelPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5z
LXNlcmlmOyAiPg0KIDE2OjAyPGJyPg0KPGI+VG86PC9iPiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNj
YXJlbGxpOyA8YSBocmVmPSJtYWlsdG86YWN0bkBpZXRmLm9yZyI+YWN0bkBpZXRmLm9yZzwvYT48
YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZG5AaXJ0Zi5vcmciPnNkbkBpcnRmLm9y
ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTZG5dIFtBY3RuXSB2aXJ0dWFsIG5ldHdv
cmsgbWFwcGluZy9lbWJlZGRpbmcgKFZOTS9WTkUpIHByb2JsZW08bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgYWxsIHNvbWUgbW9yZSB0
aG91Z2h0IHdpdGggc29tZSBjbGVhbmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CUiBhbmQgU2Vhc29uIGdyZWV0aW5ncyE8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG
NDk3RCI+RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNC4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxoMiBzdHlsZT0ibXNvLWxpc3Q6
bm9uZSI+PGEgbmFtZT0iX1RvYzM3NDcwOTEwMyI+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2gyPg0KPGgyIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7
dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+PCEtLVtpZiAhc3Vw
cG9ydExpc3RzXS0tPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu
b3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4g
bGFuZz0iRU4tVVMiPlJlcXVlc3QgUHJvY2Vzc2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBjb25jZXJuZWQg
YWJvdXQgd2hldGhlciBhIHNldCBvZiBjbGllbnQgcmVxdWVzdHMgZm9yIFZOIGNyZWF0aW9uIGNh
biBiZSBkZWFsdCB3aXRoIHNpbXVsdGFuZW91c2x5IG9yIG5vdC4gVGhpcyBkZXBlbmRzIG9uIHRo
ZSBuYXR1cmUgb2YgYXBwbGljYXRpb25zIHRoZSBjbGllbnQgc3VwcG9ydC4gSWYgdGhlIGNsaWVu
dCBkb2VzIG5vdCByZXF1aXJlIHJlYWwtdGltZQ0KIGluc3RhbnRpYXRpb24gb2YgVk4gY3JlYXRp
b24sIHRoZSBjb21wdXRhdGlvbiBlbmdpbmUgY2FuIHByb2Nlc3MgYSBzZXQgb2YgVk4gY3JlYXRp
b24gcmVxdWVzdHMgc2ltdWx0YW5lb3VzbHkgdG8gaW1wcm92ZSBuZXR3b3JrIGVmZmljaWVuY3ku
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltbRENdXSBJIHRoaW5rIGhlcmUg
d2UgY2FuIGFzc3VtZSB0aGF0IFZOIGNyZWF0aW9uIHJlcXVlc3RzIGFyZSBub24gcmVhbCB0aW1l
LiBJbnN0YW50aWF0aW9uIG9mIHNlcnZpY2VzIGFuZCBiYW5kd2lkdGggbWlnaHQgYmUgcmVhbCB0
aW1lIChhbmQgaGVuY2UgY29uY3VycmVuY3kgbmVlZHMgdG8gYmUgbWFuYWdlZCkgYnV0IEkgd291
bGQNCiBzYXkgdGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgVk4gY3JlYXRpb24uPC9zcGFuPjwvaT48
L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WU9VTkcm
Z3Q7Jmd0OyBHb29kIHBvaW50LiAmbmJzcDtJIHdhcyBsb29zZSBvbiB0aGUgdGVybSDigJhWTiBj
cmVhdGlvbuKAnS4mbmJzcDsgVGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3Rz
IG9mIFZOIGNyZWF0aW9uIHdoaWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0
aGUgY2xpZW50IGVuZHBvaW50cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQNCiB3aXRoIG5ldHdvcmsg
cHJvdmlkZXIocykgYmVmb3JlIHNlcnZpY2UgY3JlYXRpb24uIFllcywgaW4gdGhhdCBzZW5zZSwg
SSBhZ3JlZSB3aXRoIHlvdS4gSGVyZSB3aGF0IEkgbWVhbnQgdG8gc2F5IHdhcyB3aGVuIHRoZXJl
IGFyZSBtdWx0aXBsZSBzZXJ2aWNlIHJlcXVlc3RzICZuYnNwO3RvIHNldHVwIHZpcnR1YWwgY29u
bmVjdGlvbnMgdGhhdCBuZWVkIG5vdCBiZSBpbnN0YW50aWF0ZWQgcmVhbC10aW1lLCAoaW4gb3Ro
ZXIgd29yZHMsIGlmIHNvbWUgcmVxdWVzdA0KIGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2No
ZWR1bGluZyksIHRoZW4gYSBiYXRjaCBwcm9jZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdv
dWxkIGJlIG1vcmUgb3B0aW1hbCBpbiBnZW5lcmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kg
cGVyc3BlY3RpdmUgdGhhbiBzZXF1ZW50aWFsIHByb2Nlc3NpbmcuDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPltEQ10geWVzIGFuZCB0aGlzIGlzIG9uZSBvZiB0aGUgYmlnZ2Vz
dCBhZHZhbnRhZ2Ugb2YgYSBjZW50cmFsaXplZCBhcHByb2FjaCB2ZXJzdXMgYSBkaXN0cmlidXRl
ZCBvbmUsIHRoYXQgaXMgdGhlIHBvc3NpYmlsaXR5IHRvIGNvbXB1dGUgdGhlIG9wdGltYWwgc29s
dXRpb24gb2YgYSBidW5jaCBvZiByZXF1ZXN0czwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi
bHVlIj5bWGlhbl0gSSB0aGluayB3ZSBoYXZlIGEgcHJldHR5IHVuZGVyc3RhbmRpbmcgb2YgdGhl
IGlzc3VlIGFuZCBhcyBJIHVuZGVyc3RhbmQsIHRoZSBwb2ludHMgcmVsYXRlZCB0byBBQ1ROIHdv
dWxkIGluY2x1ZGUgYXQgbGVhc3QgKDEpIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgcGFz
c2VkIGZyb20gY2xpZW50DQogdG8gdmlydHVhbCBuZXR3b3JrIHByb3ZpZGVyPzsgKDIpIHdoYXQg
Y29uc3RyYWludHMmbmJzcDsgdGhlIGNsaWVudCBjYW4gYWNjZXB0ICh0aW1lIG1pZ2h0IGJlIGEg
Y29uc3RyYWludHMpLiZuYnNwOyBJZiB0aGVyZSBpcyBtb3JlLCBwbGVhc2UgYW1lbmQuDQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxo
MiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6
bDIgbGV2ZWwxIGxmbzQiPjxhIG5hbWU9Il9Ub2MzNzQ3MDkxMDQiPjwhLS1baWYgIXN1cHBvcnRM
aXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+
LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i
c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGxhbmc9
IkVOLVVTIj5UeXBlcyBvZiBOZXR3b3JrIFJlc291cmNlczwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+V2hlbiBjbGllbnQgbWFrZXMgYSBWTiBjcmVhdGlvbiByZXF1ZXN0IHRv
IHRoZSBzdWJzdHJhdGUgbmV0d29yaywgd2hhdCBraW5kIG9mIG5ldHdvcmsgcmVzb3VyY2VzIGlz
IGNvbnN1bWVkIGlzIG9mIGNvbmNlcm4gb2YgYm90aCB0aGUgY2xpZW50IGFuZCBuZXR3b3JrIHBy
b3ZpZGVycy4gSXQgZGVwZW5kcyBvbiB0aGUgYXBwbGljYXRpb24uIEZvciB0cmFuc3BvcnQgbmV0
d29yaw0KIHZpcnR1YWxpemF0aW9uLCB0aGUgbmV0d29yayByZXNvdXJjZSBjb25zdW1lZCBieSB0
aGUgY2xpZW50IGlzIHByaW1hcmlseSBuZXR3b3JrIGJhbmR3aWR0aCB0aGF0IHRoZSBwYXRocyB3
b3VsZCBvY2N1cHkgb24gdGhlIHBoeXNpY2FsIGxpbmsuIEhvd2V2ZXIsIHRoZXJlIG1heSBiZSBv
dGhlciByZXNvdXJjZSB0eXBlcyBzdWNoIGFzIENQVSBhbmQgbWVtb3J5IHRoYXQgbmVlZCB0byBi
ZSBjb25zaWRlcmVkIGZvciBjZXJ0YWluIGFwcGxpY2F0aW9ucy4NCiBUaGVzZSByZXNvdXJjZSB0
eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGllbnTigJlzIFZOIHJlcXVlc3QuIDxhIG5hbWU9Il9U
b2MzNzQ3MDkxMDUiPg0KPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1tE
Q11dIEhlcmUgdGhlIGlzc3VlIGlzIHRob3JueS4gVGhlIHBvaW50IGlzOiBhIGdpdmVuIHJlc291
cmNlIGlzIGRlZGljYXRlZCB0byBhIGdpdmVuIFZOIG9yIHNoYXJlZCBhbW9uZyBkaWZmZXJlbnQg
b25lcz8gV2Ugc2hvdWxkIHN0YXJ0IGNvbnNpZGVyaW5nIG5ldHdvcmsgcmVzb3VyY2VzIHBhcnRp
dGlvbmluZyBpc3N1ZXPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZT1VORyZndDsmZ3Q7Jm5ic3A7IEEgZ2l2
ZW4gcmVzb3VyY2UgaXMg4oCcdmlydHVhbGx54oCdIGRlZGljYXRlZCB0byBhIHBhcnRpY3VsYXIg
Y2xpZW50OyB5ZXQgdGhpcyBkb2VzIG5vdCBtZWFuIGEgcGFydGljdWxhciBjbGllbnQgb2NjdXBp
ZXMgYSBwYXJ0aWN1bGFyIHBvcnQgKHNheSBPRFUgcG9ydCAxIHZzIDIpLiZuYnNwOyBBcyBsb25n
IGFzIHJlc291cmNlIGlzIGd1YXJhbnRlZWQNCiBmb3IgdXNlIHRvIHRoZSBjbGllbnQsIGl0IGlz
IGZpbmUgZm9yIHRoZSBXb3JraW5nIFBhdGggYXQgbGVhc3Q7IGhvd2V2ZXIgZm9yIDE6TiBraW5k
IG9mIHByb3RlY3Rpb24gY2FzZSwgdGhlcmUgaXMgYSBsZXZlbCBvZiBzaGFyaW5nIGJhY2t1cCBw
YXRoIHJlc291cmNlIGZvciBtdWx0aXBsZSBjbGllbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj5bRENdIHdlbGwgYXQgbGVhc3QgdHJpYnV0YXJ5IHBvcnQgY2Fu4oCZdCBi
ZSB2aXJ0dWFsIEkgbmVlZCB0byBuYWlsIGl0IHRvIGEgcGh5c2ljYWwgbnVtYmVyaW5nIHRvIHBo
eXNpY2FsbHkgY29ubmVjdCB0aGUgSFcsIGZvciB0aGUgcmVzdCBJIGFncmVlLiZuYnNwOw0KPG86
cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymx1ZSI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsdWUiPltYaWFuXSBJIHRoaW5rIFlv
dW5nIG1lYW50IHRoZSBwaHlzaWNhbCByZXNvdXJjZSBjYW4gYmUgc2hhcmVkIGJ5IG11bHRpcGxl
IGNsaWVudHMsIHByb2JhYmx5IGJ5IGFzc2lnbmluZyB0aGUgc2FtZSBwaHlzaWNhbCBudW1iZXJp
bmcgdG8gdGhlIGRpZmZlcmVudCBjbGllbnRzLiBUaGUgcG9pbnQgdGhhdCB3b3J0aA0KIG5vdGlu
ZyBpcyB0aGF0IHdoZXRoZXIgdGhpcyBraW5kIG9mIHNoYXJpbmcgY2FuIG1ha2Ugc3VyZSBubyBj
b25mbGljdCB3b3VsZCBhcmlzZSBvciBpZiBzbywgd2hldGhlciBpdCBpcyBhY2NlcHRhYmxlLg0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwh
LS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1z
by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlm
XS0tPjxzcGFuIGxhbmc9IkVOLVVTIj5BY2N1cmFjeSBvZiBOZXR3b3JrIFJlc291cmNlIFJlcHJl
c2VudGF0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBuZXR3b3JrIGlu
IGl0c2VsZiBtYXkgY29uc2lzdHMgb2YgbGF5ZXJlZCBzdHJ1Y3R1cmUsIGl0IGlzIGEgY2hhbGxl
bmdlIGhvdyB0byByZXByZXNlbnQgdGhlc2UgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIHJl
c291cmNlcyBhbmQgdG9wb2xvZ3kgaW50byBhIGZvcm0gdGhhdCBjYW4gYmUgcmVsaWFibHkgdXNl
ZCBieSB0aGUNCiBjb21wdXRhdGlvbiBlbmdpbmUgdGhhdCBhc3NpZ25zIHRoZSBjbGllbnQgcmVx
dWVzdHMgaW50byB0aGUgcGh5c2ljYWwgbmV0d29yayByZXNvdXJjZSBhbmQgdG9wb2xvZ3kuDQo8
YSBuYW1lPSJfVG9jMzc0NzA5MTA2Ij48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj5bW0RDXV0gRGFtbmx5IHRydWU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
IzFGNDk3RCI+W0RDXSBJIHZvdGUgZm9yIGEgS0lTUyBhcHByb2FjaA0KPC9zcGFuPjwvaT48L2I+
PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s
b3I6IzFGNDk3RCI+SjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y
OmJsdWUiPltYaWFuXUNhbm5vdCBhZ3JlZSB3aXRoIERpZWdvIG1vcmUsIDpELg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwhLS1baWYgIXN1
cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln
bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFu
IGxhbmc9IkVOLVVTIj5SZXNvdXJjZSBFZmZpY2llbmN5PG86cD48L286cD48L3NwYW4+PC9oMj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWxhdGVkIHRvIHRoZSBh
Y2N1cmFjeSBvZiBuZXR3b3JrIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIGlzIHJlc291cmNlIGVm
ZmljaWVuY3kuIEFzIGEgc2V0IG9mIGluZGVwZW5kZW50IGNsaWVudCBWTiBpcyBjcmVhdGVkIGFu
ZCBtYXBwZWQgb250byBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNlcywgdGhlIG92ZXJhbGwgbmV0
d29yayByZXNvdXJjZSB1dGlsaXphdGlvbiBpcyBvZg0KIHRoZSBwcmltYXJ5IGNvbmNlcm4gb2Yg
dGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPltbRENdXSBUaGlzIGlzc3VlIGlzIHByZXR0eSBtdWNoIGxpbmtlZCB0byB0aGUgb25l
IGFib3ZlICh0eXBlcyBvZiBuZXR3b3JrIHJlc291cmNlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+
PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZT1VORyZn
dDsmZ3Q7IFllcy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsdWUiPltY
aWFuXSBUaGlzIHByb2JhYmx5IGlzIG1vcmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFk
IG9mIEFDVE4sIGJ1dCBmb3Igc3VyZSBhbiBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFs
bCBzb2x1dGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MGNtO3RleHQtaW5kZW50OjBjbTttc28tbGlzdDpub25lIj48YSBuYW1lPSJfVG9jMzc0NzA5
MTA3Ij48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaDI+
DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s
aXN0OmwyIGxldmVsMSBsZm80Ij48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0i
RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3
LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv
c3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBsYW5nPSJFTi1VUyI+R3VhcmFudGVlIG9m
IENsaWVudCBJc29sYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoaWxlIG5ldHdvcmsgcmVzb3VyY2Ugc2hhcmluZyBh
Y3Jvc3MgYSBzZXQgb2YgY2xpZW50cyBmb3IgZWZmaWNpZW50IHV0aWxpemF0aW9uIGlzIGltcG9y
dGFudCBhc3BlY3Qgb2YgbmV0d29yayB2aXJ0dWFsaXphdGlvbiwgY2xpZW50IGlzb2xhdGlvbiBo
YXMgdG8gYmUgZ3VhcmFudGVlZC4gQWRtaXNzaW9ucyBvZiBuZXcgY2xpZW50IHJlcXVlc3RzIG9y
IGFueSBjaGFuZ2VzIG9mDQogb3RoZXIgZXhpc3RpbmcgY2xpZW50c+KAmSBWTnMgbXVzdCBub3Qg
YWZmZWN0IGFueSBwYXJ0aWN1bGFyIGNsaWVudCBpbiB0ZXJtcyBvZiByZXNvdXJjZSBndWFyYW50
ZWUsIHNlY3VyaXR5IGNvbnN0cmFpbnRzLCBhbmQgb3RoZXIgcGVyZm9ybWFuY2UgY29uc3RyYWlu
dHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltbRENdXSBBZ2Fp
biBsaW5rZWQgdG8gaXNzdWVzIGFib3ZlLiBJZiBuZXR3b3JrIHJlc291cmNlcyBhcmUgZGVkaWNh
dGVkIHRvIGVhY2ggVk4sIHRoaXMgaXMgdHJ1ZSwgYnV0IGlmIHRoZXkgKG9yIHBhcnQgb2YgdGhl
bSkgYXJlIHNoYXJlZCwgdGhlIGluc3RhbnRpYXRpb24gb2YgYSBzZXJ2aWNlIGZyb20gYSBnaXZl
biBjbGllbnQNCiB3b3VsZCBpbXBhY3QgdGhlIFZOIHNlZW4gYnkgb3RoZXJzLiBPbiB0aGUgb3Ro
ZXIgc2lkZSwgYXNwZWN0cyBsaWtlIHNlY3VyaXR5IG8gcGVyZm9ybWFuY2VzIHNob3VsZCBub3Qg
YmUgaW1wYWN0ZWQgaW4gYW55IG9mIHRoZSB0d28gY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9p
PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WU9VTkcm
Z3Q7Jmd0OyBBZ3JlZS4mbmJzcDsgU28gSSBndWVzcyB3ZSBuZWVkIHRvIGJlIGNsZWFyIG9uIHJl
c291cmNlIHBhcnRpdGlvbmluZyBhbmQgc2hhcmluZyBpc3N1ZSBjbGVhcmx5IC0tLSBJIHRoaW5r
IHNvbWUgYXBwbGljYXRpb24vY2xpZW50IHJlcXVpcmVzIGEgaGFyZCBkZWRpY2F0ZWQgcmVzb3Vy
Y2Ugd2hpbGUgZm9yIHNvbWUgb3RoZXJzIGl0IGlzDQogZmx1aWQuJm5ic3A7IDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0RDXSB5ZXMgYW5kIHRoaXMgd2lsbCBnaXZlIHRvIHRo
ZSBjYXJyaWVycyB0aGUgcG9zc2liaWxpdHkgdG8gZGlmZmVyZW50aWF0ZSB0aGVpciBzZXJ2aWNl
IG9mZmVyaW5nLCBkbyB5b3Ugd2FudCBndWFyYW50ZWVkIGJhbmR3aWR0aCBpbiBjYXNlIG9mIG11
bHRpcGxlIGZhaWx1cmVzPyBUaGVuIHlvdSBoYXZlIHRvIHBheSBtb3JlLjwvc3Bhbj48L2k+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPGgyIHN0eWxlPSJtYXJnaW4tbGVmdDowY207dGV4dC1pbmRlbnQ6MGNtO21zby1s
aXN0Om5vbmUiPjxhIG5hbWU9Il9Ub2MzNzQ3MDkxMDgiPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9oMj4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu
MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwhLS1baWYg
IXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0
Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxz
cGFuIGxhbmc9IkVOLVVTIj5Db21wdXRpbmcgVGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVwZW5kaW5nIG9uIHRoZSBu
YXR1cmUgb2YgYXBwbGljYXRpb25zLCBob3cgcXVpY2tseSBhIFZOIGlzIGluc3RhbnRpYXRlZCBm
cm9tIHRoZSB0aW1lIG9mIHJlcXVlc3QgaXMgYW4gaW1wb3J0YW50IGZhY3Rvci4gRm9yIGR5bmFt
aWMgYXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSBpbnN0YW50YW5lb3VzIFZOIGNyZWF0aW9uLCB0
aGUgY29tcHV0YXRpb24gbW9kZWwvYWxnb3JpdGhtDQogc2hvdWxkIHN1cHBvcnQgdGhpcyBjb25z
dHJhaW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltbRENdXSBJIHdvdWxk
IHNheSB0aGF0IHRpbWluZyBjb25zdHJhaW50cyBuZWVkIHRvIGJlIG1ldCBmb3Igc2VydmljZSBw
cm92aXNpb25pbmcgKGkuZS4gdXBvbiBjbGllbnQgcmVxdWVzdHMgb24gYSBnaXZlbiBWTikgYnV0
IEkgdGhpbmsgVk4gaW5zdGFudGlhdGlvbiBjb3VsZCBiZSBhbHNvIGEgbm9uIHJlYWwgdGltZSBw
cm9jZWR1cmUuDQogSSBtaWdodCBiZSB3cm9uZ+KApmFyZSB0aGVyZSB1c2UgY2FzZXMgZm9yIHJl
YWwgdGltZSBhbmQgdGltaW5nIGNvbnN0cmFpbmVkIFZOIGNyZWF0aW9uIHJlcXVyZXN0cz88L3Nw
YW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO3RleHQtaW5kZW50
OjBjbTttc28tbGlzdDpub25lIj48YSBuYW1lPSJfVG9jMzc0NzA5MTA5Ij48L2E+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2gyPg0KPGgyIHN0eWxlPSJtYXJnaW4tbGVmdDowY207dGV4dC1pbmRlbnQ6MGNtO21zby1saXN0
Om5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjog
cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+WU9V
TkcmZ3Q7Jmd0OyAmbmJzcDtBZ2FpbiBoZXJlIHdoYXQgSSBtZWFudCB3YXMgc2VydmljZSByZXF1
ZXN0LiBJIG5lZWQgdG8gYmUgY2xlYXIgb24gdGhlIHRlcm1pbm9sb2d5LiZuYnNwOyBJZg0KIHdl
IHdlcmUgdG8gZGVmaW5lIFZOIGNyZWF0aW9uIGFzIHRoZSBwcm9jZXNzIG9mIG5lZ290aWF0aW9u
IChzaW1pbGFyIHRvIFNMQSBuZWdvdGlhdGlvbiksIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIGlz
IGFsd2F5cyBvZmYtbGluZSAoc3RhdGljIGFuZCBub24tcmVhbCB0aW1lKS4gT25jZSB0aGUgaW5p
dGlhbCBWTiBjcmVhdGlvbiBuZWdvdGlhdGlvbiBpcyBkb25lLCB0aGVuIHRoZXJlIG1pZ2h0IGJl
IGNhc2VzIHdoZXJlIFZOIGNhbiBiZSByZS1uZWdvdGlhdGVkDQogb24gdGhlIGZseSAoZS5nLiwg
Y2hhbmdpbmcgc29tZSBiL3cgb3Igc2VydmljZSBvYmplY3RpdmVzLCBvciBzb21lIHBoeXNpY2Fs
IGZhaWx1cmVzIHN1Y2ggYXMgZmliZXIgY3V0KS4gQnV0IHRoaXMgaXMgbm90IFZOIGNyZWF0aW9u
OyB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIHRoaXMgZnJvbSBWTiByZS1uZWdvdGlhdGlvbi4NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0
LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48IS0tW2lmICFzdXBwb3J0
TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi
Pi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu
YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBsYW5n
PSJFTi1VUyI+QWRtaXNzaW9uIENvbnRyb2w8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvIGNvb3JkaW5hdGUgdGhlIHJlcXVl
c3QgcHJvY2VzcyBvZiBtdWx0aXBsZSBjbGllbnRzLCBhbiBhZG1pc3Npb24gY29udHJvbCB3aWxs
IGhlbHAgbWF4aW1pemUgYW4gb3ZlcmFsbCBlZmZpY2llbmN5Lg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj5bW0RDXV0gWWVzLiBUbyB1bmRlcnN0YW5kIHdoZXJlIGlzIHRoZSBi
ZXN0IHBsYWNlIHRvIGRvIHRoYXQuIENsaW5lIGNvbnRyb2w/IFZOQz88bzpwPjwvbzpwPjwvc3Bh
bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Z
T1VORyZndDsmZ3Q7IEFzIHRoZXJlIGFyZSBtYW55IGNsaWVudHMgdGhhdCB0aGUgVk5DIG5lZWRz
IHRvIHN1cHBvcnQsIEkgYXNzdW1lIFZOQyBoYXMgdG8gaGF2ZSBhZG1pc3Npb24gY29udHJvbCBt
b2R1bGUgYXQgdGhlIGxlYXN0LiBDbGllbnQgQ29udHJvbGxlciwgaG93ZXZlciwgbWF5IGhhdmUg
aXRzIG93biBhZG1pc3Npb24gY29udHJvbCBmb3INCiBzdXBwb3J0aW5nIG11bHRpcGxlIGFwcGxp
Y2F0aW9ucy4gV2UgbmVlZCB0byByZWNvZ25pemUgYSByZWN1cnNpdmUgY2xpZW50LXNlcnZlciBy
ZWxhdGlvbnNoaXAuIEFzIGxvbmcgYXMgY29udHJvbGxlciBpcyBhIHNlcnZlciBjb250cm9sbGVy
IG9mIGFueSBzb3J0LCB0aGVuIGFkbWlzc2lvbiBjb250cm9sIGZ1bmN0aW9uIHdvdWxkIGhlbHAg
dG8gY29vcmRpbmF0ZSBpdHMgY2xpZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0
O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48YSBuYW1lPSJfVG9jMzc0NzA5MTEwIj48IS0tW2lm
ICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlz
dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48
c3BhbiBsYW5nPSJFTi1VUyI+UGF0aCBDb25zdHJhaW50czwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+VGhlcmUgbWF5IGJlIHNvbWUgZmFjdG9ycyBvZiBwYXRoIGNvbnN0cmFp
bnRzIHRoYXQgY2FuIGFmZmVjdCB0aGUgb3ZlcmFsbCBlZmZpY2llbmN5LiBQYXRoIFNwbGl0IGNh
biBsb3dlciBWTiByZXF1ZXN0IGJsb2NraW5nIGlmIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgY2Fu
IHN1cHBvcnQgc3VjaCBjYXBhYmlsaXR5LiBQYWNrZXQtYmFzZWQgVEUgbmV0d29yayBjYW4gc3Vw
cG9ydA0KIHBhdGggc3BsaXQgd2hpbGUgY2lyY3VpdC1iYXNlZCB0cmFuc3BvcnQgbWF5IGhhdmUg
YSBsaW1pdGF0aW9uLiAmbmJzcDtQYXRoIG1pZ3JhdGlvbiBpcyBhIHRlY2huaXF1ZSB0aGF0IGFs
bG93cyBjaGFuZ2VzIG9mIG5vZGVzIG9yIGxpbmtzIGFzc2lnbm1lbnQgb2YgdGhlIGVzdGFibGlz
aGVkIHBhdGhzIGluIGFuIGVmZm9ydCB0byBhY2NvbW1vZGF0ZSBuZXcgcmVxdWVzdHMgd2hpY2gg
d291bGQgbm90IGJlIGFjY2VwdGVkIHdpdGhvdXQgcGF0aCBtaWdyYXRpb24uDQogVGhpcyBjYW4g
aW1wcm92ZSBvdmVyYWxsIGVmZmljaWVuY3ksIHlldCBhZGRpdGlvbmFsIGNhcmUgbmVlZHMgdG8g
YmUgYXBwbGllZCB0byBhdm9pZCBhbnkgYWR2ZXJzZSBpbXBhY3RzIGFzc29jaWF0ZWQgd2l0aCBj
aGFuZ2luZyB0aGUgZXhpc3RpbmcgcGF0aHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmUtb3B0aW1pemF0aW9uIGlzIGEg
Z2xvYmFsIHByb2Nlc3MgdG8gcmUtc2h1ZmZsZSBhbGwgZXhpc3RpbmcgcGF0aCBhc3NpZ25tZW50
IHRvIG1pbmltaXplIG5ldHdvcmsgcmVzb3VyY2UgZnJhZ21lbnRhdGlvbi4gQWdhaW4sIGFuIGV4
dHJhIGNhcmUgbmVlZHMgdG8gYmUgYXBwbGllZCBmb3IgcmUtb3B0aW1pemF0aW9uLg0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bW0RDXV0gVHJ1ZS4gV2l0aCBwYXRoIGNvbnN0
cmFpbnRzIEkgdGhpbmsgd2Ugc2hvdWxkIGluY2x1ZGUgc29tZXRoaW5nIG1vcmUuIFdoZW4gYSBj
bGllbnQgbmVlZHMgdG8gc2V0dXAgYSBzZXJ2aWNlL0xTUCB0aGVyZSBtaWdodCBiZSBURSBjb25z
dHJhaW50cyBhc3NvY2lhdGVkIHRvIHRoZSByZXF1ZXN0LiBXaGFuIHRoZSBWTg0KIG5lZWRzIHRv
IGluY2x1ZGUgaXMgbm90IG9ubHkgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIGJ1dCBpbiBtYW55
IGNhc2VzIGlzIHNob3VsZCBiZSBURS1yZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uIEluIHRoaXMg
Y2FzZSB3ZSBjb3VsZCBsZXZlcmFnZSBvbiB0aGUgb3ZlcmxheSB3b3JrIGJlaW5nIGRvbmUgZS5n
LiBpbiBDQ0FNUCBhbmQgaW4gKDwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBo
cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWwtaW50ZXJjb25uZWN0
ZWQtdGUtaW5mby1leGNoYW5nZS0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
ZmFycmVsLWludGVyY29ubmVjdGVkLXRlLWluZm8tZXhjaGFuZ2UtMDI8L2E+KS48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPllPVU5HJmd0OyZndDsgWWVzLCBpZiB3ZSBpbmNsdWRlIG5vbi1URSB1bmRlcmx5
aW5nIHRyYW5zcG9ydCBhcyBwYXJ0IG9mIHRoZSBBQ1ROIHNjb3BlLCB0aGVuICZuYnNwO3RoZSBU
RS1yZWFjaGVhYmlsaXR5IG5lZWRzIHRvIGJlIGtub3duL2FkdmVydGlzZWQgYnkgdGhlIHNlcnZl
ciBuZXR3b3JrIHRvIGNsaWVudHMgYXMg4oCYY2FwYWJpbGl0eeKAmSBhdHRyaWJ1dGUuDQogJm5i
c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Y29sb3I6Ymx1ZSI+W1hpYW5dIEhhdmUgd2UgYWxyZWFkeSBjb25maW5lZCB0aGUgc2NvcGUg
dG8gVEUgdHJhbnNwb3J0IG5ldHdvcmsgb25seT8mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Y29sb3I6Ymx1ZSI+SSB0aGluayB3aGV0aGVyIHRoZSBURSBpbmZvcm1hdGlvbiBpcyBjb252
ZXllZCB0byB0aGUgY2xpZW50IGRlcGVuZHMgb24gdGhlIGRldGFpbHMgdGhlIGNsaWVudCB3YW50
cyB0byBrbm93LiBGcm9tIEFDVE4gd29yayBwb2ludCBvZiB2aWV3LCBpdCBzaG91bGQgYmUgY29u
c2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSBjb25zdHJhaW50cw0KIHdvcnRoIGNvbnNpZGVyaW5nLiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CEE853F7430D5mattabuedu_--