From nobody Thu Nov 3 02:13:39 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C300129766; Thu, 3 Nov 2016 02:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 Dre0XUCLhiae; Thu, 3 Nov 2016 02:13:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6299129715; Thu, 3 Nov 2016 02:13:17 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-43-581affac493c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id B9.AA.07742.CAFFA185; Thu, 3 Nov 2016 10:13:16 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 10:13:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+79ftig/ujgjrcK+WiWqe76nEHmV16mdHEjPxPDvGIk=; b=ceEgCxkd6f66W8XUnRRQCU7zXBy3HSjM4omI/tkMQHmsVj7tGCPaz3lDNdtwfLf+43evvpmt9U89HxEaSLFj/EfPL8gA8l1ydRQGM0u0IzFaI/NiH/8GXL70rzC6rS6aU9+PReyyll9Ag4LzK0Gj5SwNNMC7s+04iemrJ7iny9U= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0995.eurprd07.prod.outlook.com (10.162.37.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 09:13:15 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 09:13:14 +0000 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: CCAMP and JOINT YANG session agenda @IETF97 Thread-Index: AdI1sl00KIv6ZxVIScKzfSr4Zs2Uog== Date: Thu, 3 Nov 2016 09:13:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 318452b4-06a0-46ac-6700-08d403c9a465 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 7:04Ql8vYFMwnCHibYMTQkm/W+SPg45z3R2plFOOjaUKgpNBwIp9rsWNYh8tMRcuE1EPCvbrFnFXQTnLzywmYQ5fAu8Umbq+sj1blF6AyFUxBql93r+5WE3HXTNc9PFfqZi0SQqwQa7GBLCCj2rIigCeW4t6TVrxJWvQ25DDg3I5ndgx3YlYWkJCpJ9efXASgDPYSF4R5eCdqWaYqDcNtS2MCdHlE7Fhk0A7UpKbhUwldHKSWpHhQTNLn6pmuuVPoC2LCRGsiaBBarxs8oZfRVCmarPYhr0iDdM3kcBrC3PJDBekcmhcjF5F+SFkxV5YcGj/Sf2wzxCWUCzRqNtJEeJjI8/B/b1j2HF1bdX0KypLI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0995; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(53754006)(189002)(76576001)(122556002)(3660700001)(105586002)(97736004)(229853001)(87936001)(9686002)(7696004)(5660300001)(106356001)(5001770100001)(5002640100001)(19617315012)(558084003)(86362001)(101416001)(19580395003)(10400500002)(3280700002)(8936002)(50986999)(66066001)(107886002)(189998001)(33656002)(19625215002)(586003)(68736007)(54356999)(16236675004)(77096005)(8676002)(15975445007)(450100001)(2906002)(790700001)(6116002)(3846002)(102836003)(74316002)(81156014)(81166006)(19300405004)(7736002)(7846002)(2501003)(2900100001)(7906003)(92566002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 09:13:14.6140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+e3ebXerwc8587Rp6MrezUqJKdELyiCLoqAhUc28OHNO3TVJ IZiSYaPIV6jLcDLNRz4iFEdv18NMy0wzsdaYD7IsAivUNM3rneB/n3O+38M5XzgUIa3ny6k4 QwptNGj1SoGYLNY0r9lUOyvXbO4a8VIPlfSR6v6Kar4609UnVGdN2Mld5P7y8kneYRQl3h5D 6+NSaWPwjtNiXV722qTrivOFRa2kCdnAjEQU4FCY7RggzEhMSXE9grEmm6doRfCz0y5kCxJf JeBSZi2PU/J5kGF2kVzxHMFwY/vcDEUJcDgMOSLZvgxbEPxruilkl3izSx71INYjw2HwtN/A tmVYBS+vdJEsk3gVZEya5lmCT8Dka9v8KMLLYPwVu1hEEdgX+odKedzdGMofdBIc+8DXwRk+ 54+Ghiy7xxMIb2ssHj4IN95VIfY2wFYC/jiHPcI+uOae8HA8NPUWCDgOh+zcVj43YEeQOV6E OMEPqtqGBZyQIQDzlzvzZ0sxDZV1WYhLLAdnz2UP+8HIp4d8LkIiPGsa8MT0grbiITIHrbYs SmdZZLMssnH9jWC9PybgeAPcKhslFrjjySBvcd+KhDXIh6GZ6ITYrSEq2hh3hmESDSoDnXIX zX1RS+NUkB11f9/tQJhCyqWSpNnlGilfm8qkJTgQUIRSJimakWukkhhtWjptTDxlPKenGQdS UKTSV7Kt2nVcimO1KXQ8TSfRxgWVR4nkJiT/9aHRLrut+5tT4vT+diQi0dTy24rt4Q1pBen+ udP5yXvpJffWtdiiuoJ1Ky401KzUK+rUH0fMoYdOqvSKCr9g/973YS5T1kX3lDvCeTRyz868 5hpV8o/pqoDM9rLC7hfpjs9n34w+PhCQH+jNjziGQhpK3UylUzwpDhINtDYrSUan3bKeMDLa /3RePOJBAwAA Archived-At: Subject: [CCAMP] CCAMP and JOINT YANG session agenda @IETF97 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:13:26 -0000 --_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, the first version of the agenda for the CCAMP session and the Joint YANG se= ssion is available at the following link. https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01 Please let us have your comments Thanks MPLS, PCE, TEAS and CCAMP (chairs and secretaries) --_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

the first version of the agenda= for the CCAMP session and the Joint YANG session is available at the follo= wing link.

 

https://www.ietf.org/proceedings= /97/agenda/agenda-97-ccamp-01

 

Please let us have your comment= s

 

Thanks

MPLS, PCE, TEAS and CCAMP (chai= rs and secretaries)

--_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 06:15:17 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10D2129552; Thu, 3 Nov 2016 06:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AD3ZzVziRcbK; Thu, 3 Nov 2016 06:15:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4CC1288B8; Thu, 3 Nov 2016 06:15:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZP79636; Thu, 03 Nov 2016 13:15:08 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 13:15:05 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 06:15:00 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: draft-zhang-ccamp-transport-yang-gap-analysis-01 Thread-Index: AQHSNdRH8wTxiplTbUanpuZ0BVNtuQ== Date: Thu, 3 Nov 2016 13:15:00 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581B385D.0137, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 59cd424c08fea7caa8e897acb20a402a Archived-At: Subject: [CCAMP] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:15:16 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the 4.4. Function Summary and Related YANG Models, I rea= d: +-------------+-----------------------+-----------------------+ |Path Comp. | Path Computation pre | | | | service provisioning | NONE | +-------------+-----------------------+-----------------------+ I disagree with this assessment. TE tunnel model defines the COMPUTE_ONLY m= ode explicitly designed to be used to support Path computation NBI. Cheers, Igor From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Thursday, November 03, 2016 5:13 AM To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@iet= f.org Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97 Hi all, the first version of the agenda for the CCAMP session and the Joint YANG se= ssion is available at the following link. https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01 Please let us have your comments Thanks MPLS, PCE, TEAS and CCAMP (chairs and secretaries) --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

In the 4.4.  Function Su= mmary and Related YANG Models, I read:

 

+-------------+-----------------------&= #43;-----------------------+

        = ; |Path Comp.   | Path Computation pre  |   &= nbsp;           &nbs= p;       |

        = ; |             = ;| service provisioning  |      NONE &nb= sp;           |

        = ; +-------------+-----------------------+----------------------= -+

 

I disagree with thi= s assessment. TE tunnel model defines the COMPUTE_ONLY mode explicitly desi= gned to be used  to support Path computation NBI.

 

Cheers,<= /span>

Igor

 

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); m= pls@ietf.org
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

 

Hi all,

 

the first version of the agenda for the CCAMP sessio= n and the Joint YANG session is available at the following link.=

 

https://www.ietf.org/proceedings/97/agenda/agenda-97-= ccamp-01

 

Please let us have your comments

 

Thanks

MPLS, PCE, TEAS and CCAMP (chairs and secretaries)

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_-- From nobody Thu Nov 3 06:35:11 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD91295D0; Thu, 3 Nov 2016 06:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AE9MlkbZRE0Y; Thu, 3 Nov 2016 06:35:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880E11299CD; Thu, 3 Nov 2016 06:35:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL31645; Thu, 03 Nov 2016 13:35:02 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 13:34:11 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 06:34:05 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uQ== Date: Thu, 3 Nov 2016 13:34:04 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.581B3D07.045A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 528c19965a08031a827385632939270e Archived-At: Subject: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:35:09 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_-- From nobody Thu Nov 3 06:37:47 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FF21299E4; Thu, 3 Nov 2016 06:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pkSzwzzBS2A0; Thu, 3 Nov 2016 06:37:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FF81299E5; Thu, 3 Nov 2016 06:37:19 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 256112E3F227D; Thu, 3 Nov 2016 13:37:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3DbF1a022116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 13:37:17 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3Da2vL020937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 14:37:12 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.62]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 14:36:22 +0100 From: "Belotti, Sergio (Nokia - IT)" To: Igor Bryskin , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 Thread-Index: AQHSNdRYPr/r9zO8ikuUMQHj9hfS3aDHQPzw Date: Thu, 3 Nov 2016 13:36:21 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: "Sharma, Anurag 6. \(EXT - IN\)" Subject: Re: [CCAMP] [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:37:34 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Igor, you probably have an older version: +-------------+-----------------------+---------------------------+ |Path Comp. | Path Computation pre | = | | | service provisioning | ietf-te.yang = | +-------------+-----------------------+------------------------- Moreover in 5.2 : " For path computation, [I-D.busibel-teas-yang-path-com= putation] presents now only use cases but YANG model work is also under consideration to provide statelss path computation RPC. There is currently ongoing discussions on how to provide such a function using the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base." There is no explicit mention of the compute_only solution , since , as you = know, also RPC solution will be supported together with compute_only. We did not provide specific details. Thanks Sergio (as co-author) From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:15 PM To: Daniele Ceccarelli ; CCAMP (ccamp@ietf= .org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 Hi, In the 4.4. Function Summary and Related YANG Models, I rea= d: +-------------+-----------------------+-----------------------+ |Path Comp. | Path Computation pre | | | | service provisioning | NONE | +-------------+-----------------------+-----------------------+ I disagree with this assessment. TE tunnel model defines the COMPUTE_ONLY m= ode explicitly designed to be used to support Path computation NBI. Cheers, Igor From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Thursday, November 03, 2016 5:13 AM To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97 Hi all, the first version of the agenda for the CCAMP session and the Joint YANG se= ssion is available at the following link. https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01 Please let us have your comments Thanks MPLS, PCE, TEAS and CCAMP (chairs and secretaries) --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Igor, you probably have an older version:=

 

+-------------+-----------------------+-= --------------------------+
         |Path Comp.   | = Path Computation pre  |        = ;            &n= bsp;      |
         |    &= nbsp;        | service provisioning = ; |     ietf-te.yang      = ;    |
         +-------------+---= --------------------+-------------------------

 

Moreover in 5.2 : “   For path compu= tation, [I-D.busibel-teas-yang-path-computation]
   presents now only use cases but YANG model work is also under<= br>    consideration to provide statelss path computation RPC.  = There is
   currently ongoing discussions on how to provide such a functio= n using
   the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a ba= se.”

 

There is no explicit mention of the compute_only sol= ution , since , as you know, also RPC solution will be supported together w= ith compute_only.

We did not provide specific details.

 

Thanks

Sergio (as co-author)

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] = On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:15 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAM= P (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf= .org) <teas@ietf.org>; mpls@ietf.org
Subject: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01

 

Hi,<= /p>

 

In the 4.4.  Function Su= mmary and Related YANG Models, I read:

 

+-------------+-----------------------&= #43;-----------------------+

        = ; |Path Comp.   | Path Computation pre  |   &= nbsp;           &nbs= p;       |

        = ; |             = ;| service provisioning  |      NONE &nb= sp;           |

        = ; +-------------+-----------------------+----------------------= -+

 

I disagree with thi= s assessment. TE tunnel model defines the COMPUTE_ONLY mode explicitly desi= gned to be used  to support Path computation NBI.

 

Cheers,<= /span>

Igor

 

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

 

Hi all,

 

the first version of the agenda for the CCAMP sessio= n and the Joint YANG session is available at the following link.=

 

https://www.ietf.org/proceedings/97/agenda/agenda-97-= ccamp-01

 

Please let us have your comments

 

Thanks

MPLS, PCE, TEAS and CCAMP (chairs and secretaries)

--_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_-- From nobody Thu Nov 3 06:45:19 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7221299E1; Thu, 3 Nov 2016 06:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KqN30VaULo2H; Thu, 3 Nov 2016 06:45:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21573129522; Thu, 3 Nov 2016 06:45:14 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6846FB83E63C8; Thu, 3 Nov 2016 13:45:10 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3DjC8r003520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 13:45:13 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3Dj8wu005751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 14:45:12 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 14:44:54 +0100 From: "Scharf, Michael (Nokia - DE)" To: Igor Bryskin , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw Date: Thu, 3 Nov 2016 13:44:54 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:45:18 -0000 --_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas= @ietf.org); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS W= G (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Hi,

&n= bsp;

From th= e draft:

&n= bsp;

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

&n= bsp;

--_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_-- From nobody Thu Nov 3 06:49:49 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44451299E9; Thu, 3 Nov 2016 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 txepo0hc_7Kz; Thu, 3 Nov 2016 06:49:43 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FDD129A00; Thu, 3 Nov 2016 06:49:31 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-a4-581b4069d8d2 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B8.32.03250.9604B185; Thu, 3 Nov 2016 14:49:29 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 14:49:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K8HlXFRnjb3hWR83Kvj6REsqhN01G9WBPsfdgm09jzo=; b=gqO8Ms+YIJ2clnPd0TARZnlmMkFh6CJGCo7RmDs84Zfpi8vFXxhnfXLcQbuzxDx4leGtv9Hi7o3YKzzv8wi/TPyVPtQ7bVO58mWSDX3r+sx/ccTa6U1LDsGI2adGPigTsHOHx2jZNy9xcn6LwD1bFZBy/5B9bXCfj27To5K/yEo= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 13:49:20 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 13:49:20 +0000 From: Daniele Ceccarelli To: "Scharf, Michael (Nokia - DE)" , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9A= Date: Thu, 3 Nov 2016 13:49:20 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 49ba50ff-ba92-4488-c174-08d403f03675 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:iq2vVnk2mS69OOwuMx4uEzXGnA4F4vEaicDJrH6j00/GoVQu49LLfopcmQTbtZ/JzdoU03i4QvErBb8TkerItw5LZ2lhWI/2nzN9khnUUW9RAt88uxnlSCzGkZrrddACoL3S+EgWRMog35w1vRpuOqlvip/faMKCgj64zSWX715oQLHO4IjnT9XB0M6nGzf3pclZFgOsoxRN9ydREVBJ4QVTBxhaL28zzC/fVZnPjkjHCzhpfCIOqYa7tB78QR0CpP0IGDIbdW++iv00hmKAl7ISTr8xizpI0XIs0BIr6pbC6H1dhnhVBifwSDlCn+2fQhwU64RF2jHqnRRJS+B2ZWUtE3bk+RHsoEzbq8nMZbc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(199003)(2900100001)(122556002)(15975445007)(77096005)(50986999)(86362001)(33656002)(101416001)(19625215002)(220493001)(66066001)(16236675004)(92566002)(76176999)(106356001)(106116001)(105586002)(54356999)(586003)(3846002)(19300405004)(2906002)(6116002)(790700001)(102836003)(19617315012)(230783001)(68736007)(76576001)(19580395003)(19580405001)(8936002)(81156014)(81166006)(8676002)(74316002)(9686002)(3280700002)(2501003)(5002640100001)(7736002)(7846002)(7906003)(7696004)(189998001)(87936001)(107886002)(11100500001)(5660300001)(2950100002)(10400500002)(97736004)(3660700001)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 13:49:20.5642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03Sa0iTURgHcM57ma/S4LQ0nzY/5DATTVOTGCMvZZlUplHRiKJmvnjfZJum 0geTpkyyTA3UghS85C3zUg1U1FGEKWiWYUuxUjG1EiJviVrvjoHffs//eTiH83A4WtLNSrl4 jYHXadRJcpEDU6p6ccw7PkSm8p3t8FVMPhxhFGu9foqVt54Ka1Utq8geH7FTGJfNTIgo/NbL H2x4ZeUKFT5mHaKi6IsOh2L4pPg0Xrc/6KpDXGtOP5vSYELpLV+/oCw0nJmHOA5wAFgnTuYh B06CnyAofrrMkOI1go0+KysUDM6n4dnyOk06RRQsFn2mSPEKwXxVLS2cJcJKmLScEnJHfJOC np+/7PKQPbcDn4eutnpGsCM+B0vG53bESliz9ogEM9gNBmqzbRbjS/C7pIklF8wieFdeQQkN e3wZPg1u0IIR3glLbxpsOY2dwTr5yGbAGCo7BmhiJ5iZWGfJfDQ0Gc2bM64wWFdGkQVEQPNA unAX4HIaOkxZLJkJg/l7VkScCLmmic08ARZK/oiIzQgqCj2IXeBx79RmXiOC4f5wwRLMQ02j EZFFSGHsvWnTLvBttJMtQB5lW55ArIWF3CFRmW0X26G3dJIhuQ+M3C8WEXtBdcUcTewNJesW ZmtejuzqkJOe10cnx/r7+/C6+Gt6vVbjo+ENLejfv+ppW/U1o5npwxaEOSTfJk7Z2KWSsOo0 fUayBQFHyx3Fo8EylUQco87I5HXaK7rUJF5vQTKOkTuLD9aOX5DgWLWBT+T5FF73v0tx9tIs dFc2mpT6UJmjHHV1z23tbYxoXprqUg8WGPZ6BLef7VT7liY3D02FRi5KLftinOpDKilx5Fw3 tGbfCbr+ISosP0g6kXCgbTAQTxealOlnPp4IvuGY+L1PEbonWeV+VHx7Snvcs9Vfdrq6sX23 mzbQNfdIVHZmwIMBjasBqrxWjXJGH6f286R1evVfuArvoVMDAAA= Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:49:46 -0000 --_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin ; Daniele Ceccarelli ; CCAMP (ccamp@ietf.org) ; pce@ietf.or= g; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Can you please explain what the “stateful compute-only” s= tands for I don’t understand what is stateful in a path computation r= equest only.

IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute = a path and then forget about it or I ask to compute and provision it. I don= ’t understand the value of asking for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com>; Daniele Ceccarelli= <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@ietf.org) <ccamp@= ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; = mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

&n= bsp;

From th= e draft:

&n= bsp;

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

&n= bsp;

--_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 06:50:33 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E739D129A0E; Thu, 3 Nov 2016 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HJ4Lg9H6oppD; Thu, 3 Nov 2016 06:49:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2921299FB; Thu, 3 Nov 2016 06:49:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL33957; Thu, 03 Nov 2016 13:49:33 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 13:49:32 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 06:49:28 -0700 From: Igor Bryskin To: "Scharf, Michael (Nokia - DE)" , "Daniele Ceccarelli" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQA//+LfxA= Date: Thu, 3 Nov 2016 13:49:27 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581B406D.0245, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:49:49 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, Yang 1.1 action is a form of RPC. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Thursday, November 03, 2016 9:45 AM To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org;= TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas= @ietf.org); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

 

Yang 1.1 action is a f= orm of RPC.

 

Igor=

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ie= tf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS W= G (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_-- From nobody Thu Nov 3 06:58:08 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B549A129633; Thu, 3 Nov 2016 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TCOQKf8GbR2r; Thu, 3 Nov 2016 06:58:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3FC1295F5; Thu, 3 Nov 2016 06:58:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 381DFE923939F; Thu, 3 Nov 2016 13:57:56 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3Dvwj0021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 13:57:58 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3DvsIh022252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 14:57:56 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 14:57:41 +0100 From: "Scharf, Michael (Nokia - DE)" To: Daniele Ceccarelli , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw///xlACAABFawA== Date: Thu, 3 Nov 2016 13:57:40 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:58:03 -0000 --_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

&n= bsp;

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsso= n.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org=
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 =

BR
Daniele 

 =

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.=

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_-- From nobody Thu Nov 3 07:03:48 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28682129A1B; Thu, 3 Nov 2016 07:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bdPSAlr1qOk9; Thu, 3 Nov 2016 07:03:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E92412962E; Thu, 3 Nov 2016 07:03:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZP87813; Thu, 03 Nov 2016 14:03:40 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 14:03:40 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 07:03:36 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgD//4thsA== Date: Thu, 3 Nov 2016 14:03:35 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.581B43BD.0115, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:03:47 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin ; Daniele Ceccarelli ; CCAMP (ccamp@ietf.org) ; pce@ietf.or= g; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

HI Daniele,=

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract link to it= s own client, in some failure restoration scheme or as a part of disaster r= ecovery network topology re-configuration). In this case the client would want to know at least  if/when the path= has stopped being feasible any longer or (ideally) a better path is availa= ble.

 

Igor=

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.or= g); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com>; Daniele Ceccarelli= <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@ietf.org) <ccamp@= ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; = mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_-- From nobody Thu Nov 3 07:19:36 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B95129644; Thu, 3 Nov 2016 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 9pAQuu_Z0XXZ; Thu, 3 Nov 2016 07:19:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B271129406; Thu, 3 Nov 2016 07:19:17 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-94-581b47647cda Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 84.58.03250.4674B185; Thu, 3 Nov 2016 15:19:16 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 15:19:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FMwtXQkUzdn5bj7ptbTj78TAFI5mdjoyyR2X0AhJmqg=; b=TcGZqKWuXEYIYMgp7m8kXKKkfdpMnzpALtzrsoj15atlEBa/S2TSjGjsOStDtS/o+7s6v+PhD2PUlbbso44bel5GdRPTzxBznEct+HsCUL3mYaX3eY2CiIju/bL3y3kZvhA9YWi3Rw7CYOtDlCx6byE3SiQgiQiDsNJ+y32aTrE= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Thu, 3 Nov 2016 14:19:13 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 14:19:13 +0000 From: Daniele Ceccarelli To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9CAAAS6gIAAAJSQ Date: Thu, 3 Nov 2016 14:19:13 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8768911b-a5e2-409c-66dc-08d403f46318 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0994; 7:8olppoFje5h1FFI6SGb9FtQv/9PZhufmJaveFqovm5EnVnU91jwVjgMDAEwfOBF7H4rBGTVc6TvEbMgsAZoBnsr6cdInlWW4d20fh9ESpqWq+1RyLCpMziO9gA7OPbiSzWMHr0A40KcsZj/ZgNNBxHyJ1j0rxcoVYRZ7oTQ5rcDK2RGoRtkPfUxNQb/AcnNHroZnsF4ya953TSSFJdnDO+5MLzMVGYwn0nN7+lbXr7EH/SH7LUaoEJzn16GVJJ97kyjC+TqfjsGu3cc/zp401NOrJ+MFGYk0dLRjGmhntT5HgZMb/p6O8/7an1dUDG4+kDdjOOf3VeIFt43u9+i1/RkxElXmWAZNdy8AK1SA1bk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0994; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0994; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(377454003)(19580405001)(2950100002)(10400500002)(7696004)(2900100001)(220493001)(66066001)(8936002)(9686002)(19580395003)(5002640100001)(93886004)(105586002)(92566002)(106356001)(19300405004)(77096005)(15975445007)(11100500001)(19617315012)(76576001)(68736007)(106116001)(87936001)(790700001)(3846002)(102836003)(6116002)(2906002)(19625215002)(586003)(3660700001)(8676002)(3280700002)(81166006)(101416001)(5001770100001)(50986999)(16236675004)(54356999)(107886002)(97736004)(81156014)(189998001)(76176999)(7906003)(7736002)(7846002)(2501003)(5660300001)(74316002)(122556002)(230783001)(86362001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0994; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 14:19:13.3478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0994 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG/c45247DwdfSfJ1SOkpC8V4xREL/0AwUioxEIpt5vKRusqlk kGg6QSmVmHilNOwyb5VIrrTUg1ETzJVdxEtqeUnLEFTmMrW2s8D/ft/zPt/78L68NClmeRI6 VZHFqBTydClfSNXEdoX7JJ5wjfWf/rNfNls/Ssm2DAEy8zsv2dg9HU92fWpUINNs6KlQfmTR wDIvsqnJTEROjr0nTpFxwpBEJj01h1H5Hb8oTBksMJKZwyy6slnUz89Hn9pQKbKnAR8BTUut oBQJaTFuR1BvNpLc4zUCs65KYHFR+CYJ0yuhXEFLwMhnrfW7GL9C8LbudCmiaT4Ohlk2yuJx xAUErLeXUBbPXnwWejtbrOyIY8CkeSrgOAIMnQ0UF3AQhkq6rD1F+DyMl3XwuLANAn6uNVpN 9jgcjEs1PAsjvA9Mg62EhUnsDGOzdwhuHgxNPcMkx06w+G3b5k+ARxq9zeMBxuZaG0dD+eqM dX7ADSTorcmWQgT0da/ZlpQGfSXdNv0yrFf/5nOsRzD3huHYDR4a5vhcoyd8GDAtEdyKGHjQ pkHcKiQw+aHExm7wfeIFrwIdrt01BMdKKB6ZsbII7wFDzSzF6b4wWqnlc+wN9xt/kBz7QPU2 S+3WG5CgGTmpGXVCRnJgoC+jSr2kVisVvgomqwP9u6z+zk1/PVpcCGMRppHUQZS54xIr5slz 1LkZLAKalDqKqiJcY8WiRHnuVUaljFdlpzNqFrnSlNRZdEw3dU6Mk+VZTBrDZDKq/1WCtpfk o7tsW7nHR39tXoOyca1pcDpuorxPP1/w7JZdcMjOn94Zz6LNtqDCyqQNd5nnSnGMyRwVOqRj /eafS77eiA66MLHlIfFyT/jlosimiDN5MbkVX4ze1Y+Tlh3GqtxbF04G5OnGD00eXT1gjPeK XyzTTvZ0mzJeSu2uhc3UFRYk3m6RUuoUeYAXqVLL/wKoF71FVQMAAA== Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:19:27 -0000 --_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Understood the concept. It is clear but I'm still struggling with its usefu= lness. What you call statefull and stateless is with respect to the domain = controller, but I see the statefullness and stateless of the paths an highe= r level controller issue and fair enough to have the stateless concept in t= he domain controller. In other words if the higer level controller wants to keep the state of the= path why doesn't it simply do that instead of demanding it to the domain c= ontroller? Because if should be made available also to someone else? Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:04 To: Daniele Ceccarelli ; Scharf, Michael (= Nokia - DE) ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

Understood the concept. It is clear but I’m still struggling wi= th its usefulness. What you call statefull and stateless is with respect to= the domain controller, but I see the statefullness and stateless of the paths an higher level controller issue and fair enoug= h to have the stateless concept in the domain controller.=

In other words if the higer level controller wants to keep the state = of the path why doesn’t it simply do that instead of demanding it to = the domain controller? Because if should be made available also to someone else?

 

Cheers

Daniele 

 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scha= rf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

HI Dani= ele,

&n= bsp;

A clien= t may ask for a path not to be used immediately (e.g. to present as an abst= ract link to its own client, in some failure restoration scheme or as a par= t of disaster recovery network topology re-configuration). In this case the client would want to know at least &nb= sp;if/when the path has stopped being feasible any longer or (ideally) a be= tter path is available.

&n= bsp;

Igor

&n= bsp;

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 07:25:04 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C3129A3D; Thu, 3 Nov 2016 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xChB27rdT30z; Thu, 3 Nov 2016 07:24:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D3D129669; Thu, 3 Nov 2016 07:24:53 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 458121ECD4DA; Thu, 3 Nov 2016 14:24:48 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3EOoFb030903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 14:24:51 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3EOlTV001216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 15:24:49 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.62]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 15:24:32 +0100 From: "Belotti, Sergio (Nokia - IT)" To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcdFm7Ey8mkl0SoOXT6dUSe8qDHNHgAgAABRYCAABkugA== Date: Thu, 3 Nov 2016 14:24:32 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:24:56 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Igor, this is correct. But if I remember well last weekly tunnel model discussion, action proposal= to support stateless solution is still in alternative to a normal RPC. I guess in the new module Tarek has already created "arrangement" for both. Thanks Sergio From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE) ; Daniele Ceccar= elli ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Michael, Yang 1.1 action is a form of RPC. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Thursday, November 03, 2016 9:45 AM To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Igor, this is correct.

But if I remember well last weekly tunnel model disc= ussion, action proposal to support stateless solution is still in alternati= ve to a normal RPC.

I guess in the new module Tarek has already created = “arrangement” for both.

 

Thanks

Sergio

 

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; D= aniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Michael,

 

Yang 1.1 action is a f= orm of RPC.

 

Igor=

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_-- From nobody Thu Nov 3 07:29:25 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD39F129660; Thu, 3 Nov 2016 07:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 g6QeP5nToXK8; Thu, 3 Nov 2016 07:29:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076B112950B; Thu, 3 Nov 2016 07:29:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL40185; Thu, 03 Nov 2016 14:29:11 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 14:29:11 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 07:29:07 -0700 From: Igor Bryskin To: "Belotti, Sergio (Nokia - IT)" , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQA//+LfxCAAH+UAP//izag Date: Thu, 3 Nov 2016 14:29:06 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EFD1@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.581B49B8.0202, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:29:20 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO we do not need both global and action RPC. The latter is more elegant = but essentially the same as the former. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Belotti, Sergio (Nok= ia - IT) Sent: Thursday, November 03, 2016 10:25 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, this is correct. But if I remember well last weekly tunnel model discussion, action proposal= to support stateless solution is still in alternative to a normal RPC. I guess in the new module Tarek has already created "arrangement" for both. Thanks Sergio From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE) ; Daniele Ceccar= elli ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Michael, Yang 1.1 action is a form of RPC. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Thursday, November 03, 2016 9:45 AM To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMHO we do not need bo= th global and action RPC. The latter is more elegant but essentially the sa= me as the former.

 

Igor=

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Belotti, Sergio (Nokia - IT)
Sent: Thursday, November 03, 2016 10:25 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Igor, this is correct.

But if I remember well last weekly tunnel model disc= ussion, action proposal to support stateless solution is still in alternati= ve to a normal RPC.

I guess in the new module Tarek has already created = “arrangement” for both.

 

Thanks

Sergio

 

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; D= aniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Michael,

 

Yang 1.1 action is a f= orm of RPC.

 

Igor=

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_-- From nobody Thu Nov 3 07:35:17 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A0C129658; Thu, 3 Nov 2016 07:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 I7f70RW9Hlwh; Thu, 3 Nov 2016 07:35:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51FB129A3D; Thu, 3 Nov 2016 07:34:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL41023; Thu, 03 Nov 2016 14:34:52 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 14:34:52 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 07:34:46 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgD//4thsIAAfPiA//+LybA= Date: Thu, 3 Nov 2016 14:34:46 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.581B4B0D.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:35:10 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the client to keep returned by the provider path state means requesting= from the provider periodic path re-computations. Provider can re-evaluate= previously returned path in an event driven way (e.g. reacting on TED chan= ge affecting one of the path's links). From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 10:19 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Igor, Understood the concept. It is clear but I'm still struggling with its usefu= lness. What you call statefull and stateless is with respect to the domain = controller, but I see the statefullness and stateless of the paths an highe= r level controller issue and fair enough to have the stateless concept in t= he domain controller. In other words if the higer level controller wants to keep the state of the= path why doesn't it simply do that instead of demanding it to the domain c= ontroller? Because if should be made available also to someone else? Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:04 To: Daniele Ceccarelli ; Scharf, Michael (= Nokia - DE) ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For the client to keep= returned by the provider path state means requesting from the provider per= iodic path re-computations.  Provider can re-evaluate previously retur= ned path in an event driven way (e.g. reacting on TED change affecting one of the path’s links).  <= /span>

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.or= g); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Hi Igor,

 

Understood the concept. It is clear but I’m st= ill struggling with its usefulness. What you call statefull and stateless i= s with respect to the domain controller, but I see the statefullness and st= ateless of the paths an higher level controller issue and fair enough to have the stateless concept in the domain controll= er.

In other words if the higer level controller wants t= o keep the state of the path why doesn’t it simply do that instead of= demanding it to the domain controller? Because if should be made available= also to someone else?

 

Cheers

Daniele 

 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawe= i.com]
Sent: gioved=EC 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scha= rf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

HI Daniele,=

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract link to it= s own client, in some failure restoration scheme or as a part of disaster r= ecovery network topology re-configuration). In this case the client would want to know at least  if/when the path= has stopped being feasible any longer or (ideally) a better path is availa= ble.

 

Igor=

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_-- From nobody Thu Nov 3 07:42:42 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06E4129A89; Thu, 3 Nov 2016 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 xL_6GB8O3-7v; Thu, 3 Nov 2016 07:42:38 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F622129A84; Thu, 3 Nov 2016 07:42:37 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-ff-581b4cdbdb54 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 58.84.07742.BDC4B185; Thu, 3 Nov 2016 15:42:35 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 15:42:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VRZSp5GZpAGlhWkPlfIyWJVFz7eXdQd+hquGcFyBdN0=; b=IKtisCKrnqIOJXJky2tQEQbonFPgwLFsUVvAzrl8YZ6dflCky/PQ6A7uGiZ4IZupW79sV0M5Xgs8UWz65K0oc+8fc1UXZuen8USi31GTAqgi3v8mw3wiNNvhmUaCfju0JJDBQvuVKzXjfT05qf/ROSETwMm8p83vuvHSWI221OE= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 14:42:10 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 14:42:10 +0000 From: Daniele Ceccarelli To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9CAAAS6gIAAAJSQgAAIIgCAAAEokA== Date: Thu, 3 Nov 2016 14:42:10 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8910efd2-2137-4d4d-f264-08d403f797c6 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:cgw389NkduClgLnHL6he6Ws/IMSms3s5ihbyULK8+endz0SLN0bXgRJYsB4QFQbRwYbZHJcT7ebrd1KSkp118+LgRsouHZi1Bl85IfFtZwIInDG1Ep0ILaUlou4tFK6vXUCSdFITNszzVPnmeC0QUUNi4bnyxttWo5jg3zvHgbCggTxZ+GItcVAEt1ruHYjrssaY5Kkl7ME6DZVZHcsF3QsXVU+H4vek5LeXVEmJjJUVJv/oxBloOr/FGrsCQa2x0XkAht0fzgMZrTFvivvJRhhykra3E0J3jnoncGUcylERqXQLqgu20A36fk6UAFtczs1PIFHpURKyTImmpHsHadVS07Qd1VhYyGE2lCYhWL4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(199003)(2900100001)(122556002)(15975445007)(77096005)(50986999)(86362001)(33656002)(19625215002)(220493001)(101416001)(66066001)(16236675004)(92566002)(76176999)(586003)(106356001)(106116001)(54356999)(3846002)(19300405004)(2906002)(105586002)(790700001)(102836003)(6116002)(19617315012)(93886004)(230783001)(68736007)(76576001)(19580395003)(19580405001)(81156014)(81166006)(8676002)(8936002)(9686002)(3280700002)(2501003)(5002640100001)(74316002)(7736002)(7906003)(7846002)(7696004)(189998001)(87936001)(107886002)(11100500001)(5660300001)(2950100002)(10400500002)(97736004)(3660700001)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 14:42:10.3054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+845Ox5Hg6+l+Xr5x3VBjJlmxLoXpglpCamZBDbz4H0bm4n6 R2k5TSm0qaESqTGzzTISKYlUmpqXqKUuvCUazijzVmGmpuZ2Fvjf7/meh+/93oePIYWtPBcm XpbCKmXSJBHNp8oiXriLh4NcI7yLbh6QmO8NUJKVLh/JYo+nZKhax5NcHx2wk6j/NFLH6cDs tmleoFa7SASODPUSIWQk/3AMmxSfyir3HL3Ej+utNSLF+E+U1jf3i8pEc4MoH9kzgPdBd+0y mY/4jBDXIdBOaxAnOtbF3H3KIih8m4SVwWaKc4oIGFt6y+NEO4KWYQ2djxiGxgfBbAiynDvg LALm6/Ioy5CtOAxaGmqt7IBDYUH93I7jcDB8HrY+hMI7wJA1Zs0I8EVYMzUQ3IAcCop7OkmL YY/9oWOynrAwwttgofuxlUnsBEPmCoLbCIP2lZHk2BG+ja/yuHw0PFU32jLu8EFfbuNgmHmg tq4GuJKEtr/9dpwRALN3hmw1JUJFgdHGCTBfukRz3IigSuPBsRs86pqguYue0VC20GmdLMQs 1DxRI64KFxgx5dnYDb5+auIVIo/yDUuUrzdJYjn01gSXW8vYAl1lZoqLeMFASTHN8W54WPWd 5FgMpasGauN5JbLTI0cVq4pOjt3r68Uq4y+rVHKZl4xNqUfrX+t1w/LORtQ3dcKAMINEmwWK NecIIU+aqkpPNiBgSJGDoOm0a4RQECNNz2CV8ijllSRWZUCuDCVyEuzXjZ4X4lhpCpvIsgpW +d8lGHuXTBR4rSTBlDoVWjDmdu5G16ZmU60ud2E2TNHj7jlhPEImr32J7jmWrN+VIQ7puJqm i/QP/jh31k+6nNt0Urv9TP+h9tZ5Q1IsrY6qHjRnvwtf1Gx5c6FJJ5+5tdavZ3BW5GRGQE5I uKYuUfzyd/xdn/eY0Cukp/yUpPeq83Ch7w8RpYqT+niSSpX0H6voKp5WAwAA Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:42:41 -0000 --_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Makes sense. Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:35 To: Daniele Ceccarelli ; Scharf, Michael (= Nokia - DE) ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 For the client to keep returned by the provider path state means requesting= from the provider periodic path re-computations. Provider can re-evaluate= previously returned path in an event driven way (e.g. reacting on TED chan= ge affecting one of the path's links). From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 10:19 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Igor, Understood the concept. It is clear but I'm still struggling with its usefu= lness. What you call statefull and stateless is with respect to the domain = controller, but I see the statefullness and stateless of the paths an highe= r level controller issue and fair enough to have the stateless concept in t= he domain controller. In other words if the higer level controller wants to keep the state of the= path why doesn't it simply do that instead of demanding it to the domain c= ontroller? Because if should be made available also to someone else? Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:04 To: Daniele Ceccarelli >; Scharf, Michael (Nokia - DE) >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG (teas@ietf.org) >; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Makes sense.

 

Cheers

Daniele 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 3 novembre 2016 15:35
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scha= rf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

For the= client to keep returned by the provider path state means requesting from t= he provider periodic path re-computations.  Provider can re-evaluate p= reviously returned path in an event driven way (e.g. reacting on TED change affecting one of the path’s links).=  

 <= /span>

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

 

Understood the concept. It is c= lear but I’m still struggling with its usefulness. What you call stat= efull and stateless is with respect to the domain controller, but I see the= statefullness and stateless of the paths an higher level controller issue and fair enough to have the stateless con= cept in the domain controller.

In other words if the higer lev= el controller wants to keep the state of the path why doesn’t it simp= ly do that instead of demanding it to the domain controller? Because if sho= uld be made available also to someone else?

 

Cheers

Daniele 

 

 

From: Igor Bryskin [mailto= :Igor.Bryskin@huawei.com]
Sent: gioved=EC 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scharf, Michael (Nokia -= DE) <michael.scharf@nokia.c= om>; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

HI Dani= ele,

 <= /span>

A clien= t may ask for a path not to be used immediately (e.g. to present as an abst= ract link to its own client, in some failure restoration scheme or as a par= t of disaster recovery network topology re-configuration). In this case the client would want to know at least &nb= sp;if/when the path has stopped being feasible any longer or (ideally) a be= tter path is available.

 <= /span>

Igor

 <= /span>

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00<= /span>

 =

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"EN-US">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"EN-US">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 09:12:52 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574BD129581; Thu, 3 Nov 2016 09:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=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 O_DIYP_53hIc; Thu, 3 Nov 2016 09:12:50 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB503129443; Thu, 3 Nov 2016 09:03:29 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uA3FsirF003958; Thu, 3 Nov 2016 12:03:29 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 26g7wd1vsk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Nov 2016 12:03:28 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA3G3RBj002093; Thu, 3 Nov 2016 12:03:28 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA3G3Ghj001831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Nov 2016 12:03:23 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 3 Nov 2016 16:03:02 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.125]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 12:02:15 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHSNdpDvvAiNyDLrkGHzPfc/ozSdqDHaMXw Date: Thu, 3 Nov 2016 16:02:15 +0000 Message-ID: References: <147818146209.22755.6255303719663691627.idtracker@ietfa.amsl.com> In-Reply-To: <147818146209.22755.6255303719663691627.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.223.156] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030294 Archived-At: Cc: "ccamp-chairs@ietf.org" , "draft-ietf-ccamp-ospf-availability-extension@ietf.org" Subject: Re: [CCAMP] ID Tracker State Update Notice: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:12:51 -0000 SGkgQ0NBTVAsDQoNCkFzIGEgcmVzdWx0IG9mIHRoZSBHZW4tQVRSIHJldmlldyBhbmQgaXNzdWVz IHJhaXNlZCwgSSByZW1vdmVkIHRoaXMgZG9jdW1lbnQgZnJvbSB0b2RheSdzIHRlbGVjaGF0LiBZ b3VyIENoYWlycywgQXV0aG9ycywgYW5kIEkgZGVjaWRlZCB0aGUgYmVzdCBhcHByb2FjaCB3b3Vs ZCBiZSBmb3IgbWUgdG8gcmV0dXJuIHRoaXMgZG9jdW1lbnQgdG8gdGhlIFdvcmtpbmcgR3JvdXAg dG8gZnVydGhlciBkaXNjdXNzIGhvdyB0byBwcm9ncmVzcy4NCg0KQmVzdCByZWdhcmRzIGFuZCBz YWZlIHRyYXZlbHMgZm9yIHRob3NlIGdvaW5nIHRvIFNlb3VsLQ0KRGVib3JhaA0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRv OmlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBOb3Zl bWJlciAwMywgMjAxNiA5OjU4IEFNDQo+IFRvOiB6aGFuZ2ZhdGFpQGh1YXdlaS5jb207IEZhdGFp IFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+OyBjY2FtcC0NCj4gY2hhaXJzQGlldGYub3Jn OyBCUlVOR0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0LmNvbT47IGRyYWZ0LWlldGYtDQo+IGNj YW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBJRCBU cmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6IDxkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxh YmlsaXR5LQ0KPiBleHRlbnNpb24tMDgudHh0Pg0KPiANCj4gSUVTRyBzdGF0ZSBjaGFuZ2VkIHRv IEFEIGlzIHdhdGNoaW5nOjpSZXZpc2VkIEktRCBOZWVkZWQgZnJvbSBJRVNHDQo+IEV2YWx1YXRp b24NCj4gSUQgVHJhY2tlciBVUkw6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtY2NhbXAtb3NwZi0NCj4gYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi8NCg0K From nobody Thu Nov 3 09:46:41 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B949B12966D; Thu, 3 Nov 2016 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 EnicfbHmsfrW; Thu, 3 Nov 2016 09:46:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A6D129663; Thu, 3 Nov 2016 09:46:36 -0700 (PDT) X-AuditID: c1b4fb25-953ff70000001e3e-e6-581b69e8ec6e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id CD.FB.07742.8E96B185; Thu, 3 Nov 2016 17:46:35 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 17:46:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=alapHVtmoY03j1ioV6OPOx5PthIOXxR5l07p8qKnfcg=; b=LAwEfSjYQoMVNh5uFMY3uBA7hgpKqb0AcQZD7EWsjM87xTWkBYRXqmyMqlCLzxKlzh6+vMXSQfUVQMqIJNlE3jWL0N54VOdJwfs2Hlpi1N+j1yH770h50Av5lMmPhdl6LAVoUMy426Och7+OAhDdnDMloAWWqnVYL2shjOJE1ws= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 16:46:30 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 16:46:30 +0000 From: Daniele Ceccarelli To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHSNdpTbC0uLrhAzUehYA1gr+9476DHa5WAgAAJHfA= Date: Thu, 3 Nov 2016 16:46:30 +0000 Message-ID: References: <147818146209.22755.6255303719663691627.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8bd45a04-efda-4147-fcab-08d40408f675 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:g/C4y/z89OBCTvqqfN/3uQ7Z1Zyny0RWeYWcpWRs1gkf0/1gqApK3Jw7pgnXz39bNPoRKc/e4xRgbOnNapYj3aX1lUNld8j78tdm1v4nfz/jVedNk9xX1CWkUA/BPZ6JRQQ1YIuVRzm4lTN8yiFRTUKYFA/WPQvql6Ny95BOYuYpkB65Df9s+rNXVqdXMHBUUjVaYWjZ/h1e0qF9s8oUYiz+ItRAWcJPvyVFyy39AZbu5Iu1gYzvnfXOAGDeHQu6CO8X9lwwlebq1Poeh3S49bWjYuGCM+iGFnGJT6o4wwTF+gFsypKnFXygYoqac7S2yZImRz+w7zfLXc59pGAz3XWZ43kq/n2bfThXgzYVB0o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377454003)(199003)(13464003)(2900100001)(122556002)(15975445007)(77096005)(86362001)(50986999)(33656002)(101416001)(66066001)(92566002)(76176999)(586003)(106356001)(106116001)(54356999)(3846002)(105586002)(2906002)(4326007)(102836003)(6116002)(230783001)(68736007)(76576001)(19580395003)(19580405001)(81156014)(81166006)(8676002)(8936002)(9686002)(3280700002)(2501003)(5002640100001)(305945005)(7736002)(7846002)(74316002)(7696004)(189998001)(87936001)(15650500001)(5660300001)(11100500001)(2950100002)(10400500002)(97736004)(3660700001)(5001770100001)(162123002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 16:46:30.5898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUyM2K7tO7rTOkIgyuH5CyW7tjEZPFkzg0W i8td3ewWM/vmsli0/tjB4sDq8bJ/DqPHkiU/mQKYorhsUlJzMstSi/TtErgyzhxYxlRwQLLi 9o6XjA2MbyS6GDk5JARMJA43vWXpYuTiEBJYxyjR/eUZK0hCSOA4o0TDcT+QBItAL7PEr/PP WSGqJjNJtJ/8zgbhHAVq2TOPvYuRg4NNwEriySEfkG4RgSqJ68tfgDUwC6xglDg4exU7SEJY IEVi2boeNoiiVInfX55C2VYSR9ffA1vNIqAiMfXzOTCbVyBG4uPW61DL5jJKPJk3HayBUyBK YvPGDiYQm1FATOL7qTVgNrOAuMStJ/OZIJ4TkFiy5zwzhC0q8fLxP1aI+iSJ9a07oGoUJS6s mgVl+0qcWfAP7GoJgQXMEr27lkMl3CTeT7zFCGFnS8w/dowVwo6WaLm1EKpmB6PEwkkaELaM xIqTT9kgBnWwSUydtIoJEqqpEsvXtjJCgkJK4u6VTsYJjFqzkBw+CxiSzAKaEut36UOEFSWm dD9knwUODEGJkzOfsCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJEZhWDm75rbqD8fIb x0OMAhyMSjy8HwKkI4RYE8uKK3MPMUpwMCuJ8GakAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInz mq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgrDvun7Z8yt9pm7yZzshx2p1wTduo6rxcN+99me2L zbO3WiSFqmvskDGqvPevdEad/ZqsC/nvDxqtdpi2/fLT7QmyundvX98y6dXHB/FaUg9bXC+F BbgGdnO63eA5FpSrfU1RV+Xdh00lvG2lj37myJv/F/dYWfKAbe/Us01Vcq9P3JvxbJb3OyWW 4oxEQy3mouJEANPH9bEnAwAA Archived-At: Cc: "ccamp-chairs@ietf.org" , "draft-ietf-ccamp-ospf-availability-extension@ietf.org" Subject: Re: [CCAMP] ID Tracker State Update Notice: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:46:40 -0000 VGhhbmtzIERlYm9yYWggZm9yIHRyaWdnZXJpbmcgdGhpcy4NCg0KQ0NBTVAsIFRFQVMsIA0KDQpp biBhZ3JlZW1lbnQgd2l0aCB0aGUgVEVBUyBjaGFpcnMgYW5kIERlYm9yYWggd2UgZGVjaWRlZCB0 byB3cml0ZSBhIG5ldyBkcmFmdCBpbiBURUFTIGRlZmluaW5nIGEgZ2VuZXJhbGl6ZWQgU0NTSSBv ZiB0aGUgSVNDRC4gVGhlIGdlbmVyYWxpemVkIFNDU0kgY2FuIGluY2x1ZGUgYSBudW1iZXIgb2Yg U0NTSSBzdWItVExWcy4NClRoZSBnZW5lcmFsaXplZCBTQ1NJIGNhbiBiZSB1c2VkIG9ubHkgd2l0 aCAibmV3IiBzd2l0Y2hpbmcgY2FwYWJpbGl0aWVzLiBRdW90aW5nIHRoZSBkcmFmdDogDQoNCiIg R2VuZXJhbGl6ZWQgU0NTSSBNVVNUIE5PVCBiZSB1c2VkIGZvciBJU0NEcyBvZiB0ZWNobm9sb2dp ZXMgd2hvc2UNCiAgIFN3aXRjaGluZyBDYXBhYmlsaXR5IGRlZmluaXRpb24gZG8gbm90IHJlZmVy ZW5jZSB0aGlzIGRvY3VtZW50LiINCg0KVGhlIGRyYWZ0IGFsc28gZGVmaW5lcyBhIG5ldyByZWdp c3RyeSB0aGUgIkdlbmVyYWxpemVkIFNDU0kgKFN3aXRjaGluZyBDYXBhYmlsaXR5IFNwZWNpZmlj IEluZm9ybWF0aW9uKSBUTFZzICBUeXBlcyIgcmVnaXN0cnkuDQoNClRoZSBpZGVhIGlzIHRvIHJl c2hhcGUgZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb25zIHRvIGRl ZmluZSB0aGUgSVNDRCBBdmFpbGFiaWxpdHkgc3ViLVRMViBhcyBvbmUgb2YgdGhlIHN1Yi1UTFZz IHN1cHBvcnRlZCBieSB0aGUgR2VuZXJhbGl6ZWQgU0NTSS4gKFZhbHVlIDEgb2YgdGhlIHJlZ2lz dHJ5IHNob3VsZCBiZSBhc3NpZ25lZCkuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQgdGhl IGZvbGxvd2luZyBsaW5rOiANCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jZWNj YXJlbGxpLXRlYXMtZ25lcmFsaXplZC1zY3NpLTAwIA0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIHRvIGJvdGggdGhlIG1haWxpbmcgbGlzdHMuDQoNClRoYW5rcw0KRGFuaWVsZQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJSVU5HQVJELCBERUJPUkFIIEEgW21h aWx0bzpkYjM1NDZAYXR0LmNvbV0NCj4gU2VudDogZ2lvdmVkw6wgMyBub3ZlbWJyZSAyMDE2IDE3 OjAyDQo+IFRvOiBjY2FtcEBpZXRmLm9yZw0KPiBDYzogZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2 YWlsYWJpbGl0eS1leHRlbnNpb25AaWV0Zi5vcmc7IGNjYW1wLQ0KPiBjaGFpcnNAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUkU6IElEIFRyYWNrZXIgU3RhdGUgVXBkYXRlIE5vdGljZTogPGRyYWZ0LWll dGYtY2NhbXAtb3NwZi0NCj4gYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wOC50eHQ+DQo+IA0KPiBI aSBDQ0FNUCwNCj4gDQo+IEFzIGEgcmVzdWx0IG9mIHRoZSBHZW4tQVRSIHJldmlldyBhbmQgaXNz dWVzIHJhaXNlZCwgSSByZW1vdmVkIHRoaXMNCj4gZG9jdW1lbnQgZnJvbSB0b2RheSdzIHRlbGVj aGF0LiBZb3VyIENoYWlycywgQXV0aG9ycywgYW5kIEkgZGVjaWRlZCB0aGUgYmVzdA0KPiBhcHBy b2FjaCB3b3VsZCBiZSBmb3IgbWUgdG8gcmV0dXJuIHRoaXMgZG9jdW1lbnQgdG8gdGhlIFdvcmtp bmcgR3JvdXAgdG8NCj4gZnVydGhlciBkaXNjdXNzIGhvdyB0byBwcm9ncmVzcy4NCj4gDQo+IEJl c3QgcmVnYXJkcyBhbmQgc2FmZSB0cmF2ZWxzIGZvciB0aG9zZSBnb2luZyB0byBTZW91bC0gRGVi b3JhaA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBJ RVRGIFNlY3JldGFyaWF0IFttYWlsdG86aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZ10N Cj4gPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgOTo1OCBBTQ0KPiA+IFRvOiB6 aGFuZ2ZhdGFpQGh1YXdlaS5jb207IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+ Ow0KPiBjY2FtcC0NCj4gPiBjaGFpcnNAaWV0Zi5vcmc7IEJSVU5HQVJELCBERUJPUkFIIEEgPGRi MzU0NkBhdHQuY29tPjsgZHJhZnQtaWV0Zi0NCj4gPiBjY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1l eHRlbnNpb25AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBJRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBO b3RpY2U6DQo+ID4gPGRyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktDQo+ID4gZXh0 ZW5zaW9uLTA4LnR4dD4NCj4gPg0KPiA+IElFU0cgc3RhdGUgY2hhbmdlZCB0byBBRCBpcyB3YXRj aGluZzo6UmV2aXNlZCBJLUQgTmVlZGVkIGZyb20gSUVTRw0KPiA+IEV2YWx1YXRpb24gSUQgVHJh Y2tlciBVUkw6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1jY2FtcC1vc3BmLQ0KPiA+IGF2YWlsYWJpbGl0eS1leHRlbnNpb24vDQoNCg== From nobody Thu Nov 3 11:49:33 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E79129570; Thu, 3 Nov 2016 11:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NGHk6Nc3ezoa; Thu, 3 Nov 2016 11:49:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208701293EB; Thu, 3 Nov 2016 11:49:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL71260; Thu, 03 Nov 2016 18:49:18 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 18:49:18 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 11:49:08 -0700 From: Leeyoung To: "Scharf, Michael (Nokia - DE)" , "Daniele Ceccarelli" , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaA Date: Thu, 3 Nov 2016 18:49:07 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.581B86AF.00D9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:49:28 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org;= TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ie= tf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_-- From nobody Thu Nov 3 12:16:54 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3A11296A5; Thu, 3 Nov 2016 12:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 B5eoBhYaRY2F; Thu, 3 Nov 2016 12:16:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DD1129617; Thu, 3 Nov 2016 12:16:40 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EF8C6B420E913; Thu, 3 Nov 2016 19:16:34 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3JGbLl015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 19:16:38 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3JGbg0007164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 20:16:37 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 20:16:37 +0100 From: "Scharf, Michael (Nokia - DE)" To: Leeyoung , Daniele Ceccarelli , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw///xlACAABFawIAAQmiAgAAWg9A= Date: Thu, 3 Nov 2016 19:16:36 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:16:46 -0000 --_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IsnR= 17;t the intention of defining „compute-only tunnels“ to create= state in the controller, but not to signal them? If the tunnel should be s= ignaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can= be encoded in YANG. Is there anything I miss here?

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Hi Mich= ael,

&n= bsp;

I think= I am with you on your point. If we use rpc, it is clear. On the other hand= , if we were to use “stateful compute-only” it seems that the s= ystem/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datas= tore is updated only when the path is signaled and resource is allocated. W= ould this give the system/controller additional burden to keep the “i= nterim” state?

&n= bsp;

Young

&n= bsp;

From: CCAMP [mail= to:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

&n= bsp;

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

&n= bsp;

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 =

BR
Daniele 

 =

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.=

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_-- From nobody Thu Nov 3 12:34:04 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36E3129675; Thu, 3 Nov 2016 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rH_jzhkaif0q; Thu, 3 Nov 2016 12:33:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AF51296C2; Thu, 3 Nov 2016 12:33:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL74804; Thu, 03 Nov 2016 19:33:47 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 19:33:46 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 12:33:39 -0700 From: Igor Bryskin To: "Scharf, Michael (Nokia - DE)" , Leeyoung , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoA== Date: Thu, 3 Nov 2016 19:33:38 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.581B911B.030E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:33:56 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.or= g); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_-- From nobody Thu Nov 3 12:42:09 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55A1296B7; Thu, 3 Nov 2016 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XZC02QuPPWLB; Thu, 3 Nov 2016 12:42:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27A51296F6; Thu, 3 Nov 2016 12:42:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL75453; Thu, 03 Nov 2016 19:41:58 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 19:41:58 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 12:41:48 -0700 From: Leeyoung To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAB+lgCAAATCAP//jJXQ Date: Thu, 3 Nov 2016 19:41:47 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.581B9307.016A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:42:04 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_-- From nobody Thu Nov 3 13:02:56 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4857129431; Thu, 3 Nov 2016 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sb47fUC09Y6j; Thu, 3 Nov 2016 13:02:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223801296F6; Thu, 3 Nov 2016 13:02:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZQ31552; Thu, 03 Nov 2016 20:02:33 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 20:02:32 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 13:02:21 -0700 From: Igor Bryskin To: Leeyoung , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kA= Date: Thu, 3 Nov 2016 20:02:20 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.581B97D9.02E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:02:41 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_-- From nobody Thu Nov 3 13:13:06 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835B129762; Thu, 3 Nov 2016 13:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WgB0rUaAecaB; Thu, 3 Nov 2016 13:12:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D7912973D; Thu, 3 Nov 2016 13:12:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZQ32363; Thu, 03 Nov 2016 20:12:25 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 20:12:24 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 13:12:14 -0700 From: Leeyoung To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAB+lgCAAATCAP//jJXQgAB7cAD//4r10A== Date: Thu, 3 Nov 2016 20:12:14 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.581B9A2A.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:12:38 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_-- From nobody Thu Nov 3 15:27:38 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7741129453; Thu, 3 Nov 2016 15:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cYNAR96yepYT; Thu, 3 Nov 2016 15:27:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A331E129975; Thu, 3 Nov 2016 15:27:32 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id F0FB410E0B51C; Thu, 3 Nov 2016 22:27:25 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3MRTVg010253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 22:27:30 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3MRTuK011396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 23:27:29 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.36]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 23:27:28 +0100 From: "Beller, Dieter (Nokia - DE)" To: Young Lee Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNiF1aOOcuqLRzEGcGyhR2xJLlw== Date: Thu, 3 Nov 2016 22:27:28 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:27:36 -0000 --_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say =93state=94, are you referring to the YANG datastore or some o= ther =93interim=94 state of those paths that are calculated but not instant= iated as LSPs? If we were to update the YANG datastore for this, I would th= ink that we may have some issue when the customer decided not to instantiat= e the TE tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as =93normal=94 (COMPUTE_ADN_PROVISION) TE tunnels= . Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the =93compute-only=94 TE tunnel is t= o create/maintain the normal TE tunnel state and (re-)compute TE paths for = the TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn=92t the intention of defining =84compute-only tunnels=93 to create stat= e in the controller, but not to signal them? If the tunnel should be signal= ed and resources shall be allocated, why not just configure a vanilla tunne= l? Uses cases seem to exist for both variants, and both can be encoded in Y= ANG. Is there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use =93stateful compute-only=94 it seems that the sy= stem/controller has to keep the state of the paths somewhere which is not Y= ANG datastore. My understanding is that YANG datastore is updated only when= the path is signaled and resource is allocated. Would this give the system= /controller additional burden to keep the =93interim=94 state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the =93stateful compute-only=94 stands for I do= n=92t understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don=92t u= nderstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer=92s perspective, the two= clean solutions to the problem seem to either stateful =84compute-only=93 = tunnels or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 
Hi all, =0A=
=0A=
when we talk about the stateful path computation use case, it means IMHO th=
at when a path has been calculated successfully in response to a request, a=
 new path object is created in the data store. This does only make sense if=
 the resources have been allocated in the TED of the PCE irrespective of th=
e fact whether the connection along this path will be established right awa=
y or at a later point in time. This will prevent further path computation r=
equests from assuming that the resources are still available. As the TED of=
 the PCE also has to reflect the network state, I would assume that the net=
work resources can be in one of the following three states: available, allo=
catedButNotInUse,  allocatedAndInUse. The path objects also need state info=
rmation reflecting for example the alarm state of the allocated resources. =
The path calculated earlier may become (temporarily) invalid due to a link =
failure affecting the path. =0A=
=0A=
Does this make sense? =0A=
=0A=
=0A=
Thanks, =0A=
Dieter=0A=
=0A=
Sent from my tablet=0A=
=0A=
Leeyoung <leeyoung@huawei.com> wrote:=0A=
=0A=

Igor,

 

When you say =93state= =94, are you referring to the YANG datastore or some other =93interim=94 st= ate of those paths that are calculated but not instantiated as LSPs? If we = were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor B= ryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as =93normal=94 (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor

 

From: Leeyou= ng
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor B= ryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the =93compute-only=94 TE tunnel is to create/maintain the = normal TE tunnel state and (re-)compute TE paths for the TE tunnel connecti= ons/LSPs but not signal/provision the LSPs.

 

Igor

 

From: Scharf= , Michael (Nokia - DE) [mailto:= michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn=92t the intention = of defining =84compute-only tunnels=93 to create state in the controller, b= ut not to signal them? If the tunnel should be signaled and resources shall= be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:l= eeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use =93stateful compute-only=94 it seems that the system/controller has to= keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the =93interim=94 state?

 

Young

 

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniel= e Ceccarelli [mailto:dan= iele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Ig= or Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the =93stateful compute-= only=94 stands for I don=92t understand what is stateful in a path computat= ion request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don=92t understand the value of asking for it and remembering= about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer=92s perspective, the two clean solutions to th= e problem seem to either stateful =84compute-only=93 tunnels or a stateless= RPC.

 

Michael

 

 

From: mpls [mailto:mpl= s-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6. = ;   YANG Model for requesting Path Computation

 

 

 &nbs= p; Work on extending the TE Tunnel YANG model to support the need to=

 &nbs= p; request path computation has recently started also in the context of

 &nbs= p; the [TE-TUNNEL] draft.

 

 &nbs= p; It is possible to request path computation by configuring a

 &nbs= p; "compute-only" TE tunnel and retrieving the computed path(s) i= n the

 &nbs= p; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

 &nbs= p; This is a stateful solution since the state of each created

 &nbs= p; "compute-only" TE tunnel needs to be maintained and updated, w= hen

 &nbs= p; underlying network conditions change.

 

 &nbs= p; The need also for a stateless solution, based on an RPC, has been=

 &nbs= p; recognized.

 

 

 &nbs= p; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_-- From nobody Thu Nov 3 15:51:17 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8351C1296F0; Thu, 3 Nov 2016 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2BJXsoOefljo; Thu, 3 Nov 2016 15:51:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC15B1296DE; Thu, 3 Nov 2016 15:51:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZQ46250; Thu, 03 Nov 2016 22:51:03 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 22:51:02 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 15:50:50 -0700 From: Leeyoung To: "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAB+lgCAAATCAP//jJXQgAB7cAD//4r10AATswsAAA5+WSA= Date: Thu, 3 Nov 2016 22:50:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581BBF58.0286, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bee9e4788904c3a2f3d547c3eaf515ee Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:51:11 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dieter, Thanks for your clear explanation on this issue. I have no problem with tha= t. However, my real concern of the Tunnel mode with "compute only" is the a= ssumption people are making. That is, The tunnel mode with "compute only" w= ill make sense to me only when the requests turn into instantiation of tunn= els (the paths are signaled and resource allocated in the network) immediat= ely following the request. But what assures that this always happens? If th= e path computation request would not turn into instantiation right away the= n the "resource allocated but not in use" would turn out to be wasteful. I still think the stateless RPC mechanism for path compute would make sense= s to the situations where the aforementioned assumption does not hold. What= do you think? Thanks. Young From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 5:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung > wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dieter,<= /span>

 

Thanks for your clear = explanation on this issue. I have no problem with that. However, my real co= ncern of the Tunnel mode with “compute only” is the assumption = people are making. That is, The tunnel mode with “compute only” will make sense to me only when the requests tu= rn into instantiation of tunnels (the paths are signaled and resource alloc= ated in the network) immediately following the request. But what assures th= at this always happens? If the path computation request would not turn into instantiation right away then the “resou= rce allocated but not in use” would turn out to be wasteful.

 

I still think the stat= eless RPC mechanism for path compute would make senses to the situations wh= ere the aforementioned assumption does not hold. What do you think?  <= o:p>

 

Thanks.

Young

 

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computati=
on use case, it means IMHO that when a path has been calculated successfull=
y in response to a request, a new path object is created in the data store.=
 This does only make sense if the resources have been allocated in the TED =
of the PCE irrespective of the fact whether the connection along this path =
will be established right away or at a later point in time. This will preve=
nt further path computation requests from assuming that the resources are s=
till available. As the TED of the PCE also has to reflect the network state=
, I would assume that the network resources can be in one of the following =
three states: available, allocatedButNotInUse,  allocatedAndInUse. The=
 path objects also need state information reflecting for example the alarm =
state of the allocated resources. The path calculated earlier may become (t=
emporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_-- From nobody Thu Nov 3 18:15:53 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BB12949C; Thu, 3 Nov 2016 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7jatPbAw4Gp7; Thu, 3 Nov 2016 18:15:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA221129408; Thu, 3 Nov 2016 18:15:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM00547; Fri, 04 Nov 2016 01:15:46 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 01:15:44 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.52]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 09:15:36 +0800 From: "Zhangxian (Xian)" To: Igor Bryskin , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 Thread-Index: AQHSNdRhXq9GHGb5y06beM5s18Fn46DIBX2g Date: Fri, 4 Nov 2016 01:15:35 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.139.68] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.581BE142.01E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9c988c89008e6ba1609782767c4130b8 Archived-At: Subject: Re: [CCAMP] [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:15:52 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIElnb3IsDQoNCiAgICAgIFRoYW5rIHlvdS4gQnV0IHlvdSBhcmUgZGlzYWdyZWVpbmcgd2l0 aCBhIG9sZCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQuIEF0IHRoYXQgdGltZSwgaXQgd2FzIGluZGVl ZCBubyBJRVRGIG1vZGVsIHByb3ZpZGluZyB0aGlzIGZ1bmN0aW9uYWxpdHksIDopLg0KDQpUaGUg bGF0ZXN0IHZlcnNpb24gKDAxKSB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgc3RhdGVzOg0KDQogICAg ICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQogICAgICAgICB8UGF0aCBDb21wLiAgIHwgUGF0aCBDb21wdXRhdGlv biBwcmUgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICB8ICAgICAgICAg ICAgIHwgc2VydmljZSBwcm92aXNpb25pbmcgIHwgICAgIGlldGYtdGUueWFuZyAgICAgICAgICB8 DQogICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgIEhvd2V2ZXIsICBUaGUgZHJhZnQgYWxzbyBub3Rl cyBvbmdvaW5nIG9ubGluZS9vZmZsaW5lIGRpc2N1c3Npb25zIGFzIGJlbG93Og0KobANCiAgRm9y IHBhdGggY29tcHV0YXRpb24sIFtJLUQuYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlv bl0NCiAgIHByZXNlbnRzIG5vdyBvbmx5IHVzZSBjYXNlcyBidXQgWUFORyBtb2RlbCB3b3JrIGlz IGFsc28gdW5kZXINCiAgIGNvbnNpZGVyYXRpb24gdG8gcHJvdmlkZSBzdGF0ZWxzcyBwYXRoIGNv bXB1dGF0aW9uIFJQQy4gIFRoZXJlIGlzDQogICBjdXJyZW50bHkgb25nb2luZyBkaXNjdXNzaW9u cyBvbiBob3cgdG8gcHJvdmlkZSBzdWNoIGEgZnVuY3Rpb24gdXNpbmcNCiAgIHRoZSBURSB0dW5u ZWwgbW9kZWwgZGVmaW5lZCBpbiBbSS1ELmlldGYtdGVhcy15YW5nLXRlXSBhcyBhIGJhc2UuDQqh sA0KDQpDaGVlcnMsDQpYaWFuDQoNCreivP7IyzogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBJZ29yIEJyeXNraW4NCreiy83KsbzkOiAyMDE2xOoxMdTCM8jVIDIxOjE1 DQrK1bz+yMs6IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKTsgcGNl QGlldGYub3JnOyBURUFTIFdHICh0ZWFzQGlldGYub3JnKTsgbXBsc0BpZXRmLm9yZw0K1vfM4jog W1RlYXNdIGRyYWZ0LXpoYW5nLWNjYW1wLXRyYW5zcG9ydC15YW5nLWdhcC1hbmFseXNpcy0wMQ0K DQpIaSwNCg0KSW4gdGhlIDQuNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctY2NhbXAtdHJhbnNwb3J0LXlhbmctZ2FwLWFuYWx5c2lzLTAwI3NlY3Rpb24tNC40Pi4gIEZ1 bmN0aW9uIFN1bW1hcnkgYW5kIFJlbGF0ZWQgWUFORyBNb2RlbHMsIEkgcmVhZDoNCg0KKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICAgICAgICB8UGF0aCBDb21wLiAgIHwgUGF0aCBDb21wdXRhdGlvbiBwcmUgIHwgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgIHwgICAgICAgICAgICAgfCBzZXJ2aWNlIHByb3Zp c2lvbmluZyAgfCAgICAgIE5PTkUgICAgICAgICAgICAgfA0KICAgICAgICAgKy0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCkkg ZGlzYWdyZWUgd2l0aCB0aGlzIGFzc2Vzc21lbnQuIFRFIHR1bm5lbCBtb2RlbCBkZWZpbmVzIHRo ZSBDT01QVVRFX09OTFkgbW9kZSBleHBsaWNpdGx5IGRlc2lnbmVkIHRvIGJlIHVzZWQgIHRvIHN1 cHBvcnQgUGF0aCBjb21wdXRhdGlvbiBOQkkuDQoNCkNoZWVycywNCklnb3INCg0KDQpGcm9tOiBQ Y2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbGUgQ2Vj Y2FyZWxsaQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDU6MTMgQU0NClRvOiBD Q0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9y ZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVh c0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVj dDogW1BjZV0gQ0NBTVAgYW5kIEpPSU5UIFlBTkcgc2Vzc2lvbiBhZ2VuZGEgQElFVEY5Nw0KDQpI aSBhbGwsDQoNCnRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBhZ2VuZGEgZm9yIHRoZSBDQ0FNUCBz ZXNzaW9uIGFuZCB0aGUgSm9pbnQgWUFORyBzZXNzaW9uIGlzIGF2YWlsYWJsZSBhdCB0aGUgZm9s bG93aW5nIGxpbmsuDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L2FnZW5k YS9hZ2VuZGEtOTctY2NhbXAtMDENCg0KUGxlYXNlIGxldCB1cyBoYXZlIHlvdXIgY29tbWVudHMN Cg0KVGhhbmtzDQpNUExTLCBQQ0UsIFRFQVMgYW5kIENDQU1QIChjaGFpcnMgYW5kIHNlY3JldGFy aWVzKQ0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Igor,

 

      Thank you. But you are disagreeing= with a old version of this draft. At that time, it was indeed no IETF mode= l providing this functionality, J.

 

The latest version (01) version of t= his draft states:

 

         +-----------= --+-----------------------+---------------------------+

         |Path Comp. = ;  | Path Computation pre  |      &= nbsp;           &nbs= p;        |

         |  &nb= sp;          | service provisi= oning  |     ietf-te.yang    &= nbsp;     |

         +-----------= --+-----------------------+---------------------------+

 

   However,  The draft also notes ongoing online/o= ffline discussions as below:

=A1=B0

  For path computation, [I-D.busibel-teas-yang-path-computat= ion]

   presents now only use cases but YANG model work is a= lso under

   consideration to provide statelss path computation R= PC.  There is

   currently ongoing discussions on how to provide such= a function using

   the TE tunnel model defined in [I-D.ietf-teas-yang-t= e] as a base.

=A1=B0

 

Cheers,

Xian

 

=B7=A2=BC=FE=C8=CB: Teas [mailto:teas-bou= nces@ietf.org] =B4=FA=B1=ED = Igor Bryskin
=B7=A2=CB=CD= =CA=B1=BC=E4: 2016=C4=EA11=D4=C2= 3=C8=D5 21:15
=CA=D5=BC=FE=C8=CB: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
=D6=F7=CC=E2: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01=

 

Hi,

&n= bsp;

In the = 4.4.  Function Summary and= Related YANG Models, I read:

 

+-------------+---------= --------------+-----------------------+

     &n= bsp;   |Path Comp.   | Path Computation pre  |&nbs= p;            &= nbsp;         |

     &n= bsp;   |         &nb= sp;   | service provisioning  |     = ; NONE           &nb= sp; |

     &n= bsp;   +-------------+-----------------------+-------= ----------------+

 

I di= sagree with this assessment. TE tunnel model defines the COMPUTE_ONLY mode = explicitly designed to be used  to support Path computation NBI.<= /o:p>

 

Chee= rs,

Igor=

&n= bsp;

&n= bsp;

From: Pce [mailto:p= ce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

 

Hi all,

 

the first version of the agenda= for the CCAMP session and the Joint YANG session is available at the follo= wing link.

 

https://www.ietf.org/proceedings= /97/agenda/agenda-97-ccamp-01

 

Please let us have your comment= s

 

Thanks

MPLS, PCE, TEAS and CCAMP (chai= rs and secretaries)

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_-- From nobody Thu Nov 3 21:36:18 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D973129785; Thu, 3 Nov 2016 21:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1IF3QVxWZAzh; Thu, 3 Nov 2016 21:36:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499C2129705; Thu, 3 Nov 2016 21:36:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM18041; Fri, 04 Nov 2016 04:36:04 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 04:36:02 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 10:05:53 +0530 From: Dhruv Dhody To: Leeyoung , "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcs+kr+YSyrQ0+M0PsTNtuTxqDG6QgAgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAAGhwCAALoV8A== Date: Fri, 4 Nov 2016 04:35:52 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C9C3331@blreml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> 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.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.581C1035.00B6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 04:36:12 -0000 --_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, As an implementer who would like to implement a simple path computation req= uest, the rpc is the way to go. Doing this via tunnel creation would require 3 operations. (1) POST to crea= te tunnel with "compute-only"; (2) GET to get the path; (3) DELETE tunnel. Which is an overkill to say the least. We can further debate the usefulness of Stateful compute-only mode separate= ly. Regards, Dhruv From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung Sent: 04 November 2016 04:21 To: Beller, Dieter (Nokia - DE) Cc: Igor Bryskin ; mpls@ietf.org; CCAMP (ccamp@iet= f.org) ; Scharf, Michael (Nokia - DE) ; TEAS WG (teas@ietf.org) ; pce@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Dieter, Thanks for your clear explanation on this issue. I have no problem with tha= t. However, my real concern of the Tunnel mode with "compute only" is the a= ssumption people are making. That is, The tunnel mode with "compute only" w= ill make sense to me only when the requests turn into instantiation of tunn= els (the paths are signaled and resource allocated in the network) immediat= ely following the request. But what assures that this always happens? If th= e path computation request would not turn into instantiation right away the= n the "resource allocated but not in use" would turn out to be wasteful. I still think the stateless RPC mechanism for path compute would make sense= s to the situations where the aforementioned assumption does not hold. What= do you think? Thanks. Young From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 5:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung > wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

As an implementer who would like to implement a simple= path computation request, the rpc is the way to go.

Doing this via tunnel creation would require 3 operati= ons. (1) POST to create tunnel with “compute-only”; (2) GET to = get the path; (3) DELETE tunnel.

Which is an overkill to say the least.

 

We can further debate the usefulness of Stateful compu= te-only mode separately.

 

Regards,

Dhruv

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 04 November 2016 04:21
To: Beller, Dieter (Nokia - DE) <dieter.beller@nokia.com>
Cc: Igor Bryskin <Igor.Bryskin@huawei.com>; mpls@ietf.org; CCA= MP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) &l= t;michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org&g= t;; pce@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Diet= er,

&n= bsp;

Thanks = for your clear explanation on this issue. I have no problem with that. Howe= ver, my real concern of the Tunnel mode with “compute only” is = the assumption people are making. That is, The tunnel mode with “compute only” will make sense to me only when the r= equests turn into instantiation of tunnels (the paths are signaled and reso= urce allocated in the network) immediately following the request. But what = assures that this always happens? If the path computation request would not turn into instantiation right away then the = “resource allocated but not in use” would turn out to be wastef= ul.

&n= bsp;

I still= think the stateless RPC mechanism for path compute would make senses to th= e situations where the aforementioned assumption does not hold. What do you= think?  

&n= bsp;

Thanks.=

Young

&n= bsp;

&n= bsp;

&n= bsp;

From: Be= ller, Dieter (Nokia - DE) [mailt= o:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi all, 
 
when we talk about the stateful path comput=
ation use case, it means IMHO that when a path has been calculated successf=
ully in response to a request, a new path object is created in the data sto=
re. This does only make sense if the resources have been allocated in the T=
ED of the PCE irrespective of the fact whether the connection along this pa=
th will be established right away or at a later point in time. This will pr=
event further path computation requests from assuming that the resources ar=
e still available. As the TED of the PCE also has to reflect the network st=
ate, I would assume that the network resources can be in one of the followi=
ng three states: available, allocatedButNotInUse,  allocatedAndInUse. =
The path objects also need state information reflecting for example the ala=
rm state of the allocated resources. The path calculated earlier may become=
 (temporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 

 


 


Thanks, 


Dieter


 


Sent from my tablet


 


Leeyoung <leeyoung@huawei.com> wrote:


 






Igor,


 <=
/span>


When yo=
u say “state”, are you referring to the YANG datastore or some =
other “interim” state of those paths that are calculated but no=
t instantiated as LSPs? If we were to update the YANG datastore
 for this, I would think that we may have some issue when the customer deci=
ded not to instantiate the TE tunnel (after the path compute request).



 <=
/span>


Thanks.=



Young


 <=
/span>


 <=
/span>






From: Ig=
or Bryskin


Sent: Thursday, November 03, 2016 3:02 PM

To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM=
P (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Young,<=
/span>


 <=
/span>


From th=
e provider controller point of view COMPUTE_ONLY TE tunnels will have exact=
ly the same state as “normal” (COMPUTE_ADN_PROVISION) TE tunnel=
s.


 <=
/span>


Igor


 <=
/span>






From: Le=
eyoung


Sent: Thursday, November 03, 2016 3:42 PM

To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; =
CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Igor,


 <=
/span>


In such=
 case, would the YANG datastore be updated? I guess not. If not, then the s=
ystem/controller has to keep this interim state, would it?



 <=
/span>


Thanks.=



Young


 <=
/span>






From: Ig=
or Bryskin


Sent: Thursday, November 03, 2016 2:34 PM

To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM=
P (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Michael=
,


You are=
 exactly right. The purpose of the “compute-only” TE tunnel is =
to create/maintain the normal TE tunnel state and (re-)compute TE paths for=
 the TE tunnel connections/LSPs but not signal/provision
 the LSPs.


 <=
/span>


Igor


 <=
/span>






From: Sc=
harf, Michael (Nokia - DE) [mai=
lto:michael.scharf@nokia.com]


Sent: Thursday, November 03, 2016 3:17 PM

To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


IsnR=
17;t the intention of defining „compute-only tunnels“ to create=
 state in the controller, but not to signal them? If the tunnel should be s=
ignaled and resources shall be allocated, why not just configure
 a vanilla tunnel? Uses cases seem to exist for both variants, and both can=
 be encoded in YANG. Is there anything I miss here?


 <=
/span>


Michael=



 <=
/span>


 <=
/span>








From: Leeyoung=
 [mailto:leeyoung@huawei.com]


Sent: Thursday, November 03, 2016 7:49 PM

To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; =
CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 =



Hi Mich=
ael,


 <=
/span>


I think=
 I am with you on your point. If we use rpc, it is clear. On the other hand=
, if we were to use “stateful compute-only” it seems that the s=
ystem/controller has to keep the state of the paths
 somewhere which is not YANG datastore. My understanding is that YANG datas=
tore is updated only when the path is signaled and resource is allocated. W=
ould this give the system/controller additional burden to keep the “i=
nterim” state?



 <=
/span>


Young


 <=
/span>






From: CC=
AMP [mailto:ccamp-bounces@ietf.or=
g]
On Behalf Of Scharf, Michael (Nokia - DE)

Sent: Thursday, November 03, 2016 8:58 AM

To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: Re: [CCAMP] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Maybe I=
 miss something, but to me, the domain controller either computes a path st=
ateless, which can be modeled in YANG in an RPC. Or the domain controller c=
omputes a path, stores state, and provides
 access to the result in the YANG datastore. In the latter case, whether re=
sources are allocated, or whether the NEs get actually provisioned, is an o=
rthogonal question.


 <=
/span>


As a si=
de note, I am not sure of I would call a domain controller or an NMS a PCE.=
 Path computation is only a subset of the functions of a domain controller.=



 <=
/span>


Michael=



 <=
/span>


 <=
/span>


 <=
/span>








From: Da=
niele Ceccarelli [mailto=
:daniele.ceccarelli@ericsson.com]


Sent: Thursday, November 03, 2016 2:49 PM

To: Scharf, Michael (Nokia - DE); Igor Bryskin; C=
CAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 =



Can you please explain what the=
 “stateful compute-only” stands for I don’t understand wh=
at is stateful in a path computation request only.



IMHO either I ask the PCE (SDN =
controller, NMS, whatever) to compute a path and then forget about it or I =
ask to compute and provision it. I don’t understand the value of aski=
ng for it and remembering about it.


 


BR

Daniele  


 








From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]


Sent: gioved=EC 3 novembre 2016 14:45

To: Igor Bryskin <Igor=
.Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP =
(ccamp@ietf.org)
 <ccamp@ietf.org>; 
pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>;
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
o:p>






 =



We have=
 discussed this before. From an implementer’s perspective, the two cl=
ean solutions to the problem seem to either stateful „compute-only=
220; tunnels or a stateless RPC.


 <=
/span>


Michael=



 <=
/span>


 <=
/span>








From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Igor Bryskin

Sent: Thursday, November 03, 2016 2:34 PM

To: Daniele Ceccarelli; CCAMP (cca=
mp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe=
l-teas-yang-path-computation-00<=
/span>






 =



Hi,


 <=
/span>


From th=
e draft:


 <=
/span>


6. =
   YANG Model for requesting Path Computation


 


 


  =
; Work on extending the TE Tunnel YANG model to support the need to<=
span lang=3D"EN-US">


  =
; request path computation has recently started also in the context of


  =
; the [TE-TUNNEL]
 draft.


 


  =
; It is possible to request path computation by configuring a


  =
; "compute-only" TE tunnel and retrieving the computed path(s) in=
 the


  =
; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].


 


  =
; This is a stateful solution since the state of each created


  =
; "compute-only" TE tunnel needs to be maintained and updated, wh=
en


  =
; underlying network conditions change.


 


  =
; The need also for a stateless solution, based on an RPC, has been<=
span lang=3D"EN-US">


  =
; recognized.


 


 


  =
; The YANG model to support stateless RPC is for further study.


 


 


 


 


 


IB>>
Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO=
RGET mode. We also consider the concept of path computation action to be de=
fined under the TE tunnel node. All this is to facilitate stateless path co=
mputations.


 


Cheers,


Igor


 <=
/span>
--_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_-- From nobody Thu Nov 3 22:55:01 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFE112948E; Thu, 3 Nov 2016 22:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fL7fqikBgpWS; Thu, 3 Nov 2016 22:54:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E2812940F; Thu, 3 Nov 2016 22:54:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM24723; Fri, 04 Nov 2016 05:54:49 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 05:54:48 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.3]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 13:54:42 +0800 From: "Yemin (Amy)" To: Daniele Ceccarelli , "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHSNdpEBzCW8YF0cUiB6IAIYbKiGKDG5XmAgAAMXQCAAV/cUA== Date: Fri, 4 Nov 2016 05:54:40 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CE2270E@szxema506-mbs.china.huawei.com> References: <147818146209.22755.6255303719663691627.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.581C22A9.00AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.3, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 88b41a7cfaa7b8db713827550086ba58 Archived-At: Cc: "ccamp-chairs@ietf.org" , "draft-ietf-ccamp-ospf-availability-extension@ietf.org" Subject: Re: [CCAMP] ID Tracker State Update Notice: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 05:54:56 -0000 SSBzdXBwb3J0IHRoZSBhcHByb2FjaCB0byBkZWZpbmUgYSBnZW5lcmFsaXplZCBTQ1NJLiANCldp dGggdGhlIGdlbmVyYWxpemVkIFNDU0kgLCBpZiBhIG5ldyBUTFYgY2FuIGJlIGFwcGxpZWQgdG8g bXVsdGlwbGUgdGVjaG5vbG9naWVzLCB0aGVyZSdzIG5vIG5lZWQgdG8gZGVmaW5lIHRoZSB0eXBl IHVuZGVyIGVhY2ggdGVjaG5vbG9naWVzIHNwZWNpZmljIFNDLiANCkFzc29jaWF0aW9uIHdpdGgg dGhpcyBnZW5lcmFsaXplZCBTQ1NJIHdpbGwgc2ltcGxpZnkgdGhlIHByb2Nlc3MuIA0KVGhpcyBj b3VsZCByZXNvbHZlIHRoZSBwcm9ibGVtIHRoYXQgU0NTSSBpbiBSRkM0MjAzIGRvZXNuJ3Qgc3Vw cG9ydCBUTFYgZm9ybWF0LiANCg0KQlIsDQpBbXkgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tXSANClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDQsIDIwMTYgMTI6NDcgQU0N ClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBOyBjY2FtcEBpZXRmLm9yZzsgVEVBUyBXRyAodGVhc0Bp ZXRmLm9yZykNCkNjOiBkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lv bkBpZXRmLm9yZzsgY2NhbXAtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogSUQgVHJhY2tl ciBTdGF0ZSBVcGRhdGUgTm90aWNlOiA8ZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJpbGl0 eS1leHRlbnNpb24tMDgudHh0Pg0KDQpUaGFua3MgRGVib3JhaCBmb3IgdHJpZ2dlcmluZyB0aGlz Lg0KDQpDQ0FNUCwgVEVBUywgDQoNCmluIGFncmVlbWVudCB3aXRoIHRoZSBURUFTIGNoYWlycyBh bmQgRGVib3JhaCB3ZSBkZWNpZGVkIHRvIHdyaXRlIGEgbmV3IGRyYWZ0IGluIFRFQVMgZGVmaW5p bmcgYSBnZW5lcmFsaXplZCBTQ1NJIG9mIHRoZSBJU0NELiBUaGUgZ2VuZXJhbGl6ZWQgU0NTSSBj YW4gaW5jbHVkZSBhIG51bWJlciBvZiBTQ1NJIHN1Yi1UTFZzLg0KVGhlIGdlbmVyYWxpemVkIFND U0kgY2FuIGJlIHVzZWQgb25seSB3aXRoICJuZXciIHN3aXRjaGluZyBjYXBhYmlsaXRpZXMuIFF1 b3RpbmcgdGhlIGRyYWZ0OiANCg0KIiBHZW5lcmFsaXplZCBTQ1NJIE1VU1QgTk9UIGJlIHVzZWQg Zm9yIElTQ0RzIG9mIHRlY2hub2xvZ2llcyB3aG9zZQ0KICAgU3dpdGNoaW5nIENhcGFiaWxpdHkg ZGVmaW5pdGlvbiBkbyBub3QgcmVmZXJlbmNlIHRoaXMgZG9jdW1lbnQuIg0KDQpUaGUgZHJhZnQg YWxzbyBkZWZpbmVzIGEgbmV3IHJlZ2lzdHJ5IHRoZSAiR2VuZXJhbGl6ZWQgU0NTSSAoU3dpdGNo aW5nIENhcGFiaWxpdHkgU3BlY2lmaWMgSW5mb3JtYXRpb24pIFRMVnMgIFR5cGVzIiByZWdpc3Ry eS4NCg0KVGhlIGlkZWEgaXMgdG8gcmVzaGFwZSBkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxh YmlsaXR5LWV4dGVuc2lvbnMgdG8gZGVmaW5lIHRoZSBJU0NEIEF2YWlsYWJpbGl0eSBzdWItVExW IGFzIG9uZSBvZiB0aGUgc3ViLVRMVnMgc3VwcG9ydGVkIGJ5IHRoZSBHZW5lcmFsaXplZCBTQ1NJ LiAoVmFsdWUgMSBvZiB0aGUgcmVnaXN0cnkgc2hvdWxkIGJlIGFzc2lnbmVkKS4NCg0KVGhlIGRy YWZ0IGNhbiBiZSBmb3VuZCBhdCB0aGUgZm9sbG93aW5nIGxpbms6IA0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNlY2NhcmVsbGktdGVhcy1nbmVyYWxpemVkLXNjc2ktMDAgDQoN ClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gYm90aCB0aGUgbWFpbGluZyBsaXN0cy4NCg0K VGhhbmtzDQpEYW5pZWxlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog QlJVTkdBUkQsIERFQk9SQUggQSBbbWFpbHRvOmRiMzU0NkBhdHQuY29tXQ0KPiBTZW50OiBnaW92 ZWTDrCAzIG5vdmVtYnJlIDIwMTYgMTc6MDINCj4gVG86IGNjYW1wQGlldGYub3JnDQo+IENjOiBk cmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbkBpZXRmLm9yZzsgY2Nh bXAtIA0KPiBjaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IElEIFRyYWNrZXIgU3RhdGUg VXBkYXRlIE5vdGljZTogPGRyYWZ0LWlldGYtY2NhbXAtb3NwZi0gDQo+IGF2YWlsYWJpbGl0eS1l eHRlbnNpb24tMDgudHh0Pg0KPiANCj4gSGkgQ0NBTVAsDQo+IA0KPiBBcyBhIHJlc3VsdCBvZiB0 aGUgR2VuLUFUUiByZXZpZXcgYW5kIGlzc3VlcyByYWlzZWQsIEkgcmVtb3ZlZCB0aGlzIA0KPiBk b2N1bWVudCBmcm9tIHRvZGF5J3MgdGVsZWNoYXQuIFlvdXIgQ2hhaXJzLCBBdXRob3JzLCBhbmQg SSBkZWNpZGVkIA0KPiB0aGUgYmVzdCBhcHByb2FjaCB3b3VsZCBiZSBmb3IgbWUgdG8gcmV0dXJu IHRoaXMgZG9jdW1lbnQgdG8gdGhlIA0KPiBXb3JraW5nIEdyb3VwIHRvIGZ1cnRoZXIgZGlzY3Vz cyBob3cgdG8gcHJvZ3Jlc3MuDQo+IA0KPiBCZXN0IHJlZ2FyZHMgYW5kIHNhZmUgdHJhdmVscyBm b3IgdGhvc2UgZ29pbmcgdG8gU2VvdWwtIERlYm9yYWgNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRvOmlldGYt c2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmddDQo+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVy IDAzLCAyMDE2IDk6NTggQU0NCj4gPiBUbzogemhhbmdmYXRhaUBodWF3ZWkuY29tOyBGYXRhaSBa aGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPjsNCj4gY2NhbXAtDQo+ID4gY2hhaXJzQGlldGYu b3JnOyBCUlVOR0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0LmNvbT47IGRyYWZ0LWlldGYtIA0K PiA+IGNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbkBpZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6IElEIFRyYWNrZXIgU3RhdGUgVXBkYXRlIE5vdGljZToNCj4gPiA8ZHJhZnQtaWV0Zi1jY2Ft cC1vc3BmLWF2YWlsYWJpbGl0eS0NCj4gPiBleHRlbnNpb24tMDgudHh0Pg0KPiA+DQo+ID4gSUVT RyBzdGF0ZSBjaGFuZ2VkIHRvIEFEIGlzIHdhdGNoaW5nOjpSZXZpc2VkIEktRCBOZWVkZWQgZnJv bSBJRVNHIA0KPiA+IEV2YWx1YXRpb24gSUQgVHJhY2tlciBVUkw6DQo+ID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLQ0KPiA+IGF2YWlsYWJp bGl0eS1leHRlbnNpb24vDQoNCg== From nobody Fri Nov 4 03:17:56 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971A1129B15; Fri, 4 Nov 2016 03:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 qUZxObjca8AJ; Fri, 4 Nov 2016 03:17:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37914129B2E; Fri, 4 Nov 2016 03:08:17 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-12-581c5e0f91c1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id DC.E9.07742.F0E5C185; Fri, 4 Nov 2016 11:08:15 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 11:07:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nKDxn8YyPk37oCoymAT5iPI/wnwiyEDtZ5GZjYrKetI=; b=c/29SyhidguG59hIvp0dyrdIHyW4kisoePkPVazUGHXXOzsbbPZ4Ozm2BBXltYSMyGz/Yz0J1+EIEesUJuc2kGd3Kp5Dg9hjAFkI9EUnrJrCumCnJO1vr4YfU/+Gd4deseZhCn6ewTLHJVG5GVnjipQ7uoCvKTm0v6yfTO6PL6Q= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1523.eurprd07.prod.outlook.com (10.165.248.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Fri, 4 Nov 2016 10:07:19 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0707.004; Fri, 4 Nov 2016 10:07:19 +0000 From: Francesco Lazzeri To: Dhruv Dhody , Leeyoung , "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAAJPQCAAATDAIAAAkeAgAAFvQCAAALEAIAAJckAgAAGhwCAAGBnAIAAWvUQ Date: Fri, 4 Nov 2016 10:07:19 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> <23CE718903A838468A8B325B80962F9B8C9C3331@blreml501-mbx> In-Reply-To: <23CE718903A838468A8B325B80962F9B8C9C3331@blreml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8538b668-deac-4b79-2168-08d4049a5cc3 x-microsoft-exchange-diagnostics: 1; AM4PR07MB1523; 7:w438ClX9jiQ3hGaQPDC6tQReasryCZIxMNc7B1Ldt8svjLyHYt2DLUTVarB8NXhFSH7LZIYly3HO2i/s8ogrYJHCbpzYwQk/OQHnMfquXVLt2v0+FDQZJ5xv+raoonTUoI1qTsziVtN7VGXz+xP+uJcvWzzpkh1r6SbtkeQiAmpinpdewSSwGwK6K+0+BpFQxq9LDZsqcQWl2XJBl2QFFd0RY3IR9uhc542FonlY42eqNBChSHnBrycK3DJi1GEsb0epOf41k9FSC9xBRyejztSwVYIUPeGD8/sQDtLmfqz2ASH6AgBEWsfRoNWnvwHQPxMcTsbdmbim49V3zX5fpQvGBXDFL0+mDYJ4v8+6CoI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1523; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1523; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(24454002)(377454003)(76104003)(53754006)(199003)(3280700002)(11100500001)(16236675004)(19580405001)(77096005)(220493001)(81166006)(7906003)(74316002)(15975445007)(3900700001)(19580395003)(4326007)(19617315012)(189998001)(76576001)(8676002)(87936001)(33656002)(97736004)(81156014)(19609705001)(7846002)(66066001)(122556002)(3660700001)(7736002)(5001770100001)(92566002)(76176999)(2950100002)(230783001)(7696004)(54356999)(5660300001)(68736007)(86362001)(19625215002)(5002640100001)(93886004)(9686002)(8936002)(101416001)(586003)(50986999)(2906002)(6116002)(10400500002)(102836003)(2900100001)(19300405004)(3846002)(105586002)(790700001)(106116001)(106356001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1523; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 10:07:19.1997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1523 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUhUURTGuW+ZeVpT13E7qCUOFqSpbdhrwYwyBmmRaBEx65UPFXWUGZNU QtGUHAnNVMy9GjVFxdJoQtEcBHNL0yAbFKUxSVzbyIUkZ94Y/vc73/2+w/ngMqS0n3ZgIhRx vFLBRclEltTjwNdBHttDnAL3VbfvZidLRig2+3kfxTZoRim2oMyPXf7gxuora2g2dXxEzKYv aSlfRn6vc46WazTLhHxMP0QEkEGWx0P5qIh4Xunlc8MyXFvlH9vym7xTOf+QSEG/dKQaWTCA D8FP/bRYjSwZKW5AsNz6lBKGLgTvDOXIOFD4AQk1WQZSeCkgYLhtnPhv61bnIuMyEWZhpbPY lLfBaQiKppdMA4k/ISh9NEqrEcNY42B4n2FlDNjga5A/0WQOpCJI1QqbKOwKA+0rphMl6/75 hXmxkaW4TQzNE15GtsB+UJWVa9IRtoM/PXWEkUlsD/rJckKoh0HTOmCuagvThjVa8HPwQlNk 9rjAYO0Gn4PGlUzaeBDgChKaNHpz+AyUtN+njAUAR8JyPwhyInwbzxcJrEWgnjsisBNkPzNQ wp6vIjBUppkL8FBdn24qaY0dYOxjJspBe4o23S1wDDTNpNBFpv5W0P14khJ0TxjJzxMJ7A5V T2ZIgT2gcE1HbdYrkLgW2ap41c3osAMHPXllxC2VKkbhqeDjXqL1T9bRvLpLi4ZnT+oQZpBs q2QxwDFQSnPxqoRoHQKGlNlIcoOdAqWSUC4hkVfGXFfejuJVOuTIUDJ7iXfN+FUpDuPi+Eie j+WVG68EY+GQgryTwkL2Xrji4lX/d9o7T3RqLrnYdajH53Jd4sBE0t2jXna6746DjWGd8s+5 x/y3xRUunZ3IO3zRImfRNXl1R+kk7qlyjxqdm3J+9aZzLI+YzeKaO1qmeldTdp73kfe+/eGU 09wuOk2zW/qsT2QsxHTrFV+U7GBZl/wSN5PvO1PuLKNU4dx+N1Kp4v4B83nYaWADAAA= Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:17:54 -0000 --_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What happens in case the requested controller or PCE cannot or doesn't want= to send an explicit ERO ? In that case the path key mechanism is foreseen; the controller returns a p= ath key identifier which can be used eventually to implement the requested = path. Here something must be stored inside the controller in order to understand = the path key and translate it to the relevant route as needed. I would stor= e the path and probably would keep also reserved the relevant resources, un= til eventual operation or expiration of the path key. This cannot be avoide= d. I am wondering whether this is a completely diffent case or should be harmo= nized with the case under discussion. Regards, Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 04 November, 2016 5:36 AM To: Leeyoung ; Beller, Dieter (Nokia - DE) Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; TEAS WG (teas@ietf.org) ; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Hi All, As an implementer who would like to implement a simple path computation req= uest, the rpc is the way to go. Doing this via tunnel creation would require 3 operations. (1) POST to crea= te tunnel with "compute-only"; (2) GET to get the path; (3) DELETE tunnel. Which is an overkill to say the least. We can further debate the usefulness of Stateful compute-only mode separate= ly. Regards, Dhruv From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung Sent: 04 November 2016 04:21 To: Beller, Dieter (Nokia - DE) > Cc: Igor Bryskin >;= mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia - = DE) >; TEAS WG (t= eas@ietf.org) >; = pce@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Dieter, Thanks for your clear explanation on this issue. I have no problem with tha= t. However, my real concern of the Tunnel mode with "compute only" is the a= ssumption people are making. That is, The tunnel mode with "compute only" w= ill make sense to me only when the requests turn into instantiation of tunn= els (the paths are signaled and resource allocated in the network) immediat= ely following the request. But what assures that this always happens? If th= e path computation request would not turn into instantiation right away the= n the "resource allocated but not in use" would turn out to be wasteful. I still think the stateless RPC mechanism for path compute would make sense= s to the situations where the aforementioned assumption does not hold. What= do you think? Thanks. Young From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 5:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung > wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What happens in case the requested controller or PCE= cannot or doesn’t want to send an explicit ERO ?

In that case the path key mechanism is foreseen; the= controller returns a path key identifier which can be used eventually to i= mplement the requested path.

Here something must be stored inside the controller = in order to understand the path key and translate it to the relevant route = as needed. I would store the path and probably would keep also reserved the= relevant resources, until eventual operation or expiration of the path key. This cannot be avoided.

I am wondering whether this is a completely diffent = case or should be harmonized with the case under discussion.

Regards,

Francesco

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Dhruv Dhody
Sent: 04 November, 2016 5:36 AM
To: Leeyoung <leeyoung@huawei.com>; Beller, Dieter (Nokia - DE= ) <dieter.beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@= ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Hi All,

 

As an implementer who would like to implem= ent a simple path computation request, the rpc is the way to go.

Doing this via tunnel creation would requi= re 3 operations. (1) POST to create tunnel with “compute-only”;= (2) GET to get the path; (3) DELETE tunnel.

Which is an overkill to say the least.

 

We can further debate the usefulness of St= ateful compute-only mode separately.

 

Regards,

Dhruv

 

From:<= /span> mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 04 November 2016 04:21
To: Beller, Dieter (Nokia - DE) <dieter.beller@nokia.com>
Cc: Igor Bryskin <Igor= .Bryskin@huawei.com>; mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

&nbs= p;

Hi Dieter,

 

Thanks for your clear explanation on this issue. I have no problem wit= h that. However, my real concern of the Tunnel mode with “compute onl= y” is the assumption people are making. That is, The tunnel mode with “compute only” will make sense to me = only when the requests turn into instantiation of tunnels (the paths are si= gnaled and resource allocated in the network) immediately following the req= uest. But what assures that this always happens? If the path computation request would not turn into instantiation right aw= ay then the “resource allocated but not in use” would turn out = to be wasteful.

 

I still think the stateless RPC mechanism for path compute would make = senses to the situations where the aforementioned assumption does not hold.= What do you think?  

 

Thanks.

Young

 

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

&nbs= p;

Hi all, 

 


when we talk about the stateful=
 path computation use case, it means IMHO that when a path has been calcula=
ted successfully in response to a request, a new path object is created in =
the data store. This does only make sense if the resources have been alloca=
ted in the TED of the PCE irrespective of the fact whether the connection a=
long this path will be established right away or at a later point in time. =
This will prevent further path computation requests from assuming that the =
resources are still available. As the TED of the PCE also has to reflect th=
e network state, I would assume that the network resources can be in one of=
 the following three states: available, allocatedButNotInUse,  allocat=
edAndInUse. The path objects also need state information reflecting for exa=
mple the alarm state of the allocated resources. The path calculated earlie=
r may become (temporarily) invalid due to a link failure affecting the path=
. 


 


Does this make sense? 


 


 


Thanks, 

Dieter


 


Sent from my tablet<=
/span>


 


Leeyoung <leeyoung@huawei.com> wrote:

 






Igor,


 


When you say “state”, are you referring to the YANG datast=
ore or some other “interim” state of those paths that are calcu=
lated but not instantiated as LSPs? If we were to update the
 YANG datastore for this, I would think that we may have some issue when th=
e customer decided not to instantiate the TE tunnel (after the path compute=
 request).



 


Thanks.


Young


 


 






From: Igor Bryskin


Sent: Thursday, November 03, 2016 3:02 PM

To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM=
P (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Young,


 


From the provider controller point of view COMPUTE_ONLY TE tunnels wil=
l have exactly the same state as “normal” (COMPUTE_ADN_PROVISIO=
N) TE tunnels.=



 


Igor


 






From: Leeyoung


Sent: Thursday, November 03, 2016 3:42 PM

To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; =
CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Igor,


 


In such case, would the YANG datastore be updated? I guess not. If not=
, then the system/controller has to keep this interim state, would it?



 


Thanks.


Young


 






From: Igor Bryskin


Sent: Thursday, November 03, 2016 2:34 PM

To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM=
P (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Michael,<=
/span>


You are exactly right. The purpose of the “compute-only” T=
E tunnel is to create/maintain the normal TE tunnel state and (re-)compute =
TE paths for the TE tunnel connections/LSPs but
 not signal/provision the LSPs.


 


Igor


 






From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]


Sent: Thursday, November 03, 2016 3:17 PM

To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Isn’t the intention of defining „compute-only tunnels̶=
0; to create state in the controller, but not to signal them? If the tunnel=
 should be signaled and resources shall be allocated,
 why not just configure a vanilla tunnel? Uses cases seem to exist for both=
 variants, and both can be encoded in YANG. Is there anything I miss here?<=
/span>


 


Michael


 


 








From: Leeyoung [mailto:leeyoung@huawei.com]


Sent: Thursday, November 03, 2016 7:49 PM

To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; =
CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Hi Michael,


 


I think I am with you on your point. If we use rpc, it is clear. On th=
e other hand, if we were to use “stateful compute-only” it seem=
s that the system/controller has to keep the state
 of the paths somewhere which is not YANG datastore. My understanding is th=
at YANG datastore is updated only when the path is signaled and resource is=
 allocated. Would this give the system/controller additional burden to keep=
 the “interim” state?



 


Young


 






From: CCAMP [mail=
to:ccamp-bounces@ietf.org]
On Behalf Of Scharf, Michael (Nokia - DE)

Sent: Thursday, November 03, 2016 8:58 AM

To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: Re: [CCAMP] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Maybe I miss something, but to me, the domain controller either comput=
es a path stateless, which can be modeled in YANG in an RPC. Or the domain =
controller computes a path, stores state,
 and provides access to the result in the YANG datastore. In the latter cas=
e, whether resources are allocated, or whether the NEs get actually provisi=
oned, is an orthogonal question.


 


As a side note, I am not sure of I would call a domain controller or a=
n NMS a PCE. Path computation is only a subset of the functions of a domain=
 controller.


 


Michael


 


 


 








From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]


Sent: Thursday, November 03, 2016 2:49 PM

To: Scharf, Michael (N=
okia - DE); Igor Bryskin; CCAMP (ccamp@ie=
tf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
/span>






 


Can you p=
lease explain what the “stateful compute-only” stands for I don=
’t understand what is stateful in a path computation request only.



IMHO eith=
er I ask the PCE (SDN controller, NMS, whatever) to compute a path and then=
 forget about it or I ask to compute and provision it. I don’t unders=
tand the value of asking for it and remembering
 about it.


 


BR

Daniele  


 








From:<=
/span> Scharf, Michael (Noki=
a - DE) [mailto:michael.scharf@=
nokia.com]


Sent: gioved=EC 3 novembre 2016 14:45

To: Igor Bryskin <Igor=
.Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP =
(ccamp@ietf.org)
 <ccamp@ietf.org>; 
pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>;
mpls@ietf.org

Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<=
o:p>






 


We have discussed this before. From an implementer’s perspective=
, the two clean solutions to the problem seem to either stateful „com=
pute-only“ tunnels or a stateless RPC.


 


Michael


 


 








From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Igor Bryskin

Sent: Thursday, November 03, 2016 2:34 PM

To: Daniele Ceccarelli; CCAMP (cca=
mp@ietf.org);
pce@ietf.org; TEAS WG (teas@ietf.org);
mpls@ietf.org

Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe=
l-teas-yang-path-computation-00






 


Hi,


 


From the draft:=



 


6.    YANG Model for requesting Path Comp=
utation


 


 


   Work on extending the TE Tunnel YANG model to =
support the need to<=
/o:p>


   request path computation has recently started =
also in the context of


   the [TE-TUN=
NEL]
 draft.=



 


   It is possible to request path computation by =
configuring a<=
/span>


   "compute-only" TE tunnel and retriev=
ing the computed path(s) in the


   LSP(s) Record-Route Object (RRO) list as descr=
ibed in [TE-TUNNEL].


 


   This is a stateful solution since the state of=
 each created<=
/span>


   "compute-only" TE tunnel needs to be=
 maintained and updated, when


   underlying network conditions change.


 


   The need also for a stateless solution, based =
on an RPC, has been<=
/o:p>


   recognized.


 


 


   The YANG model to support stateless RPC is for=
 further study.


 


 


 


 


 


IB>>
Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO=
RGET mode. We also consider the concept of path computation action to be de=
fined under the TE tunnel node. All this is to facilitate stateless path co=
mputations.


 


Cheers,


Igor


 
--_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_-- From nobody Fri Nov 4 06:07:28 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA1E12940C; Fri, 4 Nov 2016 06:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6kqWe-a0wqYI; Fri, 4 Nov 2016 06:07:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF811293DF; Fri, 4 Nov 2016 06:07:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZR58228; Fri, 04 Nov 2016 13:07:06 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 13:07:05 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 06:06:50 -0700 From: Igor Bryskin To: Leeyoung , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAnsUA Date: Fri, 4 Nov 2016 13:06:49 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F1C9@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581C87FB.0211, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:07:14 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Young, If the client does not want to keep a COMPUTE_ONLY TE tunnel state it can a= lways delete the state. Besides it will be possible to configure TE tunnel = in COMPUTE_AND_FORGET mode, in which the provider will automatically remove= the state as soon as it delivers the tunnel path computation results to th= e client. Furthermore, YANG global/action RPC makes sense when the path computation r= esults could be returned synchronously. If this is not possible or cannot b= e guaranteed for whatever reason (e.g. path computation takes some time, ne= eds to be requested from remote controller or PCE, etc.) RPC will also work= , but this will not be much different from configuring a TE tunnel in COMPU= TE_AND_FORGET mode, because the results will have to be delivered asynchron= ously using the regular client subscription (for the TE tunnel) notificati= on. Igor From: Leeyoung Sent: Thursday, November 03, 2016 4:12 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

If the client does not= want to keep a COMPUTE_ONLY TE tunnel state it can always delete the state= . Besides it will be possible to configure TE tunnel in COMPUTE_AND_FORGET = mode, in which the provider will automatically remove the state as soon as it delivers the tunnel path computation result= s to the client.

Furthermore, YANG glob= al/action RPC makes sense when the path computation results could be return= ed synchronously. If this is not possible or cannot be guaranteed for w= hatever reason (e.g. path computation takes some time, needs to be requeste= d from remote controller or PCE, etc.) RPC will also work, but this will no= t be much different from configuring a TE tunnel in COMPUTE_AND_FORGET mode, because the results will have to b= e delivered asynchronously using the regular client subscription (for the T= E tunnel)  notification.

 

 

Igor=

 

 

From: Leeyoung
Sent: Thursday, November 03, 2016 4:12 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_-- From nobody Fri Nov 4 06:25:59 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFBF129470; Fri, 4 Nov 2016 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sOpHIkngV-Bm; Fri, 4 Nov 2016 06:25:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7EF1294F2; Fri, 4 Nov 2016 06:25:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM96569; Fri, 04 Nov 2016 13:25:45 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 13:25:43 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 06:25:30 -0700 From: Igor Bryskin To: "Beller, Dieter (Nokia - DE)" , Leeyoung Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujA= Date: Fri, 4 Nov 2016 13:25:30 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.581C8C59.02FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:25:55 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dieter,<= /span>

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.<= /o:p>

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computati=
on use case, it means IMHO that when a path has been calculated successfull=
y in response to a request, a new path object is created in the data store.=
 This does only make sense if the resources have been allocated in the TED =
of the PCE irrespective of the fact whether the connection along this path =
will be established right away or at a later point in time. This will preve=
nt further path computation requests from assuming that the resources are s=
till available. As the TED of the PCE also has to reflect the network state=
, I would assume that the network resources can be in one of the following =
three states: available, allocatedButNotInUse,  allocatedAndInUse. The=
 path objects also need state information reflecting for example the alarm =
state of the allocated resources. The path calculated earlier may become (t=
emporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_-- From nobody Fri Nov 4 10:49:02 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6819129497; Fri, 4 Nov 2016 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LBMlyD574GGf; Fri, 4 Nov 2016 10:48:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1394B129446; Fri, 4 Nov 2016 10:48:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 4DB2F131423F8; Fri, 4 Nov 2016 17:48:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA4HmXYI011290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Nov 2016 17:48:34 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA4HmXNX013436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Nov 2016 18:48:33 +0100 Received: from [149.204.106.204] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 4 Nov 2016 18:48:33 +0100 To: Igor Bryskin References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> From: Dieter Beller Organization: Nokia Message-ID: <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> Date: Fri, 4 Nov 2016 18:48:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 X-Originating-IP: [135.239.27.38] Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:48:41 -0000 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD13aW5kb3dzLTEyNTIiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAg IEhpIElnb3IsPGJyPg0KICAgIDxicj4NCiAgICBjb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkg aG93IHVzZWZ1bCBhIHN0YXRlZnVsIHBhdGggPGI+d2l0aG91dA0KICAgICAgcmVzb3VyY2Ug YWxsb2NhdGlvbjwvYj4gaXMuIEkgY2FuJ3Qgc2VlIHRoZSBiZW5lZml0cyBvZiB0aGlzIHVz ZQ0KICAgIGNhc2UuPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgVGhhbmtzLDxicj4N CiAgICBEaWV0ZXI8YnI+DQogICAgPGJyPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+T24gMDQuMTEuMjAxNiAxNDoyNSwgSWdvciBCcnlza2luDQogICAgICB3cm90ZTo8 YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUNCiAgICAgIGNpdGU9Im1pZDowQzcy QzM4RTdFQkMzNDQ5OUU4QTlFN0REMDA3ODYzOTA4RjBGMUUxQGRmd2VtbDUwMS1tYngiDQog ICAgICB0eXBlPSJjaXRlIj4NCiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw ZSIgY29udGVudD0idGV4dC9odG1sOw0KICAgICAgICBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+ DQogICAgICA8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3Jk IDEyIChmaWx0ZXJlZA0KICAgICAgICBtZWRpdW0pIj4NCiAgICAgIDxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYW1icmlhOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFk aW5nIDIgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUt bGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCglj b2xvcjojNEY4MUJEOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsMDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5iZXJzY2hy aWZ0MiwgbGkuYmVyc2NocmlmdDIsIGRpdi5iZXJzY2hyaWZ0Mg0KCXttc28tc3R5bGUtbmFt ZTpiZXJzY2hyaWZ0MjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0KcC5odG1sdm9yZm9ybWF0aWVydCwgbGkuaHRtbHZvcmZvcm1hdGllcnQsIGRpdi5o dG1sdm9yZm9ybWF0aWVydA0KCXttc28tc3R5bGUtbmFtZTpodG1sdm9yZm9ybWF0aWVydDsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5zcHJlY2hi bGFzZW50ZXh0LCBsaS5zcHJlY2hibGFzZW50ZXh0LCBkaXYuc3ByZWNoYmxhc2VudGV4dA0K CXttc28tc3R5bGUtbmFtZTpzcHJlY2hibGFzZW50ZXh0Ow0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb2NocGRlZmF1bHQsIGxpLm1zb2NocGRl ZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOm1zb2NocGRlZmF1 bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uaGVhZGluZzJjaGFyMA0KCXttc28tc3R5bGUtbmFtZTpoZWFkaW5nMmNoYXI7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4u aHRtbHByZWZvcm1hdHRlZGNoYXIwDQoJe21zby1zdHlsZS1uYW1lOmh0bWxwcmVmb3JtYXR0 ZWRjaGFyOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5iYWxsb29udGV4 dGNoYXIwDQoJe21zby1zdHlsZS1uYW1lOmJhbGxvb250ZXh0Y2hhcjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5iZXJzY2hyaWZ0MnpjaG4NCgl7bXNv LXN0eWxlLW5hbWU6YmVyc2NocmlmdDJ6Y2huOw0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwi c2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLmh0 bWx2b3Jmb3JtYXRpZXJ0emNobg0KCXttc28tc3R5bGUtbmFtZTpodG1sdm9yZm9ybWF0aWVy dHpjaG47DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5zcHJlY2hibGFzZW50ZXh0 emNobg0KCXttc28tc3R5bGUtbmFtZTpzcHJlY2hibGFzZW50ZXh0emNobjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjkNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTI5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmVtYWlsc3R5bGUzMA0KCXtt c28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMzA7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTMyDQoJe21z by1zdHlsZS1uYW1lOmVtYWlsc3R5bGUzMjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMzMNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTMzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmVtYWlsc3R5bGUzNA0KCXtt c28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMzQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTM1DQoJe21z by1zdHlsZS1uYW1lOmVtYWlsc3R5bGUzNTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMzYNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTM2Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGUzNw0KCXttc28t c3R5bGUtbmFtZTplbWFpbHN0eWxlMzc7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTM4DQoJe21zby1z dHlsZS1uYW1lOmVtYWlsc3R5bGUzODsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMzkNCgl7bXNvLXN0 eWxlLW5hbWU6ZW1haWxzdHlsZTM5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGU0MA0KCXttc28tc3R5 bGUtbmFtZTplbWFpbHN0eWxlNDA7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTQ0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQogICAgICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KICAgICAgICA8 ZGl2Pg0KICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAgIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAgICAgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQogICAgICAgICAgICAgICAgPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0KICAgICAgICAgICAgICAg ICAgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQogICAgICAgICAgICAgICAg ICA8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAg ICAgICAgICAgICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SGkNCiAgICAgICAgICAgICAgICAgICAgICAgIERpZXRlciw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPqA8L286cD48L3NwYW4+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+QQ0KICAgICAgICAgICAgICAgICAgICAgICAgcHJvdmlkZXIg bWF5IGNvbXB1dGUgcGF0aChzKSBmb3IgYSBURSB0dW5uZWwsDQogICAgICAgICAgICAgICAg ICAgICAgICBhbmQgdGhlbiAod2l0aG91dCBhbnkgcmVzb3VyY2UgYWxsb2NhdGlvbikgbWF5 DQogICAgICAgICAgICAgICAgICAgICAgICBzdGFydCBtb25pdG9yaW5nL2Vuc3VyaW5nIHRo ZSBwYXRoDQogICAgICAgICAgICAgICAgICAgICAgICB2YWxpZGl0eS9vcHRpbWFsaXR5IGJ5 IHJlLWNvbXB1dGluZyB0aGVtIGluIGFuDQogICAgICAgICAgICAgICAgICAgICAgICBldmVu dCBkcml2ZW4gbWFubmVyLiBGb3IgZXhhbXBsZSwgaXQgY2FuIHRyaWdnZXINCiAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSByZS1jb21wdXRhdGlvbiBvZiB0aGUgcGF0aChzKSB3aGVu IGRldGVjdGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgYSBjaGFuZ2UgaW4gYSBzdGF0 ZSBvZiBhIFRFIGxpbmsgdGhlIGN1cnJlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgIHBh dGgocykgYXJlIGdvaW5nIHRocm91Z2guoCBEZXBlbmRpbmcgb24gdGhlDQogICAgICAgICAg ICAgICAgICAgICAgICByZXN1bHRzIGFkZGl0aW9uYWwgbm90aWZpY2F0aW9ucyBtYXkgYmUg c2VudCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNsaWVudC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPqA8L286cD48L3NwYW4+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Tm90ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB0aGlz IGlzIGluIGFkZGl0aW9uIHRvIHRoZSByZWFzb25zIHlvdQ0KICAgICAgICAgICAgICAgICAg ICAgICAgY29ycmVjdGx5IGlkZW50aWZpZWQgZm9yIGltcGxlbWVudGluZyBzdGF0ZWZ1bA0K ICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCBjb21wdXRhdGlvbiAoc3VjaCBhcyBjb21w dXRlX2FuZF9yZXNlcnZlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPqA8L286cD48L3NwYW4+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklnb3I8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPqA8L286cD48L3NwYW4+PC9wPg0KICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD6gPC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAg ICAgICAgICAgICAgICAgICAgICAgIEJlbGxlciwgRGlldGVyIChOb2tpYSAtIERFKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQi IGhyZWY9Im1haWx0bzpkaWV0ZXIuYmVsbGVyQG5va2lhLmNvbSI+bWFpbHRvOmRpZXRlci5i ZWxsZXJAbm9raWEuY29tPC9hPl0NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIg MDMsIDIwMTYgNjoyNyBQTTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiPlRvOjwv Yj4gTGVleW91bmc8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5DYzo8L2I+IEln b3IgQnJ5c2tpbjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYQ0KICAgICAgICAgICAgICAgICAg ICAgICAgLSBERSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVANCiAgICAgICAgICAgICAg ICAgICAgICAgICg8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt YWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPik7IDxhIGNsYXNzPSJt b3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBj ZUBpZXRmLm9yZzwvYT47IFRFQVMgV0cNCiAgICAgICAgICAgICAgICAgICAgICAgICg8YSBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dGVhc0BpZXRm Lm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJl dmlhdGVkIiBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxz XQ0KICAgICAgICAgICAgICAgICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10 ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+oDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgYWxsLCA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD6gPC9vOnA+PC9zcGFuPjwv cHJlPg0KICAgICAgICAgICAgICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj53aGVuIHdlIHRhbGsgYWJvdXQgdGhlIHN0YXRlZnVsIHBh dGggY29tcHV0YXRpb24gdXNlIGNhc2UsIGl0IG1lYW5zIElNSE8gdGhhdCB3aGVuIGEgcGF0 aCBoYXMgYmVlbiBjYWxjdWxhdGVkIHN1Y2Nlc3NmdWxseSBpbiByZXNwb25zZSB0byBhIHJl cXVlc3QsIGEgbmV3IHBhdGggb2JqZWN0IGlzIGNyZWF0ZWQgaW4gdGhlIGRhdGEgc3RvcmUu IFRoaXMgZG9lcyBvbmx5IG1ha2Ugc2Vuc2UgaWYgdGhlIHJlc291cmNlcyBoYXZlIGJlZW4g YWxsb2NhdGVkIGluIHRoZSBURUQgb2YgdGhlIFBDRSBpcnJlc3BlY3RpdmUgb2YgdGhlIGZh Y3Qgd2hldGhlciB0aGUgY29ubmVjdGlvbiBhbG9uZyB0aGlzIHBhdGggd2lsbCBiZSBlc3Rh Ymxpc2hlZCByaWdodCBhd2F5IG9yIGF0IGEgbGF0ZXIgcG9pbnQgaW4gdGltZS4gVGhpcyB3 aWxsIHByZXZlbnQgZnVydGhlciBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3RzIGZyb20gYXNz dW1pbmcgdGhhdCB0aGUgcmVzb3VyY2VzIGFyZSBzdGlsbCBhdmFpbGFibGUuIEFzIHRoZSBU RUQgb2YgdGhlIFBDRSBhbHNvIGhhcyB0byByZWZsZWN0IHRoZSBuZXR3b3JrIHN0YXRlLCBJ IHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBuZXR3b3JrIHJlc291cmNlcyBjYW4gYmUgaW4gb25l IG9mIHRoZSBmb2xsb3dpbmcgdGhyZWUgc3RhdGVzOiBhdmFpbGFibGUsIGFsbG9jYXRlZEJ1 dE5vdEluVXNlLKAgYWxsb2NhdGVkQW5kSW5Vc2UuIFRoZSBwYXRoIG9iamVjdHMgYWxzbyBu ZWVkIHN0YXRlIGluZm9ybWF0aW9uIHJlZmxlY3RpbmcgZm9yIGV4YW1wbGUgdGhlIGFsYXJt IHN0YXRlIG9mIHRoZSBhbGxvY2F0ZWQgcmVzb3VyY2VzLiBUaGUgcGF0aCBjYWxjdWxhdGVk IGVhcmxpZXIgbWF5IGJlY29tZSAodGVtcG9yYXJpbHkpIGludmFsaWQgZHVlIHRvIGEgbGlu ayBmYWlsdXJlIGFmZmVjdGluZyB0aGUgcGF0aC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQogICAgICAgICAgICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+oDwvbzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAg ICAgICAgICAgPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KICAg ICAgICAgICAgICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPqA8L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgICAg ICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+oDwvbzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLCA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGlldGVyPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQogICAgICAgICAgICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+oDwvbzpwPjwvc3Bhbj48L3ByZT4NCiAg ICAgICAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+U2VudCBmcm9tIG15IHRhYmxldDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KICAgICAgICAgICAgICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPqA8L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAg ICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkxlZXlvdW5nIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1h aWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIj4mbHQ7bGVleW91bmdAaHVhd2VpLmNvbSZndDs8 L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KICAgICAgICAgICAgICAgICAg ICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PqA8L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZ29yLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5XaGVuDQogICAgICAgICAgICAgICAgICAgICAgICB5b3Ugc2F5IJNz dGF0ZZQsIGFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoZSBZQU5HDQogICAgICAgICAgICAgICAg ICAgICAgICBkYXRhc3RvcmUgb3Igc29tZSBvdGhlciCTaW50ZXJpbZQgc3RhdGUgb2YgdGhv c2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHBhdGhzIHRoYXQgYXJlIGNhbGN1bGF0ZWQg YnV0IG5vdCBpbnN0YW50aWF0ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgIGFzIExTUHM/ IElmIHdlIHdlcmUgdG8gdXBkYXRlIHRoZSBZQU5HIGRhdGFzdG9yZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgZm9yIHRoaXMsIEkgd291bGQgdGhpbmsgdGhhdCB3ZSBtYXkgaGF2ZSBz b21lDQogICAgICAgICAgICAgICAgICAgICAgICBpc3N1ZSB3aGVuIHRoZSBjdXN0b21lciBk ZWNpZGVkIG5vdCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgaW5zdGFudGlhdGUgdGhl IFRFIHR1bm5lbCAoYWZ0ZXIgdGhlIHBhdGgNCiAgICAgICAgICAgICAgICAgICAgICAgIGNv bXB1dGUgcmVxdWVzdCkuDQogICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoYW5rcy48L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5Zb3VuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+ PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0K c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KICAgICAgICAgICAgICAgICAgICAgICAgSWdvciBCcnlz a2luDQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6MDIgUE08 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IExlZXlvdW5nOyBTY2hh cmYsIE1pY2hhZWwgKE5va2lhIC0NCiAgICAgICAgICAgICAgICAgICAgICAgIERFKTsgRGFu aWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZp YXRlZCIgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4p Ow0KICAgICAgICAgICAgICAgICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjsg VEVBUyBXRyAoPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFp bHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAg ICAgICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDxiPlN1YmplY3Q6PC9iPiBSRToNCiAgICAgICAgICAgICAgICAgICAg ICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRp b24tMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15 YW5nLXBhdGgtY29tcHV0YXRpb24tMDA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48L3A+ DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5Zb3VuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RnJvbQ0K ICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHByb3ZpZGVyIGNvbnRyb2xsZXIgcG9pbnQg b2Ygdmlldw0KICAgICAgICAgICAgICAgICAgICAgICAgQ09NUFVURV9PTkxZIFRFIHR1bm5l bHMgd2lsbCBoYXZlIGV4YWN0bHkgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICBzYW1l IHN0YXRlIGFzIJNub3JtYWyUIChDT01QVVRFX0FETl9QUk9WSVNJT04pDQogICAgICAgICAg ICAgICAgICAgICAgICBURSB0dW5uZWxzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZ29y PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4N CnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIExl ZXlvdW5nDQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6NDIg UE08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IElnb3IgQnJ5c2tp bjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYQ0KICAgICAgICAgICAgICAgICAgICAgICAgLSBE RSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKDxhDQogICAgICAgICAgICAgICAgICAg ICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pOw0K ICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VA aWV0Zi5vcmc8L2E+Ow0KICAgICAgICAgICAgICAgICAgICAgICAgVEVBUyBXRyAoPGEgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJt YWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAg ICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwv YT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUkU6IDxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAiPmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29t cHV0YXRpb24tMDA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48L3A+DQogICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JZ29yLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3Nw YW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Jbg0KICAgICAgICAgICAgICAg ICAgICAgICAgc3VjaCBjYXNlLCB3b3VsZCB0aGUgWUFORyBkYXRhc3RvcmUgYmUgdXBkYXRl ZD8NCiAgICAgICAgICAgICAgICAgICAgICAgIEkgZ3Vlc3Mgbm90LiBJZiBub3QsIHRoZW4g dGhlIHN5c3RlbS9jb250cm9sbGVyDQogICAgICAgICAgICAgICAgICAgICAgICBoYXMgdG8g a2VlcCB0aGlzIGludGVyaW0gc3RhdGUsIHdvdWxkIGl0Pw0KICAgICAgICAgICAgICAgICAg ICAgIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86 cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+WW91bmc8L3NwYW4+PG86cD48L286cD48L3A+DQogICAg ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgSWdvciBCcnlza2luDQogICAgICAgICAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDI6MzQgUE08YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICA8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7DQogICAg ICAgICAgICAgICAgICAgICAgICBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FN UCAoPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5v cmciPmNjYW1wQGlldGYub3JnPC9hPik7DQogICAgICAgICAgICAgICAgICAgICAgICA8YSBt b3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvYT47DQogICAgICAgICAgICAg ICAgICAgICAgICBURUFTIFdHICg8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAg ICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGll dGYub3JnPC9hPik7DQogICAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNl bmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptcGxz QGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxiPlN1YmplY3Q6PC9iPiBSRTogPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmct cGF0aC1jb21wdXRhdGlvbi0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMDwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPqA8 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1pY2hhZWwsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91DQogICAgICAgICAgICAgICAgICAgICAgICBh cmUgZXhhY3RseSByaWdodC4gVGhlIHB1cnBvc2Ugb2YgdGhlDQogICAgICAgICAgICAgICAg ICAgICAgICCTY29tcHV0ZS1vbmx5lCBURSB0dW5uZWwgaXMgdG8gY3JlYXRlL21haW50YWlu DQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgbm9ybWFsIFRFIHR1bm5lbCBzdGF0ZSBh bmQgKHJlLSljb21wdXRlIFRFDQogICAgICAgICAgICAgICAgICAgICAgICBwYXRocyBmb3Ig dGhlIFRFIHR1bm5lbCBjb25uZWN0aW9ucy9MU1BzIGJ1dCBub3QNCiAgICAgICAgICAgICAg ICAgICAgICAgIHNpZ25hbC9wcm92aXNpb24gdGhlIExTUHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPklnb3I8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSBbPGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tIj5tYWls dG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9hPl0NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTm92ZW1iZXIgMDMsIDIwMTYgMzoxNyBQTTxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxiPlRvOjwvYj4gTGVleW91bmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgSWdvcg0KICAg ICAgICAgICAgICAgICAgICAgICAgQnJ5c2tpbjsgQ0NBTVAgKDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmNjYW1w QGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAgICAgICAgICAg ICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+Ow0KICAgICAg ICAgICAgICAgICAgICAgICAgVEVBUyBXRyAoPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0K ICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+ dGVhc0BpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUkU6IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSINCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVh cy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDA8L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj6gPG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Jc26SdA0KICAgICAgICAg ICAgICAgICAgICAgICAgdGhlIGludGVudGlvbiBvZiBkZWZpbmluZyCEY29tcHV0ZS1vbmx5 IHR1bm5lbHOTDQogICAgICAgICAgICAgICAgICAgICAgICB0byBjcmVhdGUgc3RhdGUgaW4g dGhlIGNvbnRyb2xsZXIsIGJ1dCBub3QgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgIHNp Z25hbCB0aGVtPyBJZiB0aGUgdHVubmVsIHNob3VsZCBiZSBzaWduYWxlZA0KICAgICAgICAg ICAgICAgICAgICAgICAgYW5kIHJlc291cmNlcyBzaGFsbCBiZSBhbGxvY2F0ZWQsIHdoeSBu b3QganVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJlIGEgdmFuaWxsYSB0 dW5uZWw/IFVzZXMgY2FzZXMgc2VlbSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgZXhp c3QgZm9yIGJvdGggdmFyaWFudHMsIGFuZCBib3RoIGNhbiBiZSBlbmNvZGVkDQogICAgICAg ICAgICAgICAgICAgICAgICBpbiBZQU5HLiBJcyB0aGVyZSBhbnl0aGluZyBJIG1pc3MgaGVy ZT88L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiDQog ICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkRFIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ig0KICAgICAgICAgICAgICAgICAgICAgICAg bGFuZz0iREUiPiBMZWV5b3VuZyBbPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbSI+ bWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb208L2E+XQ0KICAgICAgICAgICAgICAgICAgICAg ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBOb3ZlbWJlciAwMywgMjAxNiA3OjQ5IFBNPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyBEYW5pZWxlDQog ICAgICAgICAgICAgICAgICAgICAgICBDZWNjYXJlbGxpOyBJZ29yIEJyeXNraW47IENDQU1Q ICg8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi DQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9y ZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i bWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjsNCiAgICAgICAgICAgICAg ICAgICAgICAgIFRFQVMgV0cgKDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0 Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgPGI+U3ViamVjdDo8L2I+IFJFOiA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1w YXRoLWNvbXB1dGF0aW9uLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i dXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iREUiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I aQ0KICAgICAgICAgICAgICAgICAgICAgICAgTWljaGFlbCw8L3NwYW4+PG86cD48L286cD48 L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SQ0KICAgICAgICAgICAgICAgICAgICAgICAgdGhpbmsgSSBhbSB3aXRoIHlvdSBv biB5b3VyIHBvaW50LiBJZiB3ZSB1c2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHJwYywg aXQgaXMgY2xlYXIuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSB3ZXJlDQogICAgICAgICAg ICAgICAgICAgICAgICB0byB1c2Ugk3N0YXRlZnVsIGNvbXB1dGUtb25seZQgaXQgc2VlbXMg dGhhdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgIHN5c3RlbS9jb250cm9sbGVyIGhh cyB0byBrZWVwIHRoZSBzdGF0ZSBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgIHBh dGhzIHNvbWV3aGVyZSB3aGljaCBpcyBub3QgWUFORyBkYXRhc3RvcmUuIE15DQogICAgICAg ICAgICAgICAgICAgICAgICB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgWUFORyBkYXRhc3RvcmUg aXMgdXBkYXRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgb25seSB3aGVuIHRoZSBwYXRo IGlzIHNpZ25hbGVkIGFuZCByZXNvdXJjZSBpcw0KICAgICAgICAgICAgICAgICAgICAgICAg YWxsb2NhdGVkLiBXb3VsZCB0aGlzIGdpdmUgdGhlIHN5c3RlbS9jb250cm9sbGVyDQogICAg ICAgICAgICAgICAgICAgICAgICBhZGRpdGlvbmFsIGJ1cmRlbiB0byBrZWVwIHRoZSCTaW50 ZXJpbZQgc3RhdGU/DQogICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPllvdW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAgICAgICAgICAgICAg ICAgICAgICAgIENDQU1QIFs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQogICAgICAgICAgICAgICAgICAg ICAgICA8Yj5PbiBCZWhhbGYgT2YgPC9iPlNjaGFyZiwgTWljaGFlbCAoTm9raWEgLQ0KICAg ICAgICAgICAgICAgICAgICAgICAgREUpPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg PGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAwMywgMjAxNiA4OjU4IEFNPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGI+VG86PC9iPiBEYW5pZWxlIENlY2NhcmVsbGk7 IElnb3IgQnJ5c2tpbjsNCiAgICAgICAgICAgICAgICAgICAgICAgIENDQU1QICg8YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1h aWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAg ICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9h PjsNCiAgICAgICAgICAgICAgICAgICAgICAgIFRFQVMgV0cgKDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAg IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIDxhDQog ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBh dGgtY29tcHV0YXRpb24tMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1 c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDA8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86 cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NYXliZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgSSBtaXNzIHNvbWV0aGluZywgYnV0IHRvIG1lLCB0aGUgZG9tYWluDQogICAgICAg ICAgICAgICAgICAgICAgICBjb250cm9sbGVyIGVpdGhlciBjb21wdXRlcyBhIHBhdGggc3Rh dGVsZXNzLA0KICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggY2FuIGJlIG1vZGVsZWQg aW4gWUFORyBpbiBhbiBSUEMuIE9yIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgZG9t YWluIGNvbnRyb2xsZXIgY29tcHV0ZXMgYSBwYXRoLCBzdG9yZXMgc3RhdGUsDQogICAgICAg ICAgICAgICAgICAgICAgICBhbmQgcHJvdmlkZXMgYWNjZXNzIHRvIHRoZSByZXN1bHQgaW4g dGhlIFlBTkcNCiAgICAgICAgICAgICAgICAgICAgICAgIGRhdGFzdG9yZS4gSW4gdGhlIGxh dHRlciBjYXNlLCB3aGV0aGVyIHJlc291cmNlcw0KICAgICAgICAgICAgICAgICAgICAgICAg YXJlIGFsbG9jYXRlZCwgb3Igd2hldGhlciB0aGUgTkVzIGdldCBhY3R1YWxseQ0KICAgICAg ICAgICAgICAgICAgICAgICAgcHJvdmlzaW9uZWQsIGlzIGFuIG9ydGhvZ29uYWwgcXVlc3Rp b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzDQogICAgICAgICAgICAgICAgICAgICAg ICBhIHNpZGUgbm90ZSwgSSBhbSBub3Qgc3VyZSBvZiBJIHdvdWxkIGNhbGwgYQ0KICAgICAg ICAgICAgICAgICAgICAgICAgZG9tYWluIGNvbnRyb2xsZXIgb3IgYW4gTk1TIGEgUENFLiBQ YXRoDQogICAgICAgICAgICAgICAgICAgICAgICBjb21wdXRhdGlvbiBpcyBvbmx5IGEgc3Vi c2V0IG9mIHRoZSBmdW5jdGlvbnMgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgIGEgZG9t YWluIGNvbnRyb2xsZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+ PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogICAgICAg ICAgICAgICAgICAgICAgICBEYW5pZWxlIENlY2NhcmVsbGkgWzxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPm1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tPC9hPl0NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMDMs IDIwMTYgMjo0OSBQTTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiPlRvOjwvYj4g U2NoYXJmLCBNaWNoYWVsIDwvc3Bhbj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi DQogICAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJERSI+KE5va2lhIC0gREUpOyBJZ29y IEJyeXNraW47IENDQU1QICg8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8t bm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0 bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAg ICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAg ICAgICAgICAgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjsN CiAgICAgICAgICAgICAgICAgICAgICAgIFRFQVMgV0cgKDxhIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIDxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJFOiA8YSBtb3otZG8tbm90LXNl bmQ9InRydWUiDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNp YmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwPC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcGxlYXNl IGV4cGxhaW4gd2hhdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICCTc3RhdGVmdWwgY29t cHV0ZS1vbmx5lCBzdGFuZHMgZm9yIEkgZG9uknQNCiAgICAgICAgICAgICAgICAgICAgICB1 bmRlcnN0YW5kIHdoYXQgaXMgc3RhdGVmdWwgaW4gYSBwYXRoIGNvbXB1dGF0aW9uDQogICAg ICAgICAgICAgICAgICAgICAgcmVxdWVzdCBvbmx5Lg0KICAgICAgICAgICAgICAgICAgICAg IDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj5JTUhPIGVpdGhlciBJIGFzayB0aGUgUENFIChTRE4NCiAgICAgICAgICAgICAgICAg ICAgICBjb250cm9sbGVyLCBOTVMsIHdoYXRldmVyKSB0byBjb21wdXRlIGEgcGF0aCBhbmQN CiAgICAgICAgICAgICAgICAgICAgICB0aGVuIGZvcmdldCBhYm91dCBpdCBvciBJIGFzayB0 byBjb21wdXRlIGFuZA0KICAgICAgICAgICAgICAgICAgICAgIHByb3Zpc2lvbiBpdC4gSSBk b26SdCB1bmRlcnN0YW5kIHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICAgICAgIGFz a2luZyBmb3IgaXQgYW5kIHJlbWVtYmVyaW5nIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48 L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkJSPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgIERhbmllbGWgIDxvOnA+PC9vOnA+PC9wPg0KICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBT Y2hhcmYsIE1pY2hhZWwNCiAgICAgICAgICAgICAgICAgICAgICAoTm9raWEgLSBERSkgWzxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iPm1haWx0bzptaWNoYWVsLnNjaGFy ZkBub2tpYS5jb208L2E+XQ0KICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gZ2lvdmVk7CAzIG5vdmVtYnJlIDIwMTYgMTQ6 NDU8YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGI+VG86PC9iPiBJZ29yIEJyeXNraW4g Jmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi DQogICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86SWdvci5Ccnlza2luQGh1 YXdlaS5jb20iPklnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPC9hPiZndDs7DQogICAgICAgICAg ICAgICAgICAgICAgRGFuaWVsZSBDZWNjYXJlbGxpICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9 InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86ZGFuaWVsZS5j ZWNjYXJlbGxpQGVyaWNzc29uLmNvbSI+ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bTwvYT4mZ3Q7Ow0KICAgICAgICAgICAgICAgICAgICAgIENDQU1QICg8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86Y2Nh bXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPikNCiAgICAgICAgICAgICAgICAgICAg ICAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAg ICAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4mZ3Q7 Ow0KICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAg ICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPg0KICAg ICAgICAgICAgICAgICAgICAgICAgcGNlQGlldGYub3JnPC9hPjsgVEVBUyBXRyAoPGENCiAg ICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGlldGYu b3JnPC9hPikNCiAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0OzsNCiAgICAgICAgICAgICAgICAgICAgICA8 YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJFOiA8YSBtb3otZG8tbm90LXNlbmQ9 InRydWUiDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVs LXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwPC9hPjxv OnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJJVCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPldlDQogICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGRpc2N1c3NlZCB0aGlzIGJl Zm9yZS4gRnJvbSBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgaW1wbGVtZW50ZXKScyBw ZXJzcGVjdGl2ZSwgdGhlIHR3byBjbGVhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc29s dXRpb25zIHRvIHRoZSBwcm9ibGVtIHNlZW0gdG8gZWl0aGVyIHN0YXRlZnVsDQogICAgICAg ICAgICAgICAgICAgICAgICCEY29tcHV0ZS1vbmx5kyB0dW5uZWxzIG9yIGEgc3RhdGVsZXNz IFJQQy48L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi DQogICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkRFIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ig0KICAgICAgICAgICAgICAgICAgICAg ICAgbGFuZz0iREUiPiBtcGxzIFs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAg ICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KICAgICAgICAgICAgICAgICAg ICAgICAgPGI+T24gQmVoYWxmIE9mIDwvYj5JZ29yIEJyeXNraW48YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2 IDI6MzQgUE08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IERhbmll bGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i bWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pOw0KICAgICAgICAg ICAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8 L2E+Ow0KICAgICAgICAgICAgICAgICAgICAgICAgVEVBUyBXRyAoPGEgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86dGVh c0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAgICAgICAgICAg ICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gW0FMVV0gW21wbHNdPGEN CiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmct cGF0aC1jb21wdXRhdGlvbi0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMDwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkRFIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZyb20NCiAgICAgICAgICAgICAgICAgICAg ICAgIHRoZSBkcmFmdDo8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+Ni6goKAgWUFORyBNb2Rl bCBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgcmVxdWVzdGluZyBQYXRoIENvbXB1 dGF0aW9uPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAg ICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIN CiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAg TmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAg ICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+ oKAgV29yayBvbiBleHRlbmRpbmcgdGhlIFRFDQogICAgICAgICAgICAgICAgICAgICAgICBU dW5uZWwgWUFORyBtb2RlbCB0byBzdXBwb3J0IHRoZSBuZWVkIHRvPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcm cXVvdDsiIGxhbmc9IkVOIj6goCByZXF1ZXN0IHBhdGggY29tcHV0YXRpb24NCiAgICAgICAg ICAgICAgICAgICAgICAgIGhhcyByZWNlbnRseSBzdGFydGVkIGFsc28gaW4gdGhlIGNvbnRl eHQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAg ICAgICAgICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqCgIHRoZSBbPGENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgt Y29tcHV0YXRpb24tMDAjcmVmLVRFLVRVTk5FTCINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgdGl0bGU9IiZxdW90O0EgWUFORyBEYXRhIE1vZGVsIGZvciBUcmFmZmljDQogICAgICAg ICAgICAgICAgICAgICAgICAgIEVuZ2luZWVyaW5nIFR1bm5lbHMgYW5kIEludGVyZmFjZXMm cXVvdDsiPlRFLVRVTk5FTDwvYT5dDQogICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC48 L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAg ICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqA8L3NwYW4+PG86cD48L286cD48L3A+ DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgIE5ldyZxdW90OyIg bGFuZz0iRU4iPqCgIEl0IGlzIHBvc3NpYmxlIHRvDQogICAgICAgICAgICAgICAgICAgICAg ICByZXF1ZXN0IHBhdGggY29tcHV0YXRpb24gYnkgY29uZmlndXJpbmcgYTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIN CiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAg TmV3JnF1b3Q7IiBsYW5nPSJFTiI+oKAgImNvbXB1dGUtb25seSIgVEUgdHVubmVsDQogICAg ICAgICAgICAgICAgICAgICAgICBhbmQgcmV0cmlldmluZyB0aGUgY29tcHV0ZWQgcGF0aChz KSBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAg ICAgICAgICAgICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqCgIExTUChzKSBSZWNv cmQtUm91dGUNCiAgICAgICAgICAgICAgICAgICAgICAgIE9iamVjdCAoUlJPKSBsaXN0IGFz IGRlc2NyaWJlZCBpbiBbPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAjcmVmLVRFLVRVTk5FTCIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgdGl0bGU9IiZxdW90O0EgWUFORyBEYXRhIE1v ZGVsIGZvciBUcmFmZmljDQogICAgICAgICAgICAgICAgICAgICAgICAgIEVuZ2luZWVyaW5n IFR1bm5lbHMgYW5kIEludGVyZmFjZXMmcXVvdDsiPlRFLVRVTk5FTDwvYT5dLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAg ICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJF TiI+oKAgVGhpcyBpcyBhIHN0YXRlZnVsDQogICAgICAgICAgICAgICAgICAgICAgICBzb2x1 dGlvbiBzaW5jZSB0aGUgc3RhdGUgb2YgZWFjaCBjcmVhdGVkPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAg ICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVv dDsiIGxhbmc9IkVOIj6goCAiY29tcHV0ZS1vbmx5IiBURSB0dW5uZWwNCiAgICAgICAgICAg ICAgICAgICAgICAgIG5lZWRzIHRvIGJlIG1haW50YWluZWQgYW5kIHVwZGF0ZWQsIHdoZW48 L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAg ICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqCgIHVuZGVybHlpbmcgbmV0d29yaw0K ICAgICAgICAgICAgICAgICAgICAgICAgY29uZGl0aW9ucyBjaGFuZ2UuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0K ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBO ZXcmcXVvdDsiIGxhbmc9IkVOIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiIGxhbmc9IkVOIj6g oCBUaGUgbmVlZCBhbHNvIGZvciBhDQogICAgICAgICAgICAgICAgICAgICAgICBzdGF0ZWxl c3Mgc29sdXRpb24sIGJhc2VkIG9uIGFuIFJQQywgaGFzIGJlZW48L3NwYW4+PG86cD48L286 cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAg ICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgIE5ldyZx dW90OyIgbGFuZz0iRU4iPqCgIHJlY29nbml6ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuDQogICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiIGxh bmc9IkVOIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAg ICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiIGxhbmc9IkVOIj6gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0K ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBO ZXcmcXVvdDsiIGxhbmc9IkVOIj6goCBUaGUgWUFORyBtb2RlbCB0bw0KICAgICAgICAgICAg ICAgICAgICAgICAgc3VwcG9ydCBzdGF0ZWxlc3MgUlBDIGlzIGZvciBmdXJ0aGVyIHN0dWR5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAg ICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0K ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7 IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0K ICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAg ICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJF TiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAg ICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIiBsYW5nPSJFTiI+SUImZ3Q7 Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgPGI+UGxlYXNlLCBub3RlLCB0aGF0IGlu IHRoZSBURSBUdW5uZWwgbW9kZWwgd2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c2lkZXIgdGhlIENPTVBVVEVfQU5EX0ZPUkdFVCBtb2RlLiBXZSBhbHNvDQogICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnNpZGVyIHRoZSBjb25jZXB0IG9mIHBhdGggY29tcHV0YXRp b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9uIHRvIGJlIGRlZmluZWQgdW5k ZXIgdGhlIFRFIHR1bm5lbCBub2RlLg0KICAgICAgICAgICAgICAgICAgICAgICAgICBBbGwg dGhpcyBpcyB0byBmYWNpbGl0YXRlIHN0YXRlbGVzcyBwYXRoDQogICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbXB1dGF0aW9ucy48L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxzcGFuDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIiBsYW5nPSJFTiI+oDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAg ICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGI+PHNwYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVv dDs7Y29sb3I6YmxhY2siIGxhbmc9IkVOIj5DaGVlcnMsPC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAg ICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48Yj48 c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICAg IE5ldyZxdW90Oztjb2xvcjpibGFjayIgbGFuZz0iRU4iPklnb3I8L3NwYW4+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAg ICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD6gPC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD6gPC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8 L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogIDwv Ym9keT4NCjwvaHRtbD4NCg== From nobody Fri Nov 4 11:12:21 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3981295FB; Fri, 4 Nov 2016 11:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 Z1p3l84WWSvF; Fri, 4 Nov 2016 11:12:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2332129446; Fri, 4 Nov 2016 11:12:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUN29582; Fri, 04 Nov 2016 18:12:11 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 18:12:10 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 11:12:00 -0700 From: Igor Bryskin To: Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQ Date: Fri, 4 Nov 2016 18:11:59 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> In-Reply-To: <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.581CCF7C.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:12:19 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:diet= er.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyou=
ng@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

   Work on extending the TE Tunnel YANG model to support t= he need to

   request path computation has recently started also in t= he context of

   the [TE-TUNN= EL] draft.

 

   It is possible to request path computation by configuri= ng a

   "compute-only" TE tunnel and retrieving the c= omputed path(s) in the

   LSP(s) Record-Route Object (RRO) list as described in [= TE-TUNN= EL].

 

   This is a stateful solution since the state of each cre= ated

   "compute-only" TE tunnel needs to be maintain= ed and updated, when

   underlying network conditions change.=

 

   The need also for a stateless solution, based on an RPC= , has been

   recognized.

 

 

   The YANG model to support stateless RPC is for further = study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_-- From nobody Mon Nov 7 00:50:20 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6E5129B5F; Mon, 7 Nov 2016 00:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 lR6VJYtN9piI; Mon, 7 Nov 2016 00:50:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A9F129AE5; Mon, 7 Nov 2016 00:50:12 -0800 (PST) X-AuditID: c1b4fb2d-5b107980000009f7-b2-58204043af1a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id CF.FD.02551.34040285; Mon, 7 Nov 2016 09:50:11 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 7 Nov 2016 09:50:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=acQDa0rulKGmDn8jmRUlnCDty7cHBc1wmrd/BEnSbbI=; b=GSWW5c4WYVpLXFXhWlCTLC1pMRnL7YCnbCR9LZqaCaiWewubgG4jsV4kD6k3bhYd8J5W8/8T3WpBL7So1MAHMU6PVpvX+HA51CBR/sHXUspWSqVmYvcfVy+Qi2SURG2MnD3Wyta32flJXXmfYNjue5jKh70pKkVGEt1NhmCrOkY= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1524.eurprd07.prod.outlook.com (10.165.248.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Mon, 7 Nov 2016 08:50:08 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0707.004; Mon, 7 Nov 2016 08:50:08 +0000 From: Francesco Lazzeri To: Igor Bryskin , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNscTVO3gaGLLzUa73Uh58WTwgKDNN3tA Date: Mon, 7 Nov 2016 08:50:07 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 3a4497e9-9bc4-4398-07f5-08d406eb13a5 x-microsoft-exchange-diagnostics: 1; AM4PR07MB1524; 7:meKShh6iWzAayyWi0vRAc8Ui2hhxIzbgwIVONpRPiWMevw5RuJrDIECc5u7i9dU1iRRcFfJ7vk4glr/OHlx56BO8tmnvaR7H3s/TF7o/OU/Gv0XAzZf+e0up/PRXTkEP9dpysODVwHDsRhvtJLIoqG+4dKmnpzeiK2MpuNBx8AHYziLOp0aDRpR5M54OdrlKMsm/P3KfyCFM3O/Ic6f11PWVuN8uW9Aq03xHqjLF9PSRrPkB3LFqL3BdOl/b9wf57SO+J4YJGpWR2qv2m1mYnO9cxPZep5g239OftoyCATdlpc7zPm5mO3PsKI5Mm+pCdVEXzEcmd5KB7IiHOANu+yuUhUJQi5Zebi4qp482K2A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR07MB1524; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1524; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(377454003)(189002)(24454002)(199003)(7736002)(7906003)(74316002)(92566002)(7846002)(106356001)(15975445007)(101416001)(106116001)(5660300001)(790700001)(77096005)(189998001)(2906002)(81166006)(19300405004)(2950100002)(19580395003)(8676002)(81156014)(102836003)(7696004)(6116002)(2900100001)(68736007)(3846002)(9686002)(8936002)(5002640100001)(4326007)(586003)(10400500002)(33656002)(87936001)(76176999)(76576001)(19580405001)(220493001)(86362001)(122556002)(11100500001)(3900700001)(5001770100001)(230783001)(16236675004)(66066001)(105586002)(3280700002)(93886004)(3660700001)(54356999)(50986999)(19617315012)(97736004)(19625215002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1524; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 08:50:08.0414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1524 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURTHue+9mXmaE9dR86BSOiSYoaVGPTHCFsMPSdKmSC5DPtxHnWeS UeCSQ5mlUy45KhmMhfuKCUroaJZCZmEq41qaWhqJhGtKzjwlv/3u+f/uPfdcLk1K3gus6Ah5 AquQy6KlQmOqwP/1Gaeznrb+Rx+vWTBTRUMUU60ZoZiNbhdm9ZMjoystEzCp40MiJn2lmfIU ed/r/CXw1mhWCe9R3WfClwwwPhnKRkcksoojp0KMw1OWa4Vxda3kLfWslkhGK/fJDGREAz4G TSqlKAMZ0xJcjeDP0k9DIMHvEJRXB+oDCj8iQZVeTPBWHgElyrT/1qgO6VmIGVjrLKT0bI6v Qk1tEdJvIPEgguKnI4IMRNNm+Dr0Kk15JxByJxoofdkcu8JoVoi+TOGD0NZbbDhGvGXnDy8K +b4LIkhXzRj6GmEvKJ8pNPRFeB8s91QSeiaxJeimnhP8aBg0rR+3x7SAH5ObAt6XQZ1Gve3Y QV/5DvvAsCZVoG8GuISE370d28F5aP8yK+I5Cmb7NgheykDw5msmxS+aESxO9gt5ywbmSqa2 rS4hVCg1iH8vFl5VpRvYDFvBaP8DlI0OqXddnedYyF9OJdWGNzCF7oIpiq87w1BujpDnw/Dy xRzJsxM829RSu+slSFSOLDiW42LCXN2cWUXEDY6LlTvL2YR6tPW/2hvXnZpRxdxpLcI0kpqI 47wO+EsEskQuKUaLgCal5mIPD1t/iThUlnSbVcQGK25Gs5wWWdOU1FJ8vGzcT4LDZAlsFMvG sYqdlKCNrJJR5EC1bVCiiaqqkXnY6ffNM6hB1RS0pymvZ7BFnVKV5Us/WZSesL6T7aZczyt2 KrrgILrsQS5MKzeCakzquyoVl9Lu5gQ3fo+fCEiYj4zM6RqLaplO+Su8eCW1Jm26a/85+1If G69498xr+Tpir8OSvCrPfX62jeoYeGtnP/ZhyU1KceEyF0dSwcn+ASST6thbAwAA Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 08:50:18 -0000 --_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The point here is for how long the provider should keep the computed path a= nd its request parameters (in fact if we want to have a possibly better pat= h, at any change inside provider topology, resource status and usage, the p= rovider should check if the computed path is still feasible and/or redo pat= h computation to find a better path). This could be an overhead, in my view= . Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; in fact, if the client is asking f= or a path between A and B (A and B inside provider topology), having A' (in= client topology) connected to A and B' (in client topology) connected to B= , the relevant abstract TE link (the forwarding adjacency) should be built = between A' and B', that is in the client topology; therefore the client sho= uld be in charge of managing it, as the provider is not aware of A' and B'. BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; TEAS WG (teas@ietf.org) ; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

The point here is f= or how long the provider should keep the computed path and its request para= meters (in fact if we want to have a possibly better path, at any change in= side provider topology, resource status and usage, the provider should check if the computed path is still feasibl= e and/or redo path computation to find a better path). This could be an ove= rhead, in my view.

 

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology; in fact, if the client is asking for a path bet= ween A and B (A and B inside provider topology), having A’ (in client topology) connected to A and B’ (in clien= t topology) connected to B, the relevant abstract TE link (the forwarding a= djacency) should be built between A’ and B’, that is in the cli= ent topology; therefore the client should be in charge of managing it, as the provider is not aware of A’ and B’.

 

BR

Francesco

 

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@= ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.B= eller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.co=
m> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.c= om]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6.=     YANG Model for requesting Path Computation

 = ;

 = ;

 = ;  Work on extending the TE Tunnel YANG model to support the need to

 = ;  request path computation has recently started also in the context o= f

 = ;  the [TE-TUNN= EL] draft.

 = ;

 = ;  It is possible to request path computation by configuring a<= o:p>

 = ;  "compute-only" TE tunnel and retrieving the computed path= (s) in the

 = ;  LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 = ;

 = ;  This is a stateful solution since the state of each created<= o:p>

 = ;  "compute-only" TE tunnel needs to be maintained and updat= ed, when

 = ;  underlying network conditions change.

 = ;

 = ;  The need also for a stateless solution, based on an RPC, has been

 = ;  recognized.

 = ;

 = ;

 = ;  The YANG model to support stateless RPC is for further study.

 = ;

 = ;

 = ;

 = ;

 = ;

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

--_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_-- From nobody Tue Nov 8 11:21:16 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335BD129DBC; Tue, 8 Nov 2016 11:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 QsJ9XBkqhYDV; Tue, 8 Nov 2016 11:21:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB1E129687; Tue, 8 Nov 2016 11:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4906; q=dns/txt; s=iport; t=1478632873; x=1479842473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9NfgXSrtXWempAtjdwMURcFC9IKHZGBFC3ujyqA5kZI=; b=AdArRVaMQc70n8A+u/dtUH0JqtYCcXiLsCnywyBVWgVWFgsr3JafLHzD YJ6cxTvtupbzskncLbhA+CT93d20iu7Z6Cwj4woI9M6FzSPUWJ9tdpOAw TtIB8LYGjM5kOfwLl0HwzS5mfqn1ln2i0Qa5nGyJg/XYvtX2GPhzHYirh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBSJCJY/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy8BAQEBAR9YfweNMpcFlFOCCB4LhXsCGoF5PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBAwEBAQEgEToLBQcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQOBYhUC?= =?us-ascii?q?A6xeoJAi0oBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEJhTWBfYJahEgXgm0tgi8?= =?us-ascii?q?Fmi8BhjWGE4N/gW4XhFuJNIcyhX6EBQEeN3obg0qBRXKGLoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,611,1473120000"; d="scan'208";a="169019813" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Nov 2016 19:21:12 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA8JLCPm025664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2016 19:21:12 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 8 Nov 2016 13:21:11 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 8 Nov 2016 13:21:11 -0600 From: "Giovanni Martinelli (giomarti)" To: "Yemin (Amy)" Thread-Topic: [Teas] ID Tracker State Update Notice: Thread-Index: AQHSNdpDvvAiNyDLrkGHzPfc/ozSdqDHaMXwgABi/wCAANw2AIAHO2oA Date: Tue, 8 Nov 2016 19:21:11 +0000 Message-ID: <6D0D45C8-771F-440A-A81E-F93065ED3D0B@cisco.com> References: <147818146209.22755.6255303719663691627.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461F9CE2270E@szxema506-mbs.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461F9CE2270E@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.249.13] Content-Type: text/plain; charset="utf-8" Content-ID: <90692E0B676DAD4F8F45D5949FBA8E94@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ccamp-chairs@ietf.org" , "draft-ietf-ccamp-ospf-availability-extension@ietf.org" , "ccamp@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] ID Tracker State Update Notice: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 19:21:15 -0000 c291bmRzIGdvb2QgdG8gbWUsIEkgYWxzbyBzdXBwb3J0IGdlbmVyYWxpemVkIFNDU0kuDQoNCihz b3JyeSBmb3IgYmVpbmcgc28gc2lsZW50IG9uIGZvcm1lciBkaXNjdXNzaW9uKSANCg0KQ2hlZXJz DQpHDQoNCj4gT24gMDQgTm92IDIwMTYsIGF0IDA2OjU0LCBZZW1pbiAoQW15KSA8YW15LnllbWlu QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gSSBzdXBwb3J0IHRoZSBhcHByb2FjaCB0byBkZWZp bmUgYSBnZW5lcmFsaXplZCBTQ1NJLiANCj4gV2l0aCB0aGUgZ2VuZXJhbGl6ZWQgU0NTSSAsIGlm IGEgbmV3IFRMViBjYW4gYmUgYXBwbGllZCB0byBtdWx0aXBsZSB0ZWNobm9sb2dpZXMsIHRoZXJl J3Mgbm8gbmVlZCB0byBkZWZpbmUgdGhlIHR5cGUgdW5kZXIgZWFjaCB0ZWNobm9sb2dpZXMgc3Bl Y2lmaWMgU0MuIA0KPiBBc3NvY2lhdGlvbiB3aXRoIHRoaXMgZ2VuZXJhbGl6ZWQgU0NTSSB3aWxs IHNpbXBsaWZ5IHRoZSBwcm9jZXNzLiANCj4gVGhpcyBjb3VsZCByZXNvbHZlIHRoZSBwcm9ibGVt IHRoYXQgU0NTSSBpbiBSRkM0MjAzIGRvZXNuJ3Qgc3VwcG9ydCBUTFYgZm9ybWF0LiANCj4gDQo+ IEJSLA0KPiBBbXkgDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBE YW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t XSANCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwNCwgMjAxNiAxMjo0NyBBTQ0KPiBUbzogQlJV TkdBUkQsIERFQk9SQUggQTsgY2NhbXBAaWV0Zi5vcmc7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcp DQo+IENjOiBkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbkBpZXRm Lm9yZzsgY2NhbXAtY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBJRCBUcmFja2VyIFN0 YXRlIFVwZGF0ZSBOb3RpY2U6IDxkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4 dGVuc2lvbi0wOC50eHQ+DQo+IA0KPiBUaGFua3MgRGVib3JhaCBmb3IgdHJpZ2dlcmluZyB0aGlz Lg0KPiANCj4gQ0NBTVAsIFRFQVMsIA0KPiANCj4gaW4gYWdyZWVtZW50IHdpdGggdGhlIFRFQVMg Y2hhaXJzIGFuZCBEZWJvcmFoIHdlIGRlY2lkZWQgdG8gd3JpdGUgYSBuZXcgZHJhZnQgaW4gVEVB UyBkZWZpbmluZyBhIGdlbmVyYWxpemVkIFNDU0kgb2YgdGhlIElTQ0QuIFRoZSBnZW5lcmFsaXpl ZCBTQ1NJIGNhbiBpbmNsdWRlIGEgbnVtYmVyIG9mIFNDU0kgc3ViLVRMVnMuDQo+IFRoZSBnZW5l cmFsaXplZCBTQ1NJIGNhbiBiZSB1c2VkIG9ubHkgd2l0aCAibmV3IiBzd2l0Y2hpbmcgY2FwYWJp bGl0aWVzLiBRdW90aW5nIHRoZSBkcmFmdDogDQo+IA0KPiAiIEdlbmVyYWxpemVkIFNDU0kgTVVT VCBOT1QgYmUgdXNlZCBmb3IgSVNDRHMgb2YgdGVjaG5vbG9naWVzIHdob3NlDQo+ICAgU3dpdGNo aW5nIENhcGFiaWxpdHkgZGVmaW5pdGlvbiBkbyBub3QgcmVmZXJlbmNlIHRoaXMgZG9jdW1lbnQu Ig0KPiANCj4gVGhlIGRyYWZ0IGFsc28gZGVmaW5lcyBhIG5ldyByZWdpc3RyeSB0aGUgIkdlbmVy YWxpemVkIFNDU0kgKFN3aXRjaGluZyBDYXBhYmlsaXR5IFNwZWNpZmljIEluZm9ybWF0aW9uKSBU TFZzICBUeXBlcyIgcmVnaXN0cnkuDQo+IA0KPiBUaGUgaWRlYSBpcyB0byByZXNoYXBlIGRyYWZ0 LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9ucyB0byBkZWZpbmUgdGhlIElT Q0QgQXZhaWxhYmlsaXR5IHN1Yi1UTFYgYXMgb25lIG9mIHRoZSBzdWItVExWcyBzdXBwb3J0ZWQg YnkgdGhlIEdlbmVyYWxpemVkIFNDU0kuIChWYWx1ZSAxIG9mIHRoZSByZWdpc3RyeSBzaG91bGQg YmUgYXNzaWduZWQpLg0KPiANCj4gVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdCB0aGUgZm9sbG93 aW5nIGxpbms6IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2VjY2FyZWxs aS10ZWFzLWduZXJhbGl6ZWQtc2NzaS0wMCANCj4gDQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgdG8gYm90aCB0aGUgbWFpbGluZyBsaXN0cy4NCj4gDQo+IFRoYW5rcw0KPiBEYW5pZWxlDQo+ IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEJSVU5HQVJELCBERUJP UkFIIEEgW21haWx0bzpkYjM1NDZAYXR0LmNvbV0NCj4+IFNlbnQ6IGdpb3ZlZMOsIDMgbm92ZW1i cmUgMjAxNiAxNzowMg0KPj4gVG86IGNjYW1wQGlldGYub3JnDQo+PiBDYzogZHJhZnQtaWV0Zi1j Y2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb25AaWV0Zi5vcmc7IGNjYW1wLSANCj4+IGNo YWlyc0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUkU6IElEIFRyYWNrZXIgU3RhdGUgVXBkYXRlIE5v dGljZTogPGRyYWZ0LWlldGYtY2NhbXAtb3NwZi0gDQo+PiBhdmFpbGFiaWxpdHktZXh0ZW5zaW9u LTA4LnR4dD4NCj4+IA0KPj4gSGkgQ0NBTVAsDQo+PiANCj4+IEFzIGEgcmVzdWx0IG9mIHRoZSBH ZW4tQVRSIHJldmlldyBhbmQgaXNzdWVzIHJhaXNlZCwgSSByZW1vdmVkIHRoaXMgDQo+PiBkb2N1 bWVudCBmcm9tIHRvZGF5J3MgdGVsZWNoYXQuIFlvdXIgQ2hhaXJzLCBBdXRob3JzLCBhbmQgSSBk ZWNpZGVkIA0KPj4gdGhlIGJlc3QgYXBwcm9hY2ggd291bGQgYmUgZm9yIG1lIHRvIHJldHVybiB0 aGlzIGRvY3VtZW50IHRvIHRoZSANCj4+IFdvcmtpbmcgR3JvdXAgdG8gZnVydGhlciBkaXNjdXNz IGhvdyB0byBwcm9ncmVzcy4NCj4+IA0KPj4gQmVzdCByZWdhcmRzIGFuZCBzYWZlIHRyYXZlbHMg Zm9yIHRob3NlIGdvaW5nIHRvIFNlb3VsLSBEZWJvcmFoDQo+PiANCj4+IA0KPj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRvOmll dGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmddDQo+Pj4gU2VudDogVGh1cnNkYXksIE5vdmVt YmVyIDAzLCAyMDE2IDk6NTggQU0NCj4+PiBUbzogemhhbmdmYXRhaUBodWF3ZWkuY29tOyBGYXRh aSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPjsNCj4+IGNjYW1wLQ0KPj4+IGNoYWlyc0Bp ZXRmLm9yZzsgQlJVTkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5jb20+OyBkcmFmdC1pZXRm LSANCj4+PiBjY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb25AaWV0Zi5vcmcNCj4+PiBT dWJqZWN0OiBJRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6DQo+Pj4gPGRyYWZ0LWlldGYt Y2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktDQo+Pj4gZXh0ZW5zaW9uLTA4LnR4dD4NCj4+PiANCj4+ PiBJRVNHIHN0YXRlIGNoYW5nZWQgdG8gQUQgaXMgd2F0Y2hpbmc6OlJldmlzZWQgSS1EIE5lZWRl ZCBmcm9tIElFU0cgDQo+Pj4gRXZhbHVhdGlvbiBJRCBUcmFja2VyIFVSTDoNCj4+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW9zcGYtDQo+Pj4gYXZh aWxhYmlsaXR5LWV4dGVuc2lvbi8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFRlYXMgbWFpbGluZyBsaXN0DQo+IFRlYXNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCg== From nobody Tue Nov 8 23:36:36 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA911295DF for ; Tue, 8 Nov 2016 23:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 X-F20iT6wxCX for ; Tue, 8 Nov 2016 23:36:32 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670F012941D for ; Tue, 8 Nov 2016 23:36:32 -0800 (PST) X-AuditID: c1b4fb25-813ff70000005623-f5-5822d1fdbd3c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id D6.C0.22051.DF1D2285; Wed, 9 Nov 2016 08:36:30 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 9 Nov 2016 08:36:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s61zs4Oo9LzlzdEEEjvMZKXdqRS4WKfOojz9bqgu6L0=; b=KfCCKAczdORW7LnnzPlxzJPnPduk+NMb8qL23B1xVnMIlT0p6+BKsrfIG2niUHbw57e3+CuRYGajkOzbSv9HI5I4tFcxPAQGwB8OITqztatVRPSKJ2jT1jWbOhxFmZjf+RFJZoODSpMR46J0JneoidAwFSPkKn8OaJWKx2kvt8Q= Received: from AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) by AM3PR07MB0533.eurprd07.prod.outlook.com (10.141.47.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Wed, 9 Nov 2016 07:36:28 +0000 Received: from AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::25c6:737d:1670:a6d1]) by AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::25c6:737d:1670:a6d1%18]) with mapi id 15.01.0721.004; Wed, 9 Nov 2016 07:36:28 +0000 From: Jonas Ahlberg To: 'LUIS MIGUEL CONTRERAS MURILLO' , "'Yemin (Amy'" , "'Marko.Vaupotic@Aviatnet.com'" , "'jefftant.ietf@gmail.com'" , 'Koji Kawada' , "'Ippei Akiyoshi (i-akiyoshi@ah.jp.nec.com) (i-akiyoshi@ah.jp.nec.com)'" , 'Xi Li' , "'Martin Skorupski (External'" , "Rahman, Akbar" , "cjbc@it.uc3m.es" Thread-Topic: MDT meeting - Framework & Gap Analysis & YANG Data Model - November 10, 7:00-8:00 (CEST) Thread-Index: AdI6WnuJ+ssu0xDHQquSdaKX3bX9Mg== Date: Wed, 9 Nov 2016 07:36:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jonas.ahlberg@ericsson.com; x-originating-ip: [87.241.98.47] x-ms-office365-filtering-correlation-id: 86f3c23c-17b5-41f4-b6c3-08d408731e03 x-microsoft-exchange-diagnostics: 1; AM3PR07MB0533; 7:eEH14mTlisYjr7PMZBfcKOU9Nb2DI9paX1hxb5Z7zHGMb2saExtYCP61mX6IXMIfQpNX+/axHerYZZWlzlzYFryfnrzP1R4T/yk5TpRQhRkmbU50H7U1zxAKiTRwZnA+GPx+RIfKTEx+153Osp1QVnmAGkNZr93yg8g6e8Zh6a51wsM+9V05TA2px/GyompAyicqMM/8pui9/NuWdVuWFVRpDzOav6FTHk1JN+8E1oCs0HVaDdPmsG93r3ZK6fbvcxzq20YIa2Pg8xkNjjcvk8SaInDndVQFwf/a5ocIiz3i9rStTeTEgx7Z1GsBycWvDaTuWv215W1DyH80vs+I3sY1bPi2BKktC22sI3yWe1Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB0533; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(209352067349851)(176712945974257)(77634252153581)(120264001924599)(189100400724070)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB0533; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0533; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(3905003)(199003)(497574002)(53754006)(189002)(81156014)(74316002)(33656002)(2906002)(8676002)(106356001)(92566002)(229853001)(3660700001)(105586002)(5250100002)(4326007)(5660300001)(81166006)(7696004)(66066001)(8936002)(7066003)(87936001)(189998001)(2501003)(3846002)(76576001)(101416001)(3280700002)(54356999)(97736004)(5001770100001)(586003)(102836003)(50986999)(7416002)(9686002)(7736002)(7906003)(68736007)(7846002)(6116002)(2900100001)(790700001)(86362001)(19609705001)(921003)(1121003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0533; H:AM3PR07MB0536.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB05366EEA47823C9CE05680F689B90AM3PR07MB0536eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2016 07:36:28.1471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0533 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec97zna0Fq/L6sH1oVYRWtpdThSRRHa+FEFEIzJbeVDJVDaz ND+YOXNGJGU1R5cplhpq3shFM+YMr5W6Ci9TbGW4ecluKCZZbUfBb7/n+f+fh+f/8rJYPs0E sLHxSYImXh2nlPjS+aq6Q8GzXUrVZvvARu53bgbF1WRXSrihez00pzNXU1yB/QrDjWRPU5zB 3oy5t8MGCWcoyZNy36wGzA38aKP2LuJdBbWYb9SXIf65cUDKZ74aZ/iiommKf9SdxfCT3VUM b2hyS3n9DD7sc9x3d5QQF5ssaDbtOeUb01s/Kknsy0YXb/9dk45mUnMQywLZDu4JRQ7yZeWk AsGbwg9SsWhG4O7T0Z6CJtcxjD7NlIjKTQo67TokFp8QTNyx/ld8WAnZDGMjD7wuf9JEg+uu GXsETNZBVncb4+Gl5AzMln+hPOxPYsB6y0CLHAKu+9VSD9NkLdRnWpCHZeQEDHc0emcRWQ5T bWWUuHMF9A099DIQAkWWDizyMnB/np3zR8C4a4QW+6ug4YZzzn8QnJeverMBMWFo73RIRCEc BvWTjMhnob3959zAAwT9uQdENiMoc2lEXgnGtjdYXFTHQFbFNe8VciJAcbkOiYkDYOC9fo5X gqu/nhETJEDPl0Kci9YbFwQyLpCM3gfwg9b8IVrsbwTTix8SkTfA44JRPM+vrZ+phX0Tkj5B y7SC9vS56K3bQgRN7BmtNiE+JF5Iqkb/P2RD7cw6M3o3FmZDhEXKxbJE12qVnFEna1PO2RCw WOkv629RquSyKHVKqqBJiNScjxO0NqRgaeUKWWjp4DE5iVYnCWcFIVHQzKsU6xOQjkIVzmGq Nr2hoKgQ1YVOhVkcLYkRgjtt6tLJyCPVVe0mgf1rjvhVeWDnhcc9S3bkfU8LdCydDcx7+bVj NNnh+GOXPSt21tyaQkd7312NLPnUGuLa/rPLVrbV7zreEp6jD8ZVNsueXR8Vafnhh/Rd+zpj e3SLT18IMqkzSsfU0v1KWhuj3hKENVr1PzEOSWuMAwAA Archived-At: Cc: "ccamp@ietf.org" Subject: [CCAMP] MDT meeting - Framework & Gap Analysis & YANG Data Model - November 10, 7:00-8:00 (CEST) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 07:36:36 -0000 --_000_AM3PR07MB05366EEA47823C9CE05680F689B90AM3PR07MB0536eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I suggest that we use the meeting for reviewing/discussing the presentation= s for next week. We will have three presentation slots at IETF 97. Session I - Joint YANG session with MPLS, PCE and TEAS Monday, November 14, 2016 (KST) 17:30: 5 minutes Microwave Radio Link YANG Data Model (Amy) Session II - CCAMP WG Thursday, November 17, 2016 (KST) 14:05: 10 minutes Microwave Radio Link Framework (Jonas) 14:15 10 minutes Microwave Radio Link YANG Data Model (Amy) Proposed Agenda: * IETF 97 - Presentations o Microwave Radio Link YANG Data Model (Amy) o Microwave Radio Link Framework (Jonas) * IETF 97 - MDT F2F meeting schedule /JonasA Call-in details: ...........................................................................= .............................................................. --> Join Skype Meeting This is an online meeting for Skype for Business, the professional meetings= and communications app formerly known as Lync. Join by phone +46107140000 (Sweden) Englis= h (United States) 89925 (Sweden) English (United Sta= tes) Find a local number Conference ID: 3965728 Forgot your dial-in PIN? |Help To join a Lync / Skype for Business meeting from an Ericsson standard video= room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the= conference ID). To join from a video room outside of Ericsson add one o= f the domains after 77 and Conference ID (e.g. 771234567@ xxxx.ericsson.net= , where xxxx=3Demea/apac/amcs). For assistance contact the IT Service Desk= . [!OC([1033])!] ...........................................................................= .............................................................. --_000_AM3PR07MB05366EEA47823C9CE05680F689B90AM3PR07MB0536eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I suggest that we use the meeting for reviewing/disc= ussing the presentations for next week.

We will have three presentation slots at IETF 97.

 

Session I - Joint YANG session with MPLS, PCE and TE= AS
Monday, November 14, 2016 (KST)

17:30:      5 minutes  = ;    Microwave Radio Link YANG Data Model (Amy)

 

Session II – CCAMP WG        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        

Thursday, November 17, 2016 (KST)

14:05:    10 minutes   = ;  Microwave Radio Link Framework (Jonas)

14:15     10 minutes  =    Microwave Radio Link YANG Data Model (Amy)

 

Proposed Agenda:

·         IETF 97 - Presentations

o   Microwave Radio Link YANG Data Model (Amy)

o   Microwave Radio Link Framework (Jonas)<= /o:p>

·         IETF 97 – MDT F2F meeting schedule

 

 

/JonasA

 

 

Call-in details:=

 <= /o:p>

...................................................= ...........................................................................= ...........

&agr= ave; = Join Skype Meeting      

This is an online meeting= for Skype for Business, the professional meetings and communications app f= ormerly known as Lync.

Join by phone

 

+46107140000 (Swed= en)             = ;      English (United States)

89925 (Sweden)   &= nbsp;           &nbs= p;   English (United States)  =

 

Find a = local number

 

Conference ID: 3965728

Forgot your dial-in PIN?<= span lang=3D"EN" style=3D"font-size:3.0pt"> |Help  

 

 

To j= oin a Lync / Skype for Business meeting from an Ericsson standard video roo= m, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the con= ference ID).    To join from a video room outside of Ericsson add one of the domains after 77 and Conference ID (e.g= . 771234567@ xxxx.ericsson.net, where xxxx=3Demea/apac/amcs).  For ass= istance contact the IT Service Desk.

[!OC([1033])!]

= ...........................................................................= ..............................................................<= /p>

 

 

--_000_AM3PR07MB05366EEA47823C9CE05680F689B90AM3PR07MB0536eurp_-- From nobody Wed Nov 9 02:11:53 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7012995A; Wed, 9 Nov 2016 02:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 yIWOKBReLWTu; Wed, 9 Nov 2016 02:11:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CF812963C; Wed, 9 Nov 2016 02:11:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAA37385; Wed, 09 Nov 2016 10:11:37 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 10:11:26 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.10]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 18:11:16 +0800 From: Fatai Zhang To: Francesco Lazzeri , Igor Bryskin , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAA== Date: Wed, 9 Nov 2016 10:11:16 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.162.94] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8817AC188SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5822F65A.0200, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.10, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 858c711f7d5f14af3a2a303e368a3663 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [CCAMP] =?gb2312?b?tPC4tDogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9y?= =?gb2312?b?Zy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRp?= =?gb2312?b?b24tMDA=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 10:11:47 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF8817AC188SZXEMA504MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHNoYXJlIHRoZSBzYW1lIHVuZGVyc3RhbmRpbmcgYXMgRGlldGVyIGFuZCBG cmFuY2VzY28uDQoNCkkgZG9uoa90IHNlZSBtdWNoIHZhbHVlIG9mIHRoZSBzdGF0ZWZ1bCBwYXRo IGNvbXB1dGF0aW9uLCBiZWNhdXNlIHRoZSBjb21wdXRlZCBwYXRoIGNhbm5vdCBiZSBndWFyYW50 ZWVkIGFuZCBpdCBicmluZ3MgbXVjaCBvdmVyaGVhZCBhcyBGcmFuY2VzY28gcG9pbnRlZC4NCg0K SSB0aGluayBpdCBtYWtlcyBzZW5zZSBpZiB0aGUgcmVzb3VyY2Ugb2YgdGhlIHN0YXRlZnVsIHBh dGggc2hvdWxkIGJlIHJlc2VydmVkIChvciBhbGxvY2F0ZWRCdXROb3RJblVzZSB1c2VkIGJ5IERp ZXRlcikuDQoNCg0KDQoNClRoYW5rcw0KDQpGYXRhaQ0KDQq3orz+yMs6IENDQU1QIFttYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBGcmFuY2VzY28gTGF6emVyaQ0Kt6LLzcqxvOQ6 IDIwMTbE6jEx1MI3yNUgMTY6NTANCsrVvP7IyzogSWdvciBCcnlza2luOyBEaWV0ZXIgQmVsbGVy DQqzrcvNOiBtcGxzQGlldGYub3JnOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpOyBTY2hhcmYsIE1p Y2hhZWwgKE5va2lhIC0gREUpOyBwY2VAaWV0Zi5vcmc7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcp DQrW98ziOiBSZTogW0NDQU1QXSBbbXBsc10gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQoNClRoZSBwb2ludCBo ZXJlIGlzIGZvciBob3cgbG9uZyB0aGUgcHJvdmlkZXIgc2hvdWxkIGtlZXAgdGhlIGNvbXB1dGVk IHBhdGggYW5kIGl0cyByZXF1ZXN0IHBhcmFtZXRlcnMgKGluIGZhY3QgaWYgd2Ugd2FudCB0byBo YXZlIGEgcG9zc2libHkgYmV0dGVyIHBhdGgsIGF0IGFueSBjaGFuZ2UgaW5zaWRlIHByb3ZpZGVy IHRvcG9sb2d5LCByZXNvdXJjZSBzdGF0dXMgYW5kIHVzYWdlLCB0aGUgcHJvdmlkZXIgc2hvdWxk IGNoZWNrIGlmIHRoZSBjb21wdXRlZCBwYXRoIGlzIHN0aWxsIGZlYXNpYmxlIGFuZC9vciByZWRv IHBhdGggY29tcHV0YXRpb24gdG8gZmluZCBhIGJldHRlciBwYXRoKS4gVGhpcyBjb3VsZCBiZSBh biBvdmVyaGVhZCwgaW4gbXkgdmlldy4NCg0KRnVydGhlcm1vcmUsIEkgY2Fuoa90IHNlZSBob3cg dGhlIHByb3ZpZGVyIGNvdWxkIGV4cG9ydCB0aGUgYWJzdHJhY3QgVEUtbGluaywgYXMgdGhpcyBp cyBpbnNpZGUgdGhlIGNsaWVudCB0b3BvbG9neTsgaW4gZmFjdCwgaWYgdGhlIGNsaWVudCBpcyBh c2tpbmcgZm9yIGEgcGF0aCBiZXR3ZWVuIEEgYW5kIEIgKEEgYW5kIEIgaW5zaWRlIHByb3ZpZGVy IHRvcG9sb2d5KSwgaGF2aW5nIEGhryAoaW4gY2xpZW50IHRvcG9sb2d5KSBjb25uZWN0ZWQgdG8g QSBhbmQgQqGvIChpbiBjbGllbnQgdG9wb2xvZ3kpIGNvbm5lY3RlZCB0byBCLCB0aGUgcmVsZXZh bnQgYWJzdHJhY3QgVEUgbGluayAodGhlIGZvcndhcmRpbmcgYWRqYWNlbmN5KSBzaG91bGQgYmUg YnVpbHQgYmV0d2VlbiBBoa8gYW5kIEKhrywgdGhhdCBpcyBpbiB0aGUgY2xpZW50IHRvcG9sb2d5 OyB0aGVyZWZvcmUgdGhlIGNsaWVudCBzaG91bGQgYmUgaW4gY2hhcmdlIG9mIG1hbmFnaW5nIGl0 LCBhcyB0aGUgcHJvdmlkZXIgaXMgbm90IGF3YXJlIG9mIEGhryBhbmQgQqGvLg0KDQpCUg0KRnJh bmNlc2NvDQoNCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIElnb3IgQnJ5c2tpbg0KU2VudDogMDQgTm92ZW1iZXIsIDIwMTYgNzoxMiBQTQ0K VG86IERpZXRlciBCZWxsZXIgPERpZXRlci5CZWxsZXJAbm9raWEuY29tPG1haWx0bzpEaWV0ZXIu QmVsbGVyQG5va2lhLmNvbT4+DQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz47IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KSA8Y2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj47IFNjaGFyZiwgTWljaGFlbCAoTm9raWEg LSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9r aWEuY29tPj47IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSA8 dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4+OyBwY2VAaWV0Zi5vcmc8bWFpbHRv OnBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFttcGxzXSBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAw DQoNCkRpZXRlciwNCg0KQSBjbGllbnQgbWF5IGFzayBmb3IgYSBwYXRoIG5vdCB0byBiZSB1c2Vk IGltbWVkaWF0ZWx5IChlLmcuIHRvIHByZXNlbnQgYXMgYW4gYWJzdHJhY3QgVEUgbGluayB0byBp dHMgb3duIGNsaWVudCwgaW4gc29tZSBmYWlsdXJlIHJlc3RvcmF0aW9uIHNjaGVtZSBvciBhcyBh IHBhcnQgb2YgZGlzYXN0ZXIgcmVjb3ZlcnkgbmV0d29yayB0b3BvbG9neSByZS1jb25maWd1cmF0 aW9uKSB3aXRob3V0IGNvbW1pdHRpbmcgYW55IG5ldHdvcmsgcmVzb3VyY2VzLiBJbiB0aGlzIGNh c2UgdGhlIGNsaWVudCB3b3VsZCB3YW50IHRvIGtub3cgYXQgbGVhc3QgIGlmL3doZW4gdGhlIHBh dGggaGFzIHN0b3BwZWQgYmVpbmcgZmVhc2libGUgYW55IGxvbmdlciBvciAoaWRlYWxseSkgYSBi ZXR0ZXIgcGF0aCBpcyBhdmFpbGFibGUuDQoNClRoaXMgaXMgc2ltaWxhciB0byBleHBvc2luZyB0 byBhIGNsaWVudCBhbiBhYnN0cmFjdCBURSB0b3BvbG9neSB3aXRoIGFuIHVuY29tbWl0dGVkIGFi c3RyYWN0IFRFIGxpbmsgKGkuZS4gVEUgbGluayB0aGF0IGRvZXMgbm90IGhhdmUgYSBjb21taXR0 ZWQgVEUgdHVubmVsIHN1cHBvcnRpbmcgaXQgYW5kIGFkdmVydGlzZXMgcG90ZW50aWFsaXR5KS4g T25jZSBzdWNoIGxpbmsgaXMgcHJvdmlkZWQsIHRoZSBwcm92aWRlciBpcyBleHBlY3RlZCB0byBz ZW5kIHVwZGF0ZXMgd2hlbi9pZiB0aGUgVEUgbGluayBhdHRyaWJ1dGVzIGNoYW5nZS4gRm9yIHVu Y29tbWl0dGVkL3BvdGVudGlhbCBURSBsaW5rIHN1Y2ggdXBkYXRlcyBjb3VsZCBiZSBwcm92aWRl ZCBiYXNlZCBvbiBldmVudCBkcml2ZW4gcmUtY29tcHV0YXRpb24gb2YgdGhlIHBvdGVudGlhbGl0 eSB0aGUgVEUgbGluayByZXByZXNlbnRzLg0KVGhlIHBvaW50IGlzIHRoYXQgYW4gdW5jb21taXR0 ZWQgYWJzdHJhY3QgVEUgbGluayBhbmQgQ09NUFVURV9PTkxZIFRFIHR1bm5lbCBjYW4gcmVwcmVz ZW50IChlYWNoIGluIGl0cyBvd24gd2F5KSB0aGUgc2FtZSBuZXR3b3JrIHBvdGVudGlhbGl0eQ0K DQpDaGVlcnMsDQpJZ29yDQoNCg0KDQpGcm9tOiBEaWV0ZXIgQmVsbGVyIFttYWlsdG86RGlldGVy LkJlbGxlckBub2tpYS5jb21dDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDA0LCAyMDE2IDE6NDkg UE0NClRvOiBJZ29yIEJyeXNraW4NCkNjOiBMZWV5b3VuZzsgU2NoYXJmLCBNaWNoYWVsIChOb2tp YSAtIERFKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVB UyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttcGxzXSBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAw DQoNCkhpIElnb3IsDQoNCmNvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSBob3cgdXNlZnVsIGEgc3Rh dGVmdWwgcGF0aCB3aXRob3V0IHJlc291cmNlIGFsbG9jYXRpb24gaXMuIEkgY2FuJ3Qgc2VlIHRo ZSBiZW5lZml0cyBvZiB0aGlzIHVzZSBjYXNlLg0KDQoNClRoYW5rcywNCkRpZXRlcg0KT24gMDQu MTEuMjAxNiAxNDoyNSwgSWdvciBCcnlza2luIHdyb3RlOg0KSGkgRGlldGVyLA0KDQpBIHByb3Zp ZGVyIG1heSBjb21wdXRlIHBhdGgocykgZm9yIGEgVEUgdHVubmVsLCBhbmQgdGhlbiAod2l0aG91 dCBhbnkgcmVzb3VyY2UgYWxsb2NhdGlvbikgbWF5IHN0YXJ0IG1vbml0b3JpbmcvZW5zdXJpbmcg dGhlIHBhdGggdmFsaWRpdHkvb3B0aW1hbGl0eSBieSByZS1jb21wdXRpbmcgdGhlbSBpbiBhbiBl dmVudCBkcml2ZW4gbWFubmVyLiBGb3IgZXhhbXBsZSwgaXQgY2FuIHRyaWdnZXIgdGhlIHJlLWNv bXB1dGF0aW9uIG9mIHRoZSBwYXRoKHMpIHdoZW4gZGV0ZWN0aW5nIGEgY2hhbmdlIGluIGEgc3Rh dGUgb2YgYSBURSBsaW5rIHRoZSBjdXJyZW50IHBhdGgocykgYXJlIGdvaW5nIHRocm91Z2guICBE ZXBlbmRpbmcgb24gdGhlIHJlc3VsdHMgYWRkaXRpb25hbCBub3RpZmljYXRpb25zIG1heSBiZSBz ZW50IHRvIHRoZSBjbGllbnQuDQoNCk5vdGUgdGhhdCB0aGlzIGlzIGluIGFkZGl0aW9uIHRvIHRo ZSByZWFzb25zIHlvdSBjb3JyZWN0bHkgaWRlbnRpZmllZCBmb3IgaW1wbGVtZW50aW5nIHN0YXRl ZnVsIHBhdGggY29tcHV0YXRpb24gKHN1Y2ggYXMgY29tcHV0ZV9hbmRfcmVzZXJ2ZSkuDQoNCkNo ZWVycywNCklnb3INCg0KDQpGcm9tOiBCZWxsZXIsIERpZXRlciAoTm9raWEgLSBERSkgW21haWx0 bzpkaWV0ZXIuYmVsbGVyQG5va2lhLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMywg MjAxNiA2OjI3IFBNDQpUbzogTGVleW91bmcNCkNjOiBJZ29yIEJyeXNraW47IFNjaGFyZiwgTWlj aGFlbCAoTm9raWEgLSBERSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYu b3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRm Lm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbXBsc10gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21w dXRhdGlvbi0wMA0KDQoNCkhpIGFsbCwNCg0KDQoNCndoZW4gd2UgdGFsayBhYm91dCB0aGUgc3Rh dGVmdWwgcGF0aCBjb21wdXRhdGlvbiB1c2UgY2FzZSwgaXQgbWVhbnMgSU1ITyB0aGF0IHdoZW4g YSBwYXRoIGhhcyBiZWVuIGNhbGN1bGF0ZWQgc3VjY2Vzc2Z1bGx5IGluIHJlc3BvbnNlIHRvIGEg cmVxdWVzdCwgYSBuZXcgcGF0aCBvYmplY3QgaXMgY3JlYXRlZCBpbiB0aGUgZGF0YSBzdG9yZS4g VGhpcyBkb2VzIG9ubHkgbWFrZSBzZW5zZSBpZiB0aGUgcmVzb3VyY2VzIGhhdmUgYmVlbiBhbGxv Y2F0ZWQgaW4gdGhlIFRFRCBvZiB0aGUgUENFIGlycmVzcGVjdGl2ZSBvZiB0aGUgZmFjdCB3aGV0 aGVyIHRoZSBjb25uZWN0aW9uIGFsb25nIHRoaXMgcGF0aCB3aWxsIGJlIGVzdGFibGlzaGVkIHJp Z2h0IGF3YXkgb3IgYXQgYSBsYXRlciBwb2ludCBpbiB0aW1lLiBUaGlzIHdpbGwgcHJldmVudCBm dXJ0aGVyIHBhdGggY29tcHV0YXRpb24gcmVxdWVzdHMgZnJvbSBhc3N1bWluZyB0aGF0IHRoZSBy ZXNvdXJjZXMgYXJlIHN0aWxsIGF2YWlsYWJsZS4gQXMgdGhlIFRFRCBvZiB0aGUgUENFIGFsc28g aGFzIHRvIHJlZmxlY3QgdGhlIG5ldHdvcmsgc3RhdGUsIEkgd291bGQgYXNzdW1lIHRoYXQgdGhl IG5ldHdvcmsgcmVzb3VyY2VzIGNhbiBiZSBpbiBvbmUgb2YgdGhlIGZvbGxvd2luZyB0aHJlZSBz dGF0ZXM6IGF2YWlsYWJsZSwgYWxsb2NhdGVkQnV0Tm90SW5Vc2UsICBhbGxvY2F0ZWRBbmRJblVz ZS4gVGhlIHBhdGggb2JqZWN0cyBhbHNvIG5lZWQgc3RhdGUgaW5mb3JtYXRpb24gcmVmbGVjdGlu ZyBmb3IgZXhhbXBsZSB0aGUgYWxhcm0gc3RhdGUgb2YgdGhlIGFsbG9jYXRlZCByZXNvdXJjZXMu IFRoZSBwYXRoIGNhbGN1bGF0ZWQgZWFybGllciBtYXkgYmVjb21lICh0ZW1wb3JhcmlseSkgaW52 YWxpZCBkdWUgdG8gYSBsaW5rIGZhaWx1cmUgYWZmZWN0aW5nIHRoZSBwYXRoLg0KDQoNCg0KRG9l cyB0aGlzIG1ha2Ugc2Vuc2U/DQoNCg0KDQoNCg0KVGhhbmtzLA0KDQpEaWV0ZXINCg0KDQoNClNl bnQgZnJvbSBteSB0YWJsZXQNCg0KDQoNCkxlZXlvdW5nIDxsZWV5b3VuZ0BodWF3ZWkuY29tPjxt YWlsdG86bGVleW91bmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCg0KSWdvciwNCg0KV2hlbiB5b3Ug c2F5IKGwc3RhdGWhsSwgYXJlIHlvdSByZWZlcnJpbmcgdG8gdGhlIFlBTkcgZGF0YXN0b3JlIG9y IHNvbWUgb3RoZXIgobBpbnRlcmltobEgc3RhdGUgb2YgdGhvc2UgcGF0aHMgdGhhdCBhcmUgY2Fs Y3VsYXRlZCBidXQgbm90IGluc3RhbnRpYXRlZCBhcyBMU1BzPyBJZiB3ZSB3ZXJlIHRvIHVwZGF0 ZSB0aGUgWUFORyBkYXRhc3RvcmUgZm9yIHRoaXMsIEkgd291bGQgdGhpbmsgdGhhdCB3ZSBtYXkg aGF2ZSBzb21lIGlzc3VlIHdoZW4gdGhlIGN1c3RvbWVyIGRlY2lkZWQgbm90IHRvIGluc3RhbnRp YXRlIHRoZSBURSB0dW5uZWwgKGFmdGVyIHRoZSBwYXRoIGNvbXB1dGUgcmVxdWVzdCkuDQoNClRo YW5rcy4NCllvdW5nDQoNCg0KRnJvbTogSWdvciBCcnlza2luDQpTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMDMsIDIwMTYgMzowMiBQTQ0KVG86IExlZXlvdW5nOyBTY2hhcmYsIE1pY2hhZWwgKE5v a2lhIC0gREUpOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBU RUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPik7IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpZ b3VuZywNCg0KRnJvbSB0aGUgcHJvdmlkZXIgY29udHJvbGxlciBwb2ludCBvZiB2aWV3IENPTVBV VEVfT05MWSBURSB0dW5uZWxzIHdpbGwgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIHN0YXRlIGFzIKGw bm9ybWFsobEgKENPTVBVVEVfQUROX1BST1ZJU0lPTikgVEUgdHVubmVscy4NCg0KSWdvcg0KDQpG cm9tOiBMZWV5b3VuZw0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6NDIgUE0N ClRvOiBJZ29yIEJyeXNraW47IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7IERhbmllbGUg Q2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4p OyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5v cmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNp YmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCklnb3IsDQoNCkluIHN1Y2ggY2Fz ZSwgd291bGQgdGhlIFlBTkcgZGF0YXN0b3JlIGJlIHVwZGF0ZWQ/IEkgZ3Vlc3Mgbm90LiBJZiBu b3QsIHRoZW4gdGhlIHN5c3RlbS9jb250cm9sbGVyIGhhcyB0byBrZWVwIHRoaXMgaW50ZXJpbSBz dGF0ZSwgd291bGQgaXQ/DQoNClRoYW5rcy4NCllvdW5nDQoNCkZyb206IElnb3IgQnJ5c2tpbg0K U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDI6MzQgUE0NClRvOiBTY2hhcmYsIE1p Y2hhZWwgKE5va2lhIC0gREUpOyBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAo Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9yZzxtYWls dG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRm Lm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgt Y29tcHV0YXRpb24tMDANCg0KTWljaGFlbCwNCllvdSBhcmUgZXhhY3RseSByaWdodC4gVGhlIHB1 cnBvc2Ugb2YgdGhlIKGwY29tcHV0ZS1vbmx5obEgVEUgdHVubmVsIGlzIHRvIGNyZWF0ZS9tYWlu dGFpbiB0aGUgbm9ybWFsIFRFIHR1bm5lbCBzdGF0ZSBhbmQgKHJlLSljb21wdXRlIFRFIHBhdGhz IGZvciB0aGUgVEUgdHVubmVsIGNvbm5lY3Rpb25zL0xTUHMgYnV0IG5vdCBzaWduYWwvcHJvdmlz aW9uIHRoZSBMU1BzLg0KDQpJZ29yDQoNCkZyb206IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE RSkgW21haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb21dDQpTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMDMsIDIwMTYgMzoxNyBQTQ0KVG86IExlZXlvdW5nOyBEYW5pZWxlIENlY2NhcmVsbGk7 IElnb3IgQnJ5c2tpbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9y Zz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i dXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCklzbqGvdCB0aGUgaW50ZW50 aW9uIG9mIGRlZmluaW5nICJjb21wdXRlLW9ubHkgdHVubmVsc6GwIHRvIGNyZWF0ZSBzdGF0ZSBp biB0aGUgY29udHJvbGxlciwgYnV0IG5vdCB0byBzaWduYWwgdGhlbT8gSWYgdGhlIHR1bm5lbCBz aG91bGQgYmUgc2lnbmFsZWQgYW5kIHJlc291cmNlcyBzaGFsbCBiZSBhbGxvY2F0ZWQsIHdoeSBu b3QganVzdCBjb25maWd1cmUgYSB2YW5pbGxhIHR1bm5lbD8gVXNlcyBjYXNlcyBzZWVtIHRvIGV4 aXN0IGZvciBib3RoIHZhcmlhbnRzLCBhbmQgYm90aCBjYW4gYmUgZW5jb2RlZCBpbiBZQU5HLiBJ cyB0aGVyZSBhbnl0aGluZyBJIG1pc3MgaGVyZT8NCg0KTWljaGFlbA0KDQoNCkZyb206IExlZXlv dW5nIFttYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAwMywgMjAxNiA3OjQ5IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgRGFu aWVsZSBDZWNjYXJlbGxpOyBJZ29yIEJyeXNraW47IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBU RUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPik7IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpI aSBNaWNoYWVsLA0KDQpJIHRoaW5rIEkgYW0gd2l0aCB5b3Ugb24geW91ciBwb2ludC4gSWYgd2Ug dXNlIHJwYywgaXQgaXMgY2xlYXIuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSB3ZXJlIHRvIHVz ZSChsHN0YXRlZnVsIGNvbXB1dGUtb25seaGxIGl0IHNlZW1zIHRoYXQgdGhlIHN5c3RlbS9jb250 cm9sbGVyIGhhcyB0byBrZWVwIHRoZSBzdGF0ZSBvZiB0aGUgcGF0aHMgc29tZXdoZXJlIHdoaWNo IGlzIG5vdCBZQU5HIGRhdGFzdG9yZS4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IFlBTkcgZGF0 YXN0b3JlIGlzIHVwZGF0ZWQgb25seSB3aGVuIHRoZSBwYXRoIGlzIHNpZ25hbGVkIGFuZCByZXNv dXJjZSBpcyBhbGxvY2F0ZWQuIFdvdWxkIHRoaXMgZ2l2ZSB0aGUgc3lzdGVtL2NvbnRyb2xsZXIg YWRkaXRpb25hbCBidXJkZW4gdG8ga2VlcCB0aGUgobBpbnRlcmltobEgc3RhdGU/DQoNCllvdW5n DQoNCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAwMywgMjAxNiA4OjU4IEFNDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBJZ29yIEJyeXNraW47 IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYu b3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0 ZWFzQGlldGYub3JnPik7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW0NDQU1QXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVs LXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCk1heWJlIEkgbWlzcyBzb21ldGhpbmcs IGJ1dCB0byBtZSwgdGhlIGRvbWFpbiBjb250cm9sbGVyIGVpdGhlciBjb21wdXRlcyBhIHBhdGgg c3RhdGVsZXNzLCB3aGljaCBjYW4gYmUgbW9kZWxlZCBpbiBZQU5HIGluIGFuIFJQQy4gT3IgdGhl IGRvbWFpbiBjb250cm9sbGVyIGNvbXB1dGVzIGEgcGF0aCwgc3RvcmVzIHN0YXRlLCBhbmQgcHJv dmlkZXMgYWNjZXNzIHRvIHRoZSByZXN1bHQgaW4gdGhlIFlBTkcgZGF0YXN0b3JlLiBJbiB0aGUg bGF0dGVyIGNhc2UsIHdoZXRoZXIgcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQsIG9yIHdoZXRoZXIg dGhlIE5FcyBnZXQgYWN0dWFsbHkgcHJvdmlzaW9uZWQsIGlzIGFuIG9ydGhvZ29uYWwgcXVlc3Rp b24uDQoNCkFzIGEgc2lkZSBub3RlLCBJIGFtIG5vdCBzdXJlIG9mIEkgd291bGQgY2FsbCBhIGRv bWFpbiBjb250cm9sbGVyIG9yIGFuIE5NUyBhIFBDRS4gUGF0aCBjb21wdXRhdGlvbiBpcyBvbmx5 IGEgc3Vic2V0IG9mIHRoZSBmdW5jdGlvbnMgb2YgYSBkb21haW4gY29udHJvbGxlci4NCg0KTWlj aGFlbA0KDQoNCg0KRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMywgMjAxNiAy OjQ5IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgSWdvciBCcnlza2luOyBD Q0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9y ZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVh c0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVj dDogUkU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5n LXBhdGgtY29tcHV0YXRpb24tMDANCg0KQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiB3aGF0IHRoZSCh sHN0YXRlZnVsIGNvbXB1dGUtb25seaGxIHN0YW5kcyBmb3IgSSBkb26hr3QgdW5kZXJzdGFuZCB3 aGF0IGlzIHN0YXRlZnVsIGluIGEgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0IG9ubHkuDQpJTUhP IGVpdGhlciBJIGFzayB0aGUgUENFIChTRE4gY29udHJvbGxlciwgTk1TLCB3aGF0ZXZlcikgdG8g Y29tcHV0ZSBhIHBhdGggYW5kIHRoZW4gZm9yZ2V0IGFib3V0IGl0IG9yIEkgYXNrIHRvIGNvbXB1 dGUgYW5kIHByb3Zpc2lvbiBpdC4gSSBkb26hr3QgdW5kZXJzdGFuZCB0aGUgdmFsdWUgb2YgYXNr aW5nIGZvciBpdCBhbmQgcmVtZW1iZXJpbmcgYWJvdXQgaXQuDQoNCkJSDQpEYW5pZWxlDQoNCkZy b206IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgW21haWx0bzptaWNoYWVsLnNjaGFyZkBu b2tpYS5jb21dDQpTZW50OiBnaW92ZWSorCAzIG5vdmVtYnJlIDIwMTYgMTQ6NDUNClRvOiBJZ29y IEJyeXNraW4gPElnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPG1haWx0bzpJZ29yLkJyeXNraW5AaHVh d2VpLmNvbT4+OyBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nv bi5jb208bWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+PjsgQ0NBTVAgKGNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pIDxjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+PjsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBU RUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPikgPHRlYXNAaWV0Zi5v cmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+PjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNp YmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCldlIGhhdmUgZGlzY3Vzc2VkIHRo aXMgYmVmb3JlLiBGcm9tIGFuIGltcGxlbWVudGVyoa9zIHBlcnNwZWN0aXZlLCB0aGUgdHdvIGNs ZWFuIHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbSBzZWVtIHRvIGVpdGhlciBzdGF0ZWZ1bCAiY29t cHV0ZS1vbmx5obAgdHVubmVscyBvciBhIHN0YXRlbGVzcyBSUEMuDQoNCk1pY2hhZWwNCg0KDQpG cm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWdv ciBCcnlza2luDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgMjozNCBQTQ0KVG86 IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBp ZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRl YXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtBTFVdIFttcGxzXWh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KSGks DQoNCkZyb20gdGhlIGRyYWZ0Og0KDQo2LiAgICBZQU5HIE1vZGVsIGZvciByZXF1ZXN0aW5nIFBh dGggQ29tcHV0YXRpb24NCg0KDQogICBXb3JrIG9uIGV4dGVuZGluZyB0aGUgVEUgVHVubmVsIFlB TkcgbW9kZWwgdG8gc3VwcG9ydCB0aGUgbmVlZCB0bw0KICAgcmVxdWVzdCBwYXRoIGNvbXB1dGF0 aW9uIGhhcyByZWNlbnRseSBzdGFydGVkIGFsc28gaW4gdGhlIGNvbnRleHQgb2YNCiAgIHRoZSBb VEUtVFVOTkVMPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMt eWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwI3JlZi1URS1UVU5ORUw+XSBkcmFmdC4NCg0KICAgSXQg aXMgcG9zc2libGUgdG8gcmVxdWVzdCBwYXRoIGNvbXB1dGF0aW9uIGJ5IGNvbmZpZ3VyaW5nIGEN CiAgICJjb21wdXRlLW9ubHkiIFRFIHR1bm5lbCBhbmQgcmV0cmlldmluZyB0aGUgY29tcHV0ZWQg cGF0aChzKSBpbiB0aGUNCiAgIExTUChzKSBSZWNvcmQtUm91dGUgT2JqZWN0IChSUk8pIGxpc3Qg YXMgZGVzY3JpYmVkIGluIFtURS1UVU5ORUw8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAjcmVmLVRFLVRVTk5FTD5d Lg0KDQogICBUaGlzIGlzIGEgc3RhdGVmdWwgc29sdXRpb24gc2luY2UgdGhlIHN0YXRlIG9mIGVh Y2ggY3JlYXRlZA0KICAgImNvbXB1dGUtb25seSIgVEUgdHVubmVsIG5lZWRzIHRvIGJlIG1haW50 YWluZWQgYW5kIHVwZGF0ZWQsIHdoZW4NCiAgIHVuZGVybHlpbmcgbmV0d29yayBjb25kaXRpb25z IGNoYW5nZS4NCg0KICAgVGhlIG5lZWQgYWxzbyBmb3IgYSBzdGF0ZWxlc3Mgc29sdXRpb24sIGJh c2VkIG9uIGFuIFJQQywgaGFzIGJlZW4NCiAgIHJlY29nbml6ZWQuDQoNCg0KICAgVGhlIFlBTkcg bW9kZWwgdG8gc3VwcG9ydCBzdGF0ZWxlc3MgUlBDIGlzIGZvciBmdXJ0aGVyIHN0dWR5Lg0KDQoN Cg0KDQoNCklCPj4gUGxlYXNlLCBub3RlLCB0aGF0IGluIHRoZSBURSBUdW5uZWwgbW9kZWwgd2Ug Y29uc2lkZXIgdGhlIENPTVBVVEVfQU5EX0ZPUkdFVCBtb2RlLiBXZSBhbHNvIGNvbnNpZGVyIHRo ZSBjb25jZXB0IG9mIHBhdGggY29tcHV0YXRpb24gYWN0aW9uIHRvIGJlIGRlZmluZWQgdW5kZXIg dGhlIFRFIHR1bm5lbCBub2RlLiBBbGwgdGhpcyBpcyB0byBmYWNpbGl0YXRlIHN0YXRlbGVzcyBw YXRoIGNvbXB1dGF0aW9ucy4NCg0KQ2hlZXJzLA0KSWdvcg0KDQoNCg0KDQo= --_000_F82A4B6D50F9464B8EBA55651F541CF8817AC188SZXEMA504MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I share the same understanding as Dieter and Francesco.

 

I don=A1=AFt see much value of the stateful path computation, bec= ause the computed path cannot be guaranteed and it brings much overhead as = Francesco pointed.

 

I think it makes sense if the resource of the stateful path shoul= d be reserved (or allocatedButNotInUse used by Dieter).

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Thanks<= o:p>

&n= bsp;

Fatai

 

=B7=A2=BC=FE=C8=CB:<= /b> CCAMP [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED Francesco Lazzeri
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA11=D4=C27=C8=D5 16:50
=CA=D5=BC=FE=C8=CB: Igor Bryskin; Dieter Beller
=B3=AD=CB=CD: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@= ietf.org; TEAS WG (teas@ietf.org)
=D6=F7=CC=E2: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00

 

 

The = point here is for how long the provider should keep the computed path and i= ts request parameters (in fact if we want to have a possibly better path, a= t any change inside provider topology, resource status and usage, the provider should check if the computed path = is still feasible and/or redo path computation to find a better path). This= could be an overhead, in my view.

 

Furt= hermore, I can=A1=AFt see how the provider could export the abstract TE-lin= k, as this is inside the client topology; in fact, if the client is asking = for a path between A and B (A and B inside provider topology), having A=A1=AF (in client topology) connected to A and= B=A1=AF (in client topology) connected to B, the relevant abstract TE link= (the forwarding adjacency) should be built between A=A1=AF and B=A1=AF, th= at is in the client topology; therefore the client should be in charge of managing it, as the provider is not aware of A=A1=AF and B= =A1=AF.

 

BR

Fran= cesco

 

F= rom: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Dieter,=

&n= bsp;

A clien= t may ask for a path not to be used immediately (e.g. to present as an abst= ract TE link to its own client, in some failure restoration scheme or as a = part of disaster recovery network topology re-configuration) without committing any network resources. In this case t= he client would want to know at least  if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available.=

&n= bsp;

This is= similar to exposing to a client an abstract TE topology with an uncommitte= d abstract TE link (i.e. TE link that does not have a committed TE tunnel s= upporting it and advertises potentiality). Once such link is provided, the provider is expected to send updates when/= if the TE link attributes change. For uncommitted/potential TE link such up= dates could be provided based on event driven re-computation of the potenti= ality the TE link represents.

The poi= nt is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunnel can r= epresent (each in its own way) the same network potentiality

&n= bsp;

Cheers,=

Igor

&n= bsp;

&n= bsp;

&n= bsp;

From:= Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

= Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Brysk= in wrote:

Hi Diet= er,

 <= /span>

A provi= der may compute path(s) for a TE tunnel, and then (without any resource all= ocation) may start monitoring/ensuring the path validity/optimality by re-c= omputing them in an event driven manner. For example, it can trigger the re-computation of the path(s) when detecti= ng a change in a state of a TE link the current path(s) are going through.&= nbsp; Depending on the results additional notifications may be sent to the = client.

 <= /span>

Note th= at this is in addition to the reasons you correctly identified for implemen= ting stateful path computation (such as compute_and_reserve).

 <= /span>

Cheers,=

Igor

 <= /span>

 <= /span>

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path comput=
ation use case, it means IMHO that when a path has been calculated successf=
ully in response to a request, a new path object is created in the data sto=
re. This does only make sense if the resources have been allocated in the T=
ED of the PCE irrespective of the fact whether the connection along this pa=
th will be established right away or at a later point in time. This will pr=
event further path computation requests from assuming that the resources ar=
e still available. As the TED of the PCE also has to reflect the network st=
ate, I would assume that the network resources can be in one of the followi=
ng three states: available, allocatedButNotInUse,  allocatedAndInUse. =
The path objects also need state information reflecting for example the ala=
rm state of the allocated resources. The path calculated earlier may become=
 (temporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 <= /span>

When yo= u say =A1=B0state=A1=B1, are you referring to the YANG datastore or some ot= her =A1=B0interim=A1=B1 state of those paths that are calculated but not in= stantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer deci= ded not to instantiate the TE tunnel (after the path compute request).

 <= /span>

Thanks.=

Young

 <= /span>

 <= /span>

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,<= /span>

 <= /span>

From th= e provider controller point of view COMPUTE_ONLY TE tunnels will have exact= ly the same state as =A1=B0normal=A1=B1 (COMPUTE_ADN_PROVISION) TE tunnels.=

 <= /span>

Igor

 <= /span>

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 <= /span>

In such= case, would the YANG datastore be updated? I guess not. If not, then the s= ystem/controller has to keep this interim state, would it?

 <= /span>

Thanks.=

Young

 <= /span>

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael= ,

You are= exactly right. The purpose of the =A1=B0compute-only=A1=B1 TE tunnel is to= create/maintain the normal TE tunnel state and (re-)compute TE paths for t= he TE tunnel connections/LSPs but not signal/provision the LSPs.

 <= /span>

Igor

 <= /span>

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn=A1= =AFt the intention of defining „compute-only tunnels=A1=B0 to create = state in the controller, but not to signal them? If the tunnel should be si= gnaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can= be encoded in YANG. Is there anything I miss here?

 <= /span>

Michael=

 <= /span>

 <= /span>

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 =

Hi Mich= ael,

 <= /span>

I think= I am with you on your point. If we use rpc, it is clear. On the other hand= , if we were to use =A1=B0stateful compute-only=A1=B1 it seems that the sys= tem/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datas= tore is updated only when the path is signaled and resource is allocated. W= ould this give the system/controller additional burden to keep the =A1=B0in= terim=A1=B1 state?

 <= /span>

Young

 <= /span>

From: CCAMP [mail= to:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

 <= /span>

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

 <= /span>

Michael=

 <= /span>

 <= /span>

 <= /span>

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 =

Can you please explain what the= =A1=B0stateful compute-only=A1=B1 stands for I don=A1=AFt understand what = is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don=A1=AFt understand the value of askin= g for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=A8=AC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 =

We have= discussed this before. From an implementer=A1=AFs perspective, the two cle= an solutions to the problem seem to either stateful „compute-only=A1= =B0 tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00<= /span>

 =

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

   Work on extending the TE Tunnel YANG model to support t= he need to

   request path computation has recently started also in t= he context of

   the [TE-TUNN= EL] draft.

 

   It is possible to request path computation by configuri= ng a

   "compute-only" TE tunnel and retrieving the c= omputed path(s) in the

   LSP(s) Record-Route Object (RRO) list as described in [= TE-TUNN= EL].

 

   This is a stateful solution since the state of each cre= ated

   "compute-only" TE tunnel needs to be maintain= ed and updated, when

   underlying network conditions change.

 

   The need also for a stateless solution, based on an RPC= , has been

   recognized.

 

 

   The YANG model to support stateless RPC is for further = study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

 

 <= /span>

 

--_000_F82A4B6D50F9464B8EBA55651F541CF8817AC188SZXEMA504MBSchi_-- From nobody Wed Nov 9 05:48:51 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAF1129499; Wed, 9 Nov 2016 05:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 DIGnODFFZrrj; Wed, 9 Nov 2016 05:48:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550EB12944D; Wed, 9 Nov 2016 05:48:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAA75170; Wed, 09 Nov 2016 13:48:40 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 13:48:39 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 05:48:29 -0800 From: Igor Bryskin To: Fatai Zhang , Francesco Lazzeri , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA Date: Wed, 9 Nov 2016 13:48:29 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F747dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58232939.0173, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bee9e4788904c3a2f3d547c3eaf515ee Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 13:48:49 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F747dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F747dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Francesco,

 

Please, see in-line= .

 

Cheers,<= /span>

Igor

 

The point here is f= or how long the provider should keep the computed path and its request para= meters

 

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.<= /span>

 

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 

 

 

 

BR

Francesco

 

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:diet= er.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyou=
ng@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F747dfweml501mbx_-- From nobody Wed Nov 9 06:25:54 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900E71298BC; Wed, 9 Nov 2016 06:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 kBiKOB0kxZWH; Wed, 9 Nov 2016 06:25:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023DA1297CC; Wed, 9 Nov 2016 06:25:41 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-3a-582331e32bf6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 0E.F7.31910.3E133285; Wed, 9 Nov 2016 15:25:40 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 9 Nov 2016 15:25:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rtIUdq5JLU0EigHU/YfKwJ/8S0iMiK/NZ1BCicjzm4I=; b=evS/qHTBoTGRj3kYoSY3KAh5E51XqsoCUyM1QLljW5Q+gc6fV/UucqxYUjh2nPf08Nn78T0DOm09MmD0eXRQ7CXOnUMOxBAJKqfdzpLj3Gj2dAk1C5xUXlXsBo6mDk8hQl0IO/3I/OFqDSZt7R2gL4j4EaRQeggXzfjgi2hYaew= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1524.eurprd07.prod.outlook.com (10.165.248.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Wed, 9 Nov 2016 14:25:37 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Wed, 9 Nov 2016 14:25:37 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6A= Date: Wed, 9 Nov 2016 14:25:37 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: b32cba26-e208-4a08-70d5-08d408ac467c x-microsoft-exchange-diagnostics: 1; AM4PR07MB1524; 7:eHYwFei+lVdB2zI97nzriL/hyeV7/4hJV4QiJDr28v6smglUiATso+h9ErJyEMx8OcVzNhiCUGQ3WJx7/PZglVNm4KPbLpTCc24fIDrP/ELLc1ocvh+TpPtSwIwTNLM4KVem99NIjcJEYmfhJzHp8MyAQnuDQvBQOFlU9ldtdejwqff4j/+bkDeLNDI26kWRDrGXUsmPIzBie6WHaQW/4qP0fcpTIFhVbPwDkZG4YQJazkWIkORf63fTfVnYxf3Mv4HjCQrrsF8zMrmplm2mD65TknGjmhOhHWGUVUSDmlQSbjhMGMcKyauNP1bld0pw35AxUntHo2Mb6GtmW0zshB7PAaYI4sx8327st5M/sxg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR07MB1524; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1524; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(189002)(377454003)(53754006)(199003)(7696004)(76176999)(81156014)(50986999)(8936002)(54356999)(122556002)(66066001)(220493001)(33656002)(86362001)(5660300001)(76576001)(2950100002)(68736007)(101416001)(106116001)(106356001)(105586002)(92566002)(7846002)(7906003)(74316002)(2906002)(230783001)(81166006)(8676002)(4326007)(93886004)(7736002)(9686002)(87936001)(189998001)(77096005)(97736004)(5001770100001)(3660700001)(3280700002)(586003)(102836003)(3900700001)(790700001)(3846002)(2900100001)(6116002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1524; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521754E4B30DF2F386DFB7196B90AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2016 14:25:37.4689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1524 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRTA+Xbv3a6jwee0PK2HusrIcj563SB6QA+JCiFIk9JWXdJ8jV3T tKjUtLRSAzW3xB5Oy6FCGqgUlQ8obbkMJTFNpzMnLiorTE2p653hf79zzu/jPPhoQt5GKejI 2HhWG6uOVoqlpC6k1sfH6r8ixC/FLmGsRV0kU2XoIZnpFn9mot2b6S4tp5jUvi4Jk/67jmSy 08zUDjrwSvMXKtBgmBAF9na/FwURodKtp9joyARW67vtuDSiqm+G1DT8Ic59fTZIXEZjL4ks 5EQD3gCWjloqC0lpOa5CYLZ/JoXgFYL+mWGCD0h8k4CRPJOIfyLHBSKwfUP/rZLJbIoviDED k813SJ5dcTIMjVvFvETgDwiK63skWYimXfBRaMtwFpxjkN9fM9vOFRcjKEsZoHiHxCuhPmMV 78j+6aXtQ475Wp3g85sSCV9wwrvBXpAv5hnhRTDeWjE7HYHdoNt6VyQsh8HwzOxYdCGMDM5Q gq+Gxwa9w/GEd8Y5PgDfv6fMbgb4HgG9hQ9IobAHGjptEoGjoOax2SFlIXhuuUEKQR2CscEO sWAtBX3rW0frVgrKbauE47HwsDId8eyCFdDbkYly0Rr9vMkFjoNbxhcS/ewJnKFFZyWFvAq6 8vPEAq+FsvujhMA+UDjTSM7P30MSI1rIsdyJmNMBASpWG3mS4+JiVbFsfDX698sankz51aGR 4Z2NCNNIuUCmsXmGyCl1ApcU04iAJpSuMp3fihC57JQ6KZnVxoVrz0azXCNaQpNKN9mm8r5g OT6tjmejWFbDaueqItpJcRkthqsWD8Xgp9XhHsmJ1XRM8/KDUs60sUbnHro5TvMV1e3vNnrt akqzB47Kg1y8ekrbjiTowyylEwc69wZd19iCL5lMiYf1/WHmnKbXRYap9T+HPk7nXlu3Zd/L 8V+HNsak+lZalgW0KIbzxi5UVmxXDRjPuJ+/+HTgdlTOrR/9mY+UJBeh9vcmtJz6Lzk4aQ9h AwAA Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 14:25:48 -0000 --_000_AM4PR07MB1521754E4B30DF2F386DFB7196B90AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang ; Francesco Lazzeri ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521754E4B30DF2F386DFB7196B90AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfatai@huawei.com>; Francesco Lazzeri <= ;francesco.lazzeri@ericsson.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.B= eller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.co=
m> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.c= om]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

--_000_AM4PR07MB1521754E4B30DF2F386DFB7196B90AM4PR07MB1521eurp_-- From nobody Wed Nov 9 06:47:29 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6412955D; Wed, 9 Nov 2016 06:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 VES09S_pl2QU; Wed, 9 Nov 2016 06:47:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F170A1294F4; Wed, 9 Nov 2016 06:47:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUV75684; Wed, 09 Nov 2016 14:47:15 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 14:47:15 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 06:47:04 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oA== Date: Wed, 9 Nov 2016 14:47:03 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F774dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.582336F5.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 14:47:26 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F774dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang ; Francesco Lazzeri ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F774dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Francesco,<= /span>

 

1)      IMHO simpli= city pays back. Instead than maintaining all these states, notifying client= s all the times something changes, and repeating path-computation as needed= , isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back= at that moment ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)      Regarding t= he abstract link in the overlay topology, I still can’t see what the = provider will advertise. If it’s a new link representing the forwardi= ng adjacency between A’ and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@erics= son.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfatai@huawei.com>; Francesco Lazzeri <= ;francesco.lazzeri@ericsson.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:diet= er.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyou=
ng@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F774dfweml501mbx_-- From nobody Wed Nov 9 07:27:48 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75BF1295A9; Wed, 9 Nov 2016 07:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 1HKzqBAgjwzA; Wed, 9 Nov 2016 07:27:33 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D977E12958B; Wed, 9 Nov 2016 07:27:31 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-a1-58234061ece3 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 1D.94.31910.16043285; Wed, 9 Nov 2016 16:27:30 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 9 Nov 2016 16:27:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RMqWcX0/E/uD7n3JMu0Yz2KiS0PVpy93LPhmyiKYo4w=; b=cSvY75md+CkQsXqe4vLezEbEeySPmNe/0Vv3/4mI1+4haYpDF5RpPquZfqDkggSlGv80CzIosWyNJHXuSGWGZU9LlnoZvNTiCvus+487ybptf4SQCmTm0PFoLqx8RhOe1UaSp4yjADSZPdwEj65Ig0Xokkc+KGZN0xUZCDbhcNE= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1523.eurprd07.prod.outlook.com (10.165.248.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Wed, 9 Nov 2016 15:27:08 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Wed, 9 Nov 2016 15:27:08 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACbog Date: Wed, 9 Nov 2016 15:27:08 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 87c7f186-be9a-440d-7524-08d408b4de78 x-microsoft-exchange-diagnostics: 1; AM4PR07MB1523; 7:FYvFjLS+A1oy/JeUXvJ65wVaRdrFYY8bkRJEQhfCqDeQHWK43oGebvWWgRG+Fhpu1ui9t3ST7QfW8W3PVHZQE8onWPf7AxAiR/sUr4MhxWEI1egQ2f8ewxWqW8oXJb1PAT4BiFHal21zo98g3vbiX2iYwhHka1hTiz+orY8vqF6XMgocVPnaLuYCFCrh+y1qi4LwavHHFC4c7prHpavb43AgOa5JpZaFkAo8xCtbPmy37qg/CoKX9iry3XwM02hEnQU1pO4N7Qk7N0zRoRQSDTaaLBP/vy8xcPp9+6QW86Ou7JGJasB1xER7YpseRENSwWPTYCbIDE5z1jFf76Kux6aTwICDU7cyTyEr+qbaO6I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1523; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1523; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(53754006)(189002)(199003)(24454002)(77096005)(81156014)(7846002)(81166006)(5660300001)(74316002)(8676002)(3280700002)(92566002)(66066001)(2906002)(790700001)(97736004)(2900100001)(102836003)(5001770100001)(6116002)(3900700001)(7736002)(3846002)(7906003)(87936001)(586003)(122556002)(105586002)(106116001)(106356001)(9686002)(50986999)(230783001)(7696004)(86362001)(93886004)(2950100002)(4326007)(3660700001)(220493001)(189998001)(68736007)(101416001)(54356999)(76176999)(8936002)(33656002)(76576001)(561944003)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1523; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB15214CB0075CBB583A96B82B96B90AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2016 15:27:08.4123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1523 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyzUYRzH99z3+z1fV2ePQz5Tyzr9gfyu1dcyP9oy68dWamVSOfmG4did LP6yovxe0TWO/KgjhI2sGKq7TCiRNMeYH0ey2EprfkXd3Zfmv9fz+bye5/15nj00IeqjbOgo aQIrk0pixHwBWRj08qRzmK9dkFteCcVMF2tJpl41SjLr3e7MyidHZqSimmJujWtNmLTlZpLJ vd1H+dIBqR0LVIBKtcILGBsZ4J0hggVe4WxMVCIrc/UOFUQu/lmi4jX51M389628FNTfQWYi UxrwIcipG9ezgBbhegRv2tUm3OIdgvTlWaNF4hwCKioDuMZDHmRlKNF/a2p4ChksPmZgtaPI uMMSJ8PM0jTfIBF4CEFJy6j+XJq2wCHw8Y4551wGxcRzY7YlrkHwWDlswsXthyX1b56BhXr/ Z9s6n0vTCmCiIZUyNEzxcRgsf2RMRngXLPXUGjcQ2BpGpkt53O0wqNr6CI6tYE63QXG+BBpU yk1nH/TXbPFp+DVaxzOEAS4jIL+9ffOZ/KH4dfomR0N2rprkpEwEryazNxvNCDIXPDneA8qe XoKTxihQqFuMESLMwtO6NOPYFtgGxgYz0D3koNw2OcdxoFv4amQhNofuwmmSq7uAVvGAz/EB qCz/TnDsDAUbGnJ7vQyZ1CArOSsPi43w8HBhZVHX5PI4qYuUTWhE+m+mblpza0Zzs34ahGkk 3in84WkXJKIkifKkWA0CmhBbCp/46EvCcElSMiuLuyq7EcPKNWg3TYqthYerxy+KcIQkgY1m 2XhWttXl0aY2KajIoemLOAbf/zsRLFqwOFals33mPRai6OT7r4V0XW+dPFu1WOp6vmKVCSx9 +2I2/m6G7engErMrB0M+zH92qjphv8OnNafAPm1mxEsrUpw75TwgblurjRUE9trZdfZIZ6Ny B7v2hg4crXT65uQ3dMlhrjep40hsiy7vQpPZaNb6fKOYlEdK3B0JmVzyD5egDE9iAwAA Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 15:27:38 -0000 --_000_AM4PR07MB15214CB0075CBB583A96B82B96B90AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". If there is no (more) path, there is no path. Th= e client could only try and crankback looking for some different path or re= port an alarm. The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB15214CB0075CBB583A96B82B96B90AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

1)      IMHO simpli= city pays back. Instead than maintaining all these states, notifying client= s all the times something changes, and repeating path-computation as needed= , isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back= at that moment ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

       FL>> Probably the sam= e in case the provider notifies “Hey, I have no longer anything for y= ou”. If there is no (more) path, there is no path. The client could only try an= d crankback looking for some different path or report an alarm.

The scenario that seems more applicable to your proposal is a pr= e-planned restoration mechanism where we have a worker path in-service and a protection path just computed (but = not reserving network resources, in order to share them among several prote= ction paths), in a multi-domain network. In that case, reserving te-tunnels= like you suggest, could give an advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the pro= tection path or some of its segments is no longer valid) and not when the p= ath deployment is triggered by the client (that means the worker path is gone and we need the protection immediately). Is = this the case you are considering ?

In other cases, as when used during an end-to-end path computati= on with immediate deployment to reduce the possibility of conflicts among concurrent procedures, it seems to me l= ess important or applicable, as all these procedures will likely be orchest= rated by the same entity, which could well avoid conflicts.

 

 <= /o:p>

2)      Regarding t= he abstract link in the overlay topology, I still can’t see what the = provider will advertise. If it’s a new link representing the forwardi= ng adjacency between A’ and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provi= der just sends the reply to the path computation request and doesn’t advertise any new TE link to the client ? This i= s actually what I would expect: the task to manage TE-links in the overlay = topology is with the client.

 

Francesco

&n= bsp;

&n= bsp;

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,<= /span>

 

1)      IMHO simpli= city pays back. Instead than maintaining all these states, notifying client= s all the times something changes, and repeating path-computation as needed= , isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back= at that moment ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)      Regarding t= he abstract link in the overlay topology, I still can’t see what the = provider will advertise. If it’s a new link representing the forwardi= ng adjacency between A’ and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mail= to:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfa= tai@huawei.com>; Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.B= eller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.co=
m> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.c= om]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

--_000_AM4PR07MB15214CB0075CBB583A96B82B96B90AM4PR07MB1521eurp_-- From nobody Wed Nov 9 07:57:43 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65153129541; Wed, 9 Nov 2016 07:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 1I88WuR2CuXU; Wed, 9 Nov 2016 07:57:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9751295C0; Wed, 9 Nov 2016 07:57:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUV85396; Wed, 09 Nov 2016 15:57:22 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 15:56:27 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 07:56:17 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnA= Date: Wed, 9 Nov 2016 15:56:16 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F7CAdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58234763.00E8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 15:57:33 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F7CAdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F7CAdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

<= /p>

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

&n= bsp;

&n= bsp;

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfa= tai@huawei.com>; Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:diet= er.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyou=
ng@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F7CAdfweml501mbx_-- From nobody Wed Nov 9 09:42:38 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F488129577; Wed, 9 Nov 2016 09:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 Ym1LcSzCJmh3; Wed, 9 Nov 2016 09:42:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92541294C8; Wed, 9 Nov 2016 09:42:09 -0800 (PST) X-AuditID: c1b4fb3a-83fff70000000467-fc-58235fee3468 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id CB.AB.01127.EEF53285; Wed, 9 Nov 2016 18:42:08 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 9 Nov 2016 18:42:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1ONPKf6vyy58SjCDjnC5WdDk0veo6JGtuxhiEOiH9Nw=; b=jWmYna9/uYUz5pXpMxJi4osJW8EBtobcch3o69WklBRtdJmt/3+I7RTPJ575oOu9WiSiMnbucY4SXZ75kBkArCDa/Hltycr1VBRg2bjzVmK1ej4s/12D8QePyDCIKFTo7g/NwIpTH2jr8Lav6pQLWUkT+yOq7e0WVeXJccIwz+U= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1523.eurprd07.prod.outlook.com (10.165.248.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Wed, 9 Nov 2016 17:42:03 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Wed, 9 Nov 2016 17:42:04 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgA== Date: Wed, 9 Nov 2016 17:42:03 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 51cdecdb-7f48-4af5-b430-08d408c7b7c3 x-microsoft-exchange-diagnostics: 1; AM4PR07MB1523; 7:lFJA21plvyD4hBMlWj+MvHzIs0ECjiPDRbpENDuCIdmpLVx93gQ2k4yzMRQwSZyvabB5u5MmyiO+XegSN20KAxZlcN7DJmhTYxevEj1OgaEt+jnWAXRxnZeqUIdmxoE3dEX5tqIOLZnQ575vC+pQ60ixSW8kygQ4W4G8YBwqjjVPYqF1lXufrRNH2A56wg8TJujYc+9eEkc71lC5/2QtDSGYruh6IvJ+LWIF9j+IQATMwNIzvxQTWwi9oZSbi3//UI7ZvYXcpQQrZc5EDd8gHhnfjEFE1bAgbzEovQG7I2PT/4yRQjOnCpA2GT3NMB71JU30QdhgJl3+LYodNrj7smWaQmeu5J+PlrtaNwMORwk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1523; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1523; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(53754006)(377454003)(199003)(189002)(86362001)(3660700001)(93886004)(2950100002)(4326007)(106356001)(105586002)(9686002)(106116001)(7696004)(50986999)(230783001)(76176999)(54356999)(8936002)(101416001)(229853002)(33656002)(561944003)(76576001)(220493001)(189998001)(68736007)(66066001)(92566002)(3280700002)(2906002)(81156014)(77096005)(5660300001)(8676002)(74316002)(7846002)(81166006)(7906003)(87936001)(7736002)(3900700001)(3846002)(122556002)(586003)(2900100001)(97736004)(790700001)(5001770100001)(6116002)(102836003)(579004)(559001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1523; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521A6A7B62AFD21D0F0BAAD96B90AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2016 17:42:03.9201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1523 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SeyyVYRzH97yX46XOPI6DX9SqU//QCMVe1aybJlKtq7VK7/KG4dB5ZS5r s3RDNWsuOcetHMSwuWwhJSdNjBAt5Dq3NSl/ZEKpc86rzX+f5/l+fs/z+z17GFLWTtsyIcoo XqXkwhQSMyrL/4WX41zANn/n7/fM2YnsPoqt0A5S7J9WF3ax24EdKCyh2VsjfSbsnV+1FPso sZPez3jfbp6lvbXaRcJ7aOAjcZK8YLYvkA8LieZVOz2vmAUXab5QkS0Nkpisgl4iAT0do5OR KQN4N9ydvI+SkRkjwxUIynKSKEMgwy0IdH+OGQIKPyShZWxFIloZBHTOVZqIC72VulgoMZRI MAtLzRpjuRzHweTChLGCxJ8R5NYN6isYxhJfhA93LUTnEqSPVlMGR47rEdRn1hKGgMLbIXP4 lvFQqd6vSRyTiD1NrYO6l2cNbIq9YOhth9FH2BoW2sqMTGIbGJjII8ThMGgbOkmRreDr+Aot +hxUatWrzlboKv3PflD1oIk0NAQ4n4Sfnc2UGByB7Mb7qxwKefOllChpELzLnFp9yloEybMe Im8EdVvH6s1zNMzkM+IEPBSX30EGtsS2MNSbhFKRvXpN42r9I5E4AvKXfdTG+S2gNWuCEhUn 6EtPk4i8A4qezpAiO8KTFR21dj8fmZQiK4EXhPAgV1cnXhVyVRAilE5KPqoK6f9YU83ynlrU NH1AhzCDFOulcx7b/GU0Fy3EhusQMKRCLq2+rN+SBnKxcbwqIkB1I4wXdMiOoRQ2UveSkfMy HMRF8aE8H8mr/qcEY2qbgE6EPh+FdgttvEXBzaMdx4ly94jpH3vtfif7HkgZyoh7FfWssT/+ vf1pLue6n+qT3Hf+9ealGM1MD1Flt4nhPdKc+2dnSovLudykQ3Xf3nQl5v09GHgtfnhc+TjJ p9tTY3uG7mFTbiqLQ7x0dpqELtm5LS3WG3a5nZL7lphbHXZLUFBCMOfiQKoE7h/MhmNkXwMA AA== Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 17:42:16 -0000 --_000_AM4PR07MB1521A6A7B62AFD21D0F0BAAD96B90AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521A6A7B62AFD21D0F0BAAD96B90AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

--_000_AM4PR07MB1521A6A7B62AFD21D0F0BAAD96B90AM4PR07MB1521eurp_-- From nobody Wed Nov 9 11:33:36 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511E41295AF; Wed, 9 Nov 2016 11:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 zvARJ6SN9xS8; Wed, 9 Nov 2016 11:33:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1615129559; Wed, 9 Nov 2016 11:33:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUW07592; Wed, 09 Nov 2016 19:33:17 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 19:33:16 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 11:33:07 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTA Date: Wed, 9 Nov 2016 19:33:06 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F824dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.582379FE.0303, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 19:33:30 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F824dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F824dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F824dfweml501mbx_-- From nobody Wed Nov 9 22:13:32 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F98912948F; Wed, 9 Nov 2016 22:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 jhIW7yJ716MF; Wed, 9 Nov 2016 22:13:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F381C129476; Wed, 9 Nov 2016 22:13:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUW61667; Thu, 10 Nov 2016 06:13:19 +0000 (GMT) Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 06:13:18 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.10]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 14:13:06 +0800 From: Fatai Zhang To: Igor Bryskin , Francesco Lazzeri , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAP//uG+AgAAKYICAAAX9gIAACzMAgAAIJACAAUXkoA== Date: Thu, 10 Nov 2016 06:13:06 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.162.94] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8817AC634SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58241000.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.10, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f25b10f72311b09d545105e131638d3a Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [CCAMP] =?gb2312?b?tPC4tDogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9y?= =?gb2312?b?Zy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRp?= =?gb2312?b?b24tMDA=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 06:13:29 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF8817AC634SZXEMA504MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSWdvciwNCg0KSSB0aGluayB0aGUgY2xpZW50IHdpbGwgc3RpbGwgbWVldCB0aGUgY2FzZSB0 aGF0IHRoZXJlIGlzIG5vIGF2YWlsYWJsZSBwYXRoIGZvciB0aGUgY2xpZW50Lg0KDQpUaGUgcHJv dmlkZXIgd2lsbCBoYXZlIG5vIGNoYW5jZSB0byByZS1wbGFuIHRoZSBwYXRoIHdoZW4gdGhlIGNs aWVudCBrbm93cyB0aGUgdW5mZWFzaWJpbGl0eSBhaGVhZCBvZiBzaG9ydCB0aW1lIChlLmcuLCBt aWxsaXNlY29uZHMgYmVmb3JlIGl0IHJlYWxseSBuZWVkcyB0aGUgcGF0aCkgb3IgdGhlIGNsaWVu dCBrbm93cyB0aGUgdW5mZWFzaWJpbGl0eSBhaGVhZCBvZiBtdWNoIHRpbWUgKGUuZy4sIGhvdXJz IG9yIGRheXMpIGJlZm9yZSBpdCByZWFsbHkgbmVlZHMsIGJ1dCB0aGVyZSBpcyBubyBzdWZmaWNp ZW50IGF2YWlsYWJsZSByZXNvdXJjZSBmb3IgdGhlIHByb3ZpZGVyIHRvIHJlLXBsYW4gdW5sZXNz IHRoZSBvcGVyYXRvcnMgYWRkIG1vcmUgcGh5c2ljYWwgbm9kZXMgb3IgbGlua3MuDQoNCkkgdGhp bmsgdGhlIHN0YXRlZnVsIHBhdGggY29tcHV0YXRpb24gaXMgYSBraW5kIG9mIKGwYmVzdCBlZmZv cnShsSwgYW5kIGl0IG1pZ2h0IGJlIHN1aXRhYmxlIGZvciBJUCBzZXJ2aWNlLCBidXQgZm9yIHRo ZSB0cmFuc3BvcnQgc2VydmljZSwgdGhlIHByb3RlY3Rpb24gY2FwYWJpbGl0eShhcyB5b3UgbWVu dGlvbmVkIGEgZmFpbHVyZSByZWNvdmVyeSBvciBjb25nZXN0aW9uIGF2b2lkYW5jZSBzdHJhdGVn eSBvciBkaXNhc3RlciB0b3BvbG9neSByZS1jb25maWd1cmF0aW9uKSBNVVNUIGJlIGd1YXJhbnRl ZWQgKGF0IGxlYXN0IGZvciBvbmUgc2luZ2xlIGZhaWx1cmUpIGlmIHRoZSBjbGllbnQgcmVhbGx5 IHJlbGllcyBvbiB0aGF0Lg0KDQpJIHRoaW5rIHRoZSBzaW1wbGUgd2F5IHRvIGd1YXJhbnRlZSB0 aGUgcHJvdGVjdGlvbiAob3Igd2hhdGV2ZXIpIGNhcGFiaWxpdHkgaXMgdG8gcmVzZXJ2ZSB0aGUg cmVzb3VyY2UgZm9yIHRoZSBkZXNpcmVkIHBhdGggYW5kIHRoZSByZXNlcnZlZCByZXNvdXJjZSBj b3VsZCBiZSBzaGFyZWQgYW1vbmcgbXVsdGlwbGUgcGF0aCAoVGhpcyBpcyB0aGUgY29uY2VwdCBv ZiBTaGFyZWQgTWVzaCBQcm90ZWN0aW9uIEkgaW50cm9kdWNlZCBpbiBJVFUtVCBTRzE1IGEgZmV3 IHllYXJzIGFnbywgYnV0IGhlcmUgd2UgY2FuIGp1c3QgcmVzZXJ2ZSB0aGUgcmVzb3VyY2UgZnJv bSB0aGUgY29udHJvbCBwbGFuZSBwZXJzcGVjdGl2ZSByYXRoZXIgdGhhbiByZXNlcnZlIHRoZSBy ZXNvdXJjZSBvbiB0aGUgZGF0YSBwbGFuZSB0aHJvdWdoIFNNUCBtZWNoYW5pc20pLg0KDQoNCg0K VGhhbmtzDQoNCkZhdGFpDQoNCreivP7IyzogSWdvciBCcnlza2luDQq3osvNyrG85DogMjAxNsTq MTHUwjnI1SAyMzo1Ng0KytW8/sjLOiBGcmFuY2VzY28gTGF6emVyaTsgRmF0YWkgWmhhbmc7IERp ZXRlciBCZWxsZXINCrOty806IG1wbHNAaWV0Zi5vcmc7IENDQU1QIChjY2FtcEBpZXRmLm9yZyk7 IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7IHBjZUBpZXRmLm9yZzsgVEVBUyBXRyAodGVh c0BpZXRmLm9yZykNCtb3zOI6IFJFOiBbbXBsc10gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpGcmFuY2VzY28s DQoNClBsZWFzZSwgc2VlIGluLWxpbmUuDQoNCklnb3INCg0KDQoNCkZyb206IFRlYXMgW21haWx0 bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmFuY2VzY28gTGF6emVyaQ0K U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxNiAxMDoyNyBBTQ0KVG86IElnb3IgQnJ5 c2tpbjsgRmF0YWkgWmhhbmc7IERpZXRlciBCZWxsZXINCkNjOiBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRm Lm9yZz4pOyBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyBwY2VAaWV0Zi5vcmc8bWFpbHRv OnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5v cmc+KQ0KU3ViamVjdDogUmU6IFtUZWFzXSBbbXBsc10gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpJZ29yLA0K DQoNCjEpICAgICAgSU1ITyBzaW1wbGljaXR5IHBheXMgYmFjay4gSW5zdGVhZCB0aGFuIG1haW50 YWluaW5nIGFsbCB0aGVzZSBzdGF0ZXMsIG5vdGlmeWluZyBjbGllbnRzIGFsbCB0aGUgdGltZXMg c29tZXRoaW5nIGNoYW5nZXMsIGFuZCByZXBlYXRpbmcgcGF0aC1jb21wdXRhdGlvbiBhcyBuZWVk ZWQsIGlzbqGvdCBiZXR0ZXIgZm9yIGEgY2xpZW50IChhbmQgcHJvdmlkZXIpIHRvIGFzayB3aGF0 IGlzIG5lZWRlZCB3aGVuIGl0oa9zIG5lZWRlZCwgYW5kIGdldCB0aGUgYmVzdCByZXN1bHQgYmFj ayBhdCB0aGF0IG1vbWVudCA/DQpJQj4+IFdoYXQgaGFwcGVucyBpdCB0aGUgcHJvdmlkZXIgYXQg dGhpcyBtb21lbnQgc2F5czogobAgTm8sIEkgaGF2ZSBub3RoaW5nIGZvciB5b3WhsSA/ICBXaGF0 IGlmIHRoZSBwYXRoIHdhcyByZWxpZWQgdXBvbiBieSB0aGUgY2xpZW50IGZvciBhIGZhaWx1cmUg cmVjb3Zlcnkgb3IgY29uZ2VzdGlvbiBhdm9pZGFuY2Ugc3RyYXRlZ3kgb3IgZGlzYXN0ZXIgdG9w b2xvZ3kgcmUtY29uZmlndXJhdGlvbj8NCiAgICAgICBGTD4+IFByb2JhYmx5IHRoZSBzYW1lIGlu IGNhc2UgdGhlIHByb3ZpZGVyIG5vdGlmaWVzIKGwSGV5LCBJIGhhdmUgbm8gbG9uZ2VyIGFueXRo aW5nIGZvciB5b3WhsS4NCg0KSUI+PiBCdXQgdGhpcyB3b3VsZCBiZSBhIGJpdCB0b28gbGF0ZSwg d291bGRuoa90IGl0PyBXb3VsZG6hr3QgaXQgYmUgYmV0dGVyIGlmIHRoZSBjbGllbnQgaGFzIGxl YXJudCBhYm91dCB0aGUgcHJldmlvdXNseSByZXR1cm5lZCBwYXRoIHVuZmVhc2liaWxpdHkgYWhl YWQgb2YgdGltZSwgc28gdGhhdCBpdCBjb3VsZCByZS1wbGFuIGl0oa9zIGZhaWx1cmUgcmVjb3Zl cnkgc2NoZW1lPw0KDQpJZiB0aGVyZSBpcyBubyAobW9yZSkgcGF0aCwgdGhlcmUgaXMgbm8gcGF0 aC4gVGhlIGNsaWVudCBjb3VsZCBvbmx5IHRyeSBhbmQgY3JhbmtiYWNrIGxvb2tpbmcgZm9yIHNv bWUgZGlmZmVyZW50IHBhdGggb3IgcmVwb3J0IGFuIGFsYXJtLg0KDQpJQj4+IFJlbHlpbmcgb24g Y3JhbmtiYWtzIGluIGFuIHVucHJlZGljdGFibGUgd2F5IGlzIG5vdCBleGFjdGx5IGEgZ29vZCBz b2x1dGlvbiwgcmlnaHQ/DQoNClRoZSBzY2VuYXJpbyB0aGF0IHNlZW1zIG1vcmUgYXBwbGljYWJs ZSB0byB5b3VyIHByb3Bvc2FsIGlzIGEgcHJlLXBsYW5uZWQgcmVzdG9yYXRpb24gbWVjaGFuaXNt IHdoZXJlIHdlIGhhdmUgYSB3b3JrZXIgcGF0aCBpbi1zZXJ2aWNlIGFuZCBhIHByb3RlY3Rpb24g cGF0aCBqdXN0IGNvbXB1dGVkIChidXQgbm90IHJlc2VydmluZyBuZXR3b3JrIHJlc291cmNlcywg aW4gb3JkZXIgdG8gc2hhcmUgdGhlbSBhbW9uZyBzZXZlcmFsIHByb3RlY3Rpb24gcGF0aHMpLCBp biBhIG11bHRpLWRvbWFpbiBuZXR3b3JrLiBJbiB0aGF0IGNhc2UsIHJlc2VydmluZyB0ZS10dW5u ZWxzIGxpa2UgeW91IHN1Z2dlc3QsIGNvdWxkIGdpdmUgYW4gYWR2YW50YWdlLCBhcyB0aGUgZW5k LXRvLWVuZCBjcmFuY2tiYWNrIGNvdWxkIG9jY3VyIHdoZW4gdGhlIG5vdGlmaWNhdGlvbiB3aXRo IKGwbm8tcGF0aKGxIGlzIHRyaWdnZXJlZCBieSB0aGUgcHJvdmlkZXIgKHRoYXQgbWVhbnMgdGhl IHByb3RlY3Rpb24gcGF0aCBvciBzb21lIG9mIGl0cyBzZWdtZW50cyBpcyBubyBsb25nZXIgdmFs aWQpIGFuZCBub3Qgd2hlbiB0aGUgcGF0aCBkZXBsb3ltZW50IGlzIHRyaWdnZXJlZCBieSB0aGUg Y2xpZW50ICh0aGF0IG1lYW5zIHRoZSB3b3JrZXIgcGF0aCBpcyBnb25lIGFuZCB3ZSBuZWVkIHRo ZSBwcm90ZWN0aW9uIGltbWVkaWF0ZWx5KS4gSXMgdGhpcyB0aGUgY2FzZSB5b3UgYXJlIGNvbnNp ZGVyaW5nID8NCg0KSUI+PiBFeGFjdGx5LiBBbGwgdGhlIHNjZW5hcmlvcyB5b3UgY2FuIHRoaW5r IG9mIHdoZXJlIHlvdSBkb26hr3Qga25vdyB3aGVuIGFuZCB3aGVyZSBhIHByb2JsZW0gbWF5IGhh cHBlbiBhbmQgeW91IHdhbnQgdG8gbWFpbnRhaW4gZmxleGliaWxpdHkgYW5kIHNoYXJlIHRoZSBu ZXR3b3JrIHJlc291cmNlcyB0byBwcm90ZWN0IGFzIG11Y2ggYXMgeW91IGNhbg0KDQpJbiBvdGhl ciBjYXNlcywgYXMgd2hlbiB1c2VkIGR1cmluZyBhbiBlbmQtdG8tZW5kIHBhdGggY29tcHV0YXRp b24gd2l0aCBpbW1lZGlhdGUgZGVwbG95bWVudCB0byByZWR1Y2UgdGhlIHBvc3NpYmlsaXR5IG9m IGNvbmZsaWN0cyBhbW9uZyBjb25jdXJyZW50IHByb2NlZHVyZXMsIGl0IHNlZW1zIHRvIG1lIGxl c3MgaW1wb3J0YW50IG9yIGFwcGxpY2FibGUsIGFzIGFsbCB0aGVzZSBwcm9jZWR1cmVzIHdpbGwg bGlrZWx5IGJlIG9yY2hlc3RyYXRlZCBieSB0aGUgc2FtZSBlbnRpdHksIHdoaWNoIGNvdWxkIHdl bGwgYXZvaWQgY29uZmxpY3RzLg0KDQpJQj4+IEFsbCBjYXNlcyB3aGVyZSB0aGUgcHJvdmlkZXIg d2FudHMgdG8gZXhwb3NlIGEgcG90ZW50aWFsaXR5IHdpdGhvdXQgY29tbWl0dGluZyByZXNvdXJj ZXMgdG8gY292ZXIgZm9yIHRoZSBjbGllbnQgbXVsdGlwbGUgdXNlIGNhc2VzIGFuZCBwcm92aWRl IGF0IHRoZSBzYW1lIHRpbWUgc29tZSBkZWdyZWUgKGFsYmVpdCBub3QgcGVyZmVjdCkgcHJlZGlj dGFiaWxpdHkuDQoNCg0KDQoNCjIpICAgICAgUmVnYXJkaW5nIHRoZSBhYnN0cmFjdCBsaW5rIGlu IHRoZSBvdmVybGF5IHRvcG9sb2d5LCBJIHN0aWxsIGNhbqGvdCBzZWUgd2hhdCB0aGUgcHJvdmlk ZXIgd2lsbCBhZHZlcnRpc2UuIElmIGl0oa9zIGEgbmV3IGxpbmsgcmVwcmVzZW50aW5nIHRoZSBm b3J3YXJkaW5nIGFkamFjZW5jeSBiZXR3ZWVuIEGhryBhbmQgQqGvLCBob3cgaXQgd2lsbCBiZSBy ZXByZXNlbnRlZCBieSB0aGUgcHJvdmlkZXIgPw0KDQpJQj4+IEFjY29yZGluZyB0byB0aGUgVEUg dG9wb2xvZ3kgbW9kZWwgYWJzdHJhY3QgVEUgbGluayBBoa9Coa8gcG9pbnRzIHRvIHRoZSB1bmRl cmxheSAocHJvdmlkZXIpIFRFIHRvcG9sb2d5IHdoZXJlIHRoZSBwYXRoIGlzIGNvbXB1dGVkIGFu ZCBwcm92aXNpb25lZCBhcyBzdXBwb3J0aW5nIFRFIHR1bm5lbCBmb3IgY29tbWl0dGVkIFRFIGxp bmsgb3Igbm90IHByb3Zpc2lvbmVkIChidXQgbW9uaXRvcmVkKSBmb3IgdW5jb21taXR0ZWQgVEUg bGluayAoaS5lLiBsaW5rIGFkdmVydGlzaW5nIHBvdGVudGlhbGl0eSBpbiB0aGUgcHJvdmlkZXIg bmV0d29yaykuIEluIGVpdGhlciBjYXNlIFRFIGxpbmuhr3MgYXR0cmlidXRlcyAoZS5nLiBhdmFp bGFibGUgYmFuZHdpZHRoLCBTUkxHcykgYXJlIGRlZmluZWQgYnkgdGhlIHBhdGguDQpGTD4+IFRo aXMgbWVhbnMgdGhhdCB0aGUgcHJvdmlkZXIganVzdCBzZW5kcyB0aGUgcmVwbHkgdG8gdGhlIHBh dGggY29tcHV0YXRpb24gcmVxdWVzdCBhbmQgZG9lc26hr3QgYWR2ZXJ0aXNlIGFueSBuZXcgVEUg bGluayB0byB0aGUgY2xpZW50ID8gVGhpcyBpcyBhY3R1YWxseSB3aGF0IEkgd291bGQgZXhwZWN0 OiB0aGUgdGFzayB0byBtYW5hZ2UgVEUtbGlua3MgaW4gdGhlIG92ZXJsYXkgdG9wb2xvZ3kgaXMg d2l0aCB0aGUgY2xpZW50Lg0KDQpJQj4+IE92ZXJsYXkgVEUgdG9wb2xvZ3kgbWFuYWdlciBhZHZl cnRpc2VzIGEgVEUgbGluayB0aGF0IGlzIHN1cHBvcnRlZCBub3QgYnkgYSBwcm92aXNpb25lZCBp biBhIHNlcnZlciBsYXllciBURSB0dW5uZWwgKGNvbm5lY3Rpb24pLCByYXRoZXIsIGJ5IGEgY29t cHV0ZWQgYW5kIG1vbml0b3JlZCBwYXRoLiBUaGlzIHdheSB0aGUgb3ZlcmxheSBURSB0b3BvbG9n eSBtYW5nZXIgY2FuIGFkdmVydGlzZSBtdWx0aXBsZSBhYnN0cmFjdCBURSBsaW5rcyBtYXBwZWQg b250byB0aGUgc2FtZSBuZXR3b3JrIHJlc291cmNlcw0KDQpGcmFuY2VzY28NCg0KDQpGcm9tOiBJ Z29yIEJyeXNraW4gW21haWx0bzpJZ29yLkJyeXNraW5AaHVhd2VpLmNvbV0NClNlbnQ6IDA5IE5v dmVtYmVyLCAyMDE2IDM6NDcgUE0NClRvOiBGcmFuY2VzY28gTGF6emVyaSA8ZnJhbmNlc2NvLmxh enplcmlAZXJpY3Nzb24uY29tPG1haWx0bzpmcmFuY2VzY28ubGF6emVyaUBlcmljc3Nvbi5jb20+ PjsgRmF0YWkgWmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbTxtYWlsdG86emhhbmdmYXRhaUBo dWF3ZWkuY29tPj47IERpZXRlciBCZWxsZXIgPERpZXRlci5CZWxsZXJAbm9raWEuY29tPG1haWx0 bzpEaWV0ZXIuQmVsbGVyQG5va2lhLmNvbT4+DQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz47IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ KSA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj47IFNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5z Y2hhcmZAbm9raWEuY29tPj47IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVB UyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pIDx0ZWFzQGlldGYub3Jn PG1haWx0bzp0ZWFzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbbXBsc10gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0w MA0KDQpGcmFuY2VzY28sDQoNCg0KMSkgICAgICBJTUhPIHNpbXBsaWNpdHkgcGF5cyBiYWNrLiBJ bnN0ZWFkIHRoYW4gbWFpbnRhaW5pbmcgYWxsIHRoZXNlIHN0YXRlcywgbm90aWZ5aW5nIGNsaWVu dHMgYWxsIHRoZSB0aW1lcyBzb21ldGhpbmcgY2hhbmdlcywgYW5kIHJlcGVhdGluZyBwYXRoLWNv bXB1dGF0aW9uIGFzIG5lZWRlZCwgaXNuoa90IGJldHRlciBmb3IgYSBjbGllbnQgKGFuZCBwcm92 aWRlcikgdG8gYXNrIHdoYXQgaXMgbmVlZGVkIHdoZW4gaXShr3MgbmVlZGVkLCBhbmQgZ2V0IHRo ZSBiZXN0IHJlc3VsdCBiYWNrIGF0IHRoYXQgbW9tZW50ID8NCklCPj4gV2hhdCBoYXBwZW5zIGl0 IHRoZSBwcm92aWRlciBhdCB0aGlzIG1vbWVudCBzYXlzOiChsCBObywgSSBoYXZlIG5vdGhpbmcg Zm9yIHlvdaGxID8gIFdoYXQgaWYgdGhlIHBhdGggd2FzIHJlbGllZCB1cG9uIGJ5IHRoZSBjbGll bnQgZm9yIGEgZmFpbHVyZSByZWNvdmVyeSBvciBjb25nZXN0aW9uIGF2b2lkYW5jZSBzdHJhdGVn eSBvciBkaXNhc3RlciB0b3BvbG9neSByZS1jb25maWd1cmF0aW9uPw0KDQoNCg0KDQoNCjIpICAg ICAgUmVnYXJkaW5nIHRoZSBhYnN0cmFjdCBsaW5rIGluIHRoZSBvdmVybGF5IHRvcG9sb2d5LCBJ IHN0aWxsIGNhbqGvdCBzZWUgd2hhdCB0aGUgcHJvdmlkZXIgd2lsbCBhZHZlcnRpc2UuIElmIGl0 oa9zIGEgbmV3IGxpbmsgcmVwcmVzZW50aW5nIHRoZSBmb3J3YXJkaW5nIGFkamFjZW5jeSBiZXR3 ZWVuIEGhryBhbmQgQqGvLCBob3cgaXQgd2lsbCBiZSByZXByZXNlbnRlZCBieSB0aGUgcHJvdmlk ZXIgPw0KDQpJQj4+IEFjY29yZGluZyB0byB0aGUgVEUgdG9wb2xvZ3kgbW9kZWwgYWJzdHJhY3Qg VEUgbGluayBBoa9Coa8gcG9pbnRzIHRvIHRoZSB1bmRlcmxheSAocHJvdmlkZXIpIFRFIHRvcG9s b2d5IHdoZXJlIHRoZSBwYXRoIGlzIGNvbXB1dGVkIGFuZCBwcm92aXNpb25lZCBhcyBzdXBwb3J0 aW5nIFRFIHR1bm5lbCBmb3IgY29tbWl0dGVkIFRFIGxpbmsgb3Igbm90IHByb3Zpc2lvbmVkIChi dXQgbW9uaXRvcmVkKSBmb3IgdW5jb21taXR0ZWQgVEUgbGluayAoaS5lLiBsaW5rIGFkdmVydGlz aW5nIHBvdGVudGlhbGl0eSBpbiB0aGUgcHJvdmlkZXIgbmV0d29yaykuIEluIGVpdGhlciBjYXNl IFRFIGxpbmuhr3MgYXR0cmlidXRlcyAoZS5nLiBhdmFpbGFibGUgYmFuZHdpZHRoLCBTUkxHcykg YXJlIGRlZmluZWQgYnkgdGhlIHBhdGguDQoNCg0KSWdvcg0KDQoNCkZyb206IEZyYW5jZXNjbyBM YXp6ZXJpIFttYWlsdG86ZnJhbmNlc2NvLmxhenplcmlAZXJpY3Nzb24uY29tXQ0KU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxNiA5OjI2IEFNDQpUbzogSWdvciBCcnlza2luOyBGYXRh aSBaaGFuZzsgRGlldGVyIEJlbGxlcg0KQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+OyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IFNj aGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYu b3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pDQpTdWJq ZWN0OiBSRTogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwt dGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KSWdvciwNCklNSE8gc2ltcGxpY2l0eSBw YXlzIGJhY2suIEluc3RlYWQgdGhhbiBtYWludGFpbmluZyBhbGwgdGhlc2Ugc3RhdGVzLCBub3Rp ZnlpbmcgY2xpZW50cyBhbGwgdGhlIHRpbWVzIHNvbWV0aGluZyBjaGFuZ2VzLCBhbmQgcmVwZWF0 aW5nIHBhdGgtY29tcHV0YXRpb24gYXMgbmVlZGVkLCBpc26hr3QgYmV0dGVyIGZvciBhIGNsaWVu dCAoYW5kIHByb3ZpZGVyKSB0byBhc2sgd2hhdCBpcyBuZWVkZWQgd2hlbiBpdKGvcyBuZWVkZWQs IGFuZCBnZXQgdGhlIGJlc3QgcmVzdWx0IGJhY2sgYXQgdGhhdCBtb21lbnQgPw0KUmVnYXJkaW5n IHRoZSBhYnN0cmFjdCBsaW5rIGluIHRoZSBvdmVybGF5IHRvcG9sb2d5LCBJIHN0aWxsIGNhbqGv dCBzZWUgd2hhdCB0aGUgcHJvdmlkZXIgd2lsbCBhZHZlcnRpc2UuIElmIGl0oa9zIGEgbmV3IGxp bmsgcmVwcmVzZW50aW5nIHRoZSBmb3J3YXJkaW5nIGFkamFjZW5jeSBiZXR3ZWVuIEGhryBhbmQg QqGvLCBob3cgaXQgd2lsbCBiZSByZXByZXNlbnRlZCBieSB0aGUgcHJvdmlkZXIgPw0KDQpCUg0K RnJhbmNlc2NvDQoNCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklnb3IuQnJ5c2tpbkBodWF3 ZWkuY29tXQ0KU2VudDogMDkgTm92ZW1iZXIsIDIwMTYgMjo0OCBQTQ0KVG86IEZhdGFpIFpoYW5n IDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb208bWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbT4+OyBG cmFuY2VzY28gTGF6emVyaSA8ZnJhbmNlc2NvLmxhenplcmlAZXJpY3Nzb24uY29tPG1haWx0bzpm cmFuY2VzY28ubGF6emVyaUBlcmljc3Nvbi5jb20+PjsgRGlldGVyIEJlbGxlciA8RGlldGVyLkJl bGxlckBub2tpYS5jb208bWFpbHRvOkRpZXRlci5CZWxsZXJAbm9raWEuY29tPj4NCkNjOiBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1h aWx0bzpjY2FtcEBpZXRmLm9yZz4pIDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5v cmc+PjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEu Y29tPG1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+PjsgcGNlQGlldGYub3JnPG1haWx0 bzpwY2VAaWV0Zi5vcmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYu b3JnPikgPHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6 IFttcGxzXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFu Zy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCkhpIEZyYW5jZXNjbywNCg0KUGxlYXNlLCBzZWUgaW4t bGluZS4NCg0KQ2hlZXJzLA0KSWdvcg0KDQpUaGUgcG9pbnQgaGVyZSBpcyBmb3IgaG93IGxvbmcg dGhlIHByb3ZpZGVyIHNob3VsZCBrZWVwIHRoZSBjb21wdXRlZCBwYXRoIGFuZCBpdHMgcmVxdWVz dCBwYXJhbWV0ZXJzDQoNCklCPj4gQXMgZmFyIGFzIHRoZSBwcm92aWRlciBpcyBjb25jZXJuZWQs IHRoZSByZXF1ZXN0ZWQgcGF0aCBhbmQgaXRzIHBhcmFtZXRlcnMgaXMgYSBURSB0dW5uZWwgKGFs YmVpdCBjb21wdXRlZCBidXQgbm90IHByb3Zpc2lvbmVkKS4gU28gaXQga2VlcHMgdGhlIHN0YXRl IHVudGlsIHRoZSBjbGllbnQgcmVtb3ZlcyB0aGUgVEUgdHVubmVsLg0KDQooaW4gZmFjdCBpZiB3 ZSB3YW50IHRvIGhhdmUgYSBwb3NzaWJseSBiZXR0ZXIgcGF0aCwgYXQgYW55IGNoYW5nZSBpbnNp ZGUgcHJvdmlkZXIgdG9wb2xvZ3ksIHJlc291cmNlIHN0YXR1cyBhbmQgdXNhZ2UsIHRoZSBwcm92 aWRlciBzaG91bGQgY2hlY2sgaWYgdGhlIGNvbXB1dGVkIHBhdGggaXMgc3RpbGwgZmVhc2libGUg YW5kL29yIHJlZG8gcGF0aCBjb21wdXRhdGlvbiB0byBmaW5kIGEgYmV0dGVyIHBhdGgpLiBUaGlz IGNvdWxkIGJlIGFuIG92ZXJoZWFkLCBpbiBteSB2aWV3Lg0KDQpJQj4+IEZvciBleGFtcGxlLCBp ZiBwcm92aWRlciBpcyB0byBlbnN1cmUgdGhlIHBhdGihr3MgZmVhc2liaWxpdHksIGFsbCBpdCBu ZWVkcyBpcyB0byBkZXRlY3QgYSBjaGFuZ2UgaW4gYSBURSBsaW5rIHRoZSBwYXRoIGlzIGdvaW5n IHRocm91Z2ggYW5kIG1ha2Ugc3VyZSB0aGF0IHRoZSAgY2hhbmdlIGRvZXMgbm90IG1ha2UgdGhl IHBhdGggdW5mZWFzaWJsZS4gT25seSBpbiB0aGUgbGF0dGVyIGNhc2UgdGhlIHBhdGggcmUtY29t cHV0YXRpb24gbmVlZHMgdG8gYmUgc2NoZWR1bGVkIGFuZCBwZXJmb3JtZWQgaW4gYSBiYWNrZ3Jv dW5kIHRocmVhZC4NCg0KRnVydGhlcm1vcmUsIEkgY2Fuoa90IHNlZSBob3cgdGhlIHByb3ZpZGVy IGNvdWxkIGV4cG9ydCB0aGUgYWJzdHJhY3QgVEUtbGluaywgYXMgdGhpcyBpcyBpbnNpZGUgdGhl IGNsaWVudCB0b3BvbG9neTsNCklCPj4gVGhlIGFic3RyYWN0IGxpbmsgaXMgYSBwYXJ0IG9mIHRo ZSBhYnN0cmFjdCB0b3BvbG9neSChsGNvb2tlZKGxIChjdXN0b21pemVkKSBmb3IgdGhlIGNsaWVu dCwgd2hpY2ggaXMgc3VwcG9ydGVkIGJ5IHRoZSBjb21wdXRlZCBwYXRoIGluIHRoZSB1bmRlcmxh eSB0b3BvbG9neSwgd2hpY2ggaXMgdGhlIHByb3ZpZGVyoa9zIHRvcG9sb2d5Lg0KDQppbiBmYWN0 LCBpZiB0aGUgY2xpZW50IGlzIGFza2luZyBmb3IgYSBwYXRoIGJldHdlZW4gQSBhbmQgQiAoQSBh bmQgQiBpbnNpZGUgcHJvdmlkZXIgdG9wb2xvZ3kpLCBoYXZpbmcgQaGvIChpbiBjbGllbnQgdG9w b2xvZ3kpIGNvbm5lY3RlZCB0byBBIGFuZCBCoa8gKGluIGNsaWVudCB0b3BvbG9neSkgY29ubmVj dGVkIHRvIEIsIHRoZSByZWxldmFudCBhYnN0cmFjdCBURSBsaW5rICh0aGUgZm9yd2FyZGluZyBh ZGphY2VuY3kpIHNob3VsZCBiZSBidWlsdCBiZXR3ZWVuIEGhryBhbmQgQqGvLCB0aGF0IGlzIGlu IHRoZSBjbGllbnQgdG9wb2xvZ3k7IHRoZXJlZm9yZSB0aGUgY2xpZW50IHNob3VsZCBiZSBpbiBj aGFyZ2Ugb2YgbWFuYWdpbmcgaXQsIGFzIHRoZSBwcm92aWRlciBpcyBub3QgYXdhcmUgb2YgQaGv IGFuZCBCoa8uDQoNCklCPj4gVGhpcyBpcyBjb3JyZWN0LCBidXQgbm90ZSB0aGF0IHRoZSB0d28g dG9wb2xvZ2llcyAodW5kZXJsYXkgYW5kIG92ZXJsYXkpIGFjY29yZGluZyB0byB0aGUgVEUgdG9w b2xvZ3kgbW9kZWwgaGF2ZSBpbmRlcGVuZGVudCBhbmQgdW5yZWxhdGVkIG5hbWUgc3BhY2VzIGZv ciBub2RlLCBsaW5rIGFuZCBTUkxHIElEcy4gU28gaXQgaXMgcGVyZmVjdGx5IE9rLg0KDQpJQj4+ IEFsc28gbm90ZSB0aGF0IGFjY29yZGluZyAgdG8gVEUgdG9wb2xvZ3kgbW9kZWwgIG9uZSBpbXBv cnRhbnQgYXR0cmlidXRlIG9mIGEgVEUgbm9kZSAoZXNwZWNpYWxseSBhYnN0cmFjdCBjb21wb3Np dGUgbm9kZSkgaXMgY29ubmVjdGl2aXR5IG1hdHJpeCwgd2hpY2ggaXMgbm90aGluZyBidXQgYSBz ZXQgb2Ygc3RhdGVmdWwgcGF0aHMgY29tcHV0ZWQsIHJlLWNvbXB1dGVkIGFuZCBjb25zdGFudGx5 IG1vbml0b3JlZCAoYnV0IG5vdCByZXNlcnZlZCkgb3ZlciB0aGUgVEUgdG9wb2xvZ3kgdGhlIG5v ZGUgZW5jYXBzdWxhdGVzLiAgVGhpcyBtZWFucyB0aGF0IHN0YXRlZnVsIHVucmVzZXJ2ZWQgcGF0 aHMgcGxheSBhbHJlYWR5IGEgdmVyeSBpbXBvcnRhbnQgcGFydCBpbiBzdXBwb3J0aW5nIFRFIHRv cG9sb2dpZXMgd2l0aCBhc3ltbWV0cmljYWwgYmxvY2tpbmcgYWJzdHJhY3QgVEUgbm9kZXMuDQoN Cklnb3INCg0KDQoNCg0KQlINCkZyYW5jZXNjbw0KDQpGcm9tOiBDQ0FNUCBbbWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJZ29yIEJyeXNraW4NClNlbnQ6IDA0IE5v dmVtYmVyLCAyMDE2IDc6MTIgUE0NClRvOiBEaWV0ZXIgQmVsbGVyIDxEaWV0ZXIuQmVsbGVyQG5v a2lhLmNvbTxtYWlsdG86RGlldGVyLkJlbGxlckBub2tpYS5jb20+Pg0KQ2M6IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNj YW1wQGlldGYub3JnPikgPGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+OyBT Y2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb208bWFp bHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1h aWx0bzp0ZWFzQGlldGYub3JnPikgPHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+ PjsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1Q XSBbbXBsc10gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlh bmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpEaWV0ZXIsDQoNCkEgY2xpZW50IG1heSBhc2sgZm9y IGEgcGF0aCBub3QgdG8gYmUgdXNlZCBpbW1lZGlhdGVseSAoZS5nLiB0byBwcmVzZW50IGFzIGFu IGFic3RyYWN0IFRFIGxpbmsgdG8gaXRzIG93biBjbGllbnQsIGluIHNvbWUgZmFpbHVyZSByZXN0 b3JhdGlvbiBzY2hlbWUgb3IgYXMgYSBwYXJ0IG9mIGRpc2FzdGVyIHJlY292ZXJ5IG5ldHdvcmsg dG9wb2xvZ3kgcmUtY29uZmlndXJhdGlvbikgd2l0aG91dCBjb21taXR0aW5nIGFueSBuZXR3b3Jr IHJlc291cmNlcy4gSW4gdGhpcyBjYXNlIHRoZSBjbGllbnQgd291bGQgd2FudCB0byBrbm93IGF0 IGxlYXN0ICBpZi93aGVuIHRoZSBwYXRoIGhhcyBzdG9wcGVkIGJlaW5nIGZlYXNpYmxlIGFueSBs b25nZXIgb3IgKGlkZWFsbHkpIGEgYmV0dGVyIHBhdGggaXMgYXZhaWxhYmxlLg0KDQpUaGlzIGlz IHNpbWlsYXIgdG8gZXhwb3NpbmcgdG8gYSBjbGllbnQgYW4gYWJzdHJhY3QgVEUgdG9wb2xvZ3kg d2l0aCBhbiB1bmNvbW1pdHRlZCBhYnN0cmFjdCBURSBsaW5rIChpLmUuIFRFIGxpbmsgdGhhdCBk b2VzIG5vdCBoYXZlIGEgY29tbWl0dGVkIFRFIHR1bm5lbCBzdXBwb3J0aW5nIGl0IGFuZCBhZHZl cnRpc2VzIHBvdGVudGlhbGl0eSkuIE9uY2Ugc3VjaCBsaW5rIGlzIHByb3ZpZGVkLCB0aGUgcHJv dmlkZXIgaXMgZXhwZWN0ZWQgdG8gc2VuZCB1cGRhdGVzIHdoZW4vaWYgdGhlIFRFIGxpbmsgYXR0 cmlidXRlcyBjaGFuZ2UuIEZvciB1bmNvbW1pdHRlZC9wb3RlbnRpYWwgVEUgbGluayBzdWNoIHVw ZGF0ZXMgY291bGQgYmUgcHJvdmlkZWQgYmFzZWQgb24gZXZlbnQgZHJpdmVuIHJlLWNvbXB1dGF0 aW9uIG9mIHRoZSBwb3RlbnRpYWxpdHkgdGhlIFRFIGxpbmsgcmVwcmVzZW50cy4NClRoZSBwb2lu dCBpcyB0aGF0IGFuIHVuY29tbWl0dGVkIGFic3RyYWN0IFRFIGxpbmsgYW5kIENPTVBVVEVfT05M WSBURSB0dW5uZWwgY2FuIHJlcHJlc2VudCAoZWFjaCBpbiBpdHMgb3duIHdheSkgdGhlIHNhbWUg bmV0d29yayBwb3RlbnRpYWxpdHkNCg0KQ2hlZXJzLA0KSWdvcg0KDQoNCg0KRnJvbTogRGlldGVy IEJlbGxlciBbbWFpbHRvOkRpZXRlci5CZWxsZXJAbm9raWEuY29tXQ0KU2VudDogRnJpZGF5LCBO b3ZlbWJlciAwNCwgMjAxNiAxOjQ5IFBNDQpUbzogSWdvciBCcnlza2luDQpDYzogTGVleW91bmc7 IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAg KGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8bWFp bHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0 Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbbXBsc10gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlh bmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpIaSBJZ29yLA0KDQpjb3VsZCB5b3UgcGxlYXNlIGNs YXJpZnkgaG93IHVzZWZ1bCBhIHN0YXRlZnVsIHBhdGggd2l0aG91dCByZXNvdXJjZSBhbGxvY2F0 aW9uIGlzLiBJIGNhbid0IHNlZSB0aGUgYmVuZWZpdHMgb2YgdGhpcyB1c2UgY2FzZS4NCg0KDQpU aGFua3MsDQpEaWV0ZXINCk9uIDA0LjExLjIwMTYgMTQ6MjUsIElnb3IgQnJ5c2tpbiB3cm90ZToN CkhpIERpZXRlciwNCg0KQSBwcm92aWRlciBtYXkgY29tcHV0ZSBwYXRoKHMpIGZvciBhIFRFIHR1 bm5lbCwgYW5kIHRoZW4gKHdpdGhvdXQgYW55IHJlc291cmNlIGFsbG9jYXRpb24pIG1heSBzdGFy dCBtb25pdG9yaW5nL2Vuc3VyaW5nIHRoZSBwYXRoIHZhbGlkaXR5L29wdGltYWxpdHkgYnkgcmUt Y29tcHV0aW5nIHRoZW0gaW4gYW4gZXZlbnQgZHJpdmVuIG1hbm5lci4gRm9yIGV4YW1wbGUsIGl0 IGNhbiB0cmlnZ2VyIHRoZSByZS1jb21wdXRhdGlvbiBvZiB0aGUgcGF0aChzKSB3aGVuIGRldGVj dGluZyBhIGNoYW5nZSBpbiBhIHN0YXRlIG9mIGEgVEUgbGluayB0aGUgY3VycmVudCBwYXRoKHMp IGFyZSBnb2luZyB0aHJvdWdoLiAgRGVwZW5kaW5nIG9uIHRoZSByZXN1bHRzIGFkZGl0aW9uYWwg bm90aWZpY2F0aW9ucyBtYXkgYmUgc2VudCB0byB0aGUgY2xpZW50Lg0KDQpOb3RlIHRoYXQgdGhp cyBpcyBpbiBhZGRpdGlvbiB0byB0aGUgcmVhc29ucyB5b3UgY29ycmVjdGx5IGlkZW50aWZpZWQg Zm9yIGltcGxlbWVudGluZyBzdGF0ZWZ1bCBwYXRoIGNvbXB1dGF0aW9uIChzdWNoIGFzIGNvbXB1 dGVfYW5kX3Jlc2VydmUpLg0KDQpDaGVlcnMsDQpJZ29yDQoNCg0KRnJvbTogQmVsbGVyLCBEaWV0 ZXIgKE5va2lhIC0gREUpIFttYWlsdG86ZGlldGVyLmJlbGxlckBub2tpYS5jb21dDQpTZW50OiBU aHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgNjoyNyBQTQ0KVG86IExlZXlvdW5nDQpDYzogSWdv ciBCcnlza2luOyBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyBEYW5pZWxlIENlY2NhcmVs bGk7IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGll dGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0 bzp0ZWFzQGlldGYub3JnPik7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2li ZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KDQpIaSBhbGwsDQoNCg0KDQp3aGVu IHdlIHRhbGsgYWJvdXQgdGhlIHN0YXRlZnVsIHBhdGggY29tcHV0YXRpb24gdXNlIGNhc2UsIGl0 IG1lYW5zIElNSE8gdGhhdCB3aGVuIGEgcGF0aCBoYXMgYmVlbiBjYWxjdWxhdGVkIHN1Y2Nlc3Nm dWxseSBpbiByZXNwb25zZSB0byBhIHJlcXVlc3QsIGEgbmV3IHBhdGggb2JqZWN0IGlzIGNyZWF0 ZWQgaW4gdGhlIGRhdGEgc3RvcmUuIFRoaXMgZG9lcyBvbmx5IG1ha2Ugc2Vuc2UgaWYgdGhlIHJl c291cmNlcyBoYXZlIGJlZW4gYWxsb2NhdGVkIGluIHRoZSBURUQgb2YgdGhlIFBDRSBpcnJlc3Bl Y3RpdmUgb2YgdGhlIGZhY3Qgd2hldGhlciB0aGUgY29ubmVjdGlvbiBhbG9uZyB0aGlzIHBhdGgg d2lsbCBiZSBlc3RhYmxpc2hlZCByaWdodCBhd2F5IG9yIGF0IGEgbGF0ZXIgcG9pbnQgaW4gdGlt ZS4gVGhpcyB3aWxsIHByZXZlbnQgZnVydGhlciBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3RzIGZy b20gYXNzdW1pbmcgdGhhdCB0aGUgcmVzb3VyY2VzIGFyZSBzdGlsbCBhdmFpbGFibGUuIEFzIHRo ZSBURUQgb2YgdGhlIFBDRSBhbHNvIGhhcyB0byByZWZsZWN0IHRoZSBuZXR3b3JrIHN0YXRlLCBJ IHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBuZXR3b3JrIHJlc291cmNlcyBjYW4gYmUgaW4gb25lIG9m IHRoZSBmb2xsb3dpbmcgdGhyZWUgc3RhdGVzOiBhdmFpbGFibGUsIGFsbG9jYXRlZEJ1dE5vdElu VXNlLCAgYWxsb2NhdGVkQW5kSW5Vc2UuIFRoZSBwYXRoIG9iamVjdHMgYWxzbyBuZWVkIHN0YXRl IGluZm9ybWF0aW9uIHJlZmxlY3RpbmcgZm9yIGV4YW1wbGUgdGhlIGFsYXJtIHN0YXRlIG9mIHRo ZSBhbGxvY2F0ZWQgcmVzb3VyY2VzLiBUaGUgcGF0aCBjYWxjdWxhdGVkIGVhcmxpZXIgbWF5IGJl Y29tZSAodGVtcG9yYXJpbHkpIGludmFsaWQgZHVlIHRvIGEgbGluayBmYWlsdXJlIGFmZmVjdGlu ZyB0aGUgcGF0aC4NCg0KDQoNCkRvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQoNCg0KDQoNClRoYW5r cywNCg0KRGlldGVyDQoNCg0KDQpTZW50IGZyb20gbXkgdGFibGV0DQoNCg0KDQpMZWV5b3VuZyA8 bGVleW91bmdAaHVhd2VpLmNvbT48bWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb20+IHdyb3RlOg0K DQoNCklnb3IsDQoNCldoZW4geW91IHNheSChsHN0YXRlobEsIGFyZSB5b3UgcmVmZXJyaW5nIHRv IHRoZSBZQU5HIGRhdGFzdG9yZSBvciBzb21lIG90aGVyIKGwaW50ZXJpbaGxIHN0YXRlIG9mIHRo b3NlIHBhdGhzIHRoYXQgYXJlIGNhbGN1bGF0ZWQgYnV0IG5vdCBpbnN0YW50aWF0ZWQgYXMgTFNQ cz8gSWYgd2Ugd2VyZSB0byB1cGRhdGUgdGhlIFlBTkcgZGF0YXN0b3JlIGZvciB0aGlzLCBJIHdv dWxkIHRoaW5rIHRoYXQgd2UgbWF5IGhhdmUgc29tZSBpc3N1ZSB3aGVuIHRoZSBjdXN0b21lciBk ZWNpZGVkIG5vdCB0byBpbnN0YW50aWF0ZSB0aGUgVEUgdHVubmVsIChhZnRlciB0aGUgcGF0aCBj b21wdXRlIHJlcXVlc3QpLg0KDQpUaGFua3MuDQpZb3VuZw0KDQoNCkZyb206IElnb3IgQnJ5c2tp bg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6MDIgUE0NClRvOiBMZWV5b3Vu ZzsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FN UCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9yZzxt YWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0Bp ZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDog UkU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBh dGgtY29tcHV0YXRpb24tMDANCg0KWW91bmcsDQoNCkZyb20gdGhlIHByb3ZpZGVyIGNvbnRyb2xs ZXIgcG9pbnQgb2YgdmlldyBDT01QVVRFX09OTFkgVEUgdHVubmVscyB3aWxsIGhhdmUgZXhhY3Rs eSB0aGUgc2FtZSBzdGF0ZSBhcyChsG5vcm1hbKGxIChDT01QVVRFX0FETl9QUk9WSVNJT04pIFRF IHR1bm5lbHMuDQoNCklnb3INCg0KRnJvbTogTGVleW91bmcNClNlbnQ6IFRodXJzZGF5LCBOb3Zl bWJlciAwMywgMjAxNiAzOjQyIFBNDQpUbzogSWdvciBCcnlza2luOyBTY2hhcmYsIE1pY2hhZWwg KE5va2lhIC0gREUpOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIChjY2FtcEBpZXRmLm9yZzxt YWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+ OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPik7IG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0K DQpJZ29yLA0KDQpJbiBzdWNoIGNhc2UsIHdvdWxkIHRoZSBZQU5HIGRhdGFzdG9yZSBiZSB1cGRh dGVkPyBJIGd1ZXNzIG5vdC4gSWYgbm90LCB0aGVuIHRoZSBzeXN0ZW0vY29udHJvbGxlciBoYXMg dG8ga2VlcCB0aGlzIGludGVyaW0gc3RhdGUsIHdvdWxkIGl0Pw0KDQpUaGFua3MuDQpZb3VuZw0K DQpGcm9tOiBJZ29yIEJyeXNraW4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMywgMjAxNiAy OjM0IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgTGVleW91bmc7IERhbmll bGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9y Zz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i dXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCk1pY2hhZWwsDQpZb3UgYXJl IGV4YWN0bHkgcmlnaHQuIFRoZSBwdXJwb3NlIG9mIHRoZSChsGNvbXB1dGUtb25seaGxIFRFIHR1 bm5lbCBpcyB0byBjcmVhdGUvbWFpbnRhaW4gdGhlIG5vcm1hbCBURSB0dW5uZWwgc3RhdGUgYW5k IChyZS0pY29tcHV0ZSBURSBwYXRocyBmb3IgdGhlIFRFIHR1bm5lbCBjb25uZWN0aW9ucy9MU1Bz IGJ1dCBub3Qgc2lnbmFsL3Byb3Zpc2lvbiB0aGUgTFNQcy4NCg0KSWdvcg0KDQpGcm9tOiBTY2hh cmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIFttYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29t XQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6MTcgUE0NClRvOiBMZWV5b3Vu ZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBJZ29yIEJyeXNraW47IENDQU1QIChjY2FtcEBpZXRmLm9y ZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5v cmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPik7IG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0w MA0KDQpJc26hr3QgdGhlIGludGVudGlvbiBvZiBkZWZpbmluZyAiY29tcHV0ZS1vbmx5IHR1bm5l bHOhsCB0byBjcmVhdGUgc3RhdGUgaW4gdGhlIGNvbnRyb2xsZXIsIGJ1dCBub3QgdG8gc2lnbmFs IHRoZW0/IElmIHRoZSB0dW5uZWwgc2hvdWxkIGJlIHNpZ25hbGVkIGFuZCByZXNvdXJjZXMgc2hh bGwgYmUgYWxsb2NhdGVkLCB3aHkgbm90IGp1c3QgY29uZmlndXJlIGEgdmFuaWxsYSB0dW5uZWw/ IFVzZXMgY2FzZXMgc2VlbSB0byBleGlzdCBmb3IgYm90aCB2YXJpYW50cywgYW5kIGJvdGggY2Fu IGJlIGVuY29kZWQgaW4gWUFORy4gSXMgdGhlcmUgYW55dGhpbmcgSSBtaXNzIGhlcmU/DQoNCk1p Y2hhZWwNCg0KDQpGcm9tOiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb21dDQpT ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgNzo0OSBQTQ0KVG86IFNjaGFyZiwgTWlj aGFlbCAoTm9raWEgLSBERSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgSWdvciBCcnlza2luOyBDQ0FN UCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9yZzxt YWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0Bp ZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDog UkU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBh dGgtY29tcHV0YXRpb24tMDANCg0KSGkgTWljaGFlbCwNCg0KSSB0aGluayBJIGFtIHdpdGggeW91 IG9uIHlvdXIgcG9pbnQuIElmIHdlIHVzZSBycGMsIGl0IGlzIGNsZWFyLiBPbiB0aGUgb3RoZXIg aGFuZCwgaWYgd2Ugd2VyZSB0byB1c2UgobBzdGF0ZWZ1bCBjb21wdXRlLW9ubHmhsSBpdCBzZWVt cyB0aGF0IHRoZSBzeXN0ZW0vY29udHJvbGxlciBoYXMgdG8ga2VlcCB0aGUgc3RhdGUgb2YgdGhl IHBhdGhzIHNvbWV3aGVyZSB3aGljaCBpcyBub3QgWUFORyBkYXRhc3RvcmUuIE15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCBZQU5HIGRhdGFzdG9yZSBpcyB1cGRhdGVkIG9ubHkgd2hlbiB0aGUgcGF0 aCBpcyBzaWduYWxlZCBhbmQgcmVzb3VyY2UgaXMgYWxsb2NhdGVkLiBXb3VsZCB0aGlzIGdpdmUg dGhlIHN5c3RlbS9jb250cm9sbGVyIGFkZGl0aW9uYWwgYnVyZGVuIHRvIGtlZXAgdGhlIKGwaW50 ZXJpbaGxIHN0YXRlPw0KDQpZb3VuZw0KDQpGcm9tOiBDQ0FNUCBbbWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQpT ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgODo1OCBBTQ0KVG86IERhbmllbGUgQ2Vj Y2FyZWxsaTsgSWdvciBCcnlza2luOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1w QGlldGYub3JnPik7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAo dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpN YXliZSBJIG1pc3Mgc29tZXRoaW5nLCBidXQgdG8gbWUsIHRoZSBkb21haW4gY29udHJvbGxlciBl aXRoZXIgY29tcHV0ZXMgYSBwYXRoIHN0YXRlbGVzcywgd2hpY2ggY2FuIGJlIG1vZGVsZWQgaW4g WUFORyBpbiBhbiBSUEMuIE9yIHRoZSBkb21haW4gY29udHJvbGxlciBjb21wdXRlcyBhIHBhdGgs IHN0b3JlcyBzdGF0ZSwgYW5kIHByb3ZpZGVzIGFjY2VzcyB0byB0aGUgcmVzdWx0IGluIHRoZSBZ QU5HIGRhdGFzdG9yZS4gSW4gdGhlIGxhdHRlciBjYXNlLCB3aGV0aGVyIHJlc291cmNlcyBhcmUg YWxsb2NhdGVkLCBvciB3aGV0aGVyIHRoZSBORXMgZ2V0IGFjdHVhbGx5IHByb3Zpc2lvbmVkLCBp cyBhbiBvcnRob2dvbmFsIHF1ZXN0aW9uLg0KDQpBcyBhIHNpZGUgbm90ZSwgSSBhbSBub3Qgc3Vy ZSBvZiBJIHdvdWxkIGNhbGwgYSBkb21haW4gY29udHJvbGxlciBvciBhbiBOTVMgYSBQQ0UuIFBh dGggY29tcHV0YXRpb24gaXMgb25seSBhIHN1YnNldCBvZiB0aGUgZnVuY3Rpb25zIG9mIGEgZG9t YWluIGNvbnRyb2xsZXIuDQoNCk1pY2hhZWwNCg0KDQoNCkZyb206IERhbmllbGUgQ2VjY2FyZWxs aSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQpTZW50OiBUaHVyc2Rh eSwgTm92ZW1iZXIgMDMsIDIwMTYgMjo0OSBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEg LSBERSk7IElnb3IgQnJ5c2tpbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBp ZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRl YXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCkNhbiB5b3UgcGxl YXNlIGV4cGxhaW4gd2hhdCB0aGUgobBzdGF0ZWZ1bCBjb21wdXRlLW9ubHmhsSBzdGFuZHMgZm9y IEkgZG9uoa90IHVuZGVyc3RhbmQgd2hhdCBpcyBzdGF0ZWZ1bCBpbiBhIHBhdGggY29tcHV0YXRp b24gcmVxdWVzdCBvbmx5Lg0KSU1ITyBlaXRoZXIgSSBhc2sgdGhlIFBDRSAoU0ROIGNvbnRyb2xs ZXIsIE5NUywgd2hhdGV2ZXIpIHRvIGNvbXB1dGUgYSBwYXRoIGFuZCB0aGVuIGZvcmdldCBhYm91 dCBpdCBvciBJIGFzayB0byBjb21wdXRlIGFuZCBwcm92aXNpb24gaXQuIEkgZG9uoa90IHVuZGVy c3RhbmQgdGhlIHZhbHVlIG9mIGFza2luZyBmb3IgaXQgYW5kIHJlbWVtYmVyaW5nIGFib3V0IGl0 Lg0KDQpCUg0KRGFuaWVsZQ0KDQpGcm9tOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIFtt YWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tXQ0KU2VudDogZ2lvdmVkqKwgMyBub3ZlbWJy ZSAyMDE2IDE0OjQ1DQpUbzogSWdvciBCcnlza2luIDxJZ29yLkJyeXNraW5AaHVhd2VpLmNvbTxt YWlsdG86SWdvci5Ccnlza2luQGh1YXdlaS5jb20+PjsgRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5p ZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJp Y3Nzb24uY29tPj47IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ KSA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj47IHBjZUBpZXRmLm9yZzxt YWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0Bp ZXRmLm9yZz4pIDx0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPj47IG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0K DQpXZSBoYXZlIGRpc2N1c3NlZCB0aGlzIGJlZm9yZS4gRnJvbSBhbiBpbXBsZW1lbnRlcqGvcyBw ZXJzcGVjdGl2ZSwgdGhlIHR3byBjbGVhbiBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW0gc2VlbSB0 byBlaXRoZXIgc3RhdGVmdWwgImNvbXB1dGUtb25seaGwIHR1bm5lbHMgb3IgYSBzdGF0ZWxlc3Mg UlBDLg0KDQpNaWNoYWVsDQoNCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIElnb3IgQnJ5c2tpbg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVy IDAzLCAyMDE2IDI6MzQgUE0NClRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIChjY2FtcEBp ZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VA aWV0Zi5vcmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPik7 IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbQUxVXSBbbXBs c11odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRo LWNvbXB1dGF0aW9uLTAwDQoNCkhpLA0KDQpGcm9tIHRoZSBkcmFmdDoNCg0KNi4gICAgWUFORyBN b2RlbCBmb3IgcmVxdWVzdGluZyBQYXRoIENvbXB1dGF0aW9uDQoNCg0KICAgV29yayBvbiBleHRl bmRpbmcgdGhlIFRFIFR1bm5lbCBZQU5HIG1vZGVsIHRvIHN1cHBvcnQgdGhlIG5lZWQgdG8NCiAg IHJlcXVlc3QgcGF0aCBjb21wdXRhdGlvbiBoYXMgcmVjZW50bHkgc3RhcnRlZCBhbHNvIGluIHRo ZSBjb250ZXh0IG9mDQogICB0aGUgW1RFLVRVTk5FTDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMCNyZWYtVEUtVFVO TkVMPl0gZHJhZnQuDQoNCiAgIEl0IGlzIHBvc3NpYmxlIHRvIHJlcXVlc3QgcGF0aCBjb21wdXRh dGlvbiBieSBjb25maWd1cmluZyBhDQogICAiY29tcHV0ZS1vbmx5IiBURSB0dW5uZWwgYW5kIHJl dHJpZXZpbmcgdGhlIGNvbXB1dGVkIHBhdGgocykgaW4gdGhlDQogICBMU1AocykgUmVjb3JkLVJv dXRlIE9iamVjdCAoUlJPKSBsaXN0IGFzIGRlc2NyaWJlZCBpbiBbVEUtVFVOTkVMPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0 aW9uLTAwI3JlZi1URS1UVU5ORUw+XS4NCg0KICAgVGhpcyBpcyBhIHN0YXRlZnVsIHNvbHV0aW9u IHNpbmNlIHRoZSBzdGF0ZSBvZiBlYWNoIGNyZWF0ZWQNCiAgICJjb21wdXRlLW9ubHkiIFRFIHR1 bm5lbCBuZWVkcyB0byBiZSBtYWludGFpbmVkIGFuZCB1cGRhdGVkLCB3aGVuDQogICB1bmRlcmx5 aW5nIG5ldHdvcmsgY29uZGl0aW9ucyBjaGFuZ2UuDQoNCiAgIFRoZSBuZWVkIGFsc28gZm9yIGEg c3RhdGVsZXNzIHNvbHV0aW9uLCBiYXNlZCBvbiBhbiBSUEMsIGhhcyBiZWVuDQogICByZWNvZ25p emVkLg0KDQoNCiAgIFRoZSBZQU5HIG1vZGVsIHRvIHN1cHBvcnQgc3RhdGVsZXNzIFJQQyBpcyBm b3IgZnVydGhlciBzdHVkeS4NCg0KDQoNCg0KDQpJQj4+IFBsZWFzZSwgbm90ZSwgdGhhdCBpbiB0 aGUgVEUgVHVubmVsIG1vZGVsIHdlIGNvbnNpZGVyIHRoZSBDT01QVVRFX0FORF9GT1JHRVQgbW9k ZS4gV2UgYWxzbyBjb25zaWRlciB0aGUgY29uY2VwdCBvZiBwYXRoIGNvbXB1dGF0aW9uIGFjdGlv biB0byBiZSBkZWZpbmVkIHVuZGVyIHRoZSBURSB0dW5uZWwgbm9kZS4gQWxsIHRoaXMgaXMgdG8g ZmFjaWxpdGF0ZSBzdGF0ZWxlc3MgcGF0aCBjb21wdXRhdGlvbnMuDQoNCkNoZWVycywNCklnb3IN Cg0KDQoNCg0KDQoNCg0KDQoNCg0K --_000_F82A4B6D50F9464B8EBA55651F541CF8817AC634SZXEMA504MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

I think the client will still meet the case that there is no avai= lable path for the client.

 

The provider will have no chance to re-plan the path when the cli= ent knows the unfeasibility ahead of short time (e.g., milliseconds before = it really needs the path) or the client knows the unfeasibility ahead of much time (e.g., hours or days) before it= really needs, but there is no sufficient available resource for the provid= er to re-plan unless the operators add more physical nodes or links.

 

I think= the stateful path comput= ation is a kind of =A1=B0best effort=A1=B1, and it might be suitable for IP= service, but for the transport service, the protection capability(as you m= entioned a failure recovery or congestion avoidance strategy or disaster topology re-configuration) MUST be guaranteed (at lea= st for one single failure) if the client really relies on that.

&n= bsp;

I think= the simple way to guarantee the protection (or whatever) capability is to = reserve the resource for the desired path and the reserved resource could be shared among multiple path (This is the= concept of Shared Mesh Protection I introduced in ITU-T SG15 a few years a= go, but here we can just reserve the resource from the control plane perspe= ctive rather than reserve the resource on the data plane through SMP mechanism).

&n= bsp;

&n= bsp;

&n= bsp;

Thanks<= o:p>

&n= bsp;

Fatai

 

=B7=A2=BC=FE=C8=CB:= Igor Bryskin
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2016=C4=EA11=D4=C29=C8=D5 23:56
=CA=D5=BC=FE=C8=CB: Francesco Lazzeri; Fatai Zhang; Dieter Beller
=B3=AD=CB=CD: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@= ietf.org; TEAS WG (teas@ietf.org)
=D6=F7=CC=E2: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00

 

Frances= co,

&n= bsp;

Please,= see in-line.

&n= bsp;

Igor

&n= bsp;

&n= bsp;

&n= bsp;

From:= Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

&n= bsp;

1)      IMHO simplicity pays= back. Instead than maintaining all these states, notifying clients all the= times something changes, and repeating path-computation as needed, isn=A1= =AFt better for a client (and provider) to ask what is needed when it=A1=AFs needed, and get the best result back at = that moment ?

IB>> What happens it the provider at this mo= ment says: =A1=B0 No, I have nothing for you=A1=B1 ?  What if the path= was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

&nbs= p;      FL>> Probably the same in case the p= rovider notifies =A1=B0Hey, I have no longer anything for you=A1=B1.

 

IB>> = But this would be a bit too late, wouldn=A1=AFt it? Wouldn=A1=AFt it be bet= ter if the client has learnt about the previously returned path unfeasibili= ty ahead of time, so that it could re-plan it=A1=AFs failure recovery scheme?

 

If t= here is no (more) path, there is no path. The client could only try and cra= nkback looking for some different path or report an alarm.

 

IB>> = Relying on crankbaks in an unpredictable way is not exactly a good solution= , right?

 

The = scenario that seems more applicable to your proposal is a pre-planned resto= ration mechanism where we have a worker path in-service and a protection pa= th just computed (but not reserving network resources, in order to share them among several protection paths), in a mu= lti-domain network. In that case, reserving te-tunnels like you suggest, co= uld give an advantage, as the end-to-end cranckback could occur when the no= tification with =A1=B0no-path=A1=B1 is triggered by the provider (that means the protection path or some of its segments is= no longer valid) and not when the path deployment is triggered by the clie= nt (that means the worker path is gone and we need the protection immediate= ly). Is this the case you are considering ?

 

IB>> = Exactly. All the scenarios you can think of where you don=A1=AFt know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can

 

In o= ther cases, as when used during an end-to-end path computation with immedia= te deployment to reduce the possibility of conflicts among concurrent proce= dures, it seems to me less important or applicable, as all these procedures will likely be orchestrated by the sam= e entity, which could well avoid conflicts.

 

IB>> = All cases where the provider wants to expose a potentiality without committ= ing resources to cover for the client multiple use cases and provide at the= same time some degree (albeit not perfect) predictability.

 

 

2)      Regarding the abstra= ct link in the overlay topology, I still can=A1=AFt see what the provider w= ill advertise. If it=A1=AFs a new link representing the forwarding adjacenc= y between A=A1=AF and B=A1=AF, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstrac= t TE link A=A1=AFB=A1=AF points to the underlay (provider) TE topology wher= e the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncomm= itted TE link (i.e. link advertising potentiality in the provider network).= In either case TE link=A1=AFs attributes (e.g. available bandwidth, SRLGs)= are defined by the path.

FL>> This means that the provider just sends= the reply to the path computation request and doesn=A1=AFt advertise any n= ew TE link to the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with = the client.

 

IB>> Overlay TE topology manager advertises a TE li= nk that is supported not by a provisioned in a server layer TE tunnel (conn= ection), rather, by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE= links mapped onto the same network resources 

 

Fran= cesco=

&n= bsp;

&n= bsp;

F= rom: Igor Bryski= n [mailto:Igor.Bryskin@huawei.co= m]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Frances= co,

&n= bsp;

1)      IMHO simplicity pays= back. Instead than maintaining all these states, notifying clients all the= times something changes, and repeating path-computation as needed, isn=A1= =AFt better for a client (and provider) to ask what is needed when it=A1=AFs needed, and get the best result back at = that moment ?

IB>> What happens it the provider at this mo= ment says: =A1=B0 No, I have nothing for you=A1=B1 ?  What if the path= was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 

 

2)      Regarding the abstra= ct link in the overlay topology, I still can=A1=AFt see what the provider w= ill advertise. If it=A1=AFs a new link representing the forwarding adjacenc= y between A=A1=AF and B=A1=AF, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstrac= t TE link A=A1=AFB=A1=AF points to the underlay (provider) TE topology wher= e the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncomm= itted TE link (i.e. link advertising potentiality in the provider network).= In either case TE link=A1=AFs attributes (e.g. available bandwidth, SRLGs)= are defined by the path.

 

 

Igor

 

 

From:= Francesco Lazzeri [= mailto:francesco.lazzeri@= ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor= ,

IMHO= simplicity pays back. Instead than maintaining all these states, notifying= clients all the times something changes, and repeating path-computation as= needed, isn=A1=AFt better for a client (and provider) to ask what is needed when it=A1=AFs needed, and get the best re= sult back at that moment ?

Rega= rding the abstract link in the overlay topology, I still can=A1=AFt see wha= t the provider will advertise. If it=A1=AFs a new link representing the for= warding adjacency between A=A1=AF and B=A1=AF, how it will be represented by the provider ?

 

BR

Fran= cesco

 

F= rom: Igor Bryski= n [mailto:Igor.Bryskin@huawei.co= m]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfa= tai@huawei.com>; Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

&nbs= p;

Plea= se, see in-line.

&nbs= p;

Chee= rs,

Igor=

&nbs= p;

The = point here is for how long the provider should keep the computed path and i= ts request parameters

&nbs= p;

IB>&= gt; As far as the provider is concerned, the requested path and its paramet= ers is a TE tunnel (albeit computed but not provisioned). So it keeps the s= tate until the client removes the TE tunnel.

&nbs= p;

(in = fact if we want to have a possibly better path, at any change inside provid= er topology, resource status and usage, the provider should check if the co= mputed path is still feasible and/or redo path computation to find a better path). This could be an overhead, in my = view.

&nbs= p;

IB>&= gt; For example, if provider is to ensure the path=A1=AFs feasibility, all = it needs is to detect a change in a TE link the path is going through and m= ake sure that the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be sc= heduled and performed in a background thread.

&nbs= p;

Furt= hermore, I can=A1=AFt see how the provider could export the abstract TE-lin= k, as this is inside the client topology;

IB>&= gt; The abstract link is a part of the abstract topology =A1=B0cooked=A1=B1= (customized) for the client, which is supported by the computed path in th= e underlay topology, which is the provider=A1=AFs topology.

&nbs= p;

in f= act, if the client is asking for a path between A and B (A and B inside pro= vider topology), having A=A1=AF (in client topology) connected to A and B= =A1=AF (in client topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A=A1= =AF and B=A1=AF, that is in the client topology; therefore the client shoul= d be in charge of managing it, as the provider is not aware of A=A1=AF and = B=A1=AF.

&nbs= p;

IB>&= gt; This is correct, but note that the two topologies (underlay and overlay= ) according to the TE topology model have independent and unrelated name sp= aces for node, link and SRLG IDs. So it is perfectly Ok.

 <= /span>

IB>&= gt; Also note that according  to TE topology model  one important= attribute of a TE node (especially abstract composite node) is connectivit= y matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 <= /span>

Igor=

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

BR

Fran= cesco

&nbs= p;

F= rom: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Dieter,=

 <= /span>

A clien= t may ask for a path not to be used immediately (e.g. to present as an abst= ract TE link to its own client, in some failure restoration scheme or as a = part of disaster recovery network topology re-configuration) without committing any network resources. In this case t= he client would want to know at least  if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available.

 <= /span>

This is= similar to exposing to a client an abstract TE topology with an uncommitte= d abstract TE link (i.e. TE link that does not have a committed TE tunnel s= upporting it and advertises potentiality). Once such link is provided, the provider is expected to send updates when/= if the TE link attributes change. For uncommitted/potential TE link such up= dates could be provided based on event driven re-computation of the potenti= ality the TE link represents.=

The poi= nt is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunnel can r= epresent (each in its own way) the same network potentiality

 <= /span>

Cheers,=

Igor

 <= /span>

 <= /span>

 <= /span>

From:= Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

= Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Brysk= in wrote:

Hi Diet= er,

 <= /span>

A provi= der may compute path(s) for a TE tunnel, and then (without any resource all= ocation) may start monitoring/ensuring the path validity/optimality by re-c= omputing them in an event driven manner. For example, it can trigger the re-computation of the path(s) when detecti= ng a change in a state of a TE link the current path(s) are going through.&= nbsp; Depending on the results additional notifications may be sent to the = client.

 <= /span>

Note th= at this is in addition to the reasons you correctly identified for implemen= ting stateful path computation (such as compute_and_reserve).

 <= /span>

Cheers,=

Igor

 <= /span>

 <= /span>

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path comput=
ation use case, it means IMHO that when a path has been calculated successf=
ully in response to a request, a new path object is created in the data sto=
re. This does only make sense if the resources have been allocated in the T=
ED of the PCE irrespective of the fact whether the connection along this pa=
th will be established right away or at a later point in time. This will pr=
event further path computation requests from assuming that the resources ar=
e still available. As the TED of the PCE also has to reflect the network st=
ate, I would assume that the network resources can be in one of the followi=
ng three states: available, allocatedButNotInUse,  allocatedAndInUse. =
The path objects also need state information reflecting for example the ala=
rm state of the allocated resources. The path calculated earlier may become=
 (temporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 <= /span>

When yo= u say =A1=B0state=A1=B1, are you referring to the YANG datastore or some ot= her =A1=B0interim=A1=B1 state of those paths that are calculated but not in= stantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer deci= ded not to instantiate the TE tunnel (after the path compute request).

 <= /span>

Thanks.=

Young

 <= /span>

 <= /span>

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,<= /span>

 <= /span>

From th= e provider controller point of view COMPUTE_ONLY TE tunnels will have exact= ly the same state as =A1=B0normal=A1=B1 (COMPUTE_ADN_PROVISION) TE tunnels.=

 <= /span>

Igor

 <= /span>

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 <= /span>

In such= case, would the YANG datastore be updated? I guess not. If not, then the s= ystem/controller has to keep this interim state, would it?

 <= /span>

Thanks.=

Young

 <= /span>

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael= ,

You are= exactly right. The purpose of the =A1=B0compute-only=A1=B1 TE tunnel is to= create/maintain the normal TE tunnel state and (re-)compute TE paths for t= he TE tunnel connections/LSPs but not signal/provision the LSPs.

 <= /span>

Igor

 <= /span>

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn=A1= =AFt the intention of defining „compute-only tunnels=A1=B0 to create = state in the controller, but not to signal them? If the tunnel should be si= gnaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can= be encoded in YANG. Is there anything I miss here?

 <= /span>

Michael=

 <= /span>

 <= /span>

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 =

Hi Mich= ael,

 <= /span>

I think= I am with you on your point. If we use rpc, it is clear. On the other hand= , if we were to use =A1=B0stateful compute-only=A1=B1 it seems that the sys= tem/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datas= tore is updated only when the path is signaled and resource is allocated. W= ould this give the system/controller additional burden to keep the =A1=B0in= terim=A1=B1 state?

 <= /span>

Young

 <= /span>

From: CCAMP [mail= to:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

 <= /span>

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

 <= /span>

Michael=

 <= /span>

 <= /span>

 <= /span>

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 =

Can you please explain what the= =A1=B0stateful compute-only=A1=B1 stands for I don=A1=AFt understand what = is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don=A1=AFt understand the value of askin= g for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=A8=AC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 =

We have= discussed this before. From an implementer=A1=AFs perspective, the two cle= an solutions to the problem seem to either stateful „compute-only=A1= =B0 tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00<= /span>

 =

Hi,

 <= /span>

From th= e draft:

 <= /span>

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"EN-US">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"EN-US">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

 

 <= /span>

 

 

 <= /span>

 

&n= bsp;

 

&n= bsp;

--_000_F82A4B6D50F9464B8EBA55651F541CF8817AC634SZXEMA504MBSchi_-- From nobody Thu Nov 10 02:02:27 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B85E129639; Thu, 10 Nov 2016 02:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 J7J0vulhHL_v; Thu, 10 Nov 2016 02:02:19 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBFE1293D8; Thu, 10 Nov 2016 02:02:17 -0800 (PST) X-AuditID: c1b4fb25-bf4b398000005623-89-582445a7744f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id AF.00.22051.7A544285; Thu, 10 Nov 2016 11:02:16 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 Nov 2016 11:02:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FPdpwOIAn9wUaXZHkZA+Nn3M2dBRajXtH0hCErDniaw=; b=it2eVznJ3Av/C0qGBAKaK5uf5VFzGNzWFweBqnApZmEBny6AnTXMdWeTT16tH7brErJ5ILpXRGzW0RwxZiHHJ89N1RrHSTfMABCe0c/u0A8keq+QLgC0hwxHDV+vzU9wLDtYlXbZeyxharkukD4oORNVMvacJe3jlMxG+zKiUEo= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1524.eurprd07.prod.outlook.com (10.165.248.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Thu, 10 Nov 2016 10:02:13 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Thu, 10 Nov 2016 10:02:13 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgIAAI1UAgADWmeA= Date: Thu, 10 Nov 2016 10:02:13 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-microsoft-exchange-diagnostics: 1; AM4PR07MB1524; 7:wTQPiWASyP3CUlzceKclCbWK8Z4n3e20AzYZBp63hzWyXa8vD4JQiW/EhqkH6myezgnA1wZQBjgWOSzgXpcvVzUB4AaSZrXnqR49297zNWba719RvBI4hhucxD2OIaC1ReZCtvOdMbV4Swv240VvK6tIhml9qOaBwiswKLRBp4LrbMcwWkpa7nz95SwFA6YRwWUtKoMzBBN4XypIXIl6gj352sL4zw2uVxnwb6/W0KbDSi+30k42cJbi8R5HjpxMwkbIpdDyspkwk6JWYCT94B/YYPKgJHFGnqDH5BAJZ4nZMcofaMkvOOUWrSBGfRsPSOKzm+irlQ+XwThDOgZ1+i1wJAsQw2rXWqQ2doOkC+E= x-ms-office365-filtering-correlation-id: 641f7dd9-1346-4964-37ed-08d40950a512 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR07MB1524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR07MB1524; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1524; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(189002)(199003)(53754006)(24454002)(561944003)(87936001)(2950100002)(92566002)(122556002)(220493001)(77096005)(66066001)(33656002)(105586002)(6116002)(790700001)(102836003)(3846002)(106356001)(106116001)(5001770100001)(7696004)(97736004)(229853002)(68736007)(76176999)(50986999)(8676002)(54356999)(8936002)(9686002)(2900100001)(101416001)(5660300001)(93886004)(4326007)(2906002)(3280700002)(81166006)(74316002)(81156014)(230783001)(86362001)(3660700001)(76576001)(586003)(189998001)(7906003)(3900700001)(7736002)(7846002)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1524; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521783F7A322F705278812296B80AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 10:02:13.5278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1524 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObt323U4Oi7NB5Og6RAtLa3sGmH5QZBQrC85oreZl6bptN1l Kn2w2hQNK0JDl5jSevEls9JU0srVLM33ipZkWi7CNLMMbVbS7u4Ev/3+z/P/n3Oeh0MRsh6h D5Ws0TFajSpVLpKQZcrm6OBb0f7KjSX5K2hbuZWk603vSfpfVyhtHwyih69XC+kzo1Yxbfjd QtLnz/YLd1Ix+mffhDEmk10QMzI8JNhN7JNsT2JSkzMZ7YbIwxJ1/9wPlDHQLc4qf/IJ5aLT Y6JC5EYB3gz5i2ecLMP1CHoKE3h+geBx565CJKFIXERA7USemBMyXCqANhOXkPAuQ8ssyUVE mIaFZ1ec7Ilz4PO8zWki8FsEFa3vHXGKWon3Q1+eB+85ACVj913+TgQzHe4ck1gBRQ15BMdS h/2Gfcp18y93qBrsdp7jhqPh+x0d50F4Fcx31wk4JrA3DNuuCvjRMJja+gmevWBifFHI+1Vw 12R0edbCQA3HEgdXEjAxYyD5RhxMjHSIl/jS5LwrcAzO/a0X8YE6BA/aX7tEC4Kf45ygHMIX Xt4T8vUxIVS8GUH8Vhm4edvg5JXYB0ZeF6CLKNC47OU8p0PBl1pkdG7AA7rKbCRfDwFrSbGI 53Vwo2qS4DkYShfN5PJ6JRLXIC+WYRPTjoZtCmG0yUdYNl0TomF095Djj3U0/lG0oFdTUWaE KSR3l85E+CllQlUmm51mRkARck+pIspfKZMmqbJzGG36Ie2JVIY1o9UUKfeWhlePJsjwUZWO OcYwGYx2qSug3Hxy0foU82DpO2OsYxy9pXeWTQyJV7WtsXxN8B21INmlxa7WRvVFA34e+zHG VtFBoIcF6qgPx33DTxruhwXEbUnYZp8qVtRFXOg1NZ/aM13ceTmnb2/SzaEmse5l7Jw+g5p8 qrQGNFl2qH8teKvjI9e1E9NbDzYE6q89ykoZt/uxcpJVq0KDCC2r+g+NVJZuXwMAAA== Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 10:02:25 -0000 --_000_AM4PR07MB1521783F7A322F705278812296B80AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521783F7A322F705278812296B80AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-For some re= asons (e.g. security/privacy) the PNC doesn’t export full topology in= formation to the MDSC, so that such information is not suitable for a path = computation on MDSC

-For some re= asons (e.g. scalability) MDSC doesn’t want to get full topology infor= mation from the subtended domains

-For some re= asons (e.g. lack of knowledge about the internal model of the equipment man= aged by the PNC : especially in WDM networks) MDSC is not capable to cumput= e reliably a feasible path in a domain

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

--_000_AM4PR07MB1521783F7A322F705278812296B80AM4PR07MB1521eurp_-- From nobody Thu Nov 10 08:06:42 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99C12985C; Thu, 10 Nov 2016 08:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 f4e8jRxZdKHw; Thu, 10 Nov 2016 08:06:18 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F411C1294BD; Thu, 10 Nov 2016 08:06:17 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A1A74950BE290; Thu, 10 Nov 2016 16:06:11 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAAG6EBL013282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2016 16:06:15 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uAAG695B028574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Nov 2016 17:06:14 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Thu, 10 Nov 2016 17:05:32 +0100 From: "Belotti, Sergio (Nokia - IT)" To: Francesco Lazzeri , Igor Bryskin , Fatai Zhang , "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcdFm7Ey8mkl0SoOXT6dUSe8qDNN3tAgAMvSgCAADywgIAACmCAgAAF/YCAAAszAIAACCQAgAAdjoCAAB8HAIAA8tSAgAAY41A= Date: Thu, 10 Nov 2016 16:05:32 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B775E038FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 16:06:23 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775E038FR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, At first thanks to enrich the discussion with your considerations. We, as authors, are definitely addressing both single and multi-domain aspe= ct and we have also tried to list considerations for which abstract topolog= y not always cope with all the needs for different scenarios, as Francesco = correctly pointed out below (see section 3 of the draft). Any comments on the text or additional considerations about this topic woul= d be appreciated in the view to improve the draft. Thanks Italo and Sergio on behalf of co-authors From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 11:02 AM To: Igor Bryskin ; Fatai Zhang ; Beller, Dieter (Nokia - DE) Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775E038FR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all, =

At first thanks to = enrich the discussion with your considerations.

We, as authors, are= definitely addressing both single and multi-domain aspect and we have also= tried to list considerations for which abstract topology not always cope w= ith all the needs for different scenarios, as Francesco correctly pointed out below (see section 3 of the draft).

Any comments on the= text or additional considerations about this topic would be appreciated in= the view to improve the draft.

 

Thanks

Italo and Sergio on= behalf of co-authors

 

 

 

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 11:02 AM
To: Igor Bryskin <Igor.Bryskin@huawei.com>; Fatai Zhang <zh= angfatai@huawei.com>; Beller, Dieter (Nokia - DE) <dieter.beller@noki= a.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-For some re= asons (e.g. security/privacy) the PNC doesn’t export full topology in= formation to the MDSC, so that such information is not suitable for a path = computation on MDSC

-For some re= asons (e.g. scalability) MDSC doesn’t want to get full topology infor= mation from the subtended domains

-For some re= asons (e.g. lack of knowledge about the internal model of the equipment man= aged by the PNC : especially in WDM networks) MDSC is not capable to cumput= e reliably a feasible path in a domain

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6.=     YANG Model for requesting Path Computation

 = ;

 = ;

 = ;  Work on extending the TE Tunnel YANG model to support the need to

 = ;  request path computation has recently started also in the context o= f

 = ;  the [TE-TUNNEL] draft.

 = ;

 = ;  It is possible to request path computation by configuring a<= o:p>

 = ;  "compute-only" TE tunnel and retrieving the computed path= (s) in the

 = ;  LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 = ;

 = ;  This is a stateful solution since the state of each created<= o:p>

 = ;  "compute-only" TE tunnel needs to be maintained and updat= ed, when

 = ;  underlying network conditions change.

 = ;

 = ;  The need also for a stateless solution, based on an RPC, has been

 = ;  recognized.

 = ;

 = ;

 = ;  The YANG model to support stateless RPC is for further study.

 = ;

 = ;

 = ;

 = ;

 = ;

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

--_000_B9FEE68CE3A78C41A2B3C67549A96F48B775E038FR711WXCHMBA05z_-- From nobody Thu Nov 10 08:15:10 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770FD129525; Thu, 10 Nov 2016 08:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 Iyux4nf_9SP7; Thu, 10 Nov 2016 08:15:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B8512987F; Thu, 10 Nov 2016 08:14:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAC83648; Thu, 10 Nov 2016 16:14:56 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 16:14:55 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 08:14:44 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUA== Date: Thu, 10 Nov 2016 16:14:43 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F961dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58249D02.00CF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bee9e4788904c3a2f3d547c3eaf515ee Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 16:15:07 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F961dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F961dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F961dfweml501mbx_-- From nobody Thu Nov 10 08:30:06 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5821295A9; Thu, 10 Nov 2016 08:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 XKTdM6zVnxeX; Thu, 10 Nov 2016 08:29:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88121298CE; Thu, 10 Nov 2016 08:29:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUX55250; Thu, 10 Nov 2016 16:29:49 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 16:29:48 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 08:29:37 -0800 From: Igor Bryskin To: Fatai Zhang , Francesco Lazzeri , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnCAAHLjAP//3LvA Date: Thu, 10 Nov 2016 16:29:37 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F981@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F981dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5824A07F.01E3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 16:30:01 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F981dfweml501mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRmF0YWksDQoNClBsZWFzZSwgc2VlIGluLWxpbmUuDQoNCklnb3INCg0KRnJvbTogRmF0YWkg WmhhbmcNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiAxOjEzIEFNDQpUbzogSWdv ciBCcnlza2luOyBGcmFuY2VzY28gTGF6emVyaTsgRGlldGVyIEJlbGxlcg0KQ2M6IG1wbHNAaWV0 Zi5vcmc7IENDQU1QIChjY2FtcEBpZXRmLm9yZyk7IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE RSk7IHBjZUBpZXRmLm9yZzsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZykNClN1YmplY3Q6ILTwuLQ6 IFttcGxzXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFu Zy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCkhpIElnb3IsDQoNCkkgdGhpbmsgdGhlIGNsaWVudCB3 aWxsIHN0aWxsIG1lZXQgdGhlIGNhc2UgdGhhdCB0aGVyZSBpcyBubyBhdmFpbGFibGUgcGF0aCBm b3IgdGhlIGNsaWVudC4NCg0KVGhlIHByb3ZpZGVyIHdpbGwgaGF2ZSBubyBjaGFuY2UgdG8gcmUt cGxhbiB0aGUgcGF0aCB3aGVuIHRoZSBjbGllbnQga25vd3MgdGhlIHVuZmVhc2liaWxpdHkgYWhl YWQgb2Ygc2hvcnQgdGltZSAoZS5nLiwgbWlsbGlzZWNvbmRzIGJlZm9yZSBpdCByZWFsbHkgbmVl ZHMgdGhlIHBhdGgpIG9yIHRoZSBjbGllbnQga25vd3MgdGhlIHVuZmVhc2liaWxpdHkgYWhlYWQg b2YgbXVjaCB0aW1lIChlLmcuLCBob3VycyBvciBkYXlzKSBiZWZvcmUgaXQgcmVhbGx5IG5lZWRz LCBidXQgdGhlcmUgaXMgbm8gc3VmZmljaWVudCBhdmFpbGFibGUgcmVzb3VyY2UgZm9yIHRoZSBw cm92aWRlciB0byByZS1wbGFuIHVubGVzcyB0aGUgb3BlcmF0b3JzIGFkZCBtb3JlIHBoeXNpY2Fs IG5vZGVzIG9yIGxpbmtzLg0KDQpJQj4+IEkgdGhpbmsgeW91IHRvdGFsbHkgbWlzdW5kZXJzdG9v ZCB3aGF0IEkgd2FzIHNheWluZy4gSXQgaXMgdGhlIGNsaWVudCwgbm90IHRoZSBwcm92aWRlciwg d2lsbCBoYXZlIHRvIHJlLXBsYW4gaXRzIHJlY292ZXJ5IHNjaGVtZS4gRm9yIGV4YW1wbGUsIHRo ZSBjbGllbnQgbWF5IHJlcXVlc3QgdGhlIG5lY2Vzc2FyeSByZXNvdXJjZXMgZnJvbSBhIGRpZmZl cmVudCBwcm92aWRlciBpZiBvbmx5IGl0IGxlYXJucyBpbiB0aW1lIGFib3V0IHRoZSBwcm9ibGVt Lg0KDQpJIHRoaW5rIHRoZSBzdGF0ZWZ1bCBwYXRoIGNvbXB1dGF0aW9uIGlzIGEga2luZCBvZiCh sGJlc3QgZWZmb3J0obEsIGFuZCBpdCBtaWdodCBiZSBzdWl0YWJsZSBmb3IgSVAgc2VydmljZSwg YnV0IGZvciB0aGUgdHJhbnNwb3J0IHNlcnZpY2UsIHRoZSBwcm90ZWN0aW9uIGNhcGFiaWxpdHko YXMgeW91IG1lbnRpb25lZCBhIGZhaWx1cmUgcmVjb3Zlcnkgb3IgY29uZ2VzdGlvbiBhdm9pZGFu Y2Ugc3RyYXRlZ3kgb3IgZGlzYXN0ZXIgdG9wb2xvZ3kgcmUtY29uZmlndXJhdGlvbikgTVVTVCBi ZSBndWFyYW50ZWVkIChhdCBsZWFzdCBmb3Igb25lIHNpbmdsZSBmYWlsdXJlKSBpZiB0aGUgY2xp ZW50IHJlYWxseSByZWxpZXMgb24gdGhhdC4NCg0KSUI+PiBBdm9pZGluZyBjb25nZXN0aW9uIGlu IElQL01QTFMgbGF5ZXIgbWF5IHZlcnkgd2VsbCBtZWFuIHJlLWNvbmZpZ3VyYXRpb25zIGluIHRo ZSB0cmFuc3BvcnQgbmV0d29yay4NCg0KSSB0aGluayB0aGUgc2ltcGxlIHdheSB0byBndWFyYW50 ZWUgdGhlIHByb3RlY3Rpb24gKG9yIHdoYXRldmVyKSBjYXBhYmlsaXR5IGlzIHRvIHJlc2VydmUg dGhlIHJlc291cmNlIGZvciB0aGUgZGVzaXJlZCBwYXRoIGFuZCB0aGUgcmVzZXJ2ZWQgcmVzb3Vy Y2UgY291bGQgYmUgc2hhcmVkIGFtb25nIG11bHRpcGxlIHBhdGggKFRoaXMgaXMgdGhlIGNvbmNl cHQgb2YgU2hhcmVkIE1lc2ggUHJvdGVjdGlvbiBJIGludHJvZHVjZWQgaW4gSVRVLVQgU0cxNSBh IGZldyB5ZWFycyBhZ28sIGJ1dCBoZXJlIHdlIGNhbiBqdXN0IHJlc2VydmUgdGhlIHJlc291cmNl IGZyb20gdGhlIGNvbnRyb2wgcGxhbmUgcGVyc3BlY3RpdmUgcmF0aGVyIHRoYW4gcmVzZXJ2ZSB0 aGUgcmVzb3VyY2Ugb24gdGhlIGRhdGEgcGxhbmUgdGhyb3VnaCBTTVAgbWVjaGFuaXNtKS4NCg0K SUI+PiBSZXNlcnZpbmcgcmVzb3VyY2VzIGlzIGEgc29sdXRpb24sIGhvd2V2ZXIsIGl0IHRha2Vz IGF3YXkgdGhlIGZsZXhpYmlsaXR5IChpLmUuIHZhcmlvdXMgdXNlIGNhc2VzLCBmYWlsdXJlIHNj ZW5hcmlvcywgZXRjLikgY29tcGFyZWQgdG8gbm90IHJlc2VydmVkIGJ1dCBjbG9zZWx5IG1vbml0 b3JlZCBzdGF0ZWZ1bGwgcGF0aHMuDQoNCg0KDQoNClRoYW5rcw0KDQpGYXRhaQ0KDQq3orz+yMs6 IElnb3IgQnJ5c2tpbg0Kt6LLzcqxvOQ6IDIwMTbE6jEx1MI5yNUgMjM6NTYNCsrVvP7IyzogRnJh bmNlc2NvIExhenplcmk7IEZhdGFpIFpoYW5nOyBEaWV0ZXIgQmVsbGVyDQqzrcvNOiBtcGxzQGll dGYub3JnOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpOyBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0g REUpOyBwY2VAaWV0Zi5vcmc7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpDQrW98ziOiBSRTogW21w bHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBh dGgtY29tcHV0YXRpb24tMDANCg0KRnJhbmNlc2NvLA0KDQpQbGVhc2UsIHNlZSBpbi1saW5lLg0K DQpJZ29yDQoNCg0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRnJhbmNlc2NvIExhenplcmkNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIg MDksIDIwMTYgMTA6MjcgQU0NClRvOiBJZ29yIEJyeXNraW47IEZhdGFpIFpoYW5nOyBEaWV0ZXIg QmVsbGVyDQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IENDQU1QIChj Y2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgU2NoYXJmLCBNaWNoYWVsIChO b2tpYSAtIERFKTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBURUFTIFdHICh0 ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPikNClN1YmplY3Q6IFJlOiBbVGVhc10g W21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5n LXBhdGgtY29tcHV0YXRpb24tMDANCg0KSWdvciwNCg0KDQoxKSAgICAgIElNSE8gc2ltcGxpY2l0 eSBwYXlzIGJhY2suIEluc3RlYWQgdGhhbiBtYWludGFpbmluZyBhbGwgdGhlc2Ugc3RhdGVzLCBu b3RpZnlpbmcgY2xpZW50cyBhbGwgdGhlIHRpbWVzIHNvbWV0aGluZyBjaGFuZ2VzLCBhbmQgcmVw ZWF0aW5nIHBhdGgtY29tcHV0YXRpb24gYXMgbmVlZGVkLCBpc26hr3QgYmV0dGVyIGZvciBhIGNs aWVudCAoYW5kIHByb3ZpZGVyKSB0byBhc2sgd2hhdCBpcyBuZWVkZWQgd2hlbiBpdKGvcyBuZWVk ZWQsIGFuZCBnZXQgdGhlIGJlc3QgcmVzdWx0IGJhY2sgYXQgdGhhdCBtb21lbnQgPw0KSUI+PiBX aGF0IGhhcHBlbnMgaXQgdGhlIHByb3ZpZGVyIGF0IHRoaXMgbW9tZW50IHNheXM6IKGwIE5vLCBJ IGhhdmUgbm90aGluZyBmb3IgeW91obEgPyAgV2hhdCBpZiB0aGUgcGF0aCB3YXMgcmVsaWVkIHVw b24gYnkgdGhlIGNsaWVudCBmb3IgYSBmYWlsdXJlIHJlY292ZXJ5IG9yIGNvbmdlc3Rpb24gYXZv aWRhbmNlIHN0cmF0ZWd5IG9yIGRpc2FzdGVyIHRvcG9sb2d5IHJlLWNvbmZpZ3VyYXRpb24/DQog ICAgICAgRkw+PiBQcm9iYWJseSB0aGUgc2FtZSBpbiBjYXNlIHRoZSBwcm92aWRlciBub3RpZmll cyChsEhleSwgSSBoYXZlIG5vIGxvbmdlciBhbnl0aGluZyBmb3IgeW91obEuDQoNCklCPj4gQnV0 IHRoaXMgd291bGQgYmUgYSBiaXQgdG9vIGxhdGUsIHdvdWxkbqGvdCBpdD8gV291bGRuoa90IGl0 IGJlIGJldHRlciBpZiB0aGUgY2xpZW50IGhhcyBsZWFybnQgYWJvdXQgdGhlIHByZXZpb3VzbHkg cmV0dXJuZWQgcGF0aCB1bmZlYXNpYmlsaXR5IGFoZWFkIG9mIHRpbWUsIHNvIHRoYXQgaXQgY291 bGQgcmUtcGxhbiBpdKGvcyBmYWlsdXJlIHJlY292ZXJ5IHNjaGVtZT8NCg0KSWYgdGhlcmUgaXMg bm8gKG1vcmUpIHBhdGgsIHRoZXJlIGlzIG5vIHBhdGguIFRoZSBjbGllbnQgY291bGQgb25seSB0 cnkgYW5kIGNyYW5rYmFjayBsb29raW5nIGZvciBzb21lIGRpZmZlcmVudCBwYXRoIG9yIHJlcG9y dCBhbiBhbGFybS4NCg0KSUI+PiBSZWx5aW5nIG9uIGNyYW5rYmFrcyBpbiBhbiB1bnByZWRpY3Rh YmxlIHdheSBpcyBub3QgZXhhY3RseSBhIGdvb2Qgc29sdXRpb24sIHJpZ2h0Pw0KDQpUaGUgc2Nl bmFyaW8gdGhhdCBzZWVtcyBtb3JlIGFwcGxpY2FibGUgdG8geW91ciBwcm9wb3NhbCBpcyBhIHBy ZS1wbGFubmVkIHJlc3RvcmF0aW9uIG1lY2hhbmlzbSB3aGVyZSB3ZSBoYXZlIGEgd29ya2VyIHBh dGggaW4tc2VydmljZSBhbmQgYSBwcm90ZWN0aW9uIHBhdGgganVzdCBjb21wdXRlZCAoYnV0IG5v dCByZXNlcnZpbmcgbmV0d29yayByZXNvdXJjZXMsIGluIG9yZGVyIHRvIHNoYXJlIHRoZW0gYW1v bmcgc2V2ZXJhbCBwcm90ZWN0aW9uIHBhdGhzKSwgaW4gYSBtdWx0aS1kb21haW4gbmV0d29yay4g SW4gdGhhdCBjYXNlLCByZXNlcnZpbmcgdGUtdHVubmVscyBsaWtlIHlvdSBzdWdnZXN0LCBjb3Vs ZCBnaXZlIGFuIGFkdmFudGFnZSwgYXMgdGhlIGVuZC10by1lbmQgY3JhbmNrYmFjayBjb3VsZCBv Y2N1ciB3aGVuIHRoZSBub3RpZmljYXRpb24gd2l0aCChsG5vLXBhdGihsSBpcyB0cmlnZ2VyZWQg YnkgdGhlIHByb3ZpZGVyICh0aGF0IG1lYW5zIHRoZSBwcm90ZWN0aW9uIHBhdGggb3Igc29tZSBv ZiBpdHMgc2VnbWVudHMgaXMgbm8gbG9uZ2VyIHZhbGlkKSBhbmQgbm90IHdoZW4gdGhlIHBhdGgg ZGVwbG95bWVudCBpcyB0cmlnZ2VyZWQgYnkgdGhlIGNsaWVudCAodGhhdCBtZWFucyB0aGUgd29y a2VyIHBhdGggaXMgZ29uZSBhbmQgd2UgbmVlZCB0aGUgcHJvdGVjdGlvbiBpbW1lZGlhdGVseSku IElzIHRoaXMgdGhlIGNhc2UgeW91IGFyZSBjb25zaWRlcmluZyA/DQoNCklCPj4gRXhhY3RseS4g QWxsIHRoZSBzY2VuYXJpb3MgeW91IGNhbiB0aGluayBvZiB3aGVyZSB5b3UgZG9uoa90IGtub3cg d2hlbiBhbmQgd2hlcmUgYSBwcm9ibGVtIG1heSBoYXBwZW4gYW5kIHlvdSB3YW50IHRvIG1haW50 YWluIGZsZXhpYmlsaXR5IGFuZCBzaGFyZSB0aGUgbmV0d29yayByZXNvdXJjZXMgdG8gcHJvdGVj dCBhcyBtdWNoIGFzIHlvdSBjYW4NCg0KSW4gb3RoZXIgY2FzZXMsIGFzIHdoZW4gdXNlZCBkdXJp bmcgYW4gZW5kLXRvLWVuZCBwYXRoIGNvbXB1dGF0aW9uIHdpdGggaW1tZWRpYXRlIGRlcGxveW1l bnQgdG8gcmVkdWNlIHRoZSBwb3NzaWJpbGl0eSBvZiBjb25mbGljdHMgYW1vbmcgY29uY3VycmVu dCBwcm9jZWR1cmVzLCBpdCBzZWVtcyB0byBtZSBsZXNzIGltcG9ydGFudCBvciBhcHBsaWNhYmxl LCBhcyBhbGwgdGhlc2UgcHJvY2VkdXJlcyB3aWxsIGxpa2VseSBiZSBvcmNoZXN0cmF0ZWQgYnkg dGhlIHNhbWUgZW50aXR5LCB3aGljaCBjb3VsZCB3ZWxsIGF2b2lkIGNvbmZsaWN0cy4NCg0KSUI+ PiBBbGwgY2FzZXMgd2hlcmUgdGhlIHByb3ZpZGVyIHdhbnRzIHRvIGV4cG9zZSBhIHBvdGVudGlh bGl0eSB3aXRob3V0IGNvbW1pdHRpbmcgcmVzb3VyY2VzIHRvIGNvdmVyIGZvciB0aGUgY2xpZW50 IG11bHRpcGxlIHVzZSBjYXNlcyBhbmQgcHJvdmlkZSBhdCB0aGUgc2FtZSB0aW1lIHNvbWUgZGVn cmVlIChhbGJlaXQgbm90IHBlcmZlY3QpIHByZWRpY3RhYmlsaXR5Lg0KDQoNCg0KDQoyKSAgICAg IFJlZ2FyZGluZyB0aGUgYWJzdHJhY3QgbGluayBpbiB0aGUgb3ZlcmxheSB0b3BvbG9neSwgSSBz dGlsbCBjYW6hr3Qgc2VlIHdoYXQgdGhlIHByb3ZpZGVyIHdpbGwgYWR2ZXJ0aXNlLiBJZiBpdKGv cyBhIG5ldyBsaW5rIHJlcHJlc2VudGluZyB0aGUgZm9yd2FyZGluZyBhZGphY2VuY3kgYmV0d2Vl biBBoa8gYW5kIEKhrywgaG93IGl0IHdpbGwgYmUgcmVwcmVzZW50ZWQgYnkgdGhlIHByb3ZpZGVy ID8NCg0KSUI+PiBBY2NvcmRpbmcgdG8gdGhlIFRFIHRvcG9sb2d5IG1vZGVsIGFic3RyYWN0IFRF IGxpbmsgQaGvQqGvIHBvaW50cyB0byB0aGUgdW5kZXJsYXkgKHByb3ZpZGVyKSBURSB0b3BvbG9n eSB3aGVyZSB0aGUgcGF0aCBpcyBjb21wdXRlZCBhbmQgcHJvdmlzaW9uZWQgYXMgc3VwcG9ydGlu ZyBURSB0dW5uZWwgZm9yIGNvbW1pdHRlZCBURSBsaW5rIG9yIG5vdCBwcm92aXNpb25lZCAoYnV0 IG1vbml0b3JlZCkgZm9yIHVuY29tbWl0dGVkIFRFIGxpbmsgKGkuZS4gbGluayBhZHZlcnRpc2lu ZyBwb3RlbnRpYWxpdHkgaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmspLiBJbiBlaXRoZXIgY2FzZSBU RSBsaW5roa9zIGF0dHJpYnV0ZXMgKGUuZy4gYXZhaWxhYmxlIGJhbmR3aWR0aCwgU1JMR3MpIGFy ZSBkZWZpbmVkIGJ5IHRoZSBwYXRoLg0KRkw+PiBUaGlzIG1lYW5zIHRoYXQgdGhlIHByb3ZpZGVy IGp1c3Qgc2VuZHMgdGhlIHJlcGx5IHRvIHRoZSBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3QgYW5k IGRvZXNuoa90IGFkdmVydGlzZSBhbnkgbmV3IFRFIGxpbmsgdG8gdGhlIGNsaWVudCA/IFRoaXMg aXMgYWN0dWFsbHkgd2hhdCBJIHdvdWxkIGV4cGVjdDogdGhlIHRhc2sgdG8gbWFuYWdlIFRFLWxp bmtzIGluIHRoZSBvdmVybGF5IHRvcG9sb2d5IGlzIHdpdGggdGhlIGNsaWVudC4NCg0KSUI+PiBP dmVybGF5IFRFIHRvcG9sb2d5IG1hbmFnZXIgYWR2ZXJ0aXNlcyBhIFRFIGxpbmsgdGhhdCBpcyBz dXBwb3J0ZWQgbm90IGJ5IGEgcHJvdmlzaW9uZWQgaW4gYSBzZXJ2ZXIgbGF5ZXIgVEUgdHVubmVs IChjb25uZWN0aW9uKSwgcmF0aGVyLCBieSBhIGNvbXB1dGVkIGFuZCBtb25pdG9yZWQgcGF0aC4g VGhpcyB3YXkgdGhlIG92ZXJsYXkgVEUgdG9wb2xvZ3kgbWFuZ2VyIGNhbiBhZHZlcnRpc2UgbXVs dGlwbGUgYWJzdHJhY3QgVEUgbGlua3MgbWFwcGVkIG9udG8gdGhlIHNhbWUgbmV0d29yayByZXNv dXJjZXMNCg0KRnJhbmNlc2NvDQoNCg0KRnJvbTogSWdvciBCcnlza2luIFttYWlsdG86SWdvci5C cnlza2luQGh1YXdlaS5jb21dDQpTZW50OiAwOSBOb3ZlbWJlciwgMjAxNiAzOjQ3IFBNDQpUbzog RnJhbmNlc2NvIExhenplcmkgPGZyYW5jZXNjby5sYXp6ZXJpQGVyaWNzc29uLmNvbTxtYWlsdG86 ZnJhbmNlc2NvLmxhenplcmlAZXJpY3Nzb24uY29tPj47IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFp QGh1YXdlaS5jb208bWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbT4+OyBEaWV0ZXIgQmVsbGVy IDxEaWV0ZXIuQmVsbGVyQG5va2lhLmNvbTxtYWlsdG86RGlldGVyLkJlbGxlckBub2tpYS5jb20+ Pg0KQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBDQ0FNUCAoY2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPikgPGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4+OyBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNj aGFyZkBub2tpYS5jb208bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4+OyBwY2VAaWV0 Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRv OnRlYXNAaWV0Zi5vcmc+KSA8dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4+DQpT dWJqZWN0OiBSRTogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2li ZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KRnJhbmNlc2NvLA0KDQoNCjEpICAg ICAgSU1ITyBzaW1wbGljaXR5IHBheXMgYmFjay4gSW5zdGVhZCB0aGFuIG1haW50YWluaW5nIGFs bCB0aGVzZSBzdGF0ZXMsIG5vdGlmeWluZyBjbGllbnRzIGFsbCB0aGUgdGltZXMgc29tZXRoaW5n IGNoYW5nZXMsIGFuZCByZXBlYXRpbmcgcGF0aC1jb21wdXRhdGlvbiBhcyBuZWVkZWQsIGlzbqGv dCBiZXR0ZXIgZm9yIGEgY2xpZW50IChhbmQgcHJvdmlkZXIpIHRvIGFzayB3aGF0IGlzIG5lZWRl ZCB3aGVuIGl0oa9zIG5lZWRlZCwgYW5kIGdldCB0aGUgYmVzdCByZXN1bHQgYmFjayBhdCB0aGF0 IG1vbWVudCA/DQpJQj4+IFdoYXQgaGFwcGVucyBpdCB0aGUgcHJvdmlkZXIgYXQgdGhpcyBtb21l bnQgc2F5czogobAgTm8sIEkgaGF2ZSBub3RoaW5nIGZvciB5b3WhsSA/ICBXaGF0IGlmIHRoZSBw YXRoIHdhcyByZWxpZWQgdXBvbiBieSB0aGUgY2xpZW50IGZvciBhIGZhaWx1cmUgcmVjb3Zlcnkg b3IgY29uZ2VzdGlvbiBhdm9pZGFuY2Ugc3RyYXRlZ3kgb3IgZGlzYXN0ZXIgdG9wb2xvZ3kgcmUt Y29uZmlndXJhdGlvbj8NCg0KDQoNCg0KDQoyKSAgICAgIFJlZ2FyZGluZyB0aGUgYWJzdHJhY3Qg bGluayBpbiB0aGUgb3ZlcmxheSB0b3BvbG9neSwgSSBzdGlsbCBjYW6hr3Qgc2VlIHdoYXQgdGhl IHByb3ZpZGVyIHdpbGwgYWR2ZXJ0aXNlLiBJZiBpdKGvcyBhIG5ldyBsaW5rIHJlcHJlc2VudGlu ZyB0aGUgZm9yd2FyZGluZyBhZGphY2VuY3kgYmV0d2VlbiBBoa8gYW5kIEKhrywgaG93IGl0IHdp bGwgYmUgcmVwcmVzZW50ZWQgYnkgdGhlIHByb3ZpZGVyID8NCg0KSUI+PiBBY2NvcmRpbmcgdG8g dGhlIFRFIHRvcG9sb2d5IG1vZGVsIGFic3RyYWN0IFRFIGxpbmsgQaGvQqGvIHBvaW50cyB0byB0 aGUgdW5kZXJsYXkgKHByb3ZpZGVyKSBURSB0b3BvbG9neSB3aGVyZSB0aGUgcGF0aCBpcyBjb21w dXRlZCBhbmQgcHJvdmlzaW9uZWQgYXMgc3VwcG9ydGluZyBURSB0dW5uZWwgZm9yIGNvbW1pdHRl ZCBURSBsaW5rIG9yIG5vdCBwcm92aXNpb25lZCAoYnV0IG1vbml0b3JlZCkgZm9yIHVuY29tbWl0 dGVkIFRFIGxpbmsgKGkuZS4gbGluayBhZHZlcnRpc2luZyBwb3RlbnRpYWxpdHkgaW4gdGhlIHBy b3ZpZGVyIG5ldHdvcmspLiBJbiBlaXRoZXIgY2FzZSBURSBsaW5roa9zIGF0dHJpYnV0ZXMgKGUu Zy4gYXZhaWxhYmxlIGJhbmR3aWR0aCwgU1JMR3MpIGFyZSBkZWZpbmVkIGJ5IHRoZSBwYXRoLg0K DQoNCklnb3INCg0KDQpGcm9tOiBGcmFuY2VzY28gTGF6emVyaSBbbWFpbHRvOmZyYW5jZXNjby5s YXp6ZXJpQGVyaWNzc29uLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDksIDIwMTYg OToyNiBBTQ0KVG86IElnb3IgQnJ5c2tpbjsgRmF0YWkgWmhhbmc7IERpZXRlciBCZWxsZXINCkNj OiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgQ0NBTVAgKGNjYW1wQGlldGYu b3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pOyBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUp OyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5v cmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUkU6IFttcGxzXSBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9u LTAwDQoNCklnb3IsDQpJTUhPIHNpbXBsaWNpdHkgcGF5cyBiYWNrLiBJbnN0ZWFkIHRoYW4gbWFp bnRhaW5pbmcgYWxsIHRoZXNlIHN0YXRlcywgbm90aWZ5aW5nIGNsaWVudHMgYWxsIHRoZSB0aW1l cyBzb21ldGhpbmcgY2hhbmdlcywgYW5kIHJlcGVhdGluZyBwYXRoLWNvbXB1dGF0aW9uIGFzIG5l ZWRlZCwgaXNuoa90IGJldHRlciBmb3IgYSBjbGllbnQgKGFuZCBwcm92aWRlcikgdG8gYXNrIHdo YXQgaXMgbmVlZGVkIHdoZW4gaXShr3MgbmVlZGVkLCBhbmQgZ2V0IHRoZSBiZXN0IHJlc3VsdCBi YWNrIGF0IHRoYXQgbW9tZW50ID8NClJlZ2FyZGluZyB0aGUgYWJzdHJhY3QgbGluayBpbiB0aGUg b3ZlcmxheSB0b3BvbG9neSwgSSBzdGlsbCBjYW6hr3Qgc2VlIHdoYXQgdGhlIHByb3ZpZGVyIHdp bGwgYWR2ZXJ0aXNlLiBJZiBpdKGvcyBhIG5ldyBsaW5rIHJlcHJlc2VudGluZyB0aGUgZm9yd2Fy ZGluZyBhZGphY2VuY3kgYmV0d2VlbiBBoa8gYW5kIEKhrywgaG93IGl0IHdpbGwgYmUgcmVwcmVz ZW50ZWQgYnkgdGhlIHByb3ZpZGVyID8NCg0KQlINCkZyYW5jZXNjbw0KDQpGcm9tOiBJZ29yIEJy eXNraW4gW21haWx0bzpJZ29yLkJyeXNraW5AaHVhd2VpLmNvbV0NClNlbnQ6IDA5IE5vdmVtYmVy LCAyMDE2IDI6NDggUE0NClRvOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPG1h aWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+PjsgRnJhbmNlc2NvIExhenplcmkgPGZyYW5jZXNj by5sYXp6ZXJpQGVyaWNzc29uLmNvbTxtYWlsdG86ZnJhbmNlc2NvLmxhenplcmlAZXJpY3Nzb24u Y29tPj47IERpZXRlciBCZWxsZXIgPERpZXRlci5CZWxsZXJAbm9raWEuY29tPG1haWx0bzpEaWV0 ZXIuQmVsbGVyQG5va2lhLmNvbT4+DQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz47IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KSA8Y2Nh bXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj47IFNjaGFyZiwgTWljaGFlbCAoTm9r aWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZA bm9raWEuY29tPj47IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAo dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pIDx0ZWFzQGlldGYub3JnPG1haWx0 bzp0ZWFzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbbXBsc10gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpI aSBGcmFuY2VzY28sDQoNClBsZWFzZSwgc2VlIGluLWxpbmUuDQoNCkNoZWVycywNCklnb3INCg0K VGhlIHBvaW50IGhlcmUgaXMgZm9yIGhvdyBsb25nIHRoZSBwcm92aWRlciBzaG91bGQga2VlcCB0 aGUgY29tcHV0ZWQgcGF0aCBhbmQgaXRzIHJlcXVlc3QgcGFyYW1ldGVycw0KDQpJQj4+IEFzIGZh ciBhcyB0aGUgcHJvdmlkZXIgaXMgY29uY2VybmVkLCB0aGUgcmVxdWVzdGVkIHBhdGggYW5kIGl0 cyBwYXJhbWV0ZXJzIGlzIGEgVEUgdHVubmVsIChhbGJlaXQgY29tcHV0ZWQgYnV0IG5vdCBwcm92 aXNpb25lZCkuIFNvIGl0IGtlZXBzIHRoZSBzdGF0ZSB1bnRpbCB0aGUgY2xpZW50IHJlbW92ZXMg dGhlIFRFIHR1bm5lbC4NCg0KKGluIGZhY3QgaWYgd2Ugd2FudCB0byBoYXZlIGEgcG9zc2libHkg YmV0dGVyIHBhdGgsIGF0IGFueSBjaGFuZ2UgaW5zaWRlIHByb3ZpZGVyIHRvcG9sb2d5LCByZXNv dXJjZSBzdGF0dXMgYW5kIHVzYWdlLCB0aGUgcHJvdmlkZXIgc2hvdWxkIGNoZWNrIGlmIHRoZSBj b21wdXRlZCBwYXRoIGlzIHN0aWxsIGZlYXNpYmxlIGFuZC9vciByZWRvIHBhdGggY29tcHV0YXRp b24gdG8gZmluZCBhIGJldHRlciBwYXRoKS4gVGhpcyBjb3VsZCBiZSBhbiBvdmVyaGVhZCwgaW4g bXkgdmlldy4NCg0KSUI+PiBGb3IgZXhhbXBsZSwgaWYgcHJvdmlkZXIgaXMgdG8gZW5zdXJlIHRo ZSBwYXRooa9zIGZlYXNpYmlsaXR5LCBhbGwgaXQgbmVlZHMgaXMgdG8gZGV0ZWN0IGEgY2hhbmdl IGluIGEgVEUgbGluayB0aGUgcGF0aCBpcyBnb2luZyB0aHJvdWdoIGFuZCBtYWtlIHN1cmUgdGhh dCB0aGUgIGNoYW5nZSBkb2VzIG5vdCBtYWtlIHRoZSBwYXRoIHVuZmVhc2libGUuIE9ubHkgaW4g dGhlIGxhdHRlciBjYXNlIHRoZSBwYXRoIHJlLWNvbXB1dGF0aW9uIG5lZWRzIHRvIGJlIHNjaGVk dWxlZCBhbmQgcGVyZm9ybWVkIGluIGEgYmFja2dyb3VuZCB0aHJlYWQuDQoNCkZ1cnRoZXJtb3Jl LCBJIGNhbqGvdCBzZWUgaG93IHRoZSBwcm92aWRlciBjb3VsZCBleHBvcnQgdGhlIGFic3RyYWN0 IFRFLWxpbmssIGFzIHRoaXMgaXMgaW5zaWRlIHRoZSBjbGllbnQgdG9wb2xvZ3k7DQpJQj4+IFRo ZSBhYnN0cmFjdCBsaW5rIGlzIGEgcGFydCBvZiB0aGUgYWJzdHJhY3QgdG9wb2xvZ3kgobBjb29r ZWShsSAoY3VzdG9taXplZCkgZm9yIHRoZSBjbGllbnQsIHdoaWNoIGlzIHN1cHBvcnRlZCBieSB0 aGUgY29tcHV0ZWQgcGF0aCBpbiB0aGUgdW5kZXJsYXkgdG9wb2xvZ3ksIHdoaWNoIGlzIHRoZSBw cm92aWRlcqGvcyB0b3BvbG9neS4NCg0KaW4gZmFjdCwgaWYgdGhlIGNsaWVudCBpcyBhc2tpbmcg Zm9yIGEgcGF0aCBiZXR3ZWVuIEEgYW5kIEIgKEEgYW5kIEIgaW5zaWRlIHByb3ZpZGVyIHRvcG9s b2d5KSwgaGF2aW5nIEGhryAoaW4gY2xpZW50IHRvcG9sb2d5KSBjb25uZWN0ZWQgdG8gQSBhbmQg QqGvIChpbiBjbGllbnQgdG9wb2xvZ3kpIGNvbm5lY3RlZCB0byBCLCB0aGUgcmVsZXZhbnQgYWJz dHJhY3QgVEUgbGluayAodGhlIGZvcndhcmRpbmcgYWRqYWNlbmN5KSBzaG91bGQgYmUgYnVpbHQg YmV0d2VlbiBBoa8gYW5kIEKhrywgdGhhdCBpcyBpbiB0aGUgY2xpZW50IHRvcG9sb2d5OyB0aGVy ZWZvcmUgdGhlIGNsaWVudCBzaG91bGQgYmUgaW4gY2hhcmdlIG9mIG1hbmFnaW5nIGl0LCBhcyB0 aGUgcHJvdmlkZXIgaXMgbm90IGF3YXJlIG9mIEGhryBhbmQgQqGvLg0KDQpJQj4+IFRoaXMgaXMg Y29ycmVjdCwgYnV0IG5vdGUgdGhhdCB0aGUgdHdvIHRvcG9sb2dpZXMgKHVuZGVybGF5IGFuZCBv dmVybGF5KSBhY2NvcmRpbmcgdG8gdGhlIFRFIHRvcG9sb2d5IG1vZGVsIGhhdmUgaW5kZXBlbmRl bnQgYW5kIHVucmVsYXRlZCBuYW1lIHNwYWNlcyBmb3Igbm9kZSwgbGluayBhbmQgU1JMRyBJRHMu IFNvIGl0IGlzIHBlcmZlY3RseSBPay4NCg0KSUI+PiBBbHNvIG5vdGUgdGhhdCBhY2NvcmRpbmcg IHRvIFRFIHRvcG9sb2d5IG1vZGVsICBvbmUgaW1wb3J0YW50IGF0dHJpYnV0ZSBvZiBhIFRFIG5v ZGUgKGVzcGVjaWFsbHkgYWJzdHJhY3QgY29tcG9zaXRlIG5vZGUpIGlzIGNvbm5lY3Rpdml0eSBt YXRyaXgsIHdoaWNoIGlzIG5vdGhpbmcgYnV0IGEgc2V0IG9mIHN0YXRlZnVsIHBhdGhzIGNvbXB1 dGVkLCByZS1jb21wdXRlZCBhbmQgY29uc3RhbnRseSBtb25pdG9yZWQgKGJ1dCBub3QgcmVzZXJ2 ZWQpIG92ZXIgdGhlIFRFIHRvcG9sb2d5IHRoZSBub2RlIGVuY2Fwc3VsYXRlcy4gIFRoaXMgbWVh bnMgdGhhdCBzdGF0ZWZ1bCB1bnJlc2VydmVkIHBhdGhzIHBsYXkgYWxyZWFkeSBhIHZlcnkgaW1w b3J0YW50IHBhcnQgaW4gc3VwcG9ydGluZyBURSB0b3BvbG9naWVzIHdpdGggYXN5bW1ldHJpY2Fs IGJsb2NraW5nIGFic3RyYWN0IFRFIG5vZGVzLg0KDQpJZ29yDQoNCg0KDQoNCkJSDQpGcmFuY2Vz Y28NCg0KRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSWdvciBCcnlza2luDQpTZW50OiAwNCBOb3ZlbWJlciwgMjAxNiA3OjEyIFBNDQpUbzog RGlldGVyIEJlbGxlciA8RGlldGVyLkJlbGxlckBub2tpYS5jb208bWFpbHRvOkRpZXRlci5CZWxs ZXJAbm9raWEuY29tPj4NCkNjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsg Q0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pIDxjY2FtcEBpZXRm Lm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+PjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERF KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPG1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5j b20+PjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pIDx0ZWFz QGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPj47IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNl QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gW21wbHNdIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0K RGlldGVyLA0KDQpBIGNsaWVudCBtYXkgYXNrIGZvciBhIHBhdGggbm90IHRvIGJlIHVzZWQgaW1t ZWRpYXRlbHkgKGUuZy4gdG8gcHJlc2VudCBhcyBhbiBhYnN0cmFjdCBURSBsaW5rIHRvIGl0cyBv d24gY2xpZW50LCBpbiBzb21lIGZhaWx1cmUgcmVzdG9yYXRpb24gc2NoZW1lIG9yIGFzIGEgcGFy dCBvZiBkaXNhc3RlciByZWNvdmVyeSBuZXR3b3JrIHRvcG9sb2d5IHJlLWNvbmZpZ3VyYXRpb24p IHdpdGhvdXQgY29tbWl0dGluZyBhbnkgbmV0d29yayByZXNvdXJjZXMuIEluIHRoaXMgY2FzZSB0 aGUgY2xpZW50IHdvdWxkIHdhbnQgdG8ga25vdyBhdCBsZWFzdCAgaWYvd2hlbiB0aGUgcGF0aCBo YXMgc3RvcHBlZCBiZWluZyBmZWFzaWJsZSBhbnkgbG9uZ2VyIG9yIChpZGVhbGx5KSBhIGJldHRl ciBwYXRoIGlzIGF2YWlsYWJsZS4NCg0KVGhpcyBpcyBzaW1pbGFyIHRvIGV4cG9zaW5nIHRvIGEg Y2xpZW50IGFuIGFic3RyYWN0IFRFIHRvcG9sb2d5IHdpdGggYW4gdW5jb21taXR0ZWQgYWJzdHJh Y3QgVEUgbGluayAoaS5lLiBURSBsaW5rIHRoYXQgZG9lcyBub3QgaGF2ZSBhIGNvbW1pdHRlZCBU RSB0dW5uZWwgc3VwcG9ydGluZyBpdCBhbmQgYWR2ZXJ0aXNlcyBwb3RlbnRpYWxpdHkpLiBPbmNl IHN1Y2ggbGluayBpcyBwcm92aWRlZCwgdGhlIHByb3ZpZGVyIGlzIGV4cGVjdGVkIHRvIHNlbmQg dXBkYXRlcyB3aGVuL2lmIHRoZSBURSBsaW5rIGF0dHJpYnV0ZXMgY2hhbmdlLiBGb3IgdW5jb21t aXR0ZWQvcG90ZW50aWFsIFRFIGxpbmsgc3VjaCB1cGRhdGVzIGNvdWxkIGJlIHByb3ZpZGVkIGJh c2VkIG9uIGV2ZW50IGRyaXZlbiByZS1jb21wdXRhdGlvbiBvZiB0aGUgcG90ZW50aWFsaXR5IHRo ZSBURSBsaW5rIHJlcHJlc2VudHMuDQpUaGUgcG9pbnQgaXMgdGhhdCBhbiB1bmNvbW1pdHRlZCBh YnN0cmFjdCBURSBsaW5rIGFuZCBDT01QVVRFX09OTFkgVEUgdHVubmVsIGNhbiByZXByZXNlbnQg KGVhY2ggaW4gaXRzIG93biB3YXkpIHRoZSBzYW1lIG5ldHdvcmsgcG90ZW50aWFsaXR5DQoNCkNo ZWVycywNCklnb3INCg0KDQoNCkZyb206IERpZXRlciBCZWxsZXIgW21haWx0bzpEaWV0ZXIuQmVs bGVyQG5va2lhLmNvbV0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDQsIDIwMTYgMTo0OSBQTQ0K VG86IElnb3IgQnJ5c2tpbg0KQ2M6IExlZXlvdW5nOyBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0g REUpOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2Nh bXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+OyBURUFTIFdH ICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPik7IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0K SGkgSWdvciwNCg0KY291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IGhvdyB1c2VmdWwgYSBzdGF0ZWZ1 bCBwYXRoIHdpdGhvdXQgcmVzb3VyY2UgYWxsb2NhdGlvbiBpcy4gSSBjYW4ndCBzZWUgdGhlIGJl bmVmaXRzIG9mIHRoaXMgdXNlIGNhc2UuDQoNCg0KVGhhbmtzLA0KRGlldGVyDQpPbiAwNC4xMS4y MDE2IDE0OjI1LCBJZ29yIEJyeXNraW4gd3JvdGU6DQpIaSBEaWV0ZXIsDQoNCkEgcHJvdmlkZXIg bWF5IGNvbXB1dGUgcGF0aChzKSBmb3IgYSBURSB0dW5uZWwsIGFuZCB0aGVuICh3aXRob3V0IGFu eSByZXNvdXJjZSBhbGxvY2F0aW9uKSBtYXkgc3RhcnQgbW9uaXRvcmluZy9lbnN1cmluZyB0aGUg cGF0aCB2YWxpZGl0eS9vcHRpbWFsaXR5IGJ5IHJlLWNvbXB1dGluZyB0aGVtIGluIGFuIGV2ZW50 IGRyaXZlbiBtYW5uZXIuIEZvciBleGFtcGxlLCBpdCBjYW4gdHJpZ2dlciB0aGUgcmUtY29tcHV0 YXRpb24gb2YgdGhlIHBhdGgocykgd2hlbiBkZXRlY3RpbmcgYSBjaGFuZ2UgaW4gYSBzdGF0ZSBv ZiBhIFRFIGxpbmsgdGhlIGN1cnJlbnQgcGF0aChzKSBhcmUgZ29pbmcgdGhyb3VnaC4gIERlcGVu ZGluZyBvbiB0aGUgcmVzdWx0cyBhZGRpdGlvbmFsIG5vdGlmaWNhdGlvbnMgbWF5IGJlIHNlbnQg dG8gdGhlIGNsaWVudC4NCg0KTm90ZSB0aGF0IHRoaXMgaXMgaW4gYWRkaXRpb24gdG8gdGhlIHJl YXNvbnMgeW91IGNvcnJlY3RseSBpZGVudGlmaWVkIGZvciBpbXBsZW1lbnRpbmcgc3RhdGVmdWwg cGF0aCBjb21wdXRhdGlvbiAoc3VjaCBhcyBjb21wdXRlX2FuZF9yZXNlcnZlKS4NCg0KQ2hlZXJz LA0KSWdvcg0KDQoNCkZyb206IEJlbGxlciwgRGlldGVyIChOb2tpYSAtIERFKSBbbWFpbHRvOmRp ZXRlci5iZWxsZXJAbm9raWEuY29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2 IDY6MjcgUE0NClRvOiBMZWV5b3VuZw0KQ2M6IElnb3IgQnJ5c2tpbjsgU2NoYXJmLCBNaWNoYWVs IChOb2tpYSAtIERFKTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8 bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3Jn PjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pOyBtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttcGxzXSBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0 aW9uLTAwDQoNCg0KSGkgYWxsLA0KDQoNCg0Kd2hlbiB3ZSB0YWxrIGFib3V0IHRoZSBzdGF0ZWZ1 bCBwYXRoIGNvbXB1dGF0aW9uIHVzZSBjYXNlLCBpdCBtZWFucyBJTUhPIHRoYXQgd2hlbiBhIHBh dGggaGFzIGJlZW4gY2FsY3VsYXRlZCBzdWNjZXNzZnVsbHkgaW4gcmVzcG9uc2UgdG8gYSByZXF1 ZXN0LCBhIG5ldyBwYXRoIG9iamVjdCBpcyBjcmVhdGVkIGluIHRoZSBkYXRhIHN0b3JlLiBUaGlz IGRvZXMgb25seSBtYWtlIHNlbnNlIGlmIHRoZSByZXNvdXJjZXMgaGF2ZSBiZWVuIGFsbG9jYXRl ZCBpbiB0aGUgVEVEIG9mIHRoZSBQQ0UgaXJyZXNwZWN0aXZlIG9mIHRoZSBmYWN0IHdoZXRoZXIg dGhlIGNvbm5lY3Rpb24gYWxvbmcgdGhpcyBwYXRoIHdpbGwgYmUgZXN0YWJsaXNoZWQgcmlnaHQg YXdheSBvciBhdCBhIGxhdGVyIHBvaW50IGluIHRpbWUuIFRoaXMgd2lsbCBwcmV2ZW50IGZ1cnRo ZXIgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0cyBmcm9tIGFzc3VtaW5nIHRoYXQgdGhlIHJlc291 cmNlcyBhcmUgc3RpbGwgYXZhaWxhYmxlLiBBcyB0aGUgVEVEIG9mIHRoZSBQQ0UgYWxzbyBoYXMg dG8gcmVmbGVjdCB0aGUgbmV0d29yayBzdGF0ZSwgSSB3b3VsZCBhc3N1bWUgdGhhdCB0aGUgbmV0 d29yayByZXNvdXJjZXMgY2FuIGJlIGluIG9uZSBvZiB0aGUgZm9sbG93aW5nIHRocmVlIHN0YXRl czogYXZhaWxhYmxlLCBhbGxvY2F0ZWRCdXROb3RJblVzZSwgIGFsbG9jYXRlZEFuZEluVXNlLiBU aGUgcGF0aCBvYmplY3RzIGFsc28gbmVlZCBzdGF0ZSBpbmZvcm1hdGlvbiByZWZsZWN0aW5nIGZv ciBleGFtcGxlIHRoZSBhbGFybSBzdGF0ZSBvZiB0aGUgYWxsb2NhdGVkIHJlc291cmNlcy4gVGhl IHBhdGggY2FsY3VsYXRlZCBlYXJsaWVyIG1heSBiZWNvbWUgKHRlbXBvcmFyaWx5KSBpbnZhbGlk IGR1ZSB0byBhIGxpbmsgZmFpbHVyZSBhZmZlY3RpbmcgdGhlIHBhdGguDQoNCg0KDQpEb2VzIHRo aXMgbWFrZSBzZW5zZT8NCg0KDQoNCg0KDQpUaGFua3MsDQoNCkRpZXRlcg0KDQoNCg0KU2VudCBm cm9tIG15IHRhYmxldA0KDQoNCg0KTGVleW91bmcgPGxlZXlvdW5nQGh1YXdlaS5jb20+PG1haWx0 bzpsZWV5b3VuZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KDQpJZ29yLA0KDQpXaGVuIHlvdSBzYXkg obBzdGF0ZaGxLCBhcmUgeW91IHJlZmVycmluZyB0byB0aGUgWUFORyBkYXRhc3RvcmUgb3Igc29t ZSBvdGhlciChsGludGVyaW2hsSBzdGF0ZSBvZiB0aG9zZSBwYXRocyB0aGF0IGFyZSBjYWxjdWxh dGVkIGJ1dCBub3QgaW5zdGFudGlhdGVkIGFzIExTUHM/IElmIHdlIHdlcmUgdG8gdXBkYXRlIHRo ZSBZQU5HIGRhdGFzdG9yZSBmb3IgdGhpcywgSSB3b3VsZCB0aGluayB0aGF0IHdlIG1heSBoYXZl IHNvbWUgaXNzdWUgd2hlbiB0aGUgY3VzdG9tZXIgZGVjaWRlZCBub3QgdG8gaW5zdGFudGlhdGUg dGhlIFRFIHR1bm5lbCAoYWZ0ZXIgdGhlIHBhdGggY29tcHV0ZSByZXF1ZXN0KS4NCg0KVGhhbmtz Lg0KWW91bmcNCg0KDQpGcm9tOiBJZ29yIEJyeXNraW4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAwMywgMjAxNiAzOjAyIFBNDQpUbzogTGVleW91bmc7IFNjaGFyZiwgTWljaGFlbCAoTm9raWEg LSBERSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMg V0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCllvdW5n LA0KDQpGcm9tIHRoZSBwcm92aWRlciBjb250cm9sbGVyIHBvaW50IG9mIHZpZXcgQ09NUFVURV9P TkxZIFRFIHR1bm5lbHMgd2lsbCBoYXZlIGV4YWN0bHkgdGhlIHNhbWUgc3RhdGUgYXMgobBub3Jt YWyhsSAoQ09NUFVURV9BRE5fUFJPVklTSU9OKSBURSB0dW5uZWxzLg0KDQpJZ29yDQoNCkZyb206 IExlZXlvdW5nDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgMzo0MiBQTQ0KVG86 IElnb3IgQnJ5c2tpbjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgRGFuaWVsZSBDZWNj YXJlbGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBj ZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxt YWlsdG86dGVhc0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwt dGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KSWdvciwNCg0KSW4gc3VjaCBjYXNlLCB3 b3VsZCB0aGUgWUFORyBkYXRhc3RvcmUgYmUgdXBkYXRlZD8gSSBndWVzcyBub3QuIElmIG5vdCwg dGhlbiB0aGUgc3lzdGVtL2NvbnRyb2xsZXIgaGFzIHRvIGtlZXAgdGhpcyBpbnRlcmltIHN0YXRl LCB3b3VsZCBpdD8NCg0KVGhhbmtzLg0KWW91bmcNCg0KRnJvbTogSWdvciBCcnlza2luDQpTZW50 OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgMjozNCBQTQ0KVG86IFNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSk7IExlZXlvdW5nOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIChjY2Ft cEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1haWx0bzpw Y2VAaWV0Zi5vcmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3Jn Pik7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21w dXRhdGlvbi0wMA0KDQpNaWNoYWVsLA0KWW91IGFyZSBleGFjdGx5IHJpZ2h0LiBUaGUgcHVycG9z ZSBvZiB0aGUgobBjb21wdXRlLW9ubHmhsSBURSB0dW5uZWwgaXMgdG8gY3JlYXRlL21haW50YWlu IHRoZSBub3JtYWwgVEUgdHVubmVsIHN0YXRlIGFuZCAocmUtKWNvbXB1dGUgVEUgcGF0aHMgZm9y IHRoZSBURSB0dW5uZWwgY29ubmVjdGlvbnMvTFNQcyBidXQgbm90IHNpZ25hbC9wcm92aXNpb24g dGhlIExTUHMuDQoNCklnb3INCg0KRnJvbTogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSBb bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAwMywgMjAxNiAzOjE3IFBNDQpUbzogTGVleW91bmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgSWdv ciBCcnlza2luOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7 IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9y ZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2li ZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KSXNuoa90IHRoZSBpbnRlbnRpb24g b2YgZGVmaW5pbmcgImNvbXB1dGUtb25seSB0dW5uZWxzobAgdG8gY3JlYXRlIHN0YXRlIGluIHRo ZSBjb250cm9sbGVyLCBidXQgbm90IHRvIHNpZ25hbCB0aGVtPyBJZiB0aGUgdHVubmVsIHNob3Vs ZCBiZSBzaWduYWxlZCBhbmQgcmVzb3VyY2VzIHNoYWxsIGJlIGFsbG9jYXRlZCwgd2h5IG5vdCBq dXN0IGNvbmZpZ3VyZSBhIHZhbmlsbGEgdHVubmVsPyBVc2VzIGNhc2VzIHNlZW0gdG8gZXhpc3Qg Zm9yIGJvdGggdmFyaWFudHMsIGFuZCBib3RoIGNhbiBiZSBlbmNvZGVkIGluIFlBTkcuIElzIHRo ZXJlIGFueXRoaW5nIEkgbWlzcyBoZXJlPw0KDQpNaWNoYWVsDQoNCg0KRnJvbTogTGVleW91bmcg W21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAz LCAyMDE2IDc6NDkgUE0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyBEYW5pZWxl IENlY2NhcmVsbGk7IElnb3IgQnJ5c2tpbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMg V0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwDQoNCkhpIE1p Y2hhZWwsDQoNCkkgdGhpbmsgSSBhbSB3aXRoIHlvdSBvbiB5b3VyIHBvaW50LiBJZiB3ZSB1c2Ug cnBjLCBpdCBpcyBjbGVhci4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHdlIHdlcmUgdG8gdXNlIKGw c3RhdGVmdWwgY29tcHV0ZS1vbmx5obEgaXQgc2VlbXMgdGhhdCB0aGUgc3lzdGVtL2NvbnRyb2xs ZXIgaGFzIHRvIGtlZXAgdGhlIHN0YXRlIG9mIHRoZSBwYXRocyBzb21ld2hlcmUgd2hpY2ggaXMg bm90IFlBTkcgZGF0YXN0b3JlLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgWUFORyBkYXRhc3Rv cmUgaXMgdXBkYXRlZCBvbmx5IHdoZW4gdGhlIHBhdGggaXMgc2lnbmFsZWQgYW5kIHJlc291cmNl IGlzIGFsbG9jYXRlZC4gV291bGQgdGhpcyBnaXZlIHRoZSBzeXN0ZW0vY29udHJvbGxlciBhZGRp dGlvbmFsIGJ1cmRlbiB0byBrZWVwIHRoZSChsGludGVyaW2hsSBzdGF0ZT8NCg0KWW91bmcNCg0K RnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAz LCAyMDE2IDg6NTggQU0NClRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IElnb3IgQnJ5c2tpbjsgQ0NB TVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pOyBwY2VAaWV0Zi5vcmc8 bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNA aWV0Zi5vcmc+KTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbQ0NBTVBdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVh cy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KTWF5YmUgSSBtaXNzIHNvbWV0aGluZywgYnV0 IHRvIG1lLCB0aGUgZG9tYWluIGNvbnRyb2xsZXIgZWl0aGVyIGNvbXB1dGVzIGEgcGF0aCBzdGF0 ZWxlc3MsIHdoaWNoIGNhbiBiZSBtb2RlbGVkIGluIFlBTkcgaW4gYW4gUlBDLiBPciB0aGUgZG9t YWluIGNvbnRyb2xsZXIgY29tcHV0ZXMgYSBwYXRoLCBzdG9yZXMgc3RhdGUsIGFuZCBwcm92aWRl cyBhY2Nlc3MgdG8gdGhlIHJlc3VsdCBpbiB0aGUgWUFORyBkYXRhc3RvcmUuIEluIHRoZSBsYXR0 ZXIgY2FzZSwgd2hldGhlciByZXNvdXJjZXMgYXJlIGFsbG9jYXRlZCwgb3Igd2hldGhlciB0aGUg TkVzIGdldCBhY3R1YWxseSBwcm92aXNpb25lZCwgaXMgYW4gb3J0aG9nb25hbCBxdWVzdGlvbi4N Cg0KQXMgYSBzaWRlIG5vdGUsIEkgYW0gbm90IHN1cmUgb2YgSSB3b3VsZCBjYWxsIGEgZG9tYWlu IGNvbnRyb2xsZXIgb3IgYW4gTk1TIGEgUENFLiBQYXRoIGNvbXB1dGF0aW9uIGlzIG9ubHkgYSBz dWJzZXQgb2YgdGhlIGZ1bmN0aW9ucyBvZiBhIGRvbWFpbiBjb250cm9sbGVyLg0KDQpNaWNoYWVs DQoNCg0KDQpGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDI6NDkg UE0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyBJZ29yIEJyeXNraW47IENDQU1Q IChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgcGNlQGlldGYub3JnPG1h aWx0bzpwY2VAaWV0Zi5vcmc+OyBURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGll dGYub3JnPik7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS RTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0 aC1jb21wdXRhdGlvbi0wMA0KDQpDYW4geW91IHBsZWFzZSBleHBsYWluIHdoYXQgdGhlIKGwc3Rh dGVmdWwgY29tcHV0ZS1vbmx5obEgc3RhbmRzIGZvciBJIGRvbqGvdCB1bmRlcnN0YW5kIHdoYXQg aXMgc3RhdGVmdWwgaW4gYSBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3Qgb25seS4NCklNSE8gZWl0 aGVyIEkgYXNrIHRoZSBQQ0UgKFNETiBjb250cm9sbGVyLCBOTVMsIHdoYXRldmVyKSB0byBjb21w dXRlIGEgcGF0aCBhbmQgdGhlbiBmb3JnZXQgYWJvdXQgaXQgb3IgSSBhc2sgdG8gY29tcHV0ZSBh bmQgcHJvdmlzaW9uIGl0LiBJIGRvbqGvdCB1bmRlcnN0YW5kIHRoZSB2YWx1ZSBvZiBhc2tpbmcg Zm9yIGl0IGFuZCByZW1lbWJlcmluZyBhYm91dCBpdC4NCg0KQlINCkRhbmllbGUNCg0KRnJvbTog U2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSBbbWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lh LmNvbV0NClNlbnQ6IGdpb3ZlZKisIDMgbm92ZW1icmUgMjAxNiAxNDo0NQ0KVG86IElnb3IgQnJ5 c2tpbiA8SWdvci5Ccnlza2luQGh1YXdlaS5jb208bWFpbHRvOklnb3IuQnJ5c2tpbkBodWF3ZWku Y29tPj47IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4+OyBDQ0FNUCAoY2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPikgPGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4+OyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz47IFRFQVMg V0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSA8dGVhc0BpZXRmLm9yZzxt YWlsdG86dGVhc0BpZXRmLm9yZz4+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwt dGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDANCg0KV2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBi ZWZvcmUuIEZyb20gYW4gaW1wbGVtZW50ZXKhr3MgcGVyc3BlY3RpdmUsIHRoZSB0d28gY2xlYW4g c29sdXRpb25zIHRvIHRoZSBwcm9ibGVtIHNlZW0gdG8gZWl0aGVyIHN0YXRlZnVsICJjb21wdXRl LW9ubHmhsCB0dW5uZWxzIG9yIGEgc3RhdGVsZXNzIFJQQy4NCg0KTWljaGFlbA0KDQoNCkZyb206 IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJZ29yIEJy eXNraW4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMywgMjAxNiAyOjM0IFBNDQpUbzogRGFu aWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYu b3JnPik7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0Bp ZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KU3ViamVjdDogW0FMVV0gW21wbHNdaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMA0KDQpIaSwNCg0K RnJvbSB0aGUgZHJhZnQ6DQoNCjYuICAgIFlBTkcgTW9kZWwgZm9yIHJlcXVlc3RpbmcgUGF0aCBD b21wdXRhdGlvbg0KDQoNCiAgIFdvcmsgb24gZXh0ZW5kaW5nIHRoZSBURSBUdW5uZWwgWUFORyBt b2RlbCB0byBzdXBwb3J0IHRoZSBuZWVkIHRvDQogICByZXF1ZXN0IHBhdGggY29tcHV0YXRpb24g aGFzIHJlY2VudGx5IHN0YXJ0ZWQgYWxzbyBpbiB0aGUgY29udGV4dCBvZg0KICAgdGhlIFtURS1U VU5ORUw8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5n LXBhdGgtY29tcHV0YXRpb24tMDAjcmVmLVRFLVRVTk5FTD5dIGRyYWZ0Lg0KDQogICBJdCBpcyBw b3NzaWJsZSB0byByZXF1ZXN0IHBhdGggY29tcHV0YXRpb24gYnkgY29uZmlndXJpbmcgYQ0KICAg ImNvbXB1dGUtb25seSIgVEUgdHVubmVsIGFuZCByZXRyaWV2aW5nIHRoZSBjb21wdXRlZCBwYXRo KHMpIGluIHRoZQ0KICAgTFNQKHMpIFJlY29yZC1Sb3V0ZSBPYmplY3QgKFJSTykgbGlzdCBhcyBk ZXNjcmliZWQgaW4gW1RFLVRVTk5FTDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMCNyZWYtVEUtVFVOTkVMPl0uDQoN CiAgIFRoaXMgaXMgYSBzdGF0ZWZ1bCBzb2x1dGlvbiBzaW5jZSB0aGUgc3RhdGUgb2YgZWFjaCBj cmVhdGVkDQogICAiY29tcHV0ZS1vbmx5IiBURSB0dW5uZWwgbmVlZHMgdG8gYmUgbWFpbnRhaW5l ZCBhbmQgdXBkYXRlZCwgd2hlbg0KICAgdW5kZXJseWluZyBuZXR3b3JrIGNvbmRpdGlvbnMgY2hh bmdlLg0KDQogICBUaGUgbmVlZCBhbHNvIGZvciBhIHN0YXRlbGVzcyBzb2x1dGlvbiwgYmFzZWQg b24gYW4gUlBDLCBoYXMgYmVlbg0KICAgcmVjb2duaXplZC4NCg0KDQogICBUaGUgWUFORyBtb2Rl bCB0byBzdXBwb3J0IHN0YXRlbGVzcyBSUEMgaXMgZm9yIGZ1cnRoZXIgc3R1ZHkuDQoNCg0KDQoN Cg0KSUI+PiBQbGVhc2UsIG5vdGUsIHRoYXQgaW4gdGhlIFRFIFR1bm5lbCBtb2RlbCB3ZSBjb25z aWRlciB0aGUgQ09NUFVURV9BTkRfRk9SR0VUIG1vZGUuIFdlIGFsc28gY29uc2lkZXIgdGhlIGNv bmNlcHQgb2YgcGF0aCBjb21wdXRhdGlvbiBhY3Rpb24gdG8gYmUgZGVmaW5lZCB1bmRlciB0aGUg VEUgdHVubmVsIG5vZGUuIEFsbCB0aGlzIGlzIHRvIGZhY2lsaXRhdGUgc3RhdGVsZXNzIHBhdGgg Y29tcHV0YXRpb25zLg0KDQpDaGVlcnMsDQpJZ29yDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F981dfweml501mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Fatai,

 

Please, see in-line.

 

Igor=

 

From: Fatai Zhang
Sent: Thursday, November 10, 2016 1:13 AM
To: Igor Bryskin; Francesco Lazzeri; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: =B4=F0=B8=B4: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-compu= tation-00

 

Hi Ig= or,

=  

I thi= nk the client will still meet the case that there is no available path for = the client.

=  

The p= rovider will have no chance to re-plan the path when the client knows the u= nfeasibility ahead of short time (e.g., milliseconds before it really needs= the path) or the client knows the unfeasibility ahead of much time (e.g., hours or days) before it really needs, but there= is no sufficient available resource for the provider to re-plan unless the= operators add more physical nodes or links.

=  

IB>= ;> I think you totally misunderstood what I was saying. It is the client= , not the provider, will have to re-plan its recovery scheme. For example, = the client may request the necessary resources from a different provider if only it learns in time about the problem.

=  

I think the stateful p= ath computation is a kind of =A1=B0best effort=A1=B1, and it might be suita= ble for IP service, but for the transport service, the protection capability(as you mentioned a failure recovery or congestio= n avoidance strategy or disaster topology re-configuration) MUST be guarant= eed (at least for one single failure) if the client really relies on that.

 

IB>> Avoiding co= ngestion in IP/MPLS layer may very well mean re-configurations in the trans= port network.

 

I think the simple way= to guarantee the protection (or whatever) capability is to reserve the res= ource for the desired path and the reserved resource could be shared among multiple path (This is the concept of Share= d Mesh Protection I introduced in ITU-T SG15 a few years ago, but here we c= an just reserve the resource from the control plane perspective rather than= reserve the resource on the data plane through SMP mechanism).

 

IB>> Reserving r= esources is a solution, however, it takes away the flexibility (i.e. variou= s use cases, failure scenarios, etc.) compared to not reserved but closely monitored statefull paths.

 

 

 

 

Thanks

 

Fatai

=  

=B7=A2=BC=FE=C8=CB: Igor Bryskin
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA11=D4=C29=C8=D5 23:56
=CA=D5=BC=FE=C8=CB: Francesco Lazzeri; Fatai Zhang; Dieter Beller
=B3=AD=CB=CD: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS W= G (teas@ietf.org)
=D6=F7=CC=E2: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation= -00

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn=A1=AFt better for = a client (and provider) to ask what is needed when it=A1=AFs needed, and get the best result back at that moment = ?

IB>> What happens it the provider at this moment says: =A1= =B0 No, I have nothing for you=A1=B1 ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s =A1=B0Hey, I have no longer anything for you=A1=B1.

 

IB>> But this would = be a bit too late, wouldn=A1=AFt it? Wouldn=A1=AFt it be better if the clie= nt has learnt about the previously returned path unfeasibility ahead of tim= e, so that it could re-plan it=A1=AFs failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with =A1=B0no-path=A1=B1 is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don=A1=AFt know when and where a pro= blem may happen and you want to maintain flexibility and share the network = resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can=A1=AFt see what the provider will advertise. = If it=A1=AFs a new link representing the forwarding adjacency between A=A1= =AF and B=A1=AF, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A=A1= =AFB=A1=AF points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk=A1=AFs attributes (e.g. available bandwidth, SRLGs) are defined by the p= ath.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn=A1=AFt advertise any new TE link to th= e client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

&n= bsp;

&n= bsp;

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn=A1=AFt better for = a client (and provider) to ask what is needed when it=A1=AFs needed, and get the best result back at that moment = ?

IB>> What happens it the provider at this moment says: =A1= =B0 No, I have nothing for you=A1=B1 ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can=A1=AFt see what the provider will advertise. = If it=A1=AFs a new link representing the forwarding adjacency between A=A1= =AF and B=A1=AF, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A=A1= =AFB=A1=AF points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk=A1=AFs attributes (e.g. available bandwidth, SRLGs) are defined by the p= ath.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn=A1= =AFt better for a client (and provider) to ask what is needed when it=A1=AFs needed, and get the best result back at = that moment ?

Regarding the abstr= act link in the overlay topology, I still can=A1=AFt see what the provider = will advertise. If it=A1=AFs a new link representing the forwarding adjacen= cy between A=A1=AF and B=A1=AF, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfa= tai@huawei.com>; Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path=A1=AFs feasibility, all it needs is to = detect a change in a TE link the path is going through and make sure that t= he  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can= =A1=AFt see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology =A1=B0cooked=A1=B1 (customized) f= or the client, which is supported by the computed path in the underlay topo= logy, which is the provider=A1=AFs topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A=A1=AF (in client topology) connected to A and B=A1=AF (in client= topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A=A1=AF and B= =A1=AF, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A=A1=AF and B=A1=AF.<= /span>

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Die= ter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:diet= er.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyou=
ng@huawei.com> wrote:
 

Igor,

 

When you say =A1=B0sta= te=A1=B1, are you referring to the YANG datastore or some other =A1=B0inter= im=A1=B1 state of those paths that are calculated but not instantiated as L= SPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as =A1=B0normal=A1=B1 (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the =A1=B0compute-only=A1=B1 TE tunnel is to create/maintai= n the normal TE tunnel state and (re-)compute TE paths for the TE tunnel co= nnections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn=A1=AFt the intenti= on of defining „compute-only tunnels=A1=B0 to create state in the con= troller, but not to signal them? If the tunnel should be signaled and resou= rces shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use =A1=B0stateful compute-only=A1=B1 it seems that the system/controller = has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the =A1=B0interim=A1=B1 stat= e?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the =A1=B0stateful compu= te-only=A1=B1 stands for I don=A1=AFt understand what is stateful in a path= computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don=A1=AFt understand the value of asking for it and remember= ing about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=A8=AC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer=A1=AFs perspective, the two clean solutions to= the problem seem to either stateful „compute-only=A1=B0 tunnels or a= stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNN= EL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNN= EL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F981dfweml501mbx_-- From nobody Thu Nov 10 09:39:00 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16BB1294AE; Thu, 10 Nov 2016 09:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 sICjVQLqzLJy; Thu, 10 Nov 2016 09:38:52 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922BB12942F; Thu, 10 Nov 2016 09:38:50 -0800 (PST) X-AuditID: c1b4fb2d-1dbff700000009f7-be-5824b0a7b9bd Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id BC.14.02551.7A0B4285; Thu, 10 Nov 2016 18:38:48 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 Nov 2016 18:38:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2F8D5QWaDJJpyTTr8vYzYnQtTOVtEf53racFXFaY51I=; b=FI0XiH80uqlnJ448obqchMOvwcubZEbFxOVCazH8ffi2h6PSsHUToOeB/TMTzLpuMGMjU42idnMgT8KLghmH/YmnufSnqxE8z0yeXH4p4wTeBIhZEW9AJM5xWDbtOerDitDFUSF+r2ud00CjZBUUkvI1YopU7rpS11fCwit9VsM= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1524.eurprd07.prod.outlook.com (10.165.248.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Thu, 10 Nov 2016 17:38:44 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Thu, 10 Nov 2016 17:38:44 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgIAAI1UAgADWmeCAAIRPgIAABhYQ Date: Thu, 10 Nov 2016 17:38:44 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-microsoft-exchange-diagnostics: 1; AM4PR07MB1524; 7:0AIZQLoM6EhtZUf32/auhGp2G6PX8dly3HTFCnmQWSNDtMmpT4TzpRfyzZeb1KX4KVsIAZLAJ61PCIoD6mcUnCJ+Y/HlkMevIIr2kT0QbNHNj/Li0b7SPuW1k4VQJp3faUZWTWeTDzRmqvjo0stnihvl9rvY9rIIdHwAedVt09LUnaIvk30IUNUmYyoUJ1K/2B7+089ocy4+hOA+zTCK+9CjjJ2Kj/+XLoU4qEkE6oqwdocCvmYa3dcraZy8ufU7kCLz/tDKh94tIfdhab093eBcFVxfsXX8i6NlJsHTfSk/y+RMZWjs+VMB/mxI6Mot5BHYHfvaJocYED1nt9z1jK/K5gPoRzGw/np5trVpQO8= x-ms-office365-filtering-correlation-id: d68bfa0d-8906-4b84-dcdf-08d409906b7c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR07MB1524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1524; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1524; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(377454003)(189002)(199003)(24454002)(2950100002)(561944003)(87936001)(220493001)(92566002)(122556002)(77096005)(66066001)(33656002)(6116002)(3846002)(790700001)(102836003)(106116001)(106356001)(5001770100001)(105586002)(7696004)(97736004)(229853002)(76176999)(50986999)(68736007)(8676002)(54356999)(9686002)(8936002)(101416001)(2900100001)(5660300001)(2906002)(4326007)(81156014)(93886004)(81166006)(74316002)(230783001)(86362001)(3660700001)(3280700002)(76576001)(586003)(189998001)(7906003)(7736002)(3900700001)(7846002)(579004)(559001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1524; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB15218A98B8A2A3027DC33CE596B80AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 17:38:44.7446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1524 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRTA+XbvnXfa5HNOPWn/uCakoqaG3T8kCgr8pwcEaVHU0ouaT3an +ShQU3uYYqL4RI1mpam0aT5CTZdYKjkVyXearSKnloWYRta2q+B/v3PO7/vOOR8fTUgGKWc6 MlbFKmMV0TKhNVka0nrK6+lzecjBlgFPxlAxQTKN6hmS+dvvy2yMeDBTNbUUkzE3YcVk/W4j mbxbeuooHZTZu0wFqdUbgqDZqVHBGeKCdWAYGx2ZyCp9jlyxjsgYy0TxX9/TSbdfLxFpSDNu dQ+JaMCHYOufxsTWtAQ3IhhabReYCxL8FkHeT4tE4lwC9H0UL5UIYK1TTfCBSUpfHifNlhAz sNlbbmEpToHP6wahWSLwOILK9hnTVTRtjy/CULYd71yCovkm0uxI8SgC7fdKxLdzg5FWDWH2 xSZfXyHim2XYgvb+qqWBCJ+AwvV8yswIO8L6QL1lbAI7wZShSsDvhkHdoSd4doBvn7a2fQVo 1GXbjisM1+1wNQHTOhXPJ+HjrwFyhwuM69tOFPT1TVmGBlyPoKVzTMgHbQgWl4otWwLeB4Na is//oKC7d96Kf1QWnjRkWba0x84wO3YX5SP3sl2Dl5mOEzgOyhcZc1qM7aC/1EDyijdMFBUK efaExw+NBM9eULKlI3fnq5FVHXLgWI6LCffz92aVkaEcFxfrHcuqtMj0xXqa/3i1oWfGYzqE aSTbI47PkYdIKEUilxyjQ0ATMqn4QIMpJQ5TJKewyrjLyoRoltMhF5qUOYkDaueCJThcoWKj WDaeVe5UBbTIOQ3lcDKbR/VyKnxeGhCqW2h/1xUcPaO6Uy8PfmQIMFKOx2+cUzluiuaatDXV 3h0r8slymX/Cq66Wyma/4P2aiKSzp4m1qy7uNm4rVd0vYhZc9cz1vedzXZeu2Q4dfpDtU/xm uE7vPDNR8CF9MZ9K/fLSGDmd2hvUY1usnkzxCbwplZFchMLXg1Byiv/rM7dZXgMAAA== Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 17:38:58 -0000 --_000_AM4PR07MB15218A98B8A2A3027DC33CE596B80AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB15218A98B8A2A3027DC33CE596B80AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-As soon as = network get increasingly used, the computed paths could become invalid. So = you need to recompute them as needed and advertise all the changes

-You perform= a path computation “in advance”, that is before the actual req= uest is done, and therefore PNC cannot be aware of the future requirements = in term of bandwidth, objective functions, constraints and so on. Computed paths will not be suitable in general for all the futu= re requests, and of course it’s not conceivable to compute those path= s for all the possible combinations of the request parameters (this should = grow esponentially!)

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-It’s = built incrementally from real requests and therefore with real parameters

-It’s = build by MDSC and maintained inside MDSC, no need for notifications.

<= /p>

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-     =      For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-     =      For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-     =      For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_AM4PR07MB15218A98B8A2A3027DC33CE596B80AM4PR07MB1521eurp_-- From nobody Thu Nov 10 11:53:49 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE591299BB; Thu, 10 Nov 2016 11:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 D1e0WyK73Ubs; Thu, 10 Nov 2016 11:53:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8CA1299B2; Thu, 10 Nov 2016 11:53:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUX74976; Thu, 10 Nov 2016 19:53:25 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 19:53:23 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 11:53:14 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAWDYAgAB43DA= Date: Thu, 10 Nov 2016 19:53:14 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0FA10dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5824D036.02D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 19:53:41 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FA10dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fro= m the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over i= nter-domain links into the domains up to their respective outbound inter-do= main links with potentially significant increase in the number of successfu= l paths; c) repeat step b) until the paths reach the destination (17th) domain; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. I also hope you agree = that computing such path on a single 20 node topology equipped with node de= tailed connectivity matrices is instantaneous; 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FA10dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Francesco,

 

There are few issue= s with your logic, I think:

 

1)      Nodes repre= senting domains must be considered as blocking/asymmetrical nodes. Dijkstra= assumes symmetrical nodes; so the “idea is to run Dijkstra on the MD= SC abstract topology and trigger a path computation to the relevant PNCs as soon as a node representing a domain i= s found” is questionable to begin with;

2)      What happen= s if the algorithm finds a node represented not by a PNC, but by another (l= ower hierarchy level) MDSC?

3)      Assume you = want to compute a single path on a 20-domain topology originating in domain= 1 and terminating in, say, domain17. I don’t think you have much cho= ice but:

a) &= nbsp;    request PNC= 1 to compute all possible (not just optional) paths from the path source t= o all domain 1 inter-domain links;

b) &= nbsp;   request all= neighboring PNCs to “grow” all the computed paths over inter-d= omain links into the domains up to their respective outbound inter-domain l= inks with potentially significant increase in the number of successful paths;

c) &= nbsp;    repeat step= b) until the paths reach the destination (17th) domain;

d) &= nbsp;   grow the pa= ths until they hit the path computation destination;

e) &= nbsp;    select the = most optimal path

 

I hope you agree th= at this is a lot of computations. I also hope you agree that computing such= path on a single 20 node topology equipped with node detailed connectivity= matrices is instantaneous;

 

4)      Computing d= iverse paths as two single path computations with the topology transformati= on in between does not apply here: the paths may go through the same and/or= different domains whose internal topologies are not known (hence there is nothing to transform);=

5)      Computing a= connectivity matrix on a known (fully visible) topology is simple (as you = said, could be done in a single run) and also could be easily distributed b= etween several path computers to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix e= ntry may be associated with one or more intra-node paths and provide to the= MDSC various metrics, like delay, cost, max. bandwidth, SRLGs)  It co= uld be done in background when the path computers have nothing else to do (which is most of the time).<= /span>

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-   =        As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-   =        You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-   =        It’s built incrementally from= real requests and therefore with real parameters

-   =        It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0FA10dfweml501mbx_-- From nobody Thu Nov 10 14:28:21 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73F8129771; Thu, 10 Nov 2016 14:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 a-7yFd7MK6zU; Thu, 10 Nov 2016 14:28:10 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E735129795; Thu, 10 Nov 2016 14:28:09 -0800 (PST) X-AuditID: c1b4fb25-813ff70000005623-17-5824f476cc08 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id FC.2E.22051.674F4285; Thu, 10 Nov 2016 23:28:07 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 Nov 2016 23:28:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sR/QlT+Vc8No3s9gKnuln8gau1QrW9MN/S6lkb+ijz0=; b=d9Xup7JAuUOuExYz0a0E0gVUKRjX515QJ8xTMHUqq09IdE6bmeWBKo2VH6x2EdedYDyk2XJy0gd5JOk3W3CEdtobk8p5D1hn4KPM1wSEZwd5reEvMlKR305A8T90MLWTHVuzYydNBKtqCxbrTfy3ApSsUUG1/4WGQ2PQ8D+qOuk= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1524.eurprd07.prod.outlook.com (10.165.248.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Thu, 10 Nov 2016 22:28:03 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Thu, 10 Nov 2016 22:28:03 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgIAAI1UAgADWmeCAAIRPgIAABhYQgAA29wCAABvbsA== Date: Thu, 10 Nov 2016 22:28:03 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [79.44.121.42] x-microsoft-exchange-diagnostics: 1; AM4PR07MB1524; 7:e8x9zbdLyd/FK4dT4YkM3U51FGDPU0iFSbgBMIjE+MJrmU/6BYqBCF9bJgucJRLQ44XJECLSaqFQo8USPRC38I5EpR88CvyOq6pL2nAXERvXl50FA3iblRSmOUkWxd7EKw5H8NOHV3FDL4AMogL00AW0mvybEFxXKCHlNpraWnwQgKSZomtCBWfhl3yGro+Cah2QMslDBhkswzATr7d8A5x12baTlS6dsfHvT60rEcnuIV0ditYHl0mmztY3OovJqzP4ovXSL3GJdV1DBjnRb4zWCffrNyZfWxTeODSLXfH1TbC0sTOahlgRBtBBttc8Kg+MFN81dPnih9JHPJW+5P4zmgGByZuCI9+9NsKhYWI= x-ms-office365-filtering-correlation-id: 65af8f93-dbe6-4262-34e6-08d409b8d606 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR07MB1524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR07MB1524; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1524; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(377454003)(189002)(199003)(24454002)(561944003)(87936001)(2950100002)(220493001)(122556002)(92566002)(77096005)(66066001)(97736004)(106116001)(6116002)(33656002)(54356999)(102836003)(3846002)(790700001)(106356001)(5001770100001)(105586002)(229853002)(7696004)(50986999)(76176999)(8676002)(68736007)(8936002)(9686002)(2900100001)(5660300001)(101416001)(2906002)(3660700001)(4326007)(93886004)(81156014)(81166006)(74316002)(86362001)(230783001)(76576001)(586003)(189998001)(7736002)(3900700001)(7906003)(7846002)(3280700002)(579004)(559001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1524; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521618A37FE4B3A530703B496B80AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 22:28:03.3384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1524 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRTA++5juxstP7eph2VUw/7YQvMRdYOSggKJgghDKaOWXlTUabtm 6R8S9tQeSDQyldJaijq1bNSiJFyW2uih+Rjq0nTSQyvppRatdncN+u93zvkdzvkOH0Mqn9Ma Jt2Yy5mMhkytRE5dTryrDz/8LSwxsnpKw3oqXRTbZBmm2N9dUexct54dvFFHs0UjLil7YtZO seePvaA3MnHH2z/ScRbLHBHnHuwhdpC75etTuMz0PM60Kna/PK2sv4fMGfXKjpw1D1JH0Yd3 TAmSMYBXg/v4VWkJkjNK3ISgs8lOi0EnAmd9vz+g8DkSigZ+zlfKCJiqfEMK/X6t9WyqwBLM ws/2CkpgNS6AiRmPRGgg8QCCK/eGfUMYRoWT4PnJQNHZC+bR25TgqPEYgvMDzVKhQOEV0Nfh pAVW+PzZ6ZuEOLk0AE4+sfsLMrwFbG1vJQIjHAwzT62EwCQOgUHPVUJ8HQbLgxekyEHwftxL i74BblnK551lYKvr8w8AXEWCt/aef1PA26F4Zo/obIcLkzPzfgbUNHfQom9FcKe1VyIGdgRf xoVAaA4FZ8u8NE3D9aLXtHgvDmobTyCBVVgD7t5iVIp05f8tLnI2XLh0U1ruv0AgdF32UGI+ AlzmixKRV0JN9SQpcjiUeR3U//kqJK1HQTzHH8hKjY6J4EzpyTyfbYwwcrktyPfL2my/VtjR q6lNDoQZpF2oyDkTlqikDXl8fpYDAUNq1Qrisy+lSDHkF3Cm7H2mQ5kc70CLGUobolhTN5Kg xKmGXC6D43I4078qwcg0R9GG0iQD7bAFBsQn2FKGpGuTnxVKX3bx67JD7qveF0YfDLGG9oS2 qpQ7Yx8Xb70ftH4iKfzYrk+xX8f05w43RNYPtXR6nRDzozl+28UlSxvVZvPy/e5H/bphpkGX oPJYr6Ut6Pb+ydo6sijj4SnV5i3j37+XXApeS8zuIVxFpyMrdFqKTzNE6UkTb/gLa3goEWED AAA= Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 22:28:19 -0000 --_000_AM4PR07MB1521618A37FE4B3A530703B496B80AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521618A37FE4B3A530703B496B80AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)      Nodes repre= senting domains must be considered as blocking/asymmetrical nodes. Dijkstra= assumes symmetrical nodes; so the “idea is to run Dijkstra on the MD= SC abstract topology and trigger a path computation to the relevant PNCs as soon as a node representing a domain i= s found” is questionable to begin with;

[FL] Of course there are far more details than the ones included= in my e-mail (long enough I think). One of these is that, of course, for each path returned by the PNC also the re= levant metrics and delay shall be returned. These, and also NO-PATH informa= tion if some connectivity is not possible, will be used by MDSC during path= computation;  metrics and delay shall be added to the currently computed ones, or if no path is found towa= rds a certain inter-domain link, no propagation will occur on that link; th= is compensates the blocking/asymmetrical characteristics of the node-domain= s.

2)      What happen= s if the algorithm finds a node represented not by a PNC, but by another (l= ower hierarchy level) MDSC?

[FL] Nothing different from a PNC I believe. As far as MDSC can = compute paths as a PNC does and return them to the higher level MDSC, I can’t see any difference.

3)      Assume you = want to compute a single path on a 20-domain topology originating in domain= 1 and terminating in, say, domain17. I don’t think you have much cho= ice but:

a) &= nbsp;     request PNC= 1 to compute all possible (not just optional) paths from the path source t= o all domain 1 inter-domain links;

b) &= nbsp;    request all= neighboring PNCs to “grow” all the computed paths over inter-d= omain links into the domains up to their respective outbound inter-domain l= inks with potentially significant increase in the number of successful paths;

c) &= nbsp;     repeat step= b) until the paths reach the destination (17th) domain;

d) &= nbsp;    grow the pa= ths until they hit the path computation destination;

e) &= nbsp;    select the = most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe “a lot”, but not exponentially grow= ing with the number of domains and inter-domain links. That was the point of my previous e-mail. Then we can decide we have too m= any messages around, but I believe we first need some criteria to understan= d what “a lot” or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantaneous, but, in general, wrong as far as the con= nectivity matrices don’t reflect the actual request parameters. Think about a request asking for a path with some affi= nity constraint, for example. Affinities are 32 bits values; you can ask to= include/exclude links in 3 different ways, specifying for each one any of = the 2^32 affinity combinations. Results of the path computation can be completely different depending on t= he affinity value and include/exlcude options. In theory to cope with just = the affinity constraint we should create L*(L-1)/2 * 3 * 2^32 paths per dom= ain. And we still have to combine this (that is multiply) with all the other constraints. =

Maybe we could renounce to some constraints and limit the flexib= ility of path computation. In my view this is the only way to make the connectivity matrix method a little bit m= ore appealing. But I still have dubts even with “essential” par= ameters like just bandwidth and objective functions.

 

4)      Computing d= iverse paths as two single path computations with the topology transformati= on in between does not apply here: the paths may go through the same and/or= different domains whose internal topologies are not known (hence there is nothing to transform);=

[FL] I agree that here the problem is more complex than in a sin= gle domain. I didn’t do tests yet on this, but I assume that a PNC should give also the possibility to ask for a path= in diversity from another path. So when the second path computation crosse= s the result of the first one in the same domain, we should ask the relevan= t PNC for a path computation in diversity from the previous path (possibly using the XRO mechanism) in ord= er to be guaranteed that even though the same domain is used, the two paths= are still diverse (PNC can guarantee that; if no diverse path is found, we= should try and manage the offending domain as the offending links in bhandari algorithm, chasing them out from= the solution).

5)      Computing a= connectivity matrix on a known (fully visible) topology is simple (as you = said, could be done in a single run) and also could be easily distributed b= etween several path computers to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix e= ntry may be associated with one or more intra-node paths and provide to the= MDSC various metrics, like delay, cost, max. bandwidth, SRLGs)  It co= uld be done in background when the path computers have nothing else to do (which is most of the time).<= /span>

[FL] As said above, the point here is that you don’t know = the request parameters yet. And I do believe that in order to compute matrices suitable for the purpose, either you hav= e to compute (and store, and maintain) too many of them, or you have to red= uce too much the complexity of the problem to be solved.<= /span>

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-     =      As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-     =      You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-     =      It’s built incrementally from= real requests and therefore with real parameters

-     =      It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-     =      For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-     =      For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-     =      For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

--_000_AM4PR07MB1521618A37FE4B3A530703B496B80AM4PR07MB1521eurp_-- From nobody Thu Nov 10 15:38:40 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AF81295BE; Thu, 10 Nov 2016 15:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 qRg7BE7gyzSs; Thu, 10 Nov 2016 15:38:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B93C129415; Thu, 10 Nov 2016 15:38:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAD26004; Thu, 10 Nov 2016 23:38:17 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml701-cah.china.huawei.com ([10.201.5.93]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 23:38:09 +0000 From: Italo Busi To: Igor Bryskin , Francesco Lazzeri , Fatai Zhang , "Dieter Beller" Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSO23iykJJwiMPcEi+8pkQxHy26KDS13dw Date: Thu, 10 Nov 2016 23:38:09 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B156AB6D1@lhreml504-mbs> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.135.253] Content-Type: multipart/alternative; boundary="_000_91E3A1BD737FDF4FA14118387FF6766B156AB6D1lhreml504mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010206.582504EA.0117, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0901344d095fe8d56d1389466178eea4 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 23:38:31 -0000 --_000_91E3A1BD737FDF4FA14118387FF6766B156AB6D1lhreml504mbs_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, I have discussed the issue with many TE domains with co-authors and we have= addressed it in section 3.3 of the draft: As discussed in section 2.2, there are some scalability issues with path co= mputation requests in a multi-domain TE network with many TE domains, in te= rms of the number of requests to send to the TE domain controllers. It woul= d therefore be worthwhile using the TE topology information provided by the= domain controllers to limit the number of requests. An example about how this logic would work is provided in the remaining par= t o f section 3.3 (too long to replicate here the text). The bottom-line conclusion we have reached is described at the end of secti= on 3 of the draft: In nutshell, there is a scalability trade-off between providing all the TE = information needed by the Orchestrator's PCE to take optimal path computati= on decisions by its own versus requesting the Orchestrator to ask to too ma= ny underlying SDN Domain Controllers a set of feasible optimal intra-domain= TE paths. IMHO, this approach solves the issue and makes path computation applicable = also to multi-domain TE networks with many TE networks. What do you think? Italo From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 10 novembre 2016 17:15 To: Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_91E3A1BD737FDF4FA14118387FF6766B156AB6D1lhreml504mbs_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

I have discussed the i= ssue with many TE domains with co-authors and we have addressed it in secti= on 3.3 of the draft:

 

As discussed= in section 2.2, there are some scalability issues with path computation re= quests in a multi-domain TE network with many TE domains, in terms of the number of requests to send to the TE domain contr= ollers. It would therefore be worthwhile using the TE topology information = provided by the domain controllers to limit the number of requests.

 

An example about how t= his logic would work is provided in the remaining part o f section 3.3 (too= long to replicate here the text).

 

The bottom-line conclu= sion we have reached is described at the end of section 3 of the draft:

 

In nutshell,= there is a scalability trade-off between providing all the TE information = needed by the Orchestrator’s PCE to take optimal path computation decisions by its own versus requesting the Orchestrator t= o ask to too many underlying SDN Domain Controllers a set of feasible optim= al intra-domain TE paths.

 

IMHO, this approach so= lves the issue and makes path computation applicable also to multi-domain T= E networks with many TE networks.

 

What do you think?

 

Italo

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 10 novembre 2016 17:15
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   = ;       For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology inf= ormation, it is likely to contain proprietary information and hence useless= for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   = ;       For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   = ;       For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary compu= tations are done already by PNCs when exposing and updating the abstract TE= topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be = linked in a hierarchy. This means that for a top level MDSC e2e path comput= ation, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)  &nbs= p;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: R= 20; No, I have nothing for you” ?  What if the path was relied u= pon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)  &nbs= p;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link AR= 17;B’ points to the underlay (provider) TE topology where the path is= computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to t= he path computation request and doesn’t advertise any new TE link to = the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is supp= orted not by a provisioned in a server layer TE tunnel (connection), rather= , by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)  &nbs= p;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: R= 20; No, I have nothing for you” ?  What if the path was relied u= pon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)  &nbs= p;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link AR= 17;B’ points to the underlay (provider) TE topology where the path is= computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_91E3A1BD737FDF4FA14118387FF6766B156AB6D1lhreml504mbs_-- From nobody Fri Nov 11 00:04:49 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91B4129A2B; Fri, 11 Nov 2016 00:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5yI7-Gv_Gj0t; Fri, 11 Nov 2016 00:04:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C23129A25; Fri, 11 Nov 2016 00:04:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUZ17750; Fri, 11 Nov 2016 08:04:44 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 08:04:43 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.3]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 16:04:37 +0800 From: "Yemin (Amy)" To: "ccamp@ietf.org" , "ccamp-chairs@ietf.org" Thread-Topic: Status update on draft-ietf-ccamp-ospf-availability-extension & draft-ietf-ccamp-rsvp-te-bandwidth-availability Thread-Index: AdI78aypaPJtKAI1TuaL4p3M7JxD7g== Date: Fri, 11 Nov 2016 08:04:37 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CE24637@szxema506-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CE24637szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58257B9C.00F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.3, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e57e6cb91b799e5903d185b6bba152b9 Archived-At: Subject: [CCAMP] Status update on draft-ietf-ccamp-ospf-availability-extension & draft-ietf-ccamp-rsvp-te-bandwidth-availability X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 08:04:49 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CE24637szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMPers, The following is a status update of the two WG drafts since the last IETF m= eeting. 1. OSPF-TE Link Availability Extension for Links with Variable Discre= te Bandwidth: draft-ietf-ccamp-ospf-availability-extension-08 Current status: Completed WG LC. Draft was updated to address AD review. = There're comment raised in Gen-ATR review stage. A new draft in TEAS propos= ing a generalized SCSI is to solve the problem. Open Issues: None. Next Steps: To be published together with the new draft? 2. Ethernet Traffic Parameters with Availability Information: draft-i= etf-ccamp-rsvp-te-bandwidth-availability-05 Current status: stable since Aug. Open Issues: None. Next Steps: Waiting for WG LC. BR, Amy (on behalf of the co-authors) ________________________________ This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CE24637szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi CCAMPers,

 

The following is a statu= s update of the two WG drafts since the last IETF meeting.

 =

1.&nb= sp;      OSPF-TE Link Availability Extension for Link= s with Variable Discrete Bandwidth: draft-ietf-ccamp-ospf-availability-exte= nsion-08

Current status: Complet= ed WG LC. Draft was updated to address AD review.   There’r= e comment raised in Gen-ATR review stage. A new draft in TEAS proposing a g= eneralized SCSI is to solve the problem.

Open Issues: None.=

Next Steps: To be publi= shed together with the new draft?

 

2.&nb= sp;      Ethernet Traffic Parameters with Availabilit= y Information: draft-ietf-ccamp-rsvp-te-bandwidth-availability-05

Current status:  s= table since Aug.

Open Issues: None.=

Next Steps:  Waiti= ng for WG LC.

 

BR,

Amy (on behalf of the co-authors)

This e-mail and its attachments contain confidential inform= ation from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CE24637szxema506mbschi_-- From nobody Fri Nov 11 06:43:58 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9249129AF8; Fri, 11 Nov 2016 06:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 JP07q1HM-dIt; Fri, 11 Nov 2016 06:43:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26A6129A62; Fri, 11 Nov 2016 06:43:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE76513; Fri, 11 Nov 2016 14:43:12 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 14:43:10 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 06:43:02 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAWDYAgAB43DD//9f5gP//iVnA Date: Fri, 11 Nov 2016 14:43:01 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0FE8Ddfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5825D901.0283, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bee9e4788904c3a2f3d547c3eaf515ee Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 14:43:57 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FE8Ddfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Franseco, I probably didn't make myself clear. The two main points that I was trying = to make are: 1) Dijkstra does not work on topologies with constrained/asymmetrical = nodes; 2) There will be much more calls to PNCs that you seem to believe Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is ca= lled and the response says that the path can leave N1 over links L3, L4, L5= and L6. Suppose later the algorithm reaches N1 again over link L2. Will yo= u have to call PNC1 again? Sure, because now it returns the valid outbound = links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it = was not accounted yet. Will you have to consider link L3 again? Sure, becau= se you have not considered L2-L3 inbound/outbound link combination yet: L1-= L3 internal (intra-node) path has different costs compared to L2-L3 interna= l path. The conclusions: a) the algorithm has to (re-)visit the same node multiple times; b) PNC will be called not only when the node first discovered (as you i= mplied), but every time the node is reached (which could be as many times a= s the number of links it terminates); c) when the node is represented by an MDSC, the entire sub-tree of MDS= Cs/PNCs will be called hierarchically every time the MDSC in question is ca= lled, which may dramatically increase the number of calls to PNCs, the numb= er of paths to be grown, the overall time of the path computation, etc. ; d) The biggest scalability issue is not even the number of times PNCs/M= DSCs need to be called - the amount of paths that need to be grown. Note th= at PNC needs to return not just most optimal paths to all outbound links it= can reach, rather, all possible such paths, so that end-to-end path constr= aints could be met. Other issues are (some of them you mentioned below): a) how the algorithm prefers a segment over domain1 over a segment ove= r domain 2 when the metrics are not normalized (apples and oranges)? b) how the algorithm deals with independent/overlapping SRLGs in the do= mains? c) what if domains have independent overlapping name space for node an= d link IDs? In other words. what does a path returned by a PNC even mean to MDSC? Furthermore, I disagree with what you said about node's connectivity matric= es because: 1) Several flavors of matrices could be provided (e.g. one optimized = by smallest cost and another by shortest delay); 2) Multiple intra-node paths could be associated with the same inbound= -outbound link combination. Each such path will yield a separate vector of = costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal aff= inities) that could be compared against the MDSC's path computation constra= ints; 3) Most importantly, TE topology model allows for negotiation of exact= connectivity matrices MDSC needs from PNCs. Such negotiation could happen = at any time, including before or even in the middle of the path computation= if the MDSC thinks the ones it has already are not good or sufficient enou= gh. Cheers, Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Thursday, November 10, 2016 5:28 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FE8Ddfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Franseco,

 

I probably didn’= t make myself clear. The two main points that I was trying to make are:

1)&n= bsp;     Dijkstra does = not work on topologies with constrained/asymmetrical nodes;

2)&n= bsp;     There will be = much more calls to PNCs that you seem to believe

 

Imagine your algorithm= hit node N1 over link L1. PNC1 representing N1 is called and the response = says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later= the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns th= e valid outbound links to be L3, L4, L7 and L8. Will you have to consider l= ink L8? Sure, it was not accounted yet. Will you have to consider link L3 a= gain? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (in= tra-node) path has different costs compared to L2-L3 internal path.

The conclusions:<= /o:p>

a)&n= bsp;     the algorithm = has to (re-)visit the same node multiple times;

b)&n= bsp;    PNC will be ca= lled not only when the node first discovered (as you implied), but every ti= me the node is reached (which could be as many times as the number of links= it terminates);

c)&n= bsp;     when the node = is represented by an MDSC, the entire sub-tree of MDSCs/PNCs will be called= hierarchically every time the MDSC in question is called, which may dramat= ically increase the number of calls to PNCs, the number of paths to be grown, the overall time of the path com= putation, etc. ;

d)&n= bsp;    The biggest sc= alability issue is not even the number of times PNCs/MDSCs need to be calle= d – the amount of paths that need to be grown. Note that PNC needs to= return not just most optimal paths to all outbound links it can reach, rather, all possible such paths, so that e= nd-to-end path constraints could be met.

 

Other issues are (some= of them you mentioned below):

a)&n= bsp;     how the algori= thm prefers a segment over domain1 over a segment over domain 2 when the me= trics are not normalized (apples and oranges)?

b)&n= bsp;    how the algori= thm deals with independent/overlapping SRLGs in the domains?

c)&n= bsp;     what if domain= s have independent overlapping name space for node and link IDs?=

 

In other words. what d= oes a path returned by a PNC even mean to MDSC?

 

Furthermore, I disagre= e with what you said about node’s connectivity matrices because:=

1)&n= bsp;     Several flavor= s of  matrices could be provided (e.g. one optimized by smallest cost = and another by shortest delay);

2)&n= bsp;     Multiple intra= -node paths could be associated with the same inbound-outbound link combina= tion. Each such path will yield a separate vector of costs (summary TE cost= , delay, max. bandwidth, internal SRLGs, internal affinities) that could be compared against the MDSC’= s path computation constraints;

3)&n= bsp;     Most important= ly, TE topology model allows for negotiation of exact connectivity matrices MDSC needs from PNCs. Suc= h negotiation could happen at any time, including before or even in the mid= dle of the path computation if the MDSC thinks the ones it has already are = not good or sufficient enough.

 

 

Cheers,

Igor  

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@erics= son.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)   = ;   Nodes representing domains must be = considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nod= es; so the “idea is to run Dijkstra on the MDSC abstract topology and= trigger a path computation to the relevant PNCs as soon as a node representing a domain is found” is questionab= le to begin with;

[FL] Of course ther= e are far more details than the ones included in my e-mail (long enough I t= hink). One of these is that, of course, for each path returned by the PNC a= lso the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is n= ot possible, will be used by MDSC during path computation;  metrics an= d delay shall be added to the currently computed ones, or if no path is fou= nd towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asym= metrical characteristics of the node-domains.

2)   = ;   What happens if the algorithm finds= a node represented not by a PNC, but by another (lower hierarchy level) MD= SC?

[FL] Nothing differ= ent from a PNC I believe. As far as MDSC can compute paths as a PNC does an= d return them to the higher level MDSC, I can’t see any difference.

3)   = ;   Assume you want to compute a single= path on a 20-domain topology originating in domain 1 and terminating in, s= ay, domain17. I don’t think you have much choice but:

a)       request PNC 1 to compute all possib= le (not just optional) paths from the path source to all domain 1 inter-dom= ain links;

b)      request all neighboring PNCs to = 220;grow” all the computed paths over inter-domain links into the dom= ains up to their respective outbound inter-domain links with potentially si= gnificant increase in the number of successful paths;

c)       repeat step b) until the paths reac= h the destination (17th) domain;

d)      grow the paths until they hit the p= ath computation destination;

e)      select the most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe &#= 8220;a lot”, but not exponentially growing with the number of domains= and inter-domain links. That was the point of my previous e-mail. Then we = can decide we have too many messages around, but I believe we first need some criteria to understand what “a lot̶= 1; or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantane= ous, but, in general, wrong as far as the connectivity matrices don’t= reflect the actual request parameters. Think about a request asking for a = path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 d= ifferent ways, specifying for each one any of the 2^32 affinity combination= s. Results of the path computation can be completely different depending on= the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should cre= ate L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine thi= s (that is multiply) with all the other constraints.

Maybe we could reno= unce to some constraints and limit the flexibility of path computation. In = my view this is the only way to make the connectivity matrix method a littl= e bit more appealing. But I still have dubts even with “essential” parameters like just bandwidth and= objective functions.

 

4)   = ;   Computing diverse paths as two sing= le path computations with the topology transformation in between does not a= pply here: the paths may go through the same and/or different domains whose= internal topologies are not known (hence there is nothing to transform);

[FL] I agree that h= ere the problem is more complex than in a single domain. I didn’t do = tests yet on this, but I assume that a PNC should give also the possibility= to ask for a path in diversity from another path. So when the second path computation crosses the result of the first = one in the same domain, we should ask the relevant PNC for a path computati= on in diversity from the previous path (possibly using the XRO mechanism) i= n order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can g= uarantee that; if no diverse path is found, we should try and manage the of= fending domain as the offending links in bhandari algorithm, chasing them o= ut from the solution).

5)   = ;   Computing a connectivity matrix on = a known (fully visible) topology is simple (as you said, could be done in a= single run) and also could be easily distributed between several path comp= uters to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be asso= ciated with one or more intra-node paths and provide to the MDSC various me= trics, like delay, cost, max. bandwidth, SRLGs)  It could be done in b= ackground when the path computers have nothing else to do (which is most of the time).

[FL] As said above,= the point here is that you don’t know the request parameters yet. An= d I do believe that in order to compute matrices suitable for the purpose, = either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity = of the problem to be solved.

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-   =        As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-   =        You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-   =        It’s built incrementally from= real requests and therefore with real parameters

-   =        It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0FE8Ddfweml501mbx_-- From nobody Fri Nov 11 06:48:39 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1611294F8; Fri, 11 Nov 2016 06:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 oavCFjISyBC4; Fri, 11 Nov 2016 06:48:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC9412949C; Fri, 11 Nov 2016 06:48:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUZ73877; Fri, 11 Nov 2016 14:48:22 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 14:48:15 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 06:48:04 -0800 From: Igor Bryskin To: Italo Busi , Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAvKGA//+IfFA= Date: Fri, 11 Nov 2016 14:48:03 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0FEAC@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <91E3A1BD737FDF4FA14118387FF6766B156AB6D1@lhreml504-mbs> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B156AB6D1@lhreml504-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0FEACdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5825DA38.0025, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 488aa49910b38b0ac62a485a0ad8b155 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 14:48:33 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FEACdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Italo, Y said: "IMHO, this approach solves the issue and makes path computation applicable= also to multi-domain TE networks with many TE networks". I respectfully disagree with this conclusion for all the reasons I provided= in the response to Francesco. Cheers, Igor. From: Italo Busi Sent: Thursday, November 10, 2016 6:38 PM To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I have discussed the issue with many TE domains with co-authors and we have= addressed it in section 3.3 of the draft: As discussed in section 2.2, there are some scalability issues with path co= mputation requests in a multi-domain TE network with many TE domains, in te= rms of the number of requests to send to the TE domain controllers. It woul= d therefore be worthwhile using the TE topology information provided by the= domain controllers to limit the number of requests. An example about how this logic would work is provided in the remaining par= t o f section 3.3 (too long to replicate here the text). The bottom-line conclusion we have reached is described at the end of secti= on 3 of the draft: In nutshell, there is a scalability trade-off between providing all the TE = information needed by the Orchestrator's PCE to take optimal path computati= on decisions by its own versus requesting the Orchestrator to ask to too ma= ny underlying SDN Domain Controllers a set of feasible optimal intra-domain= TE paths. IMHO, this approach solves the issue and makes path computation applicable = also to multi-domain TE networks with many TE networks. What do you think? Italo From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 10 novembre 2016 17:15 To: Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FEACdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Italo,

 

Y said:

“IMHO, this approach solves the issue and makes path c= omputation applicable also to multi-domain TE networks with many TE network= s”.

 

I respectfully disagre= e with this conclusion for all the reasons I provided in the response to Fr= ancesco.

 

Cheers,

Igor.

 

 

 

 

From: Italo Busi
Sent: Thursday, November 10, 2016 6:38 PM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Igor,

 

I have discussed the i= ssue with many TE domains with co-authors and we have addressed it in secti= on 3.3 of the draft:

 

As discussed i= n section 2.2, there are some scalability issues with path computation requ= ests in a multi-domain TE network with many TE domains, in terms of the number of requests to send to the TE domain controllers. I= t would therefore be worthwhile using the TE topology information provided = by the domain controllers to limit the number of requests.

 

An example about how t= his logic would work is provided in the remaining part o f section 3.3 (too= long to replicate here the text).

 

The bottom-line conclu= sion we have reached is described at the end of section 3 of the draft:

 

In nutshell, t= here is a scalability trade-off between providing all the TE information ne= eded by the Orchestrator’s PCE to take optimal path computation decisions by its own versus requesting the Orchestrator to ask= to too many underlying SDN Domain Controllers a set of feasible optimal in= tra-domain TE paths.

 

IMHO, this approach so= lves the issue and makes path computation applicable also to multi-domain T= E networks with many TE networks.

 

What do you think?

 

Italo

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 10 novembre 2016 17:15
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0FEACdfweml501mbx_-- From nobody Fri Nov 11 07:21:14 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CBC12970F; Fri, 11 Nov 2016 07:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 ualco8F9IgiM; Fri, 11 Nov 2016 07:21:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369181296FF; Fri, 11 Nov 2016 07:21:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUZ78177; Fri, 11 Nov 2016 15:20:56 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml703-cah.china.huawei.com ([10.201.5.104]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 15:20:44 +0000 From: Italo Busi To: Igor Bryskin , Francesco Lazzeri , Fatai Zhang , "Dieter Beller" Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSO23iykJJwiMPcEi+8pkQxHy26KDS13dwgAEG4oCAAAXzcA== Date: Fri, 11 Nov 2016 15:20:44 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B156ABBA4@lhreml504-mbs> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <91E3A1BD737FDF4FA14118387FF6766B156AB6D1@lhreml504-mbs> <0C72C38E7EBC34499E8A9E7DD007863908F0FEAC@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0FEAC@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.144.128] Content-Type: multipart/alternative; boundary="_000_91E3A1BD737FDF4FA14118387FF6766B156ABBA4lhreml504mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5825E1D9.0220, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 488aa49910b38b0ac62a485a0ad8b155 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 15:21:11 -0000 --_000_91E3A1BD737FDF4FA14118387FF6766B156ABBA4lhreml504mbs_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, As far as I can understand your arguments with Francesco, you are assuming = that the MDSC shall request path computations to all its underlying PNCs (a= nd even multiple times). The approach described in section 3.3 of the draft is different. The idea i= s that the MDSC can use the TE Topology information provided by its underly= ing PNCs to reduce the number of PNCs path computation have to be requested= to. Let me make a simple analogy. If I need to go from New York to Los Angeles,= I know (from the topology information) that any path going outside USA wil= l be longer so there is no need to request path computation to the "PCNs" o= utside of USA. Nevertheless, I need to request information to the different= "PCNs" in USA to figure out which will be the best path within USA. In a nutshell, path computation does not eliminate the need to provide TE T= opology abstract information as well as providing TE Topology abstract info= rmation does not eliminate the need to support path computation. The two tools instead could be used together in a smart way to achieve scal= ability in these quite complex scenarios. Italo From: Igor Bryskin Sent: venerd=EC 11 novembre 2016 15:48 To: Italo Busi; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Hi Italo, Y said: "IMHO, this approach solves the issue and makes path computation applicable= also to multi-domain TE networks with many TE networks". I respectfully disagree with this conclusion for all the reasons I provided= in the response to Francesco. Cheers, Igor. From: Italo Busi Sent: Thursday, November 10, 2016 6:38 PM To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I have discussed the issue with many TE domains with co-authors and we have= addressed it in section 3.3 of the draft: As discussed in section 2.2, there are some scalability issues with path co= mputation requests in a multi-domain TE network with many TE domains, in te= rms of the number of requests to send to the TE domain controllers. It woul= d therefore be worthwhile using the TE topology information provided by the= domain controllers to limit the number of requests. An example about how this logic would work is provided in the remaining par= t o f section 3.3 (too long to replicate here the text). The bottom-line conclusion we have reached is described at the end of secti= on 3 of the draft: In nutshell, there is a scalability trade-off between providing all the TE = information needed by the Orchestrator's PCE to take optimal path computati= on decisions by its own versus requesting the Orchestrator to ask to too ma= ny underlying SDN Domain Controllers a set of feasible optimal intra-domain= TE paths. IMHO, this approach solves the issue and makes path computation applicable = also to multi-domain TE networks with many TE networks. What do you think? Italo From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 10 novembre 2016 17:15 To: Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_91E3A1BD737FDF4FA14118387FF6766B156ABBA4lhreml504mbs_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

As far as I can unders= tand your arguments with Francesco, you are assuming that the MDSC shall re= quest path computations to all its underlying PNCs (and even multiple times= ).

 

The approach described= in section 3.3 of the draft is different. The idea is that the MDSC can us= e the TE Topology information provided by its underlying PNCs to reduce the= number of PNCs path computation have to be requested to.

 

Let me make a simple a= nalogy. If I need to go from New York to Los Angeles, I know (from the topo= logy information) that any path going outside USA will be longer so there i= s no need to request path computation to the “PCNs” outside of USA. Nevertheless, I need to request = information to the different “PCNs” in USA to figure out which = will be the best  path within USA.

 

In a nutshell, path co= mputation does not eliminate the need to provide TE Topology abstract infor= mation as well as providing TE Topology abstract information does not elimi= nate the need to support path computation.

The two tools instead = could be used together in a smart way to achieve scalability in these quite= complex scenarios.

 

Italo

 

From: Igor Bryskin
Sent: venerd=EC 11 novembre 2016 15:48
To: Italo Busi; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Hi Italo,

 

Y said:

“IMHO, this appr= oach solves the issue and makes path computation applicable also to multi-d= omain TE networks with many TE networks”.

 

I respectfully disagre= e with this conclusion for all the reasons I provided in the response to Fr= ancesco.

 

Cheers,

Igor.

 

 

 

 

From: Italo Busi
Sent: Thursday, November 10, 2016 6:38 PM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

I have discussed the i= ssue with many TE domains with co-authors and we have addressed it in secti= on 3.3 of the draft:

 

As discussed= in section 2.2, there are some scalability issues with path computation re= quests in a multi-domain TE network with many TE domains, in terms of the number of requests to send to the TE domain contr= ollers. It would therefore be worthwhile using the TE topology information = provided by the domain controllers to limit the number of requests.

 

An example about how t= his logic would work is provided in the remaining part o f section 3.3 (too= long to replicate here the text).

 

The bottom-line conclu= sion we have reached is described at the end of section 3 of the draft:

 

In nutshell,= there is a scalability trade-off between providing all the TE information = needed by the Orchestrator’s PCE to take optimal path computation decisions by its own versus requesting the Orchestrator t= o ask to too many underlying SDN Domain Controllers a set of feasible optim= al intra-domain TE paths.

 

IMHO, this approach so= lves the issue and makes path computation applicable also to multi-domain T= E networks with many TE networks.

 

What do you think?

 

Italo

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 10 novembre 2016 17:15
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   = ;       For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology inf= ormation, it is likely to contain proprietary information and hence useless= for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   = ;       For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   = ;       For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary compu= tations are done already by PNCs when exposing and updating the abstract TE= topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be = linked in a hierarchy. This means that for a top level MDSC e2e path comput= ation, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)  &nbs= p;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: R= 20; No, I have nothing for you” ?  What if the path was relied u= pon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)  &nbs= p;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link AR= 17;B’ points to the underlay (provider) TE topology where the path is= computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to t= he path computation request and doesn’t advertise any new TE link to = the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is supp= orted not by a provisioned in a server layer TE tunnel (connection), rather= , by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)  &nbs= p;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: R= 20; No, I have nothing for you” ?  What if the path was relied u= pon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)  &nbs= p;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link AR= 17;B’ points to the underlay (provider) TE topology where the path is= computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_91E3A1BD737FDF4FA14118387FF6766B156ABBA4lhreml504mbs_-- From nobody Fri Nov 11 07:34:38 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F380129576; Fri, 11 Nov 2016 07:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 dJdtuB0n9-RN; Fri, 11 Nov 2016 07:34:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEAE12988F; Fri, 11 Nov 2016 07:34:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUZ79635; Fri, 11 Nov 2016 15:34:17 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 15:32:37 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 07:32:28 -0800 From: Igor Bryskin To: Italo Busi , Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAvKGA//+IfFAAL9vrAAAQjVEQ Date: Fri, 11 Nov 2016 15:32:29 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0FED7@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <91E3A1BD737FDF4FA14118387FF6766B156AB6D1@lhreml504-mbs> <0C72C38E7EBC34499E8A9E7DD007863908F0FEAC@dfweml501-mbx> <91E3A1BD737FDF4FA14118387FF6766B156ABBA4@lhreml504-mbs> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B156ABBA4@lhreml504-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0FED7dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5825E4F9.045B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 488aa49910b38b0ac62a485a0ad8b155 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 15:34:29 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FED7dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Italo, In your analogy how you can be sure that a better (faster) path from New Yo= ur, say, to Seattle is not via Canada offering wide and empty intra-country= highways? Igor From: Italo Busi Sent: Friday, November 11, 2016 10:21 AM To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, As far as I can understand your arguments with Francesco, you are assuming = that the MDSC shall request path computations to all its underlying PNCs (a= nd even multiple times). The approach described in section 3.3 of the draft is different. The idea i= s that the MDSC can use the TE Topology information provided by its underly= ing PNCs to reduce the number of PNCs path computation have to be requested= to. Let me make a simple analogy. If I need to go from New York to Los Angeles,= I know (from the topology information) that any path going outside USA wil= l be longer so there is no need to request path computation to the "PCNs" o= utside of USA. Nevertheless, I need to request information to the different= "PCNs" in USA to figure out which will be the best path within USA. In a nutshell, path computation does not eliminate the need to provide TE T= opology abstract information as well as providing TE Topology abstract info= rmation does not eliminate the need to support path computation. The two tools instead could be used together in a smart way to achieve scal= ability in these quite complex scenarios. Italo From: Igor Bryskin Sent: venerd=EC 11 novembre 2016 15:48 To: Italo Busi; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Hi Italo, Y said: "IMHO, this approach solves the issue and makes path computation applicable= also to multi-domain TE networks with many TE networks". I respectfully disagree with this conclusion for all the reasons I provided= in the response to Francesco. Cheers, Igor. From: Italo Busi Sent: Thursday, November 10, 2016 6:38 PM To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I have discussed the issue with many TE domains with co-authors and we have= addressed it in section 3.3 of the draft: As discussed in section 2.2, there are some scalability issues with path co= mputation requests in a multi-domain TE network with many TE domains, in te= rms of the number of requests to send to the TE domain controllers. It woul= d therefore be worthwhile using the TE topology information provided by the= domain controllers to limit the number of requests. An example about how this logic would work is provided in the remaining par= t o f section 3.3 (too long to replicate here the text). The bottom-line conclusion we have reached is described at the end of secti= on 3 of the draft: In nutshell, there is a scalability trade-off between providing all the TE = information needed by the Orchestrator's PCE to take optimal path computati= on decisions by its own versus requesting the Orchestrator to ask to too ma= ny underlying SDN Domain Controllers a set of feasible optimal intra-domain= TE paths. IMHO, this approach solves the issue and makes path computation applicable = also to multi-domain TE networks with many TE networks. What do you think? Italo From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 10 novembre 2016 17:15 To: Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FED7dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Italo,

 

In your analogy how yo= u can be sure that a better (faster) path from New Your, say, to Seattle is= not via Canada offering wide and empty intra-country highways?  =

 

Igor=

 

From: Italo Busi
Sent: Friday, November 11, 2016 10:21 AM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Igor,

 

As far as I can unders= tand your arguments with Francesco, you are assuming that the MDSC shall re= quest path computations to all its underlying PNCs (and even multiple times= ).

 

The approach described= in section 3.3 of the draft is different. The idea is that the MDSC can us= e the TE Topology information provided by its underlying PNCs to reduce the= number of PNCs path computation have to be requested to.

 

Let me make a simple a= nalogy. If I need to go from New York to Los Angeles, I know (from the topo= logy information) that any path going outside USA will be longer so there i= s no need to request path computation to the “PCNs” outside of USA. Nevertheless, I need to request = information to the different “PCNs” in USA to figure out which = will be the best  path within USA.

 

In a nutshell, path co= mputation does not eliminate the need to provide TE Topology abstract infor= mation as well as providing TE Topology abstract information does not elimi= nate the need to support path computation.

The two tools instead = could be used together in a smart way to achieve scalability in these quite= complex scenarios.

 

Italo

 

From: Igor Bryskin
Sent: venerd=EC 11 novembre 2016 15:48
To: Italo Busi; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Hi Italo,

 

Y said:

“IMHO, this appr= oach solves the issue and makes path computation applicable also to multi-d= omain TE networks with many TE networks”.

 

I respectfully disagre= e with this conclusion for all the reasons I provided in the response to Fr= ancesco.

 

Cheers,

Igor.

 

 

 

 

From: Italo Busi
Sent: Thursday, November 10, 2016 6:38 PM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

I have discussed the i= ssue with many TE domains with co-authors and we have addressed it in secti= on 3.3 of the draft:

 

As discussed i= n section 2.2, there are some scalability issues with path computation requ= ests in a multi-domain TE network with many TE domains, in terms of the number of requests to send to the TE domain controllers. I= t would therefore be worthwhile using the TE topology information provided = by the domain controllers to limit the number of requests.

 

An example about how t= his logic would work is provided in the remaining part o f section 3.3 (too= long to replicate here the text).

 

The bottom-line conclu= sion we have reached is described at the end of section 3 of the draft:

 

In nutshell, t= here is a scalability trade-off between providing all the TE information ne= eded by the Orchestrator’s PCE to take optimal path computation decisions by its own versus requesting the Orchestrator to ask= to too many underlying SDN Domain Controllers a set of feasible optimal in= tra-domain TE paths.

 

IMHO, this approach so= lves the issue and makes path computation applicable also to multi-domain T= E networks with many TE networks.

 

What do you think?

 

Italo

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 10 novembre 2016 17:15
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0FED7dfweml501mbx_-- From nobody Fri Nov 11 07:44:57 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5F129B78; Fri, 11 Nov 2016 07:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 7njUeOR60jPY; Fri, 11 Nov 2016 07:44:48 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1A7129435; Fri, 11 Nov 2016 07:44:46 -0800 (PST) X-AuditID: c1b4fb2d-5b107980000009f7-0a-5825e76d8efc Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id DA.FC.02551.D67E5285; Fri, 11 Nov 2016 16:44:45 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 11 Nov 2016 16:43:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K+aNzgLFS2715Z3xVsuBHcaulKzNvN+xPYjzvTAeZcY=; b=fb12u9PNb1p8TzSE2N5QRWZnF8nlev0EY1LneiPnEGBhNzj4wreuMvtQwyDLI+LS8DtrZsx96ZLQnQkC0PRsJ+CBtAw+VsED3Lo3r0oeETjU9T5NClaXzIugY0/9dYX3lZyxJj+Mdz3PsoKHkvJQmQiYPNWgBMTy89zWj+bk69o= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1523.eurprd07.prod.outlook.com (10.165.248.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Fri, 11 Nov 2016 15:43:08 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Fri, 11 Nov 2016 15:43:08 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgIAAI1UAgADWmeCAAIRPgIAABhYQgAA29wCAABvbsIABH86AgAAJT3A= Date: Fri, 11 Nov 2016 15:43:07 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-microsoft-exchange-diagnostics: 1; AM4PR07MB1523; 7:4hJCjaKLiRCdKaENVTXrsk2nH2DeC+etmOsXd8pr2Y/xz/GMrsJC8CfUMPJAYyp4JAn8VRHx2I7G8ozvyQv22vkg7kWpy02JRYaBXntkXpqtyzBSue0UEAty5Ajstgx5n/sIhJUYMjvuz1+JjbO2oruAkJBQC730K/sg6q7+VQYJcDWsWvraVgqeVjPJQD9VvTfuyYjbIE+6g0kUvEAcZgk+do8wdYL5o9ZzTW+tjlPfNefh5SnXhuTU84cSLtPyYH6ES4pKStqASm4gxQAgaPLwz9UgnHCUZN8tdf6x9FMLtCsdqLRcNhhOK4PTKcPieu8qlza7S6GJn6fr8Inut3d4mi/Ty6o/vLs1lMgO9zU= x-ms-office365-filtering-correlation-id: 7311a360-e673-44d9-3be0-08d40a496f37 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR07MB1523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1523; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1523; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(199003)(53754006)(189002)(24454002)(87936001)(586003)(3280700002)(6116002)(76576001)(74316002)(2950100002)(230783001)(102836003)(77096005)(3846002)(790700001)(50986999)(5001770100001)(54356999)(97736004)(9686002)(189998001)(76176999)(8676002)(101416001)(68736007)(561944003)(33656002)(66066001)(3660700001)(93886004)(220493001)(7906003)(2906002)(2900100001)(4326007)(7736002)(7846002)(86362001)(229853002)(92566002)(106116001)(7696004)(5660300001)(106356001)(8936002)(81156014)(105586002)(3900700001)(81166006)(122556002)(579004)(559001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1523; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521C97DF245E238041FE32296BB0AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 15:43:07.9102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1523 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfOtuNq9DpvD1qKY0IXtGaZJxGzD4YkUlDS0KJGO6jopuxY pBSpZZRpGKXpNC+5NM2MStSkhIlYat7SykZissVQU7yBWrTy7Czo2+95/v/nfS68FCF7L/Sm knUZjF6nTpWLJGSZqi0mUGsLUO3JWfGkrRXjJN1s/ErSv3uV9PrITtr8qEFI506Oi+m8tXaS vn11SBhJRV/rnhNGG43rgugJ8wfBMSJeEq5hUpMvMPrdEWclSVMz3SjdYNp08UvHWzIbtd2R 5CMXCvA+uP9jQpyPJJQMNyMwGaacwTsE1tl5AReQuJCAuZZKAa+UCmA4z0Rw9Q5bxWgIxyJM w8/ucpJjd5wF31etIq6AwJ8RVL76uvEuRbnhUzB43ZX3nIbiby+d/nkEg9PhHJM4AAZKF8Qc SzfshdduOEeqxFAxVOEocMFRUJJrdzDCnrDa1yTgmMBeYLZWCfjlMBhfDxE8e8C0xS7k/Wp4 bjQ4Pf4w3GhwbAa4moDClSIxL8RC+ceHiBua4z9LMj6dAv2tA0Le34Sg9c2YiBfaEeTPHeB5 KxTl9zobLwih4FkKfy0G6p/mIY7dsDdMjN1ERWiH4b+5eU6D5S/1IoPjAK7QW2Yl+XwQjBff E/G8C+pqZgmeA6HU3kX+n69G4kbkwTIsq00M3hvE6JPPsWyaLkjHZLxAG3/M1PIrsB09mT3U hTCF5Jul6bcUKplQfYHN1HYhoAi5u/SSJUAlk2rUmVmMPu2M/nwqw3YhH4qUe0n3N0yelOFE dQaTwjDpjP6fKqBcvLNRmG270ji0ePmqqrtYERZ3cMm3+JTYYrZ1+HmRlqpPv7UlWZMipTX0 7uH2mNCIvOECpd1cbn2RWxu33Hl0VOPnrgiuXY+vX1D0bGvxnXng2epxJSqyZ+ri2o6gml4f jX1wbIuIOu6HDYUntMmdOTr/2ISRBJu97ujjxSNVfSH9cpJNUit3EnpW/Rf5bfOpXwMAAA== Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 15:44:56 -0000 --_000_AM4PR07MB1521C97DF245E238041FE32296BB0AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, I know that "pure" Dijkstra actually cannot be used (in most cases) and use= d it for brevity. Constrained Dijkstra and derivative algorithms that are a= ctually used relax some of the rules of Dijkstra without becoming exponenti= al for that. Think to a very worst case wher you ask for all the possible paths to all d= omains and then use this information for the MDSC path computation without = any further request. Assuming a network with N domains having L inter-domain links in mean, we m= ust ask N*L*(L-1)/2 paths around wich is still polinomial. Using Dijkstra i= n a single run, as mentioned, requests should become N*L. This is what I ex= pect as an upper bound to the number of calls to PNC. This actually is the method suggested by the draft, which seems to me reaso= nable (asking only when needed will save queries to the PNCs, but on the ot= her side asking all together in the beginning would allow to send requests = in parallel to different domains, which saves time; space for some further = consideration here). The other issues, even if notable, were not discusses so far and I rather f= ocus on the scalability problem. Anyway it seems to me that they affect any= possible solution to the multi-domain problem. About the connectivity matrices, it's my turn here for not having been suff= iciently clear. 1) Several flavors as you mention is not enough. I remember you the ex= ample of the affinities, but there are many others. They are not several, t= hey are billions. 2) Multiple intra node paths : once again, how many? My point is that,= to cover all the possible actual requests they will become far too many to= be stored, maintained and notified to MDSC when a change occurs. 3) Negotiation you are mentioning isn't a path computation request to = the PNC actually? It will happen all the times MDSC can't find a good path = for a domain, that is most of the times in the beginning; the MDSC will the= n request and store these new paths and it will have a higher probability e= ventually to find a suitable path already stored in its memory; but wait...= isn't that the incremental learning mechanism I have proposed few mails ag= o ? Cheers Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 11 November, 2016 3:43 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Franseco, I probably didn't make myself clear. The two main points that I was trying = to make are: 1) Dijkstra does not work on topologies with constrained/asymmetrical = nodes; 2) There will be much more calls to PNCs that you seem to believe Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is ca= lled and the response says that the path can leave N1 over links L3, L4, L5= and L6. Suppose later the algorithm reaches N1 again over link L2. Will yo= u have to call PNC1 again? Sure, because now it returns the valid outbound = links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it = was not accounted yet. Will you have to consider link L3 again? Sure, becau= se you have not considered L2-L3 inbound/outbound link combination yet: L1-= L3 internal (intra-node) path has different costs compared to L2-L3 interna= l path. The conclusions: a) the algorithm has to (re-)visit the same node multiple times; b) PNC will be called not only when the node first discovered (as you = implied), but every time the node is reached (which could be as many times = as the number of links it terminates); c) when the node is represented by an MDSC, the entire sub-tree of MD= SCs/PNCs will be called hierarchically every time the MDSC in question is c= alled, which may dramatically increase the number of calls to PNCs, the num= ber of paths to be grown, the overall time of the path computation, etc. ; d) The biggest scalability issue is not even the number of times PNCs/= MDSCs need to be called - the amount of paths that need to be grown. Note t= hat PNC needs to return not just most optimal paths to all outbound links i= t can reach, rather, all possible such paths, so that end-to-end path const= raints could be met. Other issues are (some of them you mentioned below): a) how the algorithm prefers a segment over domain1 over a segment ov= er domain 2 when the metrics are not normalized (apples and oranges)? b) how the algorithm deals with independent/overlapping SRLGs in the d= omains? c) what if domains have independent overlapping name space for node a= nd link IDs? In other words. what does a path returned by a PNC even mean to MDSC? Furthermore, I disagree with what you said about node's connectivity matric= es because: 1) Several flavors of matrices could be provided (e.g. one optimized = by smallest cost and another by shortest delay); 2) Multiple intra-node paths could be associated with the same inbound= -outbound link combination. Each such path will yield a separate vector of = costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal aff= inities) that could be compared against the MDSC's path computation constra= ints; 3) Most importantly, TE topology model allows for negotiation of exact= connectivity matrices MDSC needs from PNCs. Such negotiation could happen = at any time, including before or even in the middle of the path computation= if the MDSC thinks the ones it has already are not good or sufficient enou= gh. Cheers, Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Thursday, November 10, 2016 5:28 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521C97DF245E238041FE32296BB0AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

I know that “= pure” Dijkstra actually cannot be used (in most cases) and used it fo= r brevity. Constrained Dijkstra and derivative algorithms that are actually= used relax some of the rules of Dijkstra without becoming exponential for that.

Think to a very wor= st case wher you ask for all the possible paths to all domains and then use= this information for the MDSC path computation without any further request= .  

Assuming a network = with N domains having L inter-domain links in mean, we must ask N*L*(L-1)/2= paths around wich is still polinomial. Using Dijkstra in a single run, as = mentioned, requests should become N*L. This is what I expect as an upper bound to the number of calls to PNC.

This actually is th= e method suggested by the draft, which seems to me reasonable (asking only = when needed will save queries to the PNCs, but on the other side asking all= together in the beginning would allow to send requests in parallel to different domains, which saves time; space= for some further consideration here).

 

The other issues, e= ven if notable, were not discusses so far and I rather focus on the scalabi= lity problem. Anyway it seems to me that they affect any possible solution = to the multi-domain problem.

 

About the connectiv= ity matrices, it’s my turn here for not having been sufficiently clea= r.

1)      Several fla= vors as you mention is not enough. I remember you the example of the affini= ties, but there are many others. They are not several, they are billions.

2)      Multiple in= tra node paths : once again, how many? My point is that, to cover all the p= ossible actual requests they will become far too many to be stored, maintai= ned and notified to MDSC when a change occurs.

3)      Negotiation= you are mentioning isn’t a path computation request to the PNC actua= lly? It will happen all the times MDSC can’t find a good path for a d= omain, that is most of the times in the beginning; the MDSC will then request and store these new paths and it will have a hi= gher probability eventually to find a suitable path already stored in its m= emory; but wait… isn’t that the incremental learning mechanism = I have proposed few mails ago ?

 

Cheers

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 11 November, 2016 3:43 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Franseco,

 

I probably didn’= t make myself clear. The two main points that I was trying to make are:

1)&n= bsp;     Dijkstra does = not work on topologies with constrained/asymmetrical nodes;

2)&n= bsp;     There will be = much more calls to PNCs that you seem to believe

 

Imagine your algorithm= hit node N1 over link L1. PNC1 representing N1 is called and the response = says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later= the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns th= e valid outbound links to be L3, L4, L7 and L8. Will you have to consider l= ink L8? Sure, it was not accounted yet. Will you have to consider link L3 a= gain? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (in= tra-node) path has different costs compared to L2-L3 internal path.

The conclusions:<= /o:p>

a)&n= bsp;      the algorithm = has to (re-)visit the same node multiple times;

b)&n= bsp;     PNC will be ca= lled not only when the node first discovered (as you implied), but every ti= me the node is reached (which could be as many times as the number of links= it terminates);

c)&n= bsp;      when the node = is represented by an MDSC, the entire sub-tree of MDSCs/PNCs will be called= hierarchically every time the MDSC in question is called, which may dramat= ically increase the number of calls to PNCs, the number of paths to be grown, the overall time of the path com= putation, etc. ;

d)&n= bsp;     The biggest sc= alability issue is not even the number of times PNCs/MDSCs need to be calle= d – the amount of paths that need to be grown. Note that PNC needs to= return not just most optimal paths to all outbound links it can reach, rather, all possible such paths, so that e= nd-to-end path constraints could be met.

 

Other issues are (some= of them you mentioned below):

a)&n= bsp;      how the algori= thm prefers a segment over domain1 over a segment over domain 2 when the me= trics are not normalized (apples and oranges)?

b)&n= bsp;     how the algori= thm deals with independent/overlapping SRLGs in the domains?

c)&n= bsp;      what if domain= s have independent overlapping name space for node and link IDs?=

 

In other words. what d= oes a path returned by a PNC even mean to MDSC?

 

Furthermore, I disagre= e with what you said about node’s connectivity matrices because:=

1)&n= bsp;     Several flavor= s of  matrices could be provided (e.g. one optimized by smallest cost = and another by shortest delay);

2)&n= bsp;     Multiple intra= -node paths could be associated with the same inbound-outbound link combina= tion. Each such path will yield a separate vector of costs (summary TE cost= , delay, max. bandwidth, internal SRLGs, internal affinities) that could be compared against the MDSC’= s path computation constraints;

3)&n= bsp;     Most important= ly, TE topology model allows for negotiation of exact connectivity matrices MDSC needs from PNCs. Suc= h negotiation could happen at any time, including before or even in the mid= dle of the path computation if the MDSC thinks the ones it has already are = not good or sufficient enough.

 

 

Cheers,

Igor  

 

 

From: Francesco Lazzeri [mail= to:francesco.lazzeri@ericsson.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)     = ; Nodes representing domains must be = considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nod= es; so the “idea is to run Dijkstra on the MDSC abstract topology and= trigger a path computation to the relevant PNCs as soon as a node representing a domain is found” is questionab= le to begin with;

[FL] Of course ther= e are far more details than the ones included in my e-mail (long enough I t= hink). One of these is that, of course, for each path returned by the PNC a= lso the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is n= ot possible, will be used by MDSC during path computation;  metrics an= d delay shall be added to the currently computed ones, or if no path is fou= nd towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asym= metrical characteristics of the node-domains.

2)     = ; What happens if the algorithm finds= a node represented not by a PNC, but by another (lower hierarchy level) MD= SC?

[FL] Nothing differ= ent from a PNC I believe. As far as MDSC can compute paths as a PNC does an= d return them to the higher level MDSC, I can’t see any difference.

3)     = ; Assume you want to compute a single= path on a 20-domain topology originating in domain 1 and terminating in, s= ay, domain17. I don’t think you have much choice but:

a)  = ;     request PNC 1 to compute all possib= le (not just optional) paths from the path source to all domain 1 inter-dom= ain links;

b)  = ;    request all neighboring PNCs to = 220;grow” all the computed paths over inter-domain links into the dom= ains up to their respective outbound inter-domain links with potentially si= gnificant increase in the number of successful paths;

c)  = ;     repeat step b) until the paths reac= h the destination (17th) domain;

d)  = ;    grow the paths until they hit the p= ath computation destination;

e)  = ;    select the most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe &#= 8220;a lot”, but not exponentially growing with the number of domains= and inter-domain links. That was the point of my previous e-mail. Then we = can decide we have too many messages around, but I believe we first need some criteria to understand what “a lot̶= 1; or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantane= ous, but, in general, wrong as far as the connectivity matrices don’t= reflect the actual request parameters. Think about a request asking for a = path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 d= ifferent ways, specifying for each one any of the 2^32 affinity combination= s. Results of the path computation can be completely different depending on= the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should cre= ate L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine thi= s (that is multiply) with all the other constraints.

Maybe we could reno= unce to some constraints and limit the flexibility of path computation. In = my view this is the only way to make the connectivity matrix method a littl= e bit more appealing. But I still have dubts even with “essential” parameters like just bandwidth and= objective functions.

 

4)     = ; Computing diverse paths as two sing= le path computations with the topology transformation in between does not a= pply here: the paths may go through the same and/or different domains whose= internal topologies are not known (hence there is nothing to transform);

[FL] I agree that h= ere the problem is more complex than in a single domain. I didn’t do = tests yet on this, but I assume that a PNC should give also the possibility= to ask for a path in diversity from another path. So when the second path computation crosses the result of the first = one in the same domain, we should ask the relevant PNC for a path computati= on in diversity from the previous path (possibly using the XRO mechanism) i= n order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can g= uarantee that; if no diverse path is found, we should try and manage the of= fending domain as the offending links in bhandari algorithm, chasing them o= ut from the solution).

5)     = ; Computing a connectivity matrix on = a known (fully visible) topology is simple (as you said, could be done in a= single run) and also could be easily distributed between several path comp= uters to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be asso= ciated with one or more intra-node paths and provide to the MDSC various me= trics, like delay, cost, max. bandwidth, SRLGs)  It could be done in b= ackground when the path computers have nothing else to do (which is most of the time).

[FL] As said above,= the point here is that you don’t know the request parameters yet. An= d I do believe that in order to compute matrices suitable for the purpose, = either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity = of the problem to be solved.

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-     =      As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-     =      You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-     =      It’s built incrementally from= real requests and therefore with real parameters

-     =      It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-     =      For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-     =      For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-     =      For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

--_000_AM4PR07MB1521C97DF245E238041FE32296BB0AM4PR07MB1521eurp_-- From nobody Fri Nov 11 08:04:22 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789EB129424; Fri, 11 Nov 2016 08:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 xmL2zvKEW7cW; Fri, 11 Nov 2016 08:04:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA251297A5; Fri, 11 Nov 2016 08:04:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUZ83099; Fri, 11 Nov 2016 16:03:56 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml703-cah.china.huawei.com ([10.201.5.104]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 16:03:46 +0000 From: Italo Busi To: Igor Bryskin , Francesco Lazzeri , Fatai Zhang , "Dieter Beller" Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSPCqoykJJwiMPcEi+8pkQxHy26KDT4oHw Date: Fri, 11 Nov 2016 16:03:46 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B156ABC28@lhreml504-mbs> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.144.128] Content-Type: multipart/alternative; boundary="_000_91E3A1BD737FDF4FA14118387FF6766B156ABC28lhreml504mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5825EBED.011B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 488aa49910b38b0ac62a485a0ad8b155 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 16:04:12 -0000 --_000_91E3A1BD737FDF4FA14118387FF6766B156ABC28lhreml504mbs_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Please see some comments/questions in line below I think your last point is very important and deserves further consideratio= ns Italo From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: venerd=EC 11 novembre 2016 15:43 To: Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Hi Franseco, I probably didn't make myself clear. The two main points that I was trying = to make are: 1) Dijkstra does not work on topologies with constrained/asymmetrical = nodes; 2) There will be much more calls to PNCs that you seem to believe Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is ca= lled and the response says that the path can leave N1 over links L3, L4, L5= and L6. Suppose later the algorithm reaches N1 again over link L2. Will yo= u have to call PNC1 again? Sure, because now it returns the valid outbound = links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it = was not accounted yet. Will you have to consider link L3 again? Sure, becau= se you have not considered L2-L3 inbound/outbound link combination yet: L1-= L3 internal (intra-node) path has different costs compared to L2-L3 interna= l path. The conclusions: a) the algorithm has to (re-)visit the same node multiple times; b) PNC will be called not only when the node first discovered (as you = implied), but every time the node is reached (which could be as many times = as the number of links it terminates); c) when the node is represented by an MDSC, the entire sub-tree of MD= SCs/PNCs will be called hierarchically every time the MDSC in question is c= alled, which may dramatically increase the number of calls to PNCs, the num= ber of paths to be grown, the overall time of the path computation, etc. ; [Italo] I have the feeling that calculating how the number of path computat= ion requests increases with the number of underlying PNCs highly depends on= the logic implemented by the MDSC. A "smart" logic, as outlined in section= 3.3 of the draft, could dramatically reduce this number. d) The biggest scalability issue is not even the number of times PNCs/= MDSCs need to be called - the amount of paths that need to be grown. Note t= hat PNC needs to return not just most optimal paths to all outbound links i= t can reach, rather, all possible such paths, so that end-to-end path const= raints could be met. [Italo] I do not fully understand this point. IMHO, for a given end-to-end path setup, I think that the amount of informa= tion the MDSC needs to get from its underlying PNCs, calculate the optimal = multi-domain path, is exactly the same no matter whether it is get via path= computation requests or via TE Topology information. The main difference is that path computation allows the MDSC to request onl= y the information it needs when it needs. Instead, if only TE Topology is used, the PNCs should provide "any" possibl= e information the MDSC may ever need before it needs it, which is much more= than what is needed for a single end-to-end path setup. Other issues are (some of them you mentioned below): a) how the algorithm prefers a segment over domain1 over a segment ove= r domain 2 when the metrics are not normalized (apples and oranges)? b) how the algorithm deals with independent/overlapping SRLGs in the d= omains? c) what if domains have independent overlapping name space for node a= nd link IDs? [Italo] Again I am a bit confused. With path computation, the path returned by the PNC and its characteristics= (e.g., SRLG, node/link IDs) are associated with a given TE Topology expose= d by the PNC itself. The MDSC shall be capable to deal with these issues ot= herwise also the TE Topology information will not be consistent. Am I missing anything? In other words. what does a path returned by a PNC even mean to MDSC? Furthermore, I disagree with what you said about node's connectivity matric= es because: 1) Several flavors of matrices could be provided (e.g. one optimized = by smallest cost and another by shortest delay); [Italo] The requested path will have several path constraints (latency, ban= dwidth, ...): this is described in sections 3.1 and 3.2 of the draft. The s= et of possible path constraints combinations is quite huge. 2) Multiple intra-node paths could be associated with the same inbound= -outbound link combination. Each such path will yield a separate vector of = costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal aff= inities) that could be compared against the MDSC's path computation constra= ints; 3) Most importantly, TE topology model allows for negotiation of exact= connectivity matrices MDSC needs from PNCs. Such negotiation could happen = at any time, including before or even in the middle of the path computation= if the MDSC thinks the ones it has already are not good or sufficient enou= gh. [Italo] This seems an important and interesting point. Requesting a new node's connectivity matrix with the specific set of path c= onstraints when needed, looks to me like a form of requesting multiple path= computations between all the possible ingress/egress ports in "one shot". = I think this is a possible solution to the problem we are trying to addres= s so I think it deserves further considerations. Cheers, Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Thursday, November 10, 2016 5:28 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_91E3A1BD737FDF4FA14118387FF6766B156ABC28lhreml504mbs_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

Please see some commen= ts/questions in line below

 

I think your last poin= t is very important and deserves further considerations

 

Italo

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: venerd=EC 11 novembre 2016 15:43
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Hi Franseco,

 

I probably didn’= t make myself clear. The two main points that I was trying to make are:

1)&= nbsp;     Dijkstra does = not work on topologies with constrained/asymmetrical nodes;

2)&= nbsp;     There will be = much more calls to PNCs that you seem to believe

 

Imagine your algorithm= hit node N1 over link L1. PNC1 representing N1 is called and the response = says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later= the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns th= e valid outbound links to be L3, L4, L7 and L8. Will you have to consider l= ink L8? Sure, it was not accounted yet. Will you have to consider link L3 a= gain? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (in= tra-node) path has different costs compared to L2-L3 internal path.

The conclusions:<= /o:p>

a)&= nbsp;     the algorithm = has to (re-)visit the same node multiple times;

b)&= nbsp;     PNC will be ca= lled not only when the node first discovered (as you implied), but every ti= me the node is reached (which could be as many times as the number of links= it terminates);

c)&= nbsp;      when the node = is represented by an MDSC, the entire sub-tree of MDSCs/PNCs will be called= hierarchically every time the MDSC in question is called, which may dramat= ically increase the number of calls to PNCs, the number of paths to be grown, the overall time of the path com= putation, etc. ;

[Italo] I have the f= eeling that calculating how the number of path computation requests increas= es with the number of underlying PNCs highly depends on the logic implement= ed by the MDSC. A “smart” logic, as outlined in section 3.3 of the draft, could dramatically reduce this numbe= r.

 

d)&= nbsp;     The biggest sc= alability issue is not even the number of times PNCs/MDSCs need to be calle= d – the amount of paths that need to be grown. Note that PNC needs to= return not just most optimal paths to all outbound links it can reach, rather, all possible such paths, so that e= nd-to-end path constraints could be met.

[Italo] I do not ful= ly understand this point.

IMHO, for a given en= d-to-end path setup, I think that the amount of information the MDSC needs = to get from its underlying PNCs, calculate the optimal multi-domain path, i= s exactly the same no matter whether it is get via path computation requests or via TE Topology information.

The main difference = is that path computation allows the MDSC to request only the information it= needs when it needs.

Instead, if only TE = Topology is used, the PNCs should provide “any” possible inform= ation the MDSC may ever need before it needs it, which is much more than wh= at is needed for a single end-to-end path setup.

 

Other issues are (some= of them you mentioned below):

a)&= nbsp;     how the algori= thm prefers a segment over domain1 over a segment over domain 2 when the me= trics are not normalized (apples and oranges)?

b)&= nbsp;     how the algori= thm deals with independent/overlapping SRLGs in the domains?

c)&= nbsp;      what if domain= s have independent overlapping name space for node and link IDs?=

[Italo] Again I am a= bit confused.

With path computatio= n, the path returned by the PNC and its characteristics (e.g., SRLG, node/l= ink IDs) are associated with a given TE Topology exposed by the PNC itself.= The MDSC shall be capable to deal with these issues otherwise also the TE Topology information will not be consis= tent.

Am I missing anythin= g?

 

In other words. what d= oes a path returned by a PNC even mean to MDSC?

 

Furthermore, I disagre= e with what you said about node’s connectivity matrices because:=

1)&= nbsp;     Several flavor= s of  matrices could be provided (e.g. one optimized by smallest cost = and another by shortest delay);

[Italo] The requeste= d path will have several path constraints (latency, bandwidth, …): th= is is described in sections 3.1 and 3.2 of the draft. The set of possible p= ath constraints combinations is quite huge.

2)&= nbsp;     Multiple intra= -node paths could be associated with the same inbound-outbound link combina= tion. Each such path will yield a separate vector of costs (summary TE cost= , delay, max. bandwidth, internal SRLGs, internal affinities) that could be compared against the MDSC’= s path computation constraints;

3)&= nbsp;     Most important= ly, TE topology model allows for negotiation of exact connectivity matrices MDSC needs from PNCs. Suc= h negotiation could happen at any time, including before or even in the mid= dle of the path computation if the MDSC thinks the ones it has already are = not good or sufficient enough.

[Italo] This seems a= n important and interesting point.

Requesting a new nod= e’s connectivity matrix with the specific set of path constraints whe= n needed, looks to me like a form of requesting multiple path computations = between all the possible ingress/egress ports in “one shot”.  I think this is a possible solution to th= e problem we are trying to address so I think it deserves further considera= tions.

 

 

Cheers,

Igor  

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)  &nbs= p;   Nodes representing domains must be = considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nod= es; so the “idea is to run Dijkstra on the MDSC abstract topology and= trigger a path computation to the relevant PNCs as soon as a node representing a domain is found” is questionab= le to begin with;

[FL] Of course ther= e are far more details than the ones included in my e-mail (long enough I t= hink). One of these is that, of course, for each path returned by the PNC a= lso the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is n= ot possible, will be used by MDSC during path computation;  metrics an= d delay shall be added to the currently computed ones, or if no path is fou= nd towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asym= metrical characteristics of the node-domains.

2)  &nbs= p;   What happens if the algorithm finds= a node represented not by a PNC, but by another (lower hierarchy level) MD= SC?

[FL] Nothing differ= ent from a PNC I believe. As far as MDSC can compute paths as a PNC does an= d return them to the higher level MDSC, I can’t see any difference.

3)  &nbs= p;   Assume you want to compute a single= path on a 20-domain topology originating in domain 1 and terminating in, s= ay, domain17. I don’t think you have much choice but:

a)       request PNC 1 to compute all possib= le (not just optional) paths from the path source to all domain 1 inter-dom= ain links;

b)      request all neighboring PNCs to = 220;grow” all the computed paths over inter-domain links into the dom= ains up to their respective outbound inter-domain links with potentially si= gnificant increase in the number of successful paths;

c)       repeat step b) until the paths reac= h the destination (17th) domain;

d)      grow the paths until they hit the p= ath computation destination;

e)      select the most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe &#= 8220;a lot”, but not exponentially growing with the number of domains= and inter-domain links. That was the point of my previous e-mail. Then we = can decide we have too many messages around, but I believe we first need some criteria to understand what “a lot̶= 1; or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantane= ous, but, in general, wrong as far as the connectivity matrices don’t= reflect the actual request parameters. Think about a request asking for a = path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 d= ifferent ways, specifying for each one any of the 2^32 affinity combination= s. Results of the path computation can be completely different depending on= the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should cre= ate L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine thi= s (that is multiply) with all the other constraints.

Maybe we could reno= unce to some constraints and limit the flexibility of path computation. In = my view this is the only way to make the connectivity matrix method a littl= e bit more appealing. But I still have dubts even with “essential” parameters like just bandwidth and= objective functions.

 

4)  &nbs= p;   Computing diverse paths as two sing= le path computations with the topology transformation in between does not a= pply here: the paths may go through the same and/or different domains whose= internal topologies are not known (hence there is nothing to transform);

[FL] I agree that h= ere the problem is more complex than in a single domain. I didn’t do = tests yet on this, but I assume that a PNC should give also the possibility= to ask for a path in diversity from another path. So when the second path computation crosses the result of the first = one in the same domain, we should ask the relevant PNC for a path computati= on in diversity from the previous path (possibly using the XRO mechanism) i= n order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can g= uarantee that; if no diverse path is found, we should try and manage the of= fending domain as the offending links in bhandari algorithm, chasing them o= ut from the solution).

5)  &nbs= p;   Computing a connectivity matrix on = a known (fully visible) topology is simple (as you said, could be done in a= single run) and also could be easily distributed between several path comp= uters to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be asso= ciated with one or more intra-node paths and provide to the MDSC various me= trics, like delay, cost, max. bandwidth, SRLGs)  It could be done in b= ackground when the path computers have nothing else to do (which is most of the time).

[FL] As said above,= the point here is that you don’t know the request parameters yet. An= d I do believe that in order to compute matrices suitable for the purpose, = either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity = of the problem to be solved.

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-   = ;       As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-   = ;       You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-   = ;       It’s built incrementally from= real requests and therefore with real parameters

-   = ;       It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   = ;       For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology inf= ormation, it is likely to contain proprietary information and hence useless= for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   = ;       For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   = ;       For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary compu= tations are done already by PNCs when exposing and updating the abstract TE= topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be = linked in a hierarchy. This means that for a top level MDSC e2e path comput= ation, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)  &nbs= p;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: R= 20; No, I have nothing for you” ?  What if the path was relied u= pon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)  &nbs= p;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link AR= 17;B’ points to the underlay (provider) TE topology where the path is= computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to t= he path computation request and doesn’t advertise any new TE link to = the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is supp= orted not by a provisioned in a server layer TE tunnel (connection), rather= , by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)  &nbs= p;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: R= 20; No, I have nothing for you” ?  What if the path was relied u= pon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)  &nbs= p;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link AR= 17;B’ points to the underlay (provider) TE topology where the path is= computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

--_000_91E3A1BD737FDF4FA14118387FF6766B156ABC28lhreml504mbs_-- From nobody Fri Nov 11 10:56:15 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB85127A91; Fri, 11 Nov 2016 10:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 T6lbTJhbnVVN; Fri, 11 Nov 2016 10:55:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607B8129C60; Fri, 11 Nov 2016 10:55:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAF03545; Fri, 11 Nov 2016 18:55:52 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 18:55:51 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 10:55:42 -0800 From: Igor Bryskin To: Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAWDYAgAB43DD//9f5gP//iVnA//5oJoD//UMEcA== Date: Fri, 11 Nov 2016 18:55:41 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0FF7B@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0FF7Bdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58261439.0161, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bee9e4788904c3a2f3d547c3eaf515ee Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 18:56:06 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FF7Bdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fransesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Friday, November 11, 2016 10:43 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I know that "pure" Dijkstra actually cannot be used (in most cases) and use= d it for brevity. Constrained Dijkstra and derivative algorithms that are a= ctually used relax some of the rules of Dijkstra without becoming exponenti= al for that. Think to a very worst case wher you ask for all the possible paths to all d= omains and then use this information for the MDSC path computation without = any further request. Assuming a network with N domains having L inter-domain links in mean, we m= ust ask N*L*(L-1)/2 paths around wich is still polinomial. Using Dijkstra i= n a single run, as mentioned, requests should become N*L. This is what I ex= pect as an upper bound to the number of calls to PNC. IB>> You assume you need a single mesh of intra-domain paths interconnectin= g L links terminated by a node/domain. This means one path per Lx/Ly link c= ombination. Assume that more than one path could be found connecting Lx to = Ly: one is most optimal (shortest), another longer but with a better delay = metric, other paths are worse but with different SRLGs, etc. MDSC needs to = know about all of them, because the e2e path made of shortest intra-domain = paths may fail e2e (e.g. max. delay) constraint or path diversity constrain= . So you need more paths to deal with than you assume. This actually is the method suggested by the draft, which seems to me reaso= nable (asking only when needed will save queries to the PNCs, but on the ot= her side asking all together in the beginning would allow to send requests = in parallel to different domains, which saves time; space for some further = consideration here). The other issues, even if notable, were not discusses so far and I rather f= ocus on the scalability problem. Anyway it seems to me that they affect any= possible solution to the multi-domain problem. About the connectivity matrices, it's my turn here for not having been suff= iciently clear. 1) Several flavors as you mention is not enough. I remember you the ex= ample of the affinities, but there are many others. They are not several, t= hey are billions. IB>> Sorry, this does not make any sense to me. Why would MDSC request affi= nity constraint from a PNC when: a) interpretation of affinities is different from domain to domain and= unknown to MDSC; b) affinities are attributes of internal TE links MDSC does not know ab= out. According to TE tunnel model, there is only so much client can specify when= requesting a service, less so that could be used as path computation reque= sts: layer, bandwidth, inclusions, exclusions, diversity, etc. 2) Multiple intra node paths : once again, how many? My point is that,= to cover all the possible actual requests they will become far too many to= be stored, maintained and notified to MDSC when a change occurs. IB>> Why? Let's say MDSC serves OTN layer 20 domain network. Assume that ea= ch domain exposes two connectivity matrices: one optimized by shortest cost= , another - by shortest delay. Assume that each matrix has an entry for eac= h Lx/Ly/ODUtype and is associated with 4 most optimal single intra-node pat= hs and 4 SRLG-diverse path pairs. Each path yields a vector of costs, inclu= ding summary TE metric, delay, SRLGs, etc. Give me an example in which this= would not be sufficient for MDSC? 3) Negotiation you are mentioning isn't a path computation request to = the PNC actually? It will happen all the times MDSC can't find a good path = for a domain, that is most of the times in the beginning; the MDSC will the= n request and store these new paths and it will have a higher probability e= ventually to find a suitable path already stored in its memory; but wait...= isn't that the incremental learning mechanism I have proposed few mails ag= o ? IB>> You are right, such negotiation is eventually a compound path computat= ion request, BUT: a) there is a guarantee that in the worst case scenario there will be = no more than 1 such request per computation per PNC/MDSC; b) All such requests could be requested simultaneously and independentl= y from all/some PNCs; c) There is a guarantee that said requests will not trigger the sub-tr= ee hierarchical avalanche of requests to inferior MDSCs/PNCs; d) Most importantly, these are stateful computations (here we go, we ar= e finishing where we started) - once requested they do not need to be (re-)= requested again. Only matrices that are missing at the moment have to be re= uested. Once provided they will stay and be automatically kept up-to-date u= ntil MDSC explicitly asks to remove them. There is a standard model and int= erface already for such negotiation Cheers Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 11 November, 2016 3:43 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Franseco, I probably didn't make myself clear. The two main points that I was trying = to make are: 1) Dijkstra does not work on topologies with constrained/asymmetrical = nodes; 2) There will be much more calls to PNCs that you seem to believe Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is ca= lled and the response says that the path can leave N1 over links L3, L4, L5= and L6. Suppose later the algorithm reaches N1 again over link L2. Will yo= u have to call PNC1 again? Sure, because now it returns the valid outbound = links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it = was not accounted yet. Will you have to consider link L3 again? Sure, becau= se you have not considered L2-L3 inbound/outbound link combination yet: L1-= L3 internal (intra-node) path has different costs compared to L2-L3 interna= l path. The conclusions: a) the algorithm has to (re-)visit the same node multiple times; b) PNC will be called not only when the node first discovered (as you = implied), but every time the node is reached (which could be as many times = as the number of links it terminates); c) when the node is represented by an MDSC, the entire sub-tree of MD= SCs/PNCs will be called hierarchically every time the MDSC in question is c= alled, which may dramatically increase the number of calls to PNCs, the num= ber of paths to be grown, the overall time of the path computation, etc. ; d) The biggest scalability issue is not even the number of times PNCs/= MDSCs need to be called - the amount of paths that need to be grown. Note t= hat PNC needs to return not just most optimal paths to all outbound links i= t can reach, rather, all possible such paths, so that end-to-end path const= raints could be met. Other issues are (some of them you mentioned below): a) how the algorithm prefers a segment over domain1 over a segment ov= er domain 2 when the metrics are not normalized (apples and oranges)? b) how the algorithm deals with independent/overlapping SRLGs in the d= omains? c) what if domains have independent overlapping name space for node a= nd link IDs? In other words. what does a path returned by a PNC even mean to MDSC? Furthermore, I disagree with what you said about node's connectivity matric= es because: 1) Several flavors of matrices could be provided (e.g. one optimized = by smallest cost and another by shortest delay); 2) Multiple intra-node paths could be associated with the same inbound= -outbound link combination. Each such path will yield a separate vector of = costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal aff= inities) that could be compared against the MDSC's path computation constra= ints; 3) Most importantly, TE topology model allows for negotiation of exact= connectivity matrices MDSC needs from PNCs. Such negotiation could happen = at any time, including before or even in the middle of the path computation= if the MDSC thinks the ones it has already are not good or sufficient enou= gh. Cheers, Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Thursday, November 10, 2016 5:28 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0FF7Bdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fransesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Friday, November 11, 2016 10:43 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Igor,

I know that “= pure” Dijkstra actually cannot be used (in most cases) and used it fo= r brevity. Constrained Dijkstra and derivative algorithms that are actually= used relax some of the rules of Dijkstra without becoming exponential for that.

Think to a very wor= st case wher you ask for all the possible paths to all domains and then use= this information for the MDSC path computation without any further request= .  

Assuming a network = with N domains having L inter-domain links in mean, we must ask N*L*(L-1)/2= paths around wich is still polinomial. Using Dijkstra in a single run, as = mentioned, requests should become N*L. This is what I expect as an upper bound to the number of calls to PNC.

 

IB>> You assume = you need a single mesh of intra-domain paths interconnecting L links termin= ated by a node/domain. This means one path per Lx/Ly link combination. Assu= me that more than one path could be found connecting Lx to Ly: one is most optimal (shortest), another longer but wi= th a better delay metric, other paths are worse but with different SRLGs, e= tc. MDSC needs to know about all of them, because the e2e path made of shor= test intra-domain paths may fail e2e (e.g. max. delay) constraint or path diversity constrain. So you need = more paths to deal with than you assume.

 

 

 

This actually is th= e method suggested by the draft, which seems to me reasonable (asking only = when needed will save queries to the PNCs, but on the other side asking all= together in the beginning would allow to send requests in parallel to different domains, which saves time; space= for some further consideration here).

 

The other issues, e= ven if notable, were not discusses so far and I rather focus on the scalabi= lity problem. Anyway it seems to me that they affect any possible solution = to the multi-domain problem.

 

About the connectiv= ity matrices, it’s my turn here for not having been sufficiently clea= r.

1)      Several fla= vors as you mention is not enough. I remember you the example of the affini= ties, but there are many others. They are not several, they are billions.

 

IB>> Sorry, this= does not make any sense to me. Why would MDSC request affinity constraint = from a PNC when:

a)&n= bsp;     interpretation= of affinities is different from domain to domain and unknown to MDSC;=

b)&n= bsp;    affinities are= attributes of internal TE links MDSC does not know about.

According to TE tunnel= model, there is only so much client can specify when requesting a service,= less so that could be used as path computation requests: layer, bandwidth,= inclusions, exclusions, diversity, etc.

 

 

 

2)      Multiple in= tra node paths : once again, how many? My point is that, to cover all the p= ossible actual requests they will become far too many to be stored, maintai= ned and notified to MDSC when a change occurs.

IB>> Why? Let= 217;s say MDSC serves OTN layer 20 domain network. Assume that each domain = exposes two connectivity matrices: one optimized by shortest cost, another = – by shortest delay. Assume that each matrix has an entry for each Lx/Ly/ODUtype and is associated with 4 most optimal sing= le intra-node paths and 4 SRLG-diverse path pairs. Each path yields a vecto= r of costs, including summary TE metric, delay, SRLGs, etc. Give me an exam= ple in which this would not be sufficient for MDSC?

 

3)      Negotiation= you are mentioning isn’t a path computation request to the PNC actua= lly? It will happen all the times MDSC can’t find a good path for a d= omain, that is most of the times in the beginning; the MDSC will then request and store these new paths and it will have a hi= gher probability eventually to find a suitable path already stored in its m= emory; but wait… isn’t that the incremental learning mechanism = I have proposed few mails ago ?

 

IB>> You are rig= ht, such negotiation is eventually a compound path computation request, BUT= :

 

a)&n= bsp;     there is a gua= rantee that in the worst case scenario there will be no more than 1 such re= quest per computation per PNC/MDSC;

b)&n= bsp;    All such reque= sts could be requested simultaneously and independently from all/some PNCs;=

c)&n= bsp;     There is a gua= rantee that said requests will not trigger the sub-tree hierarchical avalan= che of requests to inferior MDSCs/PNCs;

d)     Most im= portantly, these are stateful computations (here we go, we are finishing wh= ere we started) – once requested they do not need to be (re-)requeste= d again. Only matrices that are missing at the moment have to be reuested. Once provided they will stay and be aut= omatically kept up-to-date until MDSC explicitly asks to remove them. There= is a standard model and interface already for such negotiation<= /span>

 

Cheers

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 11 November, 2016 3:43 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Franseco,

 

I probably didn’= t make myself clear. The two main points that I was trying to make are:

1)    = ;  Dijkstra does not work on topologies w= ith constrained/asymmetrical nodes;

2)    = ;  There will be much more calls to PNCs = that you seem to believe

 

Imagine your algorithm= hit node N1 over link L1. PNC1 representing N1 is called and the response = says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later= the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns th= e valid outbound links to be L3, L4, L7 and L8. Will you have to consider l= ink L8? Sure, it was not accounted yet. Will you have to consider link L3 a= gain? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (in= tra-node) path has different costs compared to L2-L3 internal path.

The conclusions:<= /o:p>

a)    = ;   the algorithm has to (re-)visit the sa= me node multiple times;

b)    = ;  PNC will be called not only when the n= ode first discovered (as you implied), but every time the node is reached (= which could be as many times as the number of links it terminates);

c)    = ;   when the node is represented by an MDS= C, the entire sub-tree of MDSCs/PNCs will be called hierarchically every ti= me the MDSC in question is called, which may dramatically increase the numb= er of calls to PNCs, the number of paths to be grown, the overall time of the path computation, etc. ;

d)    = ;  The biggest scalability issue is not e= ven the number of times PNCs/MDSCs need to be called – the amount of = paths that need to be grown. Note that PNC needs to return not just most op= timal paths to all outbound links it can reach, rather, all possible such paths, so that end-to-end path constra= ints could be met.

 

Other issues are (some= of them you mentioned below):

a)    = ;   how the algorithm prefers a segment ov= er domain1 over a segment over domain 2 when the metrics are not normalized= (apples and oranges)?

b)    = ;  how the algorithm deals with independe= nt/overlapping SRLGs in the domains?

c)    = ;   what if domains have independent overl= apping name space for node and link IDs?

 

In other words. what d= oes a path returned by a PNC even mean to MDSC?

 

Furthermore, I disagre= e with what you said about node’s connectivity matrices because:=

1)    = ;  Several flavors of  matrices coul= d be provided (e.g. one optimized by smallest cost and another by shortest = delay);

2)    = ;  Multiple intra-node paths could be ass= ociated with the same inbound-outbound link combination. Each such path wil= l yield a separate vector of costs (summary TE cost, delay, max. bandwidth,= internal SRLGs, internal affinities) that could be compared against the MDSC’s path computation constrain= ts;

3)    = ;  Most importantly, TE topology model al= lows for negotiation of exact connectivity matrices MDSC needs from PNCs. Such n= egotiation could happen at any time, including before or even in the middle= of the path computation if the MDSC thinks the ones it has already are not= good or sufficient enough.

 

 

Cheers,

Igor  

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)   = ;   Nodes representing domains must be = considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nod= es; so the “idea is to run Dijkstra on the MDSC abstract topology and= trigger a path computation to the relevant PNCs as soon as a node representing a domain is found” is questionab= le to begin with;

[FL] Of course ther= e are far more details than the ones included in my e-mail (long enough I t= hink). One of these is that, of course, for each path returned by the PNC a= lso the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is n= ot possible, will be used by MDSC during path computation;  metrics an= d delay shall be added to the currently computed ones, or if no path is fou= nd towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asym= metrical characteristics of the node-domains.

2)   = ;   What happens if the algorithm finds= a node represented not by a PNC, but by another (lower hierarchy level) MD= SC?

[FL] Nothing differ= ent from a PNC I believe. As far as MDSC can compute paths as a PNC does an= d return them to the higher level MDSC, I can’t see any difference.

3)   = ;   Assume you want to compute a single= path on a 20-domain topology originating in domain 1 and terminating in, s= ay, domain17. I don’t think you have much choice but:

a)       request PNC 1 to compute all possib= le (not just optional) paths from the path source to all domain 1 inter-dom= ain links;

b)      request all neighboring PNCs to = 220;grow” all the computed paths over inter-domain links into the dom= ains up to their respective outbound inter-domain links with potentially si= gnificant increase in the number of successful paths;

c)       repeat step b) until the paths reac= h the destination (17th) domain;

d)      grow the paths until they hit the p= ath computation destination;

e)      select the most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe &#= 8220;a lot”, but not exponentially growing with the number of domains= and inter-domain links. That was the point of my previous e-mail. Then we = can decide we have too many messages around, but I believe we first need some criteria to understand what “a lot̶= 1; or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantane= ous, but, in general, wrong as far as the connectivity matrices don’t= reflect the actual request parameters. Think about a request asking for a = path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 d= ifferent ways, specifying for each one any of the 2^32 affinity combination= s. Results of the path computation can be completely different depending on= the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should cre= ate L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine thi= s (that is multiply) with all the other constraints.

Maybe we could reno= unce to some constraints and limit the flexibility of path computation. In = my view this is the only way to make the connectivity matrix method a littl= e bit more appealing. But I still have dubts even with “essential” parameters like just bandwidth and= objective functions.

 

4)   = ;   Computing diverse paths as two sing= le path computations with the topology transformation in between does not a= pply here: the paths may go through the same and/or different domains whose= internal topologies are not known (hence there is nothing to transform);

[FL] I agree that h= ere the problem is more complex than in a single domain. I didn’t do = tests yet on this, but I assume that a PNC should give also the possibility= to ask for a path in diversity from another path. So when the second path computation crosses the result of the first = one in the same domain, we should ask the relevant PNC for a path computati= on in diversity from the previous path (possibly using the XRO mechanism) i= n order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can g= uarantee that; if no diverse path is found, we should try and manage the of= fending domain as the offending links in bhandari algorithm, chasing them o= ut from the solution).

5)   = ;   Computing a connectivity matrix on = a known (fully visible) topology is simple (as you said, could be done in a= single run) and also could be easily distributed between several path comp= uters to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be asso= ciated with one or more intra-node paths and provide to the MDSC various me= trics, like delay, cost, max. bandwidth, SRLGs)  It could be done in b= ackground when the path computers have nothing else to do (which is most of the time).

[FL] As said above,= the point here is that you don’t know the request parameters yet. An= d I do believe that in order to compute matrices suitable for the purpose, = either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity = of the problem to be solved.

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-   =        As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-   =        You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-   =        It’s built incrementally from= real requests and therefore with real parameters

-   =        It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0FF7Bdfweml501mbx_-- From nobody Sat Nov 12 01:57:03 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361E8128B38; Sat, 12 Nov 2016 01:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 DVZdAGjg45e9; Sat, 12 Nov 2016 01:56:47 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0566126D74; Sat, 12 Nov 2016 01:56:45 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-c5-5826e75ab36e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 4C.8C.31910.A57E6285; Sat, 12 Nov 2016 10:56:42 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 12 Nov 2016 10:56:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LW1ZODj43ozb/xdHTGRsDUJJtDokxirD/CIFdTWbNF0=; b=Pbc7MVl7r2ZW6oEsvuxUUReNvSBaq8adKxRXddS6xgZUBXQ67qlwdsPiDRWyXq9XlH+KnmZKdVXnG78D1Cooe7ZA73KkDq7bSeU3VpRrLY3kYJxsqyCJsJhEwwV0eCe+wwwrSgQH908cCJh4d57CmaDUAEVeu1EQEc94YKmEmxo= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1522.eurprd07.prod.outlook.com (10.165.248.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sat, 12 Nov 2016 09:56:05 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Sat, 12 Nov 2016 09:56:05 +0000 From: Francesco Lazzeri To: Igor Bryskin , Fatai Zhang , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgIAAI1UAgADWmeCAAIRPgIAABhYQgAA29wCAABvbsIABH86AgAAJT3CAAD1JgIAA7a3g Date: Sat, 12 Nov 2016 09:56:04 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FF7B@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0FF7B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [79.44.121.42] x-microsoft-exchange-diagnostics: 1; AM4PR07MB1522; 7:lv5rLMgQwGnovaWsxQJtGCiI+9b9URM3GcBrGlVaeAzM8S/h49hppk4WOBsEv07Y6/nJy+FYvj6GOOVdsPtMCuK76C9OLa1PhXSBSiQtJhkkzzs/R84hWPFOerjK8f0tkyViAjek5tYeb2uURojMqu6VK+/HGgtKUPwASxAG7e6MTp/dAsBvmae8nGzaH7WQG4igARqAgrMQimMj7JDfmHR5lcdmIb4kxlqp5OFfWYkS0lXNNSlzX/vkC8iitN2Jl2EMQlyjRrZstc9XzZf1dZ5f5QxpFmzDAvLf9zMA+OZA/NcEOegyUAIqhNhgXXQ2dvbV4LybKzG5NGaxiEPqsohh9Ri11ppcMPEGoWrojkw= x-ms-office365-filtering-correlation-id: bc5155d2-31e5-40d1-8e15-08d40ae21e23 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR07MB1522; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060305)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061300); SRVR:AM4PR07MB1522; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1522; x-forefront-prvs: 01244308DF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(53754006)(377454003)(24454002)(189002)(790700001)(6116002)(102836003)(3846002)(586003)(76576001)(229853002)(2900100001)(7696004)(5660300001)(92566002)(68736007)(2950100002)(5890100001)(101416001)(50986999)(76176999)(54356999)(86362001)(77096005)(4326007)(9686002)(97736004)(189998001)(5001770100001)(87936001)(3660700001)(105586002)(230783001)(106356001)(122556002)(106116001)(33656002)(2906002)(561944003)(7736002)(3280700002)(74316002)(81156014)(8936002)(8676002)(66066001)(81166006)(3900700001)(220493001)(7906003)(7846002)(559001)(579004)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1522; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521E9A89B3B636CED6E40AB96BA0AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2016 09:56:04.8263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1522 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0gUURTHuTszu7PmxnVd86QGsqBg4SOJmKTCoNICyT4ppuWkgys+29VM P4RZKWpWaIqraRrrMzVTSyUV3R5oxi7aSxfN1E2JikwhH6W142zgt985////3nMPlybkw5QT HZuYwqkT2Xil2IbUhnYe8Aybdw/16TL5Mea7YyTTopsgmfWhvczqyG7GVNNAMVlTYxLm+koX ydy8aqT86cBrz79TgTrdqihw0jQqCibCbA5Gc/GxFzm19+FIG9Xrl1HJDydsL2lNK5JM1F28 LQ9JacD7YLx+VJKHbGg5bkFQNLxMCcUgguKBwU2FxAUEmOdLJXxEjktFoO2/ILDFVd6WwbMY M7D2vJzkWYEz4POyWcyHCfwBQWX3hCVM0/Y4HAzZdoInAoo/tZO8R4HXEBQ8fUDxAondYKyk W8yzzOKfqn5MCiONIjCYxkW8IMXHoP7ZGuIZ4R2w/Kpps09gRzCZ74mEx2HQ9RgJgR3gy+wG JfhZeKQrs3pcoaPhnYi/AHAVAY1LN6xCECy960f81Dxra63tOOjL7hML/iYET3rfWosBBDN/ e0gh4AJFvdZDFymorGu37o6Duubrm1PbYyeYfJuLbiOPsi2Dl1niBE6CjxVnyjYXYAdDWjMp WLxgrPiOWOA9UFv9lRDYE0o39OTWfhWSNCIHDac5nxDj6+vFqWOjNJqkRK9ELqUNWb7YQMdv ny70Zf6IHmEaKW1lPg7uoXKKvahJT9AjoAmlQrZ9ztKSRbPpGZw66Zw6NZ7T6JEzTSodZfsb pkLkOIZN4eI4LplT/1dFtNQpE7n2p+cHq1yT5Z/vz33onC485R0cyWVV/Chvf2Nodm4uqT1U aMi7fHLx0Izf6f7yoEj/gBxJ6lz18Pui44UBE9MhO401aS538h+2/vy2y2Nhl04VEOF29uhI icIla7JF+gfPsuOpRcamtF/svtYXuVduvdFvtK+HKyWzJ7DnQo7ntJLUqNi9uwm1hv0HvyOk S14DAAA= Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 09:56:57 -0000 --_000_AM4PR07MB1521E9A89B3B636CED6E40AB96BA0AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, See in-line-in-line. I promise you I'll not anwser any longer. I understand= from this discussion we are in front of a dual solution, and as always hap= pens, dual solutions have both benefits and drawbacks. I believe it's not beneficial discussing too long in abstract about such st= uff, even though I recognise that this exchange of opinions with an expert = like you is really exciting. I am running simulations about this stuff. Maybe eventually I'll come back = with some numerical results. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 11 November, 2016 7:56 PM To: Francesco Lazzeri ; Fatai Zhang ; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; pce@ietf.org; TEAS WG (teas@ietf.= org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Fransesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Friday, November 11, 2016 10:43 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I know that "pure" Dijkstra actually cannot be used (in most cases) and use= d it for brevity. Constrained Dijkstra and derivative algorithms that are a= ctually used relax some of the rules of Dijkstra without becoming exponenti= al for that. Think to a very worst case wher you ask for all the possible paths to all d= omains and then use this information for the MDSC path computation without = any further request. Assuming a network with N domains having L inter-domain links in mean, we m= ust ask N*L*(L-1)/2 paths around wich is still polinomial. Using Dijkstra i= n a single run, as mentioned, requests should become N*L. This is what I ex= pect as an upper bound to the number of calls to PNC. IB>> You assume you need a single mesh of intra-domain paths interconnectin= g L links terminated by a node/domain. This means one path per Lx/Ly link c= ombination. Assume that more than one path could be found connecting Lx to = Ly: one is most optimal (shortest), another longer but with a better delay = metric, other paths are worse but with different SRLGs, etc. MDSC needs to = know about all of them, because the e2e path made of shortest intra-domain = paths may fail e2e (e.g. max. delay) constraint or path diversity constrain= . So you need more paths to deal with than you assume. [FL] You are right, of course. Contraint management is a can of worms. But = this not only happens for multi-domain but also in single domain. Here, onc= e again, you need to relax the Dijkstra blocking condition and propagate no= t only the first relaxation step arriving at a certain node (the optimim on= e) but also all the eventual ones having some better constraints. This appl= ies to all cumulative constraints, and actually also applies to your propos= al of computing paths in PNC and exporting/notifying all of them to MDSC in= advance, doesn't it ? About SRLGs, I don't agree. If you put an SRLG insid= e a XRO in order for it to be excluded from the path, I can't see how this = contribute to growth of the number of relaxation steps. Exclude resorce is = not a cumulative constraint but just a local constraint to be checked again= st any single link the process is traversing: if the link matches the const= raint, no propagation. This applies also to the in-domain path computation = and it just discards solution: you can't have a better solution violating t= he constraint (please note : here I assume mandatory constraints in order = not to write a book on the matter). This actually is the method suggested by the draft, which seems to me reaso= nable (asking only when needed will save queries to the PNCs, but on the ot= her side asking all together in the beginning would allow to send requests = in parallel to different domains, which saves time; space for some further = consideration here). The other issues, even if notable, were not discusses so far and I rather f= ocus on the scalability problem. Anyway it seems to me that they affect any= possible solution to the multi-domain problem. About the connectivity matrices, it's my turn here for not having been suff= iciently clear. 1) Several flavors as you mention is not enough. I remember you the ex= ample of the affinities, but there are many others. They are not several, t= hey are billions. IB>> Sorry, this does not make any sense to me. Why would MDSC request affi= nity constraint from a PNC when: a) interpretation of affinities is different from domain to domain an= d unknown to MDSC; [FL] I believe there are cases where SRLGs, affinities and other constraint= s and metrics are consistent and consistently known across domains and MDSC= : If a network for example is onwed by the same carrier and domains are jus= t different PNCs serving different supplier or different technology domains= , I would say this problem doesn't exist. Also in other cases different pro= viders could make agreements in order to prevent this problem. b) affinities are attributes of internal TE links MDSC does not know a= bout. According to TE tunnel model, there is only so much client can specify when= requesting a service, less so that could be used as path computation reque= sts: layer, bandwidth, inclusions, exclusions, diversity, etc. [FL] Why ? I can't see any reason to cut information, apart simplification = (as I have already said in my past e-mails : but need a list of constraint = to be removed multi-domain path computation). If you don't like affinities,= you must accept delay though : delay is a very "popular" constraint, it's = measured hopefully in a consistent way so MDSC and PNC's should all agree o= n its meaning. So, how many values should we compute in advance (and then m= aintain and notify) on PNCs for delay constraint ? Or for any other bound o= n IGP or TE metric or number of hops ? Or any combination of them ? Once ag= ain, millions ? billions ? I don't know, but a lot surely. Too many, In my = opinion. 2) Multiple intra node paths : once again, how many? My point is that,= to cover all the possible actual requests they will become far too many to= be stored, maintained and notified to MDSC when a change occurs. IB>> Why? Let's say MDSC serves OTN layer 20 domain network. Assume that ea= ch domain exposes two connectivity matrices: one optimized by shortest cost= , another - by shortest delay. Assume that each matrix has an entry for eac= h Lx/Ly/ODUtype and is associated with 4 most optimal single intra-node pat= hs and 4 SRLG-diverse path pairs. Each path yields a vector of costs, inclu= ding summary TE metric, delay, SRLGs, etc. Give me an example in which this= would not be sufficient for MDSC? [FL] Here it is : you want to compute a path with a certain bound of delay = and another bound on IGP metric, while optimizing against TE metric. Please= , don't tell me it doesn't make sense. It could well happen that the path i= n the matrix optimized for delay has a too high IGP metric and the bound on= IGP can't eventually be respected. The matrix optimized for IGP has a dela= y too high and eventually the relevant bound can't be respected as well. In= stead, it exists a path with "intermediate" values of delay and IGP, which = would make both the bounds in the end. But it's not captured in your matric= es and you loose the only suitable solution. Think also to the bandwidth parameter, and in general all parameters with a= ttached a value. In principle you should compute and export all their possi= ble combinations, or at least all the combinations that produce different p= aths, each path having attached the relevant combinations of request parame= ters. Producing matrices against single parameters doesn't work. 3) Negotiation you are mentioning isn't a path computation request to = the PNC actually? It will happen all the times MDSC can't find a good path = for a domain, that is most of the times in the beginning; the MDSC will the= n request and store these new paths and it will have a higher probability e= ventually to find a suitable path already stored in its memory; but wait...= isn't that the incremental learning mechanism I have proposed few mails ag= o ? IB>> You are right, such negotiation is eventually a compound path computat= ion request, BUT: a) there is a guarantee that in the worst case scenario there will be= no more than 1 such request per computation per PNC/MDSC; b) All such requests could be requested simultaneously and independent= ly from all/some PNCs; c) There is a guarantee that said requests will not trigger the sub-t= ree hierarchical avalanche of requests to inferior MDSCs/PNCs; d) Most importantly, these are stateful computations (here we go, we a= re finishing where we started) - once requested they do not need to be (re-= )requested again. Only matrices that are missing at the moment have to be r= euested. Once provided they will stay and be automatically kept up-to-date = until MDSC explicitly asks to remove them. There is a standard model and in= terface already for such negotiation [FL] The difference here is where the statefulness happens; in my proposal = on MDSC. MDSC, while performing path computation, collects and store the re= sults from PNCs in its store and reuse them eventually. No need for notifications or maintaining states in PNCs. Just remove a path= and substitute it with a better one when it's no longer suitable for the p= urpose. Cheers Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 11 November, 2016 3:43 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Franseco, I probably didn't make myself clear. The two main points that I was trying = to make are: 1) Dijkstra does not work on topologies with constrained/asymmetrical = nodes; 2) There will be much more calls to PNCs that you seem to believe Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is ca= lled and the response says that the path can leave N1 over links L3, L4, L5= and L6. Suppose later the algorithm reaches N1 again over link L2. Will yo= u have to call PNC1 again? Sure, because now it returns the valid outbound = links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it = was not accounted yet. Will you have to consider link L3 again? Sure, becau= se you have not considered L2-L3 inbound/outbound link combination yet: L1-= L3 internal (intra-node) path has different costs compared to L2-L3 interna= l path. The conclusions: a) the algorithm has to (re-)visit the same node multiple times; b) PNC will be called not only when the node first discovered (as you = implied), but every time the node is reached (which could be as many times = as the number of links it terminates); c) when the node is represented by an MDSC, the entire sub-tree of MD= SCs/PNCs will be called hierarchically every time the MDSC in question is c= alled, which may dramatically increase the number of calls to PNCs, the num= ber of paths to be grown, the overall time of the path computation, etc. ; d) The biggest scalability issue is not even the number of times PNCs/= MDSCs need to be called - the amount of paths that need to be grown. Note t= hat PNC needs to return not just most optimal paths to all outbound links i= t can reach, rather, all possible such paths, so that end-to-end path const= raints could be met. Other issues are (some of them you mentioned below): a) how the algorithm prefers a segment over domain1 over a segment ov= er domain 2 when the metrics are not normalized (apples and oranges)? b) how the algorithm deals with independent/overlapping SRLGs in the d= omains? c) what if domains have independent overlapping name space for node a= nd link IDs? In other words. what does a path returned by a PNC even mean to MDSC? Furthermore, I disagree with what you said about node's connectivity matric= es because: 1) Several flavors of matrices could be provided (e.g. one optimized = by smallest cost and another by shortest delay); 2) Multiple intra-node paths could be associated with the same inbound= -outbound link combination. Each such path will yield a separate vector of = costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal aff= inities) that could be compared against the MDSC's path computation constra= ints; 3) Most importantly, TE topology model allows for negotiation of exact= connectivity matrices MDSC needs from PNCs. Such negotiation could happen = at any time, including before or even in the middle of the path computation= if the MDSC thinks the ones it has already are not good or sufficient enou= gh. Cheers, Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Thursday, November 10, 2016 5:28 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521E9A89B3B636CED6E40AB96BA0AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

See in-line-in-line= . I promise you I’ll not anwser any longer. I understand from this di= scussion we are in front of a dual solution, and as always happens, dual so= lutions have both benefits and drawbacks.

I believe it’= s not beneficial discussing too long in abstract about such stuff, even tho= ugh I recognise that this exchange of opinions with an expert like you is r= eally exciting.

I am running simula= tions about this stuff. Maybe eventually I’ll come back with some num= erical results.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.= com]
Sent: 11 November, 2016 7:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai = Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter.Beller@nokia.= com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; = TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Fransesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Friday, November 11, 2016 10:43 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I know that “= pure” Dijkstra actually cannot be used (in most cases) and used it fo= r brevity. Constrained Dijkstra and derivative algorithms that are actually= used relax some of the rules of Dijkstra without becoming exponential for that.

Think to a very wor= st case wher you ask for all the possible paths to all domains and then use= this information for the MDSC path computation without any further request= .  

Assuming a network = with N domains having L inter-domain links in mean, we must ask N*L*(L-1)/2= paths around wich is still polinomial. Using Dijkstra in a single run, as = mentioned, requests should become N*L. This is what I expect as an upper bound to the number of calls to PNC.

 

IB>> You assume = you need a single mesh of intra-domain paths interconnecting L links termin= ated by a node/domain. This means one path per Lx/Ly link combination. Assu= me that more than one path could be found connecting Lx to Ly: one is most optimal (shortest), another longer but wi= th a better delay metric, other paths are worse but with different SRLGs, e= tc. MDSC needs to know about all of them, because the e2e path made of shor= test intra-domain paths may fail e2e (e.g. max. delay) constraint or path diversity constrain. So you need = more paths to deal with than you assume.

 

[FL] You are right,= of course. Contraint management is a can of worms. But this not only happe= ns for multi-domain but also in single domain. Here, once again, you need t= o relax the Dijkstra blocking condition and propagate not only the first relaxation step arriving at a certain nod= e (the optimim one) but also all the eventual ones having some better const= raints. This applies to all cumulative constraints, and actually also appli= es to your proposal of computing paths in PNC and exporting/notifying all of them to MDSC in advance, doesn= ’t it ? About SRLGs, I don’t agree. If you put an SRLG inside a= XRO in order for it to be excluded from the path, I can’t see how th= is contribute to growth of the number of relaxation steps. Exclude resorce is not a cumulative constraint but just a local con= straint to be checked against any single link the process is traversing: if= the link matches the constraint, no propagation. This applies also to the = in-domain path computation and it just discards solution: you can’t have a better solution violating t= he constraint (please  note : here I assume mandatory constraints in o= rder not to write a book on the matter).

 

 

This actually is th= e method suggested by the draft, which seems to me reasonable (asking only = when needed will save queries to the PNCs, but on the other side asking all= together in the beginning would allow to send requests in parallel to different domains, which saves time; space= for some further consideration here).

 

The other issues, e= ven if notable, were not discusses so far and I rather focus on the scalabi= lity problem. Anyway it seems to me that they affect any possible solution = to the multi-domain problem.

 

About the connectiv= ity matrices, it’s my turn here for not having been sufficiently clea= r.

1)      Several fla= vors as you mention is not enough. I remember you the example of the affini= ties, but there are many others. They are not several, they are billions.

 

IB>> Sorry, this= does not make any sense to me. Why would MDSC request affinity constraint = from a PNC when:

a)&n= bsp;      interpretation= of affinities is different from domain to domain and unknown to MDSC;=

[FL] I believe ther= e are cases where SRLGs, affinities and other constraints and metrics are c= onsistent and consistently known across domains and MDSC: If a network for = example is onwed by the same carrier and domains are just different PNCs serving different supplier or differen= t technology domains, I would say this problem doesn’t exist. Also in= other cases different providers could make agreements in order to prevent = this problem.

b)&n= bsp;     affinities are= attributes of internal TE links MDSC does not know about.

According to TE tunnel= model, there is only so much client can specify when requesting a service,= less so that could be used as path computation requests: layer, bandwidth,= inclusions, exclusions, diversity, etc.

[FL] Why ? I can= 217;t see any reason to cut information, apart simplification (as I have al= ready said in my past e-mails : but need a list of constraint to be removed= multi-domain path computation). If you don’t like affinities, you must accept delay though : delay is a very “pop= ular” constraint, it’s measured hopefully in a consistent way s= o MDSC and PNC’s should all agree on its meaning. So, how many values= should we compute in advance (and then maintain and notify) on PNCs for delay constraint ? Or for any other bound on IGP or TE metric = or number of hops ? Or any combination of them ? Once again, millions ? bil= lions ? I don’t know, but a lot surely. Too many, In my opinion.=

 

2)      Multiple in= tra node paths : once again, how many? My point is that, to cover all the p= ossible actual requests they will become far too many to be stored, maintai= ned and notified to MDSC when a change occurs.

IB>> Why? Let= 217;s say MDSC serves OTN layer 20 domain network. Assume that each domain = exposes two connectivity matrices: one optimized by shortest cost, another = – by shortest delay. Assume that each matrix has an entry for each Lx/Ly/ODUtype and is associated with 4 most optimal sing= le intra-node paths and 4 SRLG-diverse path pairs. Each path yields a vecto= r of costs, including summary TE metric, delay, SRLGs, etc. Give me an exam= ple in which this would not be sufficient for MDSC?

[FL] Here it is : y= ou want to compute a path with a certain bound of delay and another bound o= n IGP metric, while optimizing against TE metric. Please, don’t tell = me it doesn’t make sense. It could well happen that the path in the matrix optimized for delay has a too high IGP metric = and the bound on IGP can’t eventually be respected. The matrix optimi= zed for IGP has a delay too high and eventually the relevant bound can̵= 7;t be respected as well. Instead, it exists a path with “intermediate” values of delay and IGP, which woul= d make both the bounds in the end. But it’s not captured in your matr= ices and you loose the only suitable solution.

Think also to the b= andwidth parameter, and in general all parameters with attached a value. In= principle you should compute and export all their possible combinations, o= r at least all the combinations that produce different paths, each path having attached the relevant combinatio= ns of request parameters. Producing matrices against single parameters does= n’t work.

 

3)      Negotiation= you are mentioning isn’t a path computation request to the PNC actua= lly? It will happen all the times MDSC can’t find a good path for a d= omain, that is most of the times in the beginning; the MDSC will then request and store these new paths and it will have a hi= gher probability eventually to find a suitable path already stored in its m= emory; but wait… isn’t that the incremental learning mechanism = I have proposed few mails ago ?

 

IB>> You are rig= ht, such negotiation is eventually a compound path computation request, BUT= :

 

a)&n= bsp;      there is a gua= rantee that in the worst case scenario there will be no more than 1 such re= quest per computation per PNC/MDSC;

b)&n= bsp;     All such reque= sts could be requested simultaneously and independently from all/some PNCs;=

c)&n= bsp;      There is a gua= rantee that said requests will not trigger the sub-tree hierarchical avalan= che of requests to inferior MDSCs/PNCs;

d)      Most im= portantly, these are stateful computations (here we go, we are finishing wh= ere we started) – once requested they do not need to be (re-)requeste= d again. Only matrices that are missing at the moment have to be reuested. Once provided they will stay and be aut= omatically kept up-to-date until MDSC explicitly asks to remove them. There= is a standard model and interface already for such negotiation<= /span>

[FL] The difference= here is where the statefulness happens; in my proposal on MDSC. MDSC, whil= e performing path computation, collects and store the results from PNCs in = its store and reuse them eventually.

No need for notific= ations or maintaining states in PNCs. Just remove a path and substitute it = with a better one when it’s no longer suitable for the purpose.

 

 

Cheers

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 11 November, 2016 3:43 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Franseco,

 

I probably didn’= t make myself clear. The two main points that I was trying to make are:

1)      Dijkstra does not work on topologies w= ith constrained/asymmetrical nodes;

2)      There will be much more calls to PNCs = that you seem to believe

 

Imagine your algorithm= hit node N1 over link L1. PNC1 representing N1 is called and the response = says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later= the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns th= e valid outbound links to be L3, L4, L7 and L8. Will you have to consider l= ink L8? Sure, it was not accounted yet. Will you have to consider link L3 a= gain? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (in= tra-node) path has different costs compared to L2-L3 internal path.

The conclusions:<= /o:p>

a)      = ; the algorithm has to (re-)visit the sa= me node multiple times;

b)      PNC will be called not only when the n= ode first discovered (as you implied), but every time the node is reached (= which could be as many times as the number of links it terminates);

c)      = ; when the node is represented by an MDS= C, the entire sub-tree of MDSCs/PNCs will be called hierarchically every ti= me the MDSC in question is called, which may dramatically increase the numb= er of calls to PNCs, the number of paths to be grown, the overall time of the path computation, etc. ;

d)      The biggest scalability issue is not e= ven the number of times PNCs/MDSCs need to be called – the amount of = paths that need to be grown. Note that PNC needs to return not just most op= timal paths to all outbound links it can reach, rather, all possible such paths, so that end-to-end path constra= ints could be met.

 

Other issues are (some= of them you mentioned below):

a)      = ; how the algorithm prefers a segment ov= er domain1 over a segment over domain 2 when the metrics are not normalized= (apples and oranges)?

b)      how the algorithm deals with independe= nt/overlapping SRLGs in the domains?

c)      = ; what if domains have independent overl= apping name space for node and link IDs?

 

In other words. what d= oes a path returned by a PNC even mean to MDSC?

 

Furthermore, I disagre= e with what you said about node’s connectivity matrices because:=

1)      Several flavors of  matrices coul= d be provided (e.g. one optimized by smallest cost and another by shortest = delay);

2)      Multiple intra-node paths could be ass= ociated with the same inbound-outbound link combination. Each such path wil= l yield a separate vector of costs (summary TE cost, delay, max. bandwidth,= internal SRLGs, internal affinities) that could be compared against the MDSC’s path computation constrain= ts;

3)      Most importantly, TE topology model al= lows for negotiation of exact connectivity matrices MDSC needs from PNCs. Such n= egotiation could happen at any time, including before or even in the middle= of the path computation if the MDSC thinks the ones it has already are not= good or sufficient enough.

 

 

Cheers,

Igor  

 

 

From: Francesco Lazzeri [mail= to:francesco.lazzeri@ericsson.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)     = ; Nodes representing domains must be = considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nod= es; so the “idea is to run Dijkstra on the MDSC abstract topology and= trigger a path computation to the relevant PNCs as soon as a node representing a domain is found” is questionab= le to begin with;

[FL] Of course ther= e are far more details than the ones included in my e-mail (long enough I t= hink). One of these is that, of course, for each path returned by the PNC a= lso the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is n= ot possible, will be used by MDSC during path computation;  metrics an= d delay shall be added to the currently computed ones, or if no path is fou= nd towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asym= metrical characteristics of the node-domains.

2)     = ; What happens if the algorithm finds= a node represented not by a PNC, but by another (lower hierarchy level) MD= SC?

[FL] Nothing differ= ent from a PNC I believe. As far as MDSC can compute paths as a PNC does an= d return them to the higher level MDSC, I can’t see any difference.

3)     = ; Assume you want to compute a single= path on a 20-domain topology originating in domain 1 and terminating in, s= ay, domain17. I don’t think you have much choice but:

a)  = ;     request PNC 1 to compute all possib= le (not just optional) paths from the path source to all domain 1 inter-dom= ain links;

b)  = ;    request all neighboring PNCs to = 220;grow” all the computed paths over inter-domain links into the dom= ains up to their respective outbound inter-domain links with potentially si= gnificant increase in the number of successful paths;

c)  = ;     repeat step b) until the paths reac= h the destination (17th) domain;

d)  = ;    grow the paths until they hit the p= ath computation destination;

e)  = ;    select the most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe &#= 8220;a lot”, but not exponentially growing with the number of domains= and inter-domain links. That was the point of my previous e-mail. Then we = can decide we have too many messages around, but I believe we first need some criteria to understand what “a lot̶= 1; or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantane= ous, but, in general, wrong as far as the connectivity matrices don’t= reflect the actual request parameters. Think about a request asking for a = path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 d= ifferent ways, specifying for each one any of the 2^32 affinity combination= s. Results of the path computation can be completely different depending on= the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should cre= ate L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine thi= s (that is multiply) with all the other constraints.

Maybe we could reno= unce to some constraints and limit the flexibility of path computation. In = my view this is the only way to make the connectivity matrix method a littl= e bit more appealing. But I still have dubts even with “essential” parameters like just bandwidth and= objective functions.

 

4)     = ; Computing diverse paths as two sing= le path computations with the topology transformation in between does not a= pply here: the paths may go through the same and/or different domains whose= internal topologies are not known (hence there is nothing to transform);

[FL] I agree that h= ere the problem is more complex than in a single domain. I didn’t do = tests yet on this, but I assume that a PNC should give also the possibility= to ask for a path in diversity from another path. So when the second path computation crosses the result of the first = one in the same domain, we should ask the relevant PNC for a path computati= on in diversity from the previous path (possibly using the XRO mechanism) i= n order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can g= uarantee that; if no diverse path is found, we should try and manage the of= fending domain as the offending links in bhandari algorithm, chasing them o= ut from the solution).

5)     = ; Computing a connectivity matrix on = a known (fully visible) topology is simple (as you said, could be done in a= single run) and also could be easily distributed between several path comp= uters to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be asso= ciated with one or more intra-node paths and provide to the MDSC various me= trics, like delay, cost, max. bandwidth, SRLGs)  It could be done in b= ackground when the path computers have nothing else to do (which is most of the time).

[FL] As said above,= the point here is that you don’t know the request parameters yet. An= d I do believe that in order to compute matrices suitable for the purpose, = either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity = of the problem to be solved.

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-     =      As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-     =      You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-     =      It’s built incrementally from= real requests and therefore with real parameters

-     =      It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-     =      For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-     =      For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-     =      For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces= @ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html= /draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)     = ; IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)     = ; Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org= ; CCAMP (ccamp@ie= tf.org); Scharf, Michael (Nokia - DE); pce@i= etf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:D= ieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.c= om]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case, it means IM=
HO that when a path has been calculated successfully in response to a reque=
st, a new path object is created in the data store. This does only make sen=
se if the resources have been allocated in the TED of the PCE irrespective =
of the fact whether the connection along this path will be established righ=
t away or at a later point in time. This will prevent further path computat=
ion requests from assuming that the resources are still available. As the T=
ED of the PCE also has to reflect the network state, I would assume that th=
e network resources can be in one of the following three states: available,=
 allocatedButNotInUse,  allocatedAndInUse. The path objects also need =
state information reflecting for example the alarm state of the allocated r=
esources. The path calculated earlier may become (temporarily) invalid due =
to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@hu=
awei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@noki= a.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung= [mailto:leeyoung= @huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft= -busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@eri= csson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org<= span lang=3D"DE" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">; TEAS WG (t= eas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

--_000_AM4PR07MB1521E9A89B3B636CED6E40AB96BA0AM4PR07MB1521eurp_-- From nobody Sat Nov 12 21:45:14 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37711294FF for ; Sat, 12 Nov 2016 21:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 aUlSj10P8zVl for ; Sat, 12 Nov 2016 21:45:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B6E12949B for ; Sat, 12 Nov 2016 21:45:08 -0800 (PST) X-AuditID: c1b4fb3a-c2aab98000000467-52-5827fde3e11b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 1D.F3.01127.3EDF7285; Sun, 13 Nov 2016 06:45:07 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 13 Nov 2016 06:42:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XM2IV4VWE1R245j1Gqhlpg1sl6TJZW0/twz5IAQoIXs=; b=BnLZX0UDk7sRWRJxFe7jQwuxTkByjznlvhkXwkWB7r43Lf/1UNuKpTIw2i5vIa9nqO6QydJrVYT/U+roJYNZrCPw1D5TL7tFX/tnJZZ6NHH73EuzaDIctXa5Qphib/gF+quevvZG02UEkdlpcAgkP4ayP2gjEJgLnM8HAD0Ofg8= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Sun, 13 Nov 2016 05:42:23 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0721.004; Sun, 13 Nov 2016 05:42:23 +0000 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: Transport NBI - Design Team - ANNOUNCEMENT Thread-Index: AdI9cIJ1MqUvgzEDSKajRHrd00HOHA== Date: Sun, 13 Nov 2016 05:42:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [31.133.159.210] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0994; 7:3mpUinLqlkBSVuB+N6YwkRZufHiM+ch4VSijmR0MuMuCpub9hFOCimp1btblSSyTNp9YwmRrihxhlwLXvsPf7VbPiYi32nxgveY16sI/kcbGIPGPIX4MrEmcVerJp/jmFmvK7y9L1GPoumservNDOw+dzELrckkItNvOdirYWR6pykFWdGeJrANjHXpE/0zzzMD/4EbkxjrhWFQCQHtXWNJMg5UizHx4zwQnw7NFUoWgnLupnJHBQaFIcXjSa4ck0+qm4w0ozwiohObJ84cbk9XBLkDnOqZdmPjsi9eJED2yi4NYeQSHtA3uLlS9z1tjO+GB8cBaPEss2XjtrmrdKQLBfT+x7RW93qqA23K/yQQ= x-ms-office365-filtering-correlation-id: b2297636-5041-4e27-ca92-08d40b87d795 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(50582790962513)(82608151540597)(97927398514766)(43874152186217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0994; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0994; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(336003)(199003)(189002)(3660700001)(106356001)(6116002)(54356999)(3846002)(189998001)(68736007)(3280700002)(102836003)(4326007)(8676002)(66066001)(5660300001)(81156014)(81166006)(586003)(9686002)(105586002)(790700001)(86362001)(2906002)(33656002)(101416001)(76576001)(8936002)(122556002)(97736004)(87936001)(6916009)(74316002)(229853002)(7846002)(7736002)(2900100001)(7696004)(77096005)(50986999)(110136003)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0994; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994E95087FB39E9FC7110D2F0BD0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 05:42:22.9319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0994 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGO/febdfR6DY1/0yNGJRabqW9LQtRSPKDgfShRgi1tZuKc5Nd tSxIJVZqWIoO2hLS8m2WpjZygmZbJKZgoYIvqaXOpShiVFpJkutM8NvvPM9zXp4/hybFVp6E TtVlsgadSivlCymzsk0mm/kbojxUsCRWuCpGKMVg0T1BDBE//6ACxVdX/yYSiYvCUxpWm5rN Gg5GXxamLLdPkBkd9eh66dvDeWiyHBUhHxqYI1Dw3corQkJazDQh6JwvJvGiB0H36xXCk6KY YhKedNzysJgxEfCy8jwOdSMw31/a2EHTfCYKXM4ET8aPkUFnyzDpYZKJg49TNsrDvsxxmF7u o3BGAaY7SzzMclh1O7x37QXT6DO+h0VMEtgWfwk8jJhdsNr7nMBnBsCY6zGBGzBQ3fGBxOwP 8zPrPJxXwwuj3ZuRQpN7CHneDEwlCT+n7wqwcRYaqtzkJr/qKvTqaTCyUkPiDRYE9eNNPGzY Ecz2sJiDYNhYw8ehWQpqm1sFeEQs1DUaEa4sgYmhQi8Hwdx4Jw9X0MO3sadUCQqxbGlk2WJZ /k9gJ7w3uyisy2HEVM7HfABqqxZIzDJ4uO6ktuqVSNCA/DmW49KTIyPlrCH1CsfpdXIdm9mK Nj6Qw7YWZUeOr7FOxNBIul3UfDVEKeapsrmcdCcCmpT6idbWNiSRRpVzgzXoLxmytCznRIE0 JQ0QHbN+viBmklWZbBrLZrCGTZegfSR5KNg8EPbu0biWDtYo99gkfGGLIsxdEh4a2m0OPMcN XMstEa2X3sw6s82nrWqsrF0YzfaWnbgdnhZrdvbL1KNMvlbersj/49CdbvlU98U3gdPqcxM1 QYvLYdahiCc7pqZjBukK09Ekv5Nzanmczm5s/DFZ36VufBPR37d7YV+flOJSVBH7SQOn+gdX 0eEpPAMAAA== Archived-At: Subject: Re: [CCAMP] Transport NBI - Design Team - ANNOUNCEMENT X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:45:12 -0000 --_000_AM2PR07MB0994E95087FB39E9FC7110D2F0BD0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear CCAMP, First of all thanks a lot to the many people that volunteered to be part of= the Northbound API Design Team. We received 19 candidacies. We were so imp= ressed by the number of people willing to be part of the team and by the en= thusiasm that we decided to include everyone. The team will be led by two people: Daniel King d.king@lancaster.ac.uk Italo Busi Italo.Busi@huawei.com Which will take the responsibility to do the initial arrangement, distribut= e the work and put together the various contributions. The team will be composed by: Luis Miguel Contreras Murillo luismiguel.contrerasmurillo@telefonica.com Oscar Gonz=E1lez de Dios oscar.gonzalezdedios@telefonica.com Zhangxian zhang.xian@huawei.com Tara Cummings tara.cummings@ericsson.com Yan Shi shiyan49@chinaunicom.cn Monali Chakrabarty MChakrabarty@advaoptical.com Rod Lu lu.rongduo@zte.com.cn Carlo Perocchio carlo.perocchio@ericsson.com Qilei Wang wang.qilei@zte.com.cn Xing Zhao zhaoxing@ritt.cn Yunbin Xu xuyunbin@ritt.cn Zheng Haomian zhenghaomian@huawei.com Dieter Beller dieter.beller@nokia.com Sergio Belotti sergio.belotti@nokia.com Michael Scharf michael.scharf@nokia.com Young Lee ylee@huawei.com Anurag Sharma ansharma@infinera.com The team will meet weekly or biweekly (at discretion of the leaders) and th= e calls will be announced on the mailing list and open to everyone (also to= who is not part of the DT). Please remember the problem statement, the goals/deliverables and the relat= ionship with other work noted below. Thank you Daniele & Fatai From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: marted=EC 25 ottobre 2016 21:50 To: CCAMP (ccamp@ietf.org) Cc: ccamp-chairs@ietf.org; BRUNGARD, DEBORAH A (ATTLABS) (db3546@att.com) <= db3546@att.com> Subject: Transport NBI - Design Team Dear CCAMP, We (chair and AD) decided to create a design team with the aim to work on t= he definition of technology specific extensions to the NBI of Transport con= troller. Problem Statement: Transport networks, such as Optical Transport Network (OTN) and Wavelength = Division Multiplexing (WDM) networks, are built using equipment from a sing= le vendor and are managed using proprietary interfaces to dedicated Element= Management Systems (EMS) / Network Management Systems (NMS). A common open= interface to each domain controller/management system is pre-requisite for= network operators to control multi-vendor/multi-domain networks and enable= also service provisioning coordination/automation. This can be achieved by using standardized YANG models, used together with = an appropriate protocol (e.g., RESTCONF). However, there is often confusion= of how the existing models in IETF can be used for transport networks. Fur= thermore, there is no clear answer to the question of whether there is miss= ing information for the control of specific technologies in the existing mo= dels (available in IETF or other SDOs) or even missing models since existin= g drafts focus on providing only the YANG models and explanation around the= m. Draft-zhang-ccamp-transport-yang-gap-analysis-00 already provides an overvi= ew of the problem. Goals/Deliverables: - Use cases and Gap analysis: identify a set of technologies use c= ases and providing a gap analysis against existing models - Missing YANG models: Document requirements for new models or, w= here possible, as augmentation of existing IETF models. Coordinate requirem= ents with appropriate WGs, e.g., TEAS, RTGWG and CCAMP itself. - Guidelines: Providing guidelines in terms of how all the related= models can be used in a step-wise manner, using a couple of well identifie= d transport network use cases. Relationship with other work: The control of transport networks in general is covered by mechanisms defin= ed in the TEAS WG. That WG is expected to produce base models that may requ= ire technology specific augmentations. The Transport NBI is applicable to the ACTN (Abstraction and Control of TE = Networks) architecture defined in the TEAS WG, and the scope of the DT may = be applicable to the technology specific extensions of the ACTN MPI interfa= ce (MDSC-PNC interface). If you are willing to candidate yourself as a member of the Transport NBI D= T please send an email to the CCAMP chairs and secretary within Friday Nove= mber 4th. Daniele & Fatai --_000_AM2PR07MB0994E95087FB39E9FC7110D2F0BD0AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear CCAMP,

 

First of all thanks a lot to th= e many people that volunteered to be part of the Northbound API Design Team= . We received 19 candidacies. We were so impressed by the number of people = willing to be part of the team and by the enthusiasm that we decided to include everyone.

The team will be led by two peo= ple:

 

Daniel King d.king@lancaster.ac.uk

Italo Busi = Italo.Busi@huawei.com

 

Which will take the responsibil= ity to do the initial arrangement, distribute the work and put together the= various contributions.

The team will be composed by:

 

Luis Miguel Contreras Murillo luismiguel.contrerasmurillo@telefonica.com

Oscar Gonz=E1lez de Dios oscar.gonzalezdedios@telefonica.com<= /o:p>

Zhangxian zhang.xian@huawei.com

Tara Cummings tara.cummings@eric= sson.com

Yan Shi shiyan49@chinaunicom.cn

Monali Chakrabarty MChakrabart= y@advaoptical.com

Rod Lu lu.r= ongduo@zte.com.cn

Carlo Perocchio carlo.perocchio@ericsson.com

Qilei Wang wang.qilei@zte.com.cn

Xing Zhao zhaoxing@ritt.cn

Yunbin Xu xuyunbin@ritt.cn

Zheng Haomian zhenghaomian@huawei.c= om

Dieter Beller  dieter.beller@nokia.c= om

Sergio Belotti sergio.belotti@nokia.com

Michael Scharf michael.scharf@no= kia.com

Young Lee ylee@huawei.com

Anurag Sharma ansharma@infinera.com

 

The team will meet weekly or bi= weekly (at discretion of the leaders) and the calls will be announced on th= e mailing list and open to everyone (also to who is not part of the DT).

Please remember the problem sta= tement, the goals/deliverables and the relationship with other work noted b= elow.

 

Thank you

Daniele & Fatai<= /span>

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: marted=EC 25 ottobre 2016 21:50
To: CCAMP (ccamp@ietf.org) <ccamp@ietf.org>
Cc: ccamp-chairs@ietf.org; BRUNGARD, DEBORAH A (ATTLABS) (db3546@att= .com) <db3546@att.com>
Subject: Transport NBI - Design Team

 

Dear CCAMP,

 

We (chair and AD) decided to= create a design team with the aim to work on the definition of technology = specific extensions to the NBI of Transport controller.

 

Problem Statement:

Transport networks, such as = Optical Transport Network (OTN) and Wavelength Division Multiplexing (WDM) = networks, are built using equipment from a single vendor and are managed us= ing proprietary interfaces to dedicated Element Management Systems (EMS) / Network Management Systems (NMS). A com= mon open interface to each domain controller/management system is pre-requi= site for network operators to control multi-vendor/multi-domain networks an= d enable also service provisioning coordination/automation.

This can be achieved by usin= g standardized YANG models, used together with an appropriate protocol (e.g= ., RESTCONF). However, there is often confusion of how the existing models = in IETF can be used for transport networks. Furthermore, there is no clear answer to the question of whether there is = missing information for the control of specific technologies in the existin= g models (available in IETF or other SDOs) or even missing models since exi= sting drafts focus on providing only the YANG models and explanation around them.

Draft-zhang-ccamp-transport-= yang-gap-analysis-00 already provides an overview of the problem.

 

Goals/Deliverables:<= /o:p>

-=    &n= bsp;      Use cases and Gap analy= sis: identify a set of technologies use cases and providing a gap analysis = against existing models

-=    &n= bsp;      Missing YANG models: Do= cument  requirements for new models or, where possible, as augmentatio= n of existing IETF models. Coordinate requirements with appropriate WGs, e.= g., TEAS, RTGWG and CCAMP itself.

-=    &n= bsp;      Guidelines: Providing g= uidelines in terms of how all the related models can be used in a step-wise= manner, using a couple of well identified transport network use cases.

 

Relationship with other w= ork:

The control of transport net= works in general is covered by mechanisms defined in the TEAS WG. That WG i= s expected to produce base models that may require technology specific augm= entations.

The Transport NBI is applica= ble to the ACTN (Abstraction and Control of TE Networks) architecture defin= ed in the TEAS WG, and the scope of the DT may be applicable to the technol= ogy specific extensions of the ACTN MPI interface (MDSC-PNC interface).

 

If you are willing to candid= ate yourself as a member of the Transport NBI DT please send an email to th= e CCAMP chairs and secretary within Friday November 4th.

 

Daniele & Fatai<= /span>

--_000_AM2PR07MB0994E95087FB39E9FC7110D2F0BD0AM2PR07MB0994eurp_-- From nobody Sat Nov 12 21:52:01 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77816129585; Sat, 12 Nov 2016 21:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 a8MgjoYHWu0Y; Sat, 12 Nov 2016 21:51:57 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD781294FF; Sat, 12 Nov 2016 21:51:56 -0800 (PST) X-AuditID: c1b4fb2d-5b107980000009f7-2f-5827ff7ac913 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 4E.76.02551.A7FF7285; Sun, 13 Nov 2016 06:51:55 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 13 Nov 2016 06:49:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sCcNGQdxrOzBM/pDFKQK/ZRJzyKVNt+oFX3HJ8Y/m14=; b=EJ//kSjUPnlRelWYCdciFB+muEUL5ow1cZ+KSSpv4UbEn8E4ELWdQZcYVIYEpOaRsX5GK7N4x+1mFnqcEU7UEV3q2RBSWqfe1l4TsJCT7FEQqTny0wveswU93OG7E8QxGXtXzaUCZ+B7FLQB1WNPNY9uQ2frjly4vIfNr7bTiNY= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Sun, 13 Nov 2016 05:49:14 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0721.004; Sun, 13 Nov 2016 05:49:15 +0000 From: Daniele Ceccarelli To: TEAS WG Chairs , "mpls@ietf.org" , "pce@ietf.org" , "CCAMP (ccamp@ietf.org)" Thread-Topic: Slides for Joint YANG session Thread-Index: AdI9cVBSJQRaX/jmSNis0b5g/Y4e/Q== Date: Sun, 13 Nov 2016 05:49:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [31.133.159.210] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:0B1EkyM2fWNzrMyz/sfrIgOmiV4Or6Mtp03titi/J3HH9GnL3lMHCBRJdSI9GXrRLVOoYw1RhOtyBxxwNPLjhsLAOoXX/d++6F0SzTOds5PEe5gJpIM0aojLcQuZZC4TlJMsW40yzaSZsD53/UVE7Z/RvJgqyV24kb4KucfCdIz+0pvXgd4f3rru4Ky1d2SRosvgqSRVcwZrq+gOF6YJ07hZ4w8b9IZW2g8UCm+Sh+vK5XVCOdLCT6LoGGyJzZHFl/FUE1IVgRYeKGy/ZL2B6QpZ6IynmRCgoZj/zQUM6gWuYyNT4wpRze29RhEr1190OLAVd7SjoWtmIaT4JUXOWzxvACxDL3lPjWVRtuABYdo= x-ms-office365-filtering-correlation-id: 0bec74e0-1c74-4df3-df0c-08d40b88cd11 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060305)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6072127); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(336003)(199003)(189002)(2906002)(8676002)(92566002)(450100001)(81156014)(5660300001)(7696004)(81166006)(54356999)(8936002)(7846002)(77096005)(66066001)(2900100001)(7736002)(122556002)(50986999)(101416001)(68736007)(2201001)(105586002)(76576001)(97736004)(9686002)(5001770100001)(2501003)(106356001)(33656002)(87936001)(3280700002)(790700001)(586003)(86362001)(102836003)(74316002)(6116002)(3846002)(3660700001)(189998001)(107886002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994D5F394223D25AAD1751EF0BD0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 05:49:14.8869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3bO2Y6jweea+qYWMUjBpZZdHEuiyz9BSSlBdiGbebzOKTsm akFD8Bql4bBciVpTMZ06L2hpFwV1piKV4pJipCMSxWIVEdPM45nkf7/3eZ/n431fPpqQmilf Olmbyei0ao1cKCYrY7pPBd9YDYzZa39JKR2PbKRypq6RUubZbSJlXtVzwVHypMn0R3AWXRRH xDOa5CxGF3rkqjipqHYeZYxuz1560EDqkcW7BHnQgA9A6zszxbEUtyAYrw8rQeI1tiJoNtgo riDxHQKWTT+EfMcggG6b0V0MIXAOfkMliKaFWAWOgdOcLsMVCKqqpgXcu9twAJiqC0Ucy7AC 2o16xHMITDWNEhyTeDcYPvxdn0OCL0NHQce6B2Fv+P2mef0dAvvAjKNawM+NwdQ3QfDsBfNz fBbhOGjN73F75NDyZRJxAwGuIcDSzK3ANSJhrMeMNth1d9AdSIXZqkm3roKie8MUH+5H8Llx xB32h+n8OiHfWCHBvDzlPh8DDeZ8xK/sC58mi93sD18/vqC4ExE4HayLKn5LTxipdJBlKMC4 aTnjf5dxk4u37IGaXqeQZwXU1y4QGzz2ek6wWa9BoqfIi2VYNi0xbH8Io0u+xrLp2hAtk9mO 1j5Rf6cruAc1LRwbQJhG8q2StoTAGCmlzmJz0gYQ0IRcJnG51iRJvDonl9Glx+quaxh2APnR pNxHcqjRfl6KE9WZTCrDZDC6ja6A9vDVo/vWcUI1rNTv8Ax57N9+y5lX7ugr7CxNOJdIx769 WTDbqSj1+jlj/dXWHZhLvcq2nIjCeVuQJFrQu9riZwlP/t5UxPYz4bcLS59UPCxeGXwfcak8 e0nkDDJYDYllh9kJxRmPwUWJJu7KLt3xZ/aUrtChg10pWtx1YXlndGSUTE6ySep9QYSOVf8D bHKKlEADAAA= Archived-At: Subject: [CCAMP] Slides for Joint YANG session X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:51:59 -0000 --_000_AM2PR07MB0994D5F394223D25AAD1751EF0BD0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The joint YANG session will be on Monday and as of Sunday afternoon 8 slide= decks out of 12 are still missing !! If you sent the slides and you don't see them in the meeting material (sorr= y...) please send a ping, otherwise please have them sent ASAP. Oscar is not here at this time, please remember to send them also to Fatai = and myself. Daniele --_000_AM2PR07MB0994D5F394223D25AAD1751EF0BD0AM2PR07MB0994eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The joint YANG session will be = on Monday and as of Sunday afternoon 8 slide decks out of 12 are still miss= ing !!

 

If you sent the slides and you = don’t see them in the meeting material (sorry…) please send a p= ing, otherwise please have them sent ASAP.

Oscar is not here at this time,= please remember to send them also to Fatai and myself.

 

Daniele 

--_000_AM2PR07MB0994D5F394223D25AAD1751EF0BD0AM2PR07MB0994eurp_-- From nobody Mon Nov 14 07:45:15 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC12A12966A; Mon, 14 Nov 2016 07:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 llcOVcl406Xb; Mon, 14 Nov 2016 07:45:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885E31295CB; Mon, 14 Nov 2016 07:45:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAI87582; Mon, 14 Nov 2016 15:44:59 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Nov 2016 15:44:58 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 14 Nov 2016 07:44:49 -0800 From: Igor Bryskin To: Italo Busi , Francesco Lazzeri , Fatai Zhang , Dieter Beller Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAWDYAgAB43DD//9f5gP//iVnA//5iYQD/+KhbgA== Date: Mon, 14 Nov 2016 15:44:48 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F17531@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> <91E3A1BD737FDF4FA14118387FF6766B156ABC28@lhreml504-mbs> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B156ABC28@lhreml504-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.198] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F17531dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5829DBFC.013D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0901344d095fe8d56d1389466178eea4 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [CCAMP] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 15:45:14 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F17531dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Italo, Please, see in-line. Igor From: Italo Busi Sent: Friday, November 11, 2016 11:04 AM To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Hi Igor, Please see some comments/questions in line below I think your last point is very important and deserves further consideratio= ns Italo From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: venerd=EC 11 novembre 2016 15:43 To: Francesco Lazzeri; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pc= e@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Hi Franseco, I probably didn't make myself clear. The two main points that I was trying = to make are: 1) Dijkstra does not work on topologies with constrained/asymmetrical = nodes; 2) There will be much more calls to PNCs that you seem to believe Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is ca= lled and the response says that the path can leave N1 over links L3, L4, L5= and L6. Suppose later the algorithm reaches N1 again over link L2. Will yo= u have to call PNC1 again? Sure, because now it returns the valid outbound = links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it = was not accounted yet. Will you have to consider link L3 again? Sure, becau= se you have not considered L2-L3 inbound/outbound link combination yet: L1-= L3 internal (intra-node) path has different costs compared to L2-L3 interna= l path. The conclusions: a) the algorithm has to (re-)visit the same node multiple times; b) PNC will be called not only when the node first discovered (as you i= mplied), but every time the node is reached (which could be as many times a= s the number of links it terminates); c) when the node is represented by an MDSC, the entire sub-tree of MDS= Cs/PNCs will be called hierarchically every time the MDSC in question is ca= lled, which may dramatically increase the number of calls to PNCs, the numb= er of paths to be grown, the overall time of the path computation, etc. ; [Italo] I have the feeling that calculating how the number of path computat= ion requests increases with the number of underlying PNCs highly depends on= the logic implemented by the MDSC. A "smart" logic, as outlined in section= 3.3 of the draft, could dramatically reduce this number. IB>> In the draft I have not found any consideration (smart or not) WRT the= use case when a MDSC talks down not to a PNC, rather to a lower level MDSC= . If the top-level MDSC has to ask for path computation services from its s= ubordinate controllers, why the same logic does not apply to the lower leve= l MDSC? Furthermore, I disagree that it is possible to combine in a given algorithm= path computation services provided by the PNCs with the topology informati= on provided by the PNCs. In other words, the MDSC has to use one service or= the other, combining the two won't work. To prove otherwise, you have to p= rovide a concrete example as to how this could be done. d) The biggest scalability issue is not even the number of times PNCs/M= DSCs need to be called - the amount of paths that need to be grown. Note th= at PNC needs to return not just most optimal paths to all outbound links it= can reach, rather, all possible such paths, so that end-to-end path constr= aints could be met. [Italo] I do not fully understand this point. IMHO, for a given end-to-end path setup, I think that the amount of informa= tion the MDSC needs to get from its underlying PNCs, calculate the optimal = multi-domain path, is exactly the same no matter whether it is get via path= computation requests or via TE Topology information. The main difference is that path computation allows the MDSC to request onl= y the information it needs when it needs. Instead, if only TE Topology is used, the PNCs should provide "any" possibl= e information the MDSC may ever need before it needs it, which is much more= than what is needed for a single end-to-end path setup. IB>> From example I gave to Fransesco: Let's say MDSC serves OTN layer 20 domain network. Assume that each domain = exposes two connectivity matrices: one optimized by shortest cost, another = - by shortest delay. Assume that each matrix has an entry for each Lx/Ly/OD= Utype and is associated with 4 most optimal single intra-node paths and 4 S= RLG-diverse path pairs. Each path yields a vector of costs, including summa= ry TE metric, delay, SRLGs, etc. Please, give me an example in which this w= ould not be sufficient for MDSC. Note that said matrices could be (re-)computed in single path computation r= uns, and as far as a PNC is concerned are not more computationally expensiv= e than single p2p path computations Other issues are (some of them you mentioned below): a) how the algorithm prefers a segment over domain1 over a segment ove= r domain 2 when the metrics are not normalized (apples and oranges)? b) how the algorithm deals with independent/overlapping SRLGs in the do= mains? c) what if domains have independent overlapping name space for node an= d link IDs? [Italo] Again I am a bit confused. With path computation, the path returned by the PNC and its characteristics= (e.g., SRLG, node/link IDs) are associated with a given TE Topology expose= d by the PNC itself. The MDSC shall be capable to deal with these issues ot= herwise also the TE Topology information will not be consistent. Am I missing anything? IB>> Yes, you are. Connectivity matrices provided by PNCs are not meant to = be used as are. Instead, they are supposed to be merged into MDSC's native = topology, and part of this merging process is link, node. SRLG renaming and= metrics normalization. With the path computation approach said normalizati= on has to be done on the fly every time when a new path is received (or com= pare apples to oranges, when selecting a better path from ones provided by = different PNCs) In other words. what does a path returned by a PNC even mean to MDSC? Furthermore, I disagree with what you said about node's connectivity matric= es because: 1) Several flavors of matrices could be provided (e.g. one optimized = by smallest cost and another by shortest delay); [Italo] The requested path will have several path constraints (latency, ban= dwidth, ...): this is described in sections 3.1 and 3.2 of the draft. The s= et of possible path constraints combinations is quite huge IB>>Please, elaborate on this, because it is not obvious from the draft. Ac= cording to the TE tunnel model there is only so many parameters one can con= figure for a TE tunnel. A sub-set of said parameters could be used to expre= ss path computation constraints: bandwidth, latency, inclusions, exclusions= , diversities, affinities. Not all said constraints (e.g. affinities) are a= pplicable when requesting path computation services from PNCs. Please, give= an example, from which it could be seen that "The set of possible path con= straints combinations is quite huge" 2) Multiple intra-node paths could be associated with the same inbound= -outbound link combination. Each such path will yield a separate vector of = costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal aff= inities) that could be compared against the MDSC's path computation constra= ints; 3) Most importantly, TE topology model allows for negotiation of exact= connectivity matrices MDSC needs from PNCs. Such negotiation could happen = at any time, including before or even in the middle of the path computation= if the MDSC thinks the ones it has already are not good or sufficient enou= gh. [Italo] This seems an important and interesting point. Requesting a new node's connectivity matrix with the specific set of path c= onstraints when needed, looks to me like a form of requesting multiple path= computations between all the possible ingress/egress ports in "one shot". = I think this is a possible solution to the problem we are trying to addres= s so I think it deserves further considerations. IB>> I think you are confusing "path computation" constructs, which are spe= cific for a given path computation reqiest, with "TE topology" constructs, = which are supposed to support numerous computations. Take TE link, for exam= ple. It is not advertised/tailored to address a particular computation requ= est. Rather, TE link and its attributes are stateful in nature and are supp= osed to cover a particular range of path computations. If such attributes p= rove to be not sufficient the TE link is either re-configured or additional= TE link is advertised. Connectivity matrix is an attribute of a TE node, h= ence it is a topological concept, not computational Cheers, Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Thursday, November 10, 2016 5:28 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, please see inline. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 8:53 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, There are few issues with your logic, I think: 1) Nodes representing domains must be considered as blocking/asymmetri= cal nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijks= tra on the MDSC abstract topology and trigger a path computation to the rel= evant PNCs as soon as a node representing a domain is found" is questionabl= e to begin with; [FL] Of course there are far more details than the ones included in my e-ma= il (long enough I think). One of these is that, of course, for each path re= turned by the PNC also the relevant metrics and delay shall be returned. Th= ese, and also NO-PATH information if some connectivity is not possible, wil= l be used by MDSC during path computation; metrics and delay shall be adde= d to the currently computed ones, or if no path is found towards a certain = inter-domain link, no propagation will occur on that link; this compensates= the blocking/asymmetrical characteristics of the node-domains. 2) What happens if the algorithm finds a node represented not by a PNC= , but by another (lower hierarchy level) MDSC? [FL] Nothing different from a PNC I believe. As far as MDSC can compute pat= hs as a PNC does and return them to the higher level MDSC, I can't see any = difference. 3) Assume you want to compute a single path on a 20-domain topology or= iginating in domain 1 and terminating in, say, domain17. I don't think you = have much choice but: a) request PNC 1 to compute all possible (not just optional) paths fr= om the path source to all domain 1 inter-domain links; b) request all neighboring PNCs to "grow" all the computed paths over = inter-domain links into the domains up to their respective outbound inter-d= omain links with potentially significant increase in the number of successf= ul paths; c) repeat step b) until the paths reach the destination (17th) domain= ; d) grow the paths until they hit the path computation destination; e) select the most optimal path I hope you agree that this is a lot of computations. [FL] Well, maybe "a lot", but not exponentially growing with the number of = domains and inter-domain links. That was the point of my previous e-mail. T= hen we can decide we have too many messages around, but I believe we first = need some criteria to understand what "a lot" or "too many" means. I also hope you agree that computing such path on a single 20 node topology= equipped with node detailed connectivity matrices is instantaneous; [FL] Yes, istantaneous, but, in general, wrong as far as the connectivity m= atrices don't reflect the actual request parameters. Think about a request = asking for a path with some affinity constraint, for example. Affinities ar= e 32 bits values; you can ask to include/exclude links in 3 different ways,= specifying for each one any of the 2^32 affinity combinations. Results of = the path computation can be completely different depending on the affinity = value and include/exlcude options. In theory to cope with just the affinity= constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we = still have to combine this (that is multiply) with all the other constraint= s. Maybe we could renounce to some constraints and limit the flexibility of pa= th computation. In my view this is the only way to make the connectivity ma= trix method a little bit more appealing. But I still have dubts even with "= essential" parameters like just bandwidth and objective functions. 4) Computing diverse paths as two single path computations with the to= pology transformation in between does not apply here: the paths may go thro= ugh the same and/or different domains whose internal topologies are not kno= wn (hence there is nothing to transform); [FL] I agree that here the problem is more complex than in a single domain.= I didn't do tests yet on this, but I assume that a PNC should give also th= e possibility to ask for a path in diversity from another path. So when the= second path computation crosses the result of the first one in the same do= main, we should ask the relevant PNC for a path computation in diversity fr= om the previous path (possibly using the XRO mechanism) in order to be guar= anteed that even though the same domain is used, the two paths are still di= verse (PNC can guarantee that; if no diverse path is found, we should try a= nd manage the offending domain as the offending links in bhandari algorithm= , chasing them out from the solution). 5) Computing a connectivity matrix on a known (fully visible) topology= is simple (as you said, could be done in a single run) and also could be e= asily distributed between several path computers to produce/support several= flavors of said matrix (e.g. differently optimized). Each matrix entry may= be associated with one or more intra-node paths and provide to the MDSC va= rious metrics, like delay, cost, max. bandwidth, SRLGs) It could be done i= n background when the path computers have nothing else to do (which is most= of the time). [FL] As said above, the point here is that you don't know the request param= eters yet. And I do believe that in order to compute matrices suitable for = the purpose, either you have to compute (and store, and maintain) too many = of them, or you have to reduce too much the complexity of the problem to be= solved. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 12:39 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, it seems to me that the number of path computations should grow polinomiall= y and not esponentially with the number of domains and inter-domain links. Here it is some consideration about that, and correct me if I am wrong. Assume that the domains are abstracted on MDSC as nodes, and assume we have= a network of domains only (adding "normal" nodes doesn't affect the propos= ition). The idea is to run Dijkstra on the MDSC abstract topology and trigger a pat= h computation to the relevant PNCs as soon as a node representing a domain = is found. The abstract topology on MDSC will be a network with a number of nodes equa= l to the number of domains and a number of links equal to the inter-domain = links. If we run the Dijkstra algorithm to compute an end-to-end path on that topo= logy the complexity of it, which is related to the number of relaxation ste= ps, is polinomial as you know. So the number of requests going down to the = different PNCs must be polinomial as well. Take also into account that Dijkstra is normally used to find the shortest = path between two end-points in the network, but actually the algorithm is c= apable to find in a single run (with the same complexity) the shortest path= between a given node and any other node in the network. This should suggest to make the best of this property and foresee in the pr= otocol/model a single request capable to return all the suitable paths from= a given source to all the other nodes (or to a selected set of nodes, name= ly the exit nodes connected to the inter-domain links). In that way we shou= ld have one request per domain, to feed the relaxation steps between one in= gress point of the domain and all the points connected to inter-domain link= s. In the standard Dijkstra one domain/node will be traversed (that is will ge= nerate relaxation steps to its links) at most once, as any other relaxation= step passing through it eventually will be stopped once the node has been = visited. So, with this method, in the very worst case (when the best path i= s the Hamiltonian path, the one traversing all the nodes once) we'll have a= number of requests to the PNCs equal to the number of PNCs (one per PNC). If instead we use normal point-to point path computations, we should ask L-= 1 path computations to each PNC, where L is the number of inter-domain link= s connected to the domain managed by the PNC, which is still polinomial in = the number of domains and inter-domain links. Regarding path computation for paths in diversity, it should be still polin= omial, as if you use for example the Bhandari algorithm to do so, you see t= hat it's actually a sequence of two Dijkstra path computations plus some ne= twork transformation in between (modification of some link weights). The fi= rst instance is a traditional path computation, while the second one is a m= odified version allowing negative costs on the edges, but still polinomial.= So once again the result should still be polinomial and the number of requ= est shouldn't diverge. Now, something about the other approach mentioned in your e-mail, which imp= lies computing all the possible paths inside any domain in advance. It is polinomial as well, but with a higher number of path computations, as= for any domain in the network you have to compute L(L-1)/2 paths. Of course, you'll say, this happens once and not at any path computation. T= hat's true, but : - As soon as network get increasingly used, the computed paths cou= ld become invalid. So you need to recompute them as needed and advertise al= l the changes - You perform a path computation "in advance", that is before the = actual request is done, and therefore PNC cannot be aware of the future req= uirements in term of bandwidth, objective functions, constraints and so on.= Computed paths will not be suitable in general for all the future requests= , and of course it's not conceivable to compute those paths for all the pos= sible combinations of the request parameters (this should grow esponentiall= y!) Something that I would like to investigate further is the possibility for t= he MDSC to store the results of the path computations returned by the PNCs= along the time and reuse them as applicable during the future path computa= tions. At the end of the day this is something similar to the connectivity matrix = concept, with two main differences: - It's built incrementally from real requests and therefore with r= eal parameters - It's build by MDSC and maintained inside MDSC, no need for notif= ications. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 10 November, 2016 5:15 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Franseco, We have discussed with Italo the applicability of path computation service = for multi-domain scenarios and agreed (at least my impression) that this re= alistically works for no more than two or three domains. For a single e2e p= ath computation the number of paths MDSC needs to request from PNCs grows e= xponentially with the number of domains and the number of inter-domain link= s. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-d= isjoint) paths for a single e2e protected service and still worse when MDS= C needs to place more than one e2e services with global optimization criter= ia in mind. Things get still much worse when MDSCs are linked into a hierar= chy, and path computation services will have to be requested vertically thr= ough entire hierarchy from all subordinate MDSCs and PNCs Please, see further in line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Thursday, November 10, 2016 5:02 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, I assumed in fact a multi-domain ACTN scenario, as stated in the abstract o= f draft-busibel-teas-yang-path-computation-00, where I believe we have the = most interesting use cases for path computation services. I believe we shou= ld consider all of these, as the same model shall be used both for single a= nd multi-domain scenarios. Regarding path computation on MDSC: in an ideal world MDSC could read topol= ogy from PNCs and compute itself end-to-end paths but there are cases where= this could be either impossible or not convenient: - For some reasons (e.g. security/privacy) the PNC doesn't export = full topology information to the MDSC, so that such information is not suit= able for a path computation on MDSC IB>> No one expects PNC to export full topology information, it is likely t= o contain proprietary information and hence useless for the MDSC anyway. PN= C is expected to expose an abstract TE topology, which could be as small as= a single TE node with detailed connectivity matrix; - For some reasons (e.g. scalability) MDSC doesn't want to get ful= l topology information from the subtended domains IB>> See comment above; - For some reasons (e.g. lack of knowledge about the internal mode= l of the equipment managed by the PNC : especially in WDM networks) MDSC is= not capable to cumpute reliably a feasible path in a domain IB>> This is not a concern: all the necessary computations are done already= by PNCs when exposing and updating the abstract TE topologies. IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. T= his means that for a top level MDSC e2e path computation, the path computat= ion services need to be requested hierarchically from all subordinate MDSCs= and PNCs across all hierarchy levels. In contrast, multi-level abstraction= of TE topologies is not a problem BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 8:33 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, note that the context of this discussion is single domain. In my op= inion MDSC should not rely on the Path computation services (stateless or = stateful) provided by PNCs, rather, on its own path computation on TE topol= ogy, the product of merging of abstract TE topologies catered by the subor= dinate PNCs. And BTW said abstract TE topologies should be kept up-to-date = by the PNCs (i.e. with updates, stateful). Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 12:42 PM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Well, I know implementations of both the "flavours", and I would say that t= he most complex are the pre-planned ones. So, it could be an interesting use case, but we need to be aware that it co= mes with a price. Take also into account that the path recomputation inside the provider coul= d not necessarily offer an optimal solution end-to-end, and the client (the= MDSC actually) should anyway check whether the end-to-end path, when a cha= nge happens on a segment, is still in compliance with its constraints (e.g.= if there is a latency constraint on the end-to-end path, it may happen tha= t the recomputed segment has a longer latency that leads to exceeding the c= onstraint on the end to end path : but the provider only sees that single s= egment of the end-to-end path and taking into account the end-to-end constr= aints could be really difficult). Regarding the TE-link, I was actually interested on what the provider (that= is the PNC) advertises to the client (MDSC) when reservation occurs. It ca= nnot advertise A'B' as it knows only A and B, but advertising AB seems to m= e not correct. BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 4:56 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, Please, see in-line. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri Sent: Wednesday, November 09, 2016 10:27 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00 Igor, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? FL>> Probably the same in case the provider notifies "Hey, I have no= longer anything for you". IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better i= f the client has learnt about the previously returned path unfeasibility ah= ead of time, so that it could re-plan it's failure recovery scheme? If there is no (more) path, there is no path. The client could only try and= crankback looking for some different path or report an alarm. IB>> Relying on crankbaks in an unpredictable way is not exactly a good sol= ution, right? The scenario that seems more applicable to your proposal is a pre-planned r= estoration mechanism where we have a worker path in-service and a protectio= n path just computed (but not reserving network resources, in order to shar= e them among several protection paths), in a multi-domain network. In that = case, reserving te-tunnels like you suggest, could give an advantage, as th= e end-to-end cranckback could occur when the notification with "no-path" is= triggered by the provider (that means the protection path or some of its s= egments is no longer valid) and not when the path deployment is triggered b= y the client (that means the worker path is gone and we need the protection= immediately). Is this the case you are considering ? IB>> Exactly. All the scenarios you can think of where you don't know when = and where a problem may happen and you want to maintain flexibility and sha= re the network resources to protect as much as you can In other cases, as when used during an end-to-end path computation with imm= ediate deployment to reduce the possibility of conflicts among concurrent p= rocedures, it seems to me less important or applicable, as all these proced= ures will likely be orchestrated by the same entity, which could well avoid= conflicts. IB>> All cases where the provider wants to expose a potentiality without co= mmitting resources to cover for the client multiple use cases and provide a= t the same time some degree (albeit not perfect) predictability. 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. FL>> This means that the provider just sends the reply to the path computat= ion request and doesn't advertise any new TE link to the client ? This is a= ctually what I would expect: the task to manage TE-links in the overlay top= ology is with the client. IB>> Overlay TE topology manager advertises a TE link that is supported not= by a provisioned in a server layer TE tunnel (connection), rather, by a co= mputed and monitored path. This way the overlay TE topology manger can adve= rtise multiple abstract TE links mapped onto the same network resources Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 3:47 PM To: Francesco Lazzeri >; Fatai Zhang >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Francesco, 1) IMHO simplicity pays back. Instead than maintaining all these state= s, notifying clients all the times something changes, and repeating path-co= mputation as needed, isn't better for a client (and provider) to ask what i= s needed when it's needed, and get the best result back at that moment ? IB>> What happens it the provider at this moment says: " No, I have nothing= for you" ? What if the path was relied upon by the client for a failure r= ecovery or congestion avoidance strategy or disaster topology re-configurat= ion? 2) Regarding the abstract link in the overlay topology, I still can't = see what the provider will advertise. If it's a new link representing the f= orwarding adjacency between A' and B', how it will be represented by the pr= ovider ? IB>> According to the TE topology model abstract TE link A'B' points to the= underlay (provider) TE topology where the path is computed and provisioned= as supporting TE tunnel for committed TE link or not provisioned (but moni= tored) for uncommitted TE link (i.e. link advertising potentiality in the p= rovider network). In either case TE link's attributes (e.g. available bandw= idth, SRLGs) are defined by the path. Igor From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: Wednesday, November 09, 2016 9:26 AM To: Igor Bryskin; Fatai Zhang; Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, IMHO simplicity pays back. Instead than maintaining all these states, notif= ying clients all the times something changes, and repeating path-computatio= n as needed, isn't better for a client (and provider) to ask what is needed= when it's needed, and get the best result back at that moment ? Regarding the abstract link in the overlay topology, I still can't see what= the provider will advertise. If it's a new link representing the forwardin= g adjacency between A' and B', how it will be represented by the provider ? BR Francesco From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: 09 November, 2016 2:48 PM To: Fatai Zhang >; Fran= cesco Lazzeri >; Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; pce@iet= f.org; TEAS WG (teas@ietf.org) <= teas@ietf.org> Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Francesco, Please, see in-line. Cheers, Igor The point here is for how long the provider should keep the computed path a= nd its request parameters IB>> As far as the provider is concerned, the requested path and its parame= ters is a TE tunnel (albeit computed but not provisioned). So it keeps the = state until the client removes the TE tunnel. (in fact if we want to have a possibly better path, at any change inside pr= ovider topology, resource status and usage, the provider should check if th= e computed path is still feasible and/or redo path computation to find a be= tter path). This could be an overhead, in my view. IB>> For example, if provider is to ensure the path's feasibility, all it n= eeds is to detect a change in a TE link the path is going through and make = sure that the change does not make the path unfeasible. Only in the latter= case the path re-computation needs to be scheduled and performed in a back= ground thread. Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; IB>> The abstract link is a part of the abstract topology "cooked" (customi= zed) for the client, which is supported by the computed path in the underla= y topology, which is the provider's topology. in fact, if the client is asking for a path between A and B (A and B inside= provider topology), having A' (in client topology) connected to A and B' (= in client topology) connected to B, the relevant abstract TE link (the forw= arding adjacency) should be built between A' and B', that is in the client = topology; therefore the client should be in charge of managing it, as the p= rovider is not aware of A' and B'. IB>> This is correct, but note that the two topologies (underlay and overla= y) according to the TE topology model have independent and unrelated name s= paces for node, link and SRLG IDs. So it is perfectly Ok. IB>> Also note that according to TE topology model one important attribut= e of a TE node (especially abstract composite node) is connectivity matrix,= which is nothing but a set of stateful paths computed, re-computed and con= stantly monitored (but not reserved) over the TE topology the node encapsul= ates. This means that stateful unreserved paths play already a very import= ant part in supporting TE topologies with asymmetrical blocking abstract TE= nodes. Igor BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller > Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia= - DE) >; TEAS WG= (teas@ietf.org) = >; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F17531dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Italo,

 

Please, see in-line.

 

Igor=

 

From: Italo Busi
Sent: Friday, November 11, 2016 11:04 AM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Hi Igor,

 

Please see some commen= ts/questions in line below

 

I think your last poin= t is very important and deserves further considerations

 

Italo

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: venerd=EC 11 novembre 2016 15:43
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-= teas-yang-path-computation-00

 

Hi Franseco,

 

I probably didn’= t make myself clear. The two main points that I was trying to make are:

1)&n= bsp;     Dijkstra does = not work on topologies with constrained/asymmetrical nodes;

2)&n= bsp;     There will be = much more calls to PNCs that you seem to believe

 

Imagine your algorithm= hit node N1 over link L1. PNC1 representing N1 is called and the response = says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later= the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns th= e valid outbound links to be L3, L4, L7 and L8. Will you have to consider l= ink L8? Sure, it was not accounted yet. Will you have to consider link L3 a= gain? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (in= tra-node) path has different costs compared to L2-L3 internal path.

The conclusions:<= /o:p>

a)&n= bsp;     the algorithm = has to (re-)visit the same node multiple times;

b)&n= bsp;    PNC will be ca= lled not only when the node first discovered (as you implied), but every ti= me the node is reached (which could be as many times as the number of links= it terminates);

c)&n= bsp;     when the node = is represented by an MDSC, the entire sub-tree of MDSCs/PNCs will be called= hierarchically every time the MDSC in question is called, which may dramat= ically increase the number of calls to PNCs, the number of paths to be grown, the overall time of the path com= putation, etc. ;

[Italo] I have the f= eeling that calculating how the number of path computation requests increas= es with the number of underlying PNCs highly depends on the logic implement= ed by the MDSC. A “smart” logic, as outlined in section 3.3 of the draft, could dramatically reduce this numbe= r.

 

IB>> In th= e draft I have not found any consideration (smart or not) WRT the use case = when a MDSC talks down not to a PNC, rather to a lower level MDSC. If the t= op-level MDSC has to ask for path computation services from its subordinate controllers, why the same logic does not app= ly to the lower level MDSC?

Furthermore, I d= isagree that it is possible to combine in a given algorithm path computatio= n services provided by the PNCs with the topology information provided by t= he PNCs. In other words, the MDSC has to use one service or the other, combining the two won’t work. To pr= ove otherwise, you have to provide a concrete example as to how this could = be done.

 

d)&n= bsp;    The biggest sc= alability issue is not even the number of times PNCs/MDSCs need to be calle= d – the amount of paths that need to be grown. Note that PNC needs to= return not just most optimal paths to all outbound links it can reach, rather, all possible such paths, so that e= nd-to-end path constraints could be met.

[Italo] I do not ful= ly understand this point.

IMHO, for a given en= d-to-end path setup, I think that the amount of information the MDSC needs = to get from its underlying PNCs, calculate the optimal multi-domain path, i= s exactly the same no matter whether it is get via path computation requests or via TE Topology information.

The main difference = is that path computation allows the MDSC to request only the information it= needs when it needs.

Instead, if only TE = Topology is used, the PNCs should provide “any” possible inform= ation the MDSC may ever need before it needs it, which is much more than wh= at is needed for a single end-to-end path setup.

 

IB>> From = example I gave to Fransesco:

Let’s say MDSC s= erves OTN layer 20 domain network. Assume that each domain exposes two conn= ectivity matrices: one optimized by shortest cost, another – by short= est delay. Assume that each matrix has an entry for each Lx/Ly/ODUtype and is associated with 4 most optimal single intra-= node paths and 4 SRLG-diverse path pairs. Each path yields a vector of cost= s, including summary TE metric, delay, SRLGs, etc. Please, give me an examp= le in which this would not be sufficient for MDSC.

Note that said matrice= s could be (re-)computed in single path computation runs, and as far as a P= NC is concerned are not more computationally expensive than single p2p path= computations

 

Other issues are (some= of them you mentioned below):

a)&n= bsp;     how the algori= thm prefers a segment over domain1 over a segment over domain 2 when the me= trics are not normalized (apples and oranges)?

b)&n= bsp;    how the algori= thm deals with independent/overlapping SRLGs in the domains?

c)&n= bsp;     what if domain= s have independent overlapping name space for node and link IDs?=

[Italo] Again I am a= bit confused.

With path computatio= n, the path returned by the PNC and its characteristics (e.g., SRLG, node/l= ink IDs) are associated with a given TE Topology exposed by the PNC itself.= The MDSC shall be capable to deal with these issues otherwise also the TE Topology information will not be consis= tent.

Am I missing anythin= g?

 

IB>> Yes, = you are. Connectivity matrices provided by PNCs are not meant to be used as= are. Instead, they are supposed to be merged into MDSC’s native topo= logy, and part of this merging process is link, node. SRLG renaming and metrics normalization. With the path computation a= pproach said normalization has to be done on the fly every time when a new = path is received (or compare apples to oranges, when selecting a better pat= h from ones provided by different PNCs)

 

In other words. what d= oes a path returned by a PNC even mean to MDSC?

 

Furthermore, I disagre= e with what you said about node’s connectivity matrices because:=

1)&n= bsp;     Several flavor= s of  matrices could be provided (e.g. one optimized by smallest cost = and another by shortest delay);

[Italo] The requeste= d path will have several path constraints (latency, bandwidth, …): th= is is described in sections 3.1 and 3.2 of the draft. The set of possible p= ath constraints combinations is quite huge

 

IB>>Please= , elaborate on this, because it is not obvious from the draft. According to= the TE tunnel model there is only so many parameters one can configure for= a TE tunnel. A sub-set of said parameters could be used to express path computation constraints: bandwidth, latency,= inclusions, exclusions, diversities, affinities. Not all said constraints = (e.g. affinities) are applicable when requesting path computation services = from PNCs. Please, give an example, from which it could be seen that “The set of possible path constrain= ts combinations is quite huge”

<= span style=3D"color:#C00000">

2)&n= bsp;     Multiple intra= -node paths could be associated with the same inbound-outbound link combina= tion. Each such path will yield a separate vector of costs (summary TE cost= , delay, max. bandwidth, internal SRLGs, internal affinities) that could be compared against the MDSC’= s path computation constraints;

3)&n= bsp;     Most important= ly, TE topology model allows for negotiation of exact connectivity matrices MDSC needs from PNCs. Suc= h negotiation could happen at any time, including before or even in the mid= dle of the path computation if the MDSC thinks the ones it has already are = not good or sufficient enough.

[Italo] This seems a= n important and interesting point.

Requesting a new nod= e’s connectivity matrix with the specific set of path constraints whe= n needed, looks to me like a form of requesting multiple path computations = between all the possible ingress/egress ports in “one shot”.  I think this is a possible solution to th= e problem we are trying to address so I think it deserves further considera= tions.

 

IB>> I thi= nk you are confusing “path computation” constructs, which are s= pecific for a given path computation reqiest, with “TE topology”= ; constructs, which are supposed to support numerous computations. Take TE link, for example. It is not advertised/tailored to address a part= icular computation request. Rather, TE link and its attributes are state= ful in nature and are supposed to cover a particular range of path computat= ions. If such attributes prove to be not sufficient the TE link is either r= e-configured or additional TE link is advertised. Connectivity matrix is an attribute of a TE node, hence it = is a topological concept, not computational

 

 

Cheers,

Igor  

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor, please see in= line.

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

There are few issue= s with your logic, I think:

 

1)   = ;   Nodes representing domains must be = considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nod= es; so the “idea is to run Dijkstra on the MDSC abstract topology and= trigger a path computation to the relevant PNCs as soon as a node representing a domain is found” is questionab= le to begin with;

[FL] Of course ther= e are far more details than the ones included in my e-mail (long enough I t= hink). One of these is that, of course, for each path returned by the PNC a= lso the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is n= ot possible, will be used by MDSC during path computation;  metrics an= d delay shall be added to the currently computed ones, or if no path is fou= nd towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asym= metrical characteristics of the node-domains.

2)   = ;   What happens if the algorithm finds= a node represented not by a PNC, but by another (lower hierarchy level) MD= SC?

[FL] Nothing differ= ent from a PNC I believe. As far as MDSC can compute paths as a PNC does an= d return them to the higher level MDSC, I can’t see any difference.

3)   = ;   Assume you want to compute a single= path on a 20-domain topology originating in domain 1 and terminating in, s= ay, domain17. I don’t think you have much choice but:

a)       request PNC 1 to compute all possib= le (not just optional) paths from the path source to all domain 1 inter-dom= ain links;

b)      request all neighboring PNCs to = 220;grow” all the computed paths over inter-domain links into the dom= ains up to their respective outbound inter-domain links with potentially si= gnificant increase in the number of successful paths;

c)       repeat step b) until the paths reac= h the destination (17th) domain;

d)      grow the paths until they hit the p= ath computation destination;

e)      select the most optimal path

 

I hope you agree th= at this is a lot of computations.

[FL] Well, maybe &#= 8220;a lot”, but not exponentially growing with the number of domains= and inter-domain links. That was the point of my previous e-mail. Then we = can decide we have too many messages around, but I believe we first need some criteria to understand what “a lot̶= 1; or “too many” means.

 

I also hope you agr= ee that computing such path on a single 20 node topology equipped with node= detailed connectivity matrices is instantaneous;

[FL] Yes, istantane= ous, but, in general, wrong as far as the connectivity matrices don’t= reflect the actual request parameters. Think about a request asking for a = path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 d= ifferent ways, specifying for each one any of the 2^32 affinity combination= s. Results of the path computation can be completely different depending on= the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should cre= ate L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine thi= s (that is multiply) with all the other constraints.

Maybe we could reno= unce to some constraints and limit the flexibility of path computation. In = my view this is the only way to make the connectivity matrix method a littl= e bit more appealing. But I still have dubts even with “essential” parameters like just bandwidth and= objective functions.

 

4)   = ;   Computing diverse paths as two sing= le path computations with the topology transformation in between does not a= pply here: the paths may go through the same and/or different domains whose= internal topologies are not known (hence there is nothing to transform);

[FL] I agree that h= ere the problem is more complex than in a single domain. I didn’t do = tests yet on this, but I assume that a PNC should give also the possibility= to ask for a path in diversity from another path. So when the second path computation crosses the result of the first = one in the same domain, we should ask the relevant PNC for a path computati= on in diversity from the previous path (possibly using the XRO mechanism) i= n order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can g= uarantee that; if no diverse path is found, we should try and manage the of= fending domain as the offending links in bhandari algorithm, chasing them o= ut from the solution).

5)   = ;   Computing a connectivity matrix on = a known (fully visible) topology is simple (as you said, could be done in a= single run) and also could be easily distributed between several path comp= uters to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be asso= ciated with one or more intra-node paths and provide to the MDSC various me= trics, like delay, cost, max. bandwidth, SRLGs)  It could be done in b= ackground when the path computers have nothing else to do (which is most of the time).

[FL] As said above,= the point here is that you don’t know the request parameters yet. An= d I do believe that in order to compute matrices suitable for the purpose, = either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity = of the problem to be solved.

 

Cheers,<= /span>

Igor

 

 

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 12:39 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

it seems to me that= the number of path computations should grow polinomially and not esponenti= ally with the number of domains and inter-domain links.

Here it is some con= sideration about that, and correct me if I am wrong.

 

Assume that the dom= ains are abstracted on MDSC as nodes, and assume we have a network of domai= ns only (adding “normal” nodes doesn’t affect the proposi= tion).

The idea is to run = Dijkstra on the MDSC abstract topology and trigger a path computation to th= e relevant PNCs as soon as a node representing a domain is found.

The abstract topolo= gy on MDSC will be a network with a number of nodes equal to the number of = domains and a number of links equal to the inter-domain links.

If we run the Dijks= tra algorithm to compute an end-to-end path on that topology the complexity= of it, which is related to the number of relaxation steps, is polinomial a= s you know. So the number of requests going down to the different PNCs must be polinomial as well.

Take also into acco= unt that Dijkstra is normally used to find the shortest path between two en= d-points in the network, but actually the algorithm is capable to find in a= single run (with the same complexity) the shortest path between a given node and any other node in the network. =

This should suggest= to make the best of this property and foresee in the protocol/model a sing= le request capable to return all the suitable paths from a given source to = all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). = In that way we should have one request per domain, to feed the relaxation s= teps between one ingress point of the domain and all the points connected t= o inter-domain links.

In the standard Dij= kstra one domain/node will be traversed (that is will generate relaxation s= teps to its links) at most once, as any other relaxation step passing throu= gh it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (w= hen the best path is the Hamiltonian path, the one traversing all the nodes= once) we’ll have a number of requests to the PNCs equal to the numbe= r of PNCs (one per PNC).

If instead we use n= ormal point-to point path computations, we should ask L-1 path computations= to each PNC, where L is the number of inter-domain links connected to the = domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

 

Regarding path comp= utation for paths in diversity, it should be still polinomial, as if you us= e for example the Bhandari algorithm to do so, you see that it’s actu= ally a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link wei= ghts). The first instance is a traditional path computation, while the seco= nd one is a modified version allowing negative costs on the edges, but stil= l polinomial. So once again the result should still be polinomial and the number of request shouldn’= t diverge.

 

Now, something abou= t the other approach mentioned in your e-mail, which implies computing all = the possible paths inside any domain in advance.

It is polinomial as= well, but with a higher number of path computations, as for any domain in = the network you have to compute L(L-1)/2 paths.

Of course, you̵= 7;ll say, this happens once and not at any path computation. That’s t= rue, but :

 

-   =        As soon as network get increasingly= used, the computed paths could become invalid. So you need to recompute th= em as needed and advertise all the changes

-   =        You perform a path computation R= 20;in advance”, that is before the actual request is done, and theref= ore PNC cannot be aware of the future requirements in term of bandwidth, ob= jective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of = course it’s not conceivable to compute those paths for all the possib= le combinations of the request parameters (this should grow esponentially!)=

 

Something that I wo= uld like to investigate further is the possibility for the MDSC to store th= e results of the path computations  returned by the PNCs along the tim= e and reuse them as applicable during the future path computations.

At the end of the d= ay this is something similar to the connectivity matrix concept, with two m= ain differences:

 

-   =        It’s built incrementally from= real requests and therefore with real parameters

-   =        It’s build by MDSC and mainta= ined inside MDSC, no need for notifications.

 

BR

Francesco

 

 

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Franseco,

 

We have discussed with= Italo the applicability of path computation service for multi-domain scena= rios and agreed (at least my impression) that this realistically works for = no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request fr= om PNCs grows exponentially with the number of domains and the number of in= ter-domain links. The things get worse when MDSC needs to compute e2e diver= se (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to pl= ace more than one e2e services with global optimization criteria in mind. T= hings get still much worse when MDSCs are linked into a hierarchy, and path= computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs a= nd PNCs

 

Please, see further in= line.

 

Igor=

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 5:02 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - = DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

I assumed in fact a= multi-domain ACTN scenario, as stated in the abstract of draft-busibel-tea= s-yang-path-computation-00, where I believe we have the most interesting us= e cases for path computation services. I believe we should consider all of these, as the same model shall be used= both for single and multi-domain scenarios.

Regarding path comp= utation on MDSC: in an ideal world MDSC could read topology from PNCs and c= ompute itself end-to-end paths but there are cases where this could be eith= er impossible or not convenient:

 

-   =        For some reasons (e.g. security/pri= vacy) the PNC doesn’t export full topology information to the MDSC, s= o that such information is not suitable for a path computation on MDSC=

 

IB>> No one expects PNC to export full topology info= rmation, it is likely to contain proprietary information and hence useless = for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with = detailed connectivity matrix;

 

-   =        For some reasons (e.g. scalability)= MDSC doesn’t want to get full topology information from the subtende= d domains

IB>> See comment above;

 

-   =        For some reasons (e.g. lack of know= ledge about the internal model of the equipment managed by the PNC : especi= ally in WDM networks) MDSC is not capable to cumpute reliably a feasible pa= th in a domain

IB>> This is not a concern: all the necessary comput= ations are done already by PNCs when exposing and updating the abstract TE = topologies.

 

IB>> Furthermore, according to ACTN MDSCs could be l= inked in a hierarchy. This means that for a top level MDSC e2e path computa= tion, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs acr= oss all hierarchy levels. In contrast, multi-level abstraction of TE topolo= gies is not a problem

 

BR

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller = <Dieter.Beller@nokia.com&= gt;
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,

 

Please, note that t= he context of this discussion is single domain. In my opinion MDSC  sh= ould not rely on the Path computation services (stateless or stateful) prov= ided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies cat= ered by the subordinate PNCs. And BTW said abstract TE topologies should be= kept up-to-date by the PNCs (i.e. with updates, stateful).

 

Igor

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Well, I know implem= entations of both the “flavours”, and I would say that the most= complex are the pre-planned ones.

So, it could be an = interesting use case, but we need to be aware that it comes with a price.

Take also into acco= unt that the path recomputation inside the provider could not necessarily o= ffer an optimal solution end-to-end, and the client (the MDSC actually) sho= uld anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its = constraints (e.g. if there is a latency constraint on the end-to-end path, = it may happen that the recomputed segment has a longer latency that leads t= o exceeding the constraint on the end to end path : but the provider only sees that single segment of the en= d-to-end path and taking into account the end-to-end constraints could be r= eally difficult).

 

Regarding the TE-li= nk, I was actually interested on what the provider (that is the PNC) advert= ises to the client (MDSC) when reservation occurs. It cannot advertise A= 217;B’ as it knows only A and B, but advertising AB seems to me not correct.

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

Please, see in-line.

 

Igor=

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.i= etf.org/html/draft-busibel-teas-yang-path-computation-00

 

Igor,

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

   &= nbsp;   FL>> Probably the same in case the provider notifie= s “Hey, I have no longer anything for you”.

 

IB>> But this would = be a bit too late, wouldn’t it? Wouldn’t it be better if the cl= ient has learnt about the previously returned path unfeasibility ahead of t= ime, so that it could re-plan it’s failure recovery scheme?

 

If there is no (mor= e) path, there is no path. The client could only try and crankback looking = for some different path or report an alarm.

 

IB>> Relying on cran= kbaks in an unpredictable way is not exactly a good solution, right?

 

The scenario that s= eems more applicable to your proposal is a pre-planned restoration mechanis= m where we have a worker path in-service and a protection path just compute= d (but not reserving network resources, in order to share them among several protection paths), in a multi-domain = network. In that case, reserving te-tunnels like you suggest, could give an= advantage, as the end-to-end cranckback could occur when the notification = with “no-path” is triggered by the provider (that means the protection path or some of its segments is no lon= ger valid) and not when the path deployment is triggered by the client (tha= t means the worker path is gone and we need the protection immediately). Is= this the case you are considering ?

 

IB>> Exactly. All th= e scenarios you can think of where you don’t know when and where a pr= oblem may happen and you want to maintain flexibility and share the network= resources to protect as much as you can

 

In other cases, as = when used during an end-to-end path computation with immediate deployment t= o reduce the possibility of conflicts among concurrent procedures, it seems= to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, wh= ich could well avoid conflicts.

 

IB>> All cases where= the provider wants to expose a potentiality without committing resources t= o cover for the client multiple use cases and provide at the same time some= degree (albeit not perfect) predictability.

 

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

FL>> This means that the provider just sends the reply to th= e path computation request and doesn’t advertise any new TE link to t= he client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

 

IB>> Overlay TE topology manager advertises a TE link that is suppo= rted not by a provisioned in a server layer TE tunnel (connection), rather,= by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links ma= pped onto the same network resources 

 

Francesco

 

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Fatai Zhang <zhangfatai@huawei.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Francesco,<= /span>

 

1)   = ;   IMHO simplicity pays back. Instead = than maintaining all these states, notifying clients all the times somethin= g changes, and repeating path-computation as needed, isn’t better for= a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment= ?

IB>> What happens it the provider at this moment says: ̶= 0; No, I have nothing for you” ?  What if the path was relied up= on by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

 <= /o:p>

 <= /o:p>

2)   = ;   Regarding the abstract link in the = overlay topology, I still can’t see what the provider will advertise.= If it’s a new link representing the forwarding adjacency between A&#= 8217; and B’, how it will be represented by the provider ?

 

IB>> According to the TE topology model abstract TE link A̵= 7;B’ points to the underlay (provider) TE topology where the path is = computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. l= ink advertising potentiality in the provider network). In either case TE li= nk’s attributes (e.g. available bandwidth, SRLGs) are defined by the = path.

 

 

Igor

 

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.co= m]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.or= g; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Igor,

IMHO simplicity pay= s back. Instead than maintaining all these states, notifying clients all th= e times something changes, and repeating path-computation as needed, isn= 217;t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at= that moment ?

Regarding the abstr= act link in the overlay topology, I still can’t see what the provider= will advertise. If it’s a new link representing the forwarding adjac= ency between A’ and B’, how it will be represented by the provider ?

 

BR

Francesco

 

From:= Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <= zhangfatai@huawei.com>; Francesco L= azzeri <frances= co.lazzeri@ericsson.com>; Dieter Beller <Dieter= .Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; pce@ietf.org; TEAS WG (teas@ietf.o= rg) <teas@ietf.org>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-= busibel-teas-yang-path-computation-00<= o:p>

 

Hi Francesco,

 <= /o:p>

Please, see in-line= .

 <= /o:p>

Cheers,=

Igor

 <= /o:p>

The point here is f= or how long the provider should keep the computed path and its request para= meters

 <= /o:p>

IB>> As far as t= he provider is concerned, the requested path and its parameters is a TE tun= nel (albeit computed but not provisioned). So it keeps the state until the = client removes the TE tunnel.

 <= /o:p>

(in fact if we want= to have a possibly better path, at any change inside provider topology, re= source status and usage, the provider should check if the computed path is = still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.=

 <= /o:p>

IB>> For example= , if provider is to ensure the path’s feasibility, all it needs is to= detect a change in a TE link the path is going through and make sure that = the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and perfo= rmed in a background thread.

 <= /o:p>

Furthermore, I can&= #8217;t see how the provider could export the abstract TE-link, as this is = inside the client topology;

IB>> The abstrac= t link is a part of the abstract topology “cooked” (customized)= for the client, which is supported by the computed path in the underlay to= pology, which is the provider’s topology.

 <= /o:p>

in fact, if the cli= ent is asking for a path between A and B (A and B inside provider topology)= , having A’ (in client topology) connected to A and B’ (in clie= nt topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B&= #8217;, that is in the client topology; therefore the client should be in c= harge of managing it, as the provider is not aware of A’ and B’= .

 <= /o:p>

IB>> This is cor= rect, but note that the two topologies (underlay and overlay) according to = the TE topology model have independent and unrelated name spaces for node, = link and SRLG IDs. So it is perfectly Ok.

 

IB>> Also note t= hat according  to TE topology model  one important attribute of a= TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and c= onstantly monitored (but not reserved) over the TE topology the node encaps= ulates.  This means that stateful unreserved paths play already a very imp= ortant part in supporting TE topologies with asymmetrical blocking abstract= TE nodes.

 

Igor

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

BR

Francesco

 <= /o:p>

From:= CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org= >; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>= ; TEAS WG (teas@ietf.org) <tea= s@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/htm= l/draft-busibel-teas-yang-path-computation-00

 

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:windowtext">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org= /html/draft-busibel-teas-yang-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org<= /span>); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/d= raft-busibel-teas-yang-path-computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (cca= mp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= /span>mailto:ccamp-bo= unces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.or= g/html/draft-busibel-teas-yang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: RE: http://tools.iet= f.org/html/draft-busibel-teas-yang-path-computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org= ; TEAS WG (teas@ietf.org); mpls@ietf.o= rg
Subject: [ALU] [mpls]http://t= ools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [T= E-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [T= E-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

 

 

 

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F17531dfweml501mbx_-- From nobody Thu Nov 17 00:19:00 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA9129658 for ; Thu, 17 Nov 2016 00:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 SLcTSGD7FwJL for ; Thu, 17 Nov 2016 00:18:55 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0093.outbound.protection.outlook.com [104.47.41.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3B91296E9 for ; Thu, 17 Nov 2016 00:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zEl42TrFto50WrUhEoe/wLXlIV1CZe4VfseQDOnmkys=; b=kxmaQMVWUuUdHOunOx2lN/RTufFMed85+YAacZtyhU6fD2+ykeLrE28skhcAsvkVm2mXkkZIsSuj2qhuu0rcecOee+uz1ydvY6n4qL7djw7OpdRjgwboCF7biaczHeIxzN0m+tM0+nTIA9e//hXyAre0dBJJNicnDYclB7d9/Gg= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Thu, 17 Nov 2016 08:18:27 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0734.004; Thu, 17 Nov 2016 08:18:27 +0000 From: Gert Grammel To: CCAMP Thread-Topic: ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVQ== Date: Thu, 17 Nov 2016 08:18:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.188.14] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 7:GkeYGG+56U9hxtb1bN2yGRtb3WYT6XhtsUDN6BItI/MJ2djPB84LgCIZQl92Xphy5ZuyIdFZis3exlN0ksVgtnmffuNCVh3YcaUJWD2p9BslY+7VsBu+FTtxePKNXyfoN8WMfAi+BfIQ8bsNkD9kdQ2hqBkKP0y5O26nq47i4gvpk5mf/rk5zJZqTzZgV+K5piGEATKR+Hbh/lH4OL49cAV0GOZ63FgoOaVW9u2qAVoLw+06BC5DGqjhrNXnhE+/z+6+VrhP+e5xhhhFR/humIEn4YotWqy5j+fa7mrzkVnGF3C3Yl4KsHbSN1Q2EaC7QCwWQz5+YX8u1iRL+51IZGLAQmx8TwD7CrjCOMQRvHk= x-ms-office365-filtering-correlation-id: 61e03e0b-5c7d-4e12-7c17-08d40ec24eeb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1612; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324)(6041223)(6072148); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(57704003)(37854004)(189002)(106116001)(97736004)(92566002)(77096005)(106356001)(8936002)(4001350100001)(105586002)(36756003)(99286002)(50986999)(54356999)(2900100001)(66066001)(189998001)(3280700002)(101416001)(107886002)(6916009)(8676002)(81156014)(7846002)(81166006)(7736002)(450100001)(2906002)(122556002)(3660700001)(33656002)(3846002)(68736007)(7906003)(6506003)(102836003)(86362001)(83716003)(87936001)(6116002)(5660300001)(5890100001)(6512003)(110136003)(606004)(83506001)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E84D89BEE1194123A7ABD4A1DA3AA71Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 08:18:27.5331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612 Archived-At: Subject: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:18:58 -0000 --_000_E84D89BEE1194123A7ABD4A1DA3AA71Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBZnRlciB0aGUgY2NhbXAgbWVldGluZyBEYW5pZWxlIHN1Z2dlc3RlZCB0byBicmllZmx5IHN1 bSB1cCB0aGUgaXNzdWVzIG9uIG1vcmUgZGV0YWlsIG9uIHRoZSBsaXN0IHRvIHRyaWdnZXIgYSBk aXNjdXNzaW9uLiBBcyBGYXRhaSBtZW50aW9uZWQsIE9EVTQgaXMgaW5jb21wYXRpYmxlIHdpdGgg T0RVQzEgd2hpY2ggbG9va2VkIHN1cnByaXNpbmcgdG8gbW9zdCBvZiB1cy4gQ29uc3VsdGluZyBo dHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2 LTEwLTA1LWl0dS10LXNnLTE1LW1wbHMtY2NhbXAtcGNlLWxzLW9uLXNnMTUtb3RudC1zdGFuZGFy ZGl6YXRpb24td29yay1wbGFuLWF0dGFjaG1lbnQtMy5wZGYgZGlkbuKAmXQgcHJvdmlkZSBtYW55 IG1vcmUgZGV0YWlsczoNClRoZSA1dGggZWRpdGlvbiBvZiBSZWNvbW1lbmRhdGlvbiBJVFUtVCBH LjcwOS9ZLjEzMzEg4oCcSW50ZXJmYWNlcyBmb3IgdGhlIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdv cmvigJ0sDQpwdWJsaXNoZWQgaW4gSnVuZSAyMDE2LCBlbmFibGVzIG9wdGljYWwgdHJhbnNwb3J0 IGF0IHJhdGVzIGhpZ2hlciB0aGFuIDEwMCBHYml0L3MgKHRoZSBjb2RlIG5hbWUgaXMgYmV5b25k IDEwMCBHYml0L3Mgb3IgQjEwMEcpLg0KRGV0YWlscyBvZiBHLjcwOSBhcmUgZ2l2ZW4gaW4gUGFy dCAxIG9mIHRoaXMgZG9jdW1lbnQuDQpTbyBzb21lIGNsYXJpdHkgYWJvdXQgd2hldGhlciAxMDBH IGlzIGFjdHVhbGx5IGNvbnNpZGVyZWQg4oCcYmV5b25kIDEwMEfigJ0gaXMgYXBwcmVjaWF0ZWQu IElmIGluZGVlZCBPRFU0IGlzIGluY29tcGF0aWJsZSB3aXRoIE9EVUMxLCBpdCB3b3VsZCBiZSBn cmVhdCB0byBnZXQgc29tZSBjb2xvciBhYm91dCB3aHkgYm90aCBvcHRpb25zIGFyZSBuZWVkZWQg YW5kIHdoYXQgYXJlIHRoZWlyIHBhcnRpY3VsYXJpdGllcy4gU3VjaCB1bmRlcnN0YW5kaW5nIHdv dWxkIHJlYWxseSBoZWxwIHRvIGdldCB0aGUgY29udHJvbCBwbGFuZSB3b3JrIHJpZ2h0Lg0KDQpC YXNlZCBvbiBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgKE9EVTQgYW5kIE9EVUMxIGFyZSBpbmNv bXBhdGlibGUgdmVyc2lvbnMgb2YgT0RVKSBoZXJlIGEgZmV3IHRlY2huaWNhbCBxdWVzdGlvbnMg dGhhdCB3b3VsZCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiBHTVBMUzoNCg0KDQoxLiAgICAgICBP RFU0IGFuZCBPRFVDMSBhcmUgYm90aCAxMDBHLCBzbyB3aGF0IHdpbGwgYmUgdGhlIGJhbmR3aWR0 aCB0byBiZSBlbmNvZGVkPyBTZWUgUkZDMzQ3MSAgMy4xLjI8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzM0NzEjc2VjdGlvbi0zLjEuMj4uIEJhbmR3aWR0aCBFbmNvZGluZw0KDQphLiAg ICAgICBTZWVtcyB0byBiZSBhIHNvbHZhYmxlIGlzc3VlDQoNCjIuICAgICAgIEEgdXNlIGNhc2Ug dG8gY29uc2lkZXIgaXM6DQoNCiAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t Kw0KMTAwR0UgLS0tLXwtR01QLU9EVTQtfC1PVFU0LS0tLS0tLS0tLS1PVFU0LXwtT0RVNC1HTVAt T0RVQzEtfC1PVFVDMS0tLS0tLS0tLS1PVFVDMS18LU9EVUMxLUdNUC18LS0tLTEwMEdFDQogICAg ICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0r ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgTkUxICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE5FMiAoPUdXLU5FKSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE5FMw0KDQoNCjMuICBDb25zaWRlcmluZyBORTEgaXMgYW4gZXhpc3RpbmcgR2Vu LTEgZGV2aWNlIChPRFU0IG9ubHkpLCB3aGlsZSBORTIrTkUzIGFyZSBuZXcgR2VuLTIgKE9EVUMr T0RVNCBjYXBhYmxlKSBkZXZpY2VzLiBUaGUgc2VydmljZSBwcm92aWRlZCBpcyBhIDEwMEcgRXRo ZXJuZXQgcDJwIHNlcnZpY2UuDQoNCmEuICBIb3cgaXMgc3VjaCBhIHNlcnZpY2Ugc2lnbmFsZWQ/ IChyZW1hcms6IEEgZ29vZCBzdGFydGluZyBwb2ludCBjb3VsZCBiZSB0aGUgc3RpdGNoaW5nIG1v ZGVsIHVzZWQgaW4gTVBMUykNCg0KICAgICAgICAgICAgICAgICAgICAgICAgaS4gICBPbmUgUlNW UCBzZXNzaW9uIHBlciBzZXJ2aWNlPw0KDQogICAgICAgICAgICAgICAgICAgICAgaWkuICAgT25l IFJTVlAgc2Vzc2lvbiBwZXIgT0RVIChhYnN0cmFjdGluZyBPRFU0L09EVUMxIGRldGFpbHM/KQ0K DQogICAgICAgICAgICAgICAgICAgIGlpaS4gICBUd28gc2VwYXJhdGUgc2lnbmFsaW5nIHNlc3Np b25zOiBPRFU0IGFuZCBPRFVDMSBlYWNoDQoNCiAgICAgICAgICAgICAgICAgICAgICBpdi4gICBU aHJlZSBzZXNzaW9uczogb25lIGZvciB0aGUgMTAwR0UgYW5kIHR3byBzZXJ2ZXIgbGF5ZXIgc2Vz c2lvbnMgb25lIGZvciBlYWNoIE9EVT8NCg0KYi4gIEhvdyBkb2VzIE9EVS1PQU0gd29yaz8NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgaS4gICBJcyB0aGVyZSBhIFRDTSBzZXNzaW9uIGF2YWls YWJsZSBmb3IgdGhlIHNlcnZpY2UgaS5lLiBiZXR3ZWVuIGluZ3Jlc3Mgb24gTkUxIGFuZCBlZ3Jl c3Mgb24gTkUzPw0KDQogICAgICAgICAgICAgICAgICAgICAgaWkuICAgSG93IHdvdWxkIG90aGVy IE9EVSBPQU0gcHJvcGFnYXRlIGluIHRoZSBkYXRhIHBsYW5lPyBpLmUuIEFJUywgUkRJLCDigKYN Cg0KICAgICAgICAgICAgICAgICAgICBpaWkuICAgSWYgT0FNIGRvZXNu4oCZdCBwYXNzIG9uIHRo ZSBkYXRlLXBsYW5lIGlzIHRoZXJlIGEgbmVlZCB0byBzdWJzdGl0dXRlIGJ5IGNvbnRyb2wgcGxh bmU/IGkuZS4gZ2VuZXJhdGUgc29tZXRoaW5nIGxpa2UgYW4gT0RVLUFJUyBpbiBHTVBMUyBvbmNl IG9uZSBvZiB0aGUgT0RVIHNlZ21lbnRzIGlzIGN1dCB0byBpbmZvcm0gdGhlIG90aGVyIE9EVSBz ZWdtZW50Pw0KDQpjLiAgSG93IHdvdWxkIHRoZSB3aG9sZSB0aGluZyB3b3JrIGluIGNhc2Ugb2Yg T0RVZmxleCBpcyB1c2VkPyAobnVtYmVyIG9mIHNlc3Npb25zLCBlbmNvZGluZyBldGMpDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgIGkuICAgV291bGQgaXQgbWF0dGVyIGlmIGFuIE9EVWZsZXgg aXMgcHV0IGluIGFuIE9UVTQgdnMgT1RVQzEgb3IgaXMgaXQgdGhlIHNhbWU/DQoNCiAgICAgICAg ICAgICAgICAgICAgICBpaS4gICBXb3VsZCBhbGwgdGhlIE9EVWZsZXgtT0FNIHN0dWZmIHBhc3Mg dHJhbnNwYXJlbnRseSB0aHJvdWdoIE5FMj8NCg0KZC4gIElmIExPIE9EVXMgc3VjaCBhcyA4Kk9E VTIgYXJlIHRyYW5zcG9ydGVkIG92ZXIgYW4gT0RVNC9PRFVDMSwgYXJlIHRob3NlIE9EVTIgc3Rp bGwgdGhlIHNhbWUgaS5lLiBwYXNzIHRyYW5zcGFyZW50bHkgdGhyb3VnaCB0aGUgR1ctTkUgb3Ig aXMgdGhlcmUgYW55dGhpbmcgdG8gY29uc2lkZXIgb24gT0RVMiBsZXZlbCB0b28/DQoNCmUuICBE byB3ZSBuZWVkIHRvIGNvbnNpZGVyIHJlLXByb2dyYW1tYWJsZSBpbnRlcmZhY2VzIHRoYXQgY2Fu IGJlIHNldCB0byBPRFU0L09UVTQgWE9SIE9EVUMxL09UVUMxIHByaW9yIG9yIGR1cmluZyB0aGUg c2lnbmFsaW5nIHBhc3NlcyBhbG9uZz8NCg0KNC4gICAgICAgRm9yIHdhdmVsZW5ndGggc3dpdGNo aW5nIGEgc2ltaWxhciBjb25jZXJuIGV4aXN0cyByZWxhdGVkIHRvIE9UVUMxIHZzIE9UVTQNCg0K YS4gICAgICAgV2hhdCB3b3VsZCBiZSB0aGUgQlcgZW5jb2RpbmcgZm9yIGVhY2g/DQoNCmIuICAg ICAgIEEgcmVnZW5lcmF0b3IgZGV2aWNlIG1heSByZWdlbmVyYXRlIGFuIE9EVTQvT1RVNCBvbiBp bmdyZXNzIHRvIE9EVUMxL09UVUMxIG9uIGVncmVzcy4gSG93IHdvdWxkIHRoYXQgYmUgc2lnbmFs ZWQ/IChzYW1lIGRpc2N1c3Npb24gYXMgZm9yIE9EVSkNCg0KYy4gICAgICAgT1RVQ24gbWF5IGNv bnNpc3Qgb2Ygc2V2ZXJhbCBjYXJyaWVycyAoaS5lLiB3YXZlbGVuZ3RoLCB0aGluayBpdCBpcyBj YWxsZWQgT1RTaSk/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgSWYgc28sIGFyZSB0aGUgYXZhaWxhYmxlIG1l Y2hhbmlzbXMgaW4gR01QTFMgc3VmZmljaWVudCB0byBjby1yb3V0ZSB0aGVzZT8NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlp LiAgICAgIFdvdWxkIGl0IHRoZW4gYmUgb25lIFJTVlAgc2Vzc2lvbiBwZXIgY2FycmllciBvciBv bmUgcGVyIE9UVUNuPw0KDQpUbyBzdW0gdXA6DQoNCi0gICAgICAgICAgS2VlcGluZyBHTVBMUyBp biBzeW5jIHdpdGggYXZhaWxhYmxlIGRhdGFwbGFuZSBzdGFuZGFyZHMgaXMgYSBnb29kIHdvcmtp bmcgcHJhY3RpY2UgdGhhdCBzaG91bGQgY29udGludWUNCg0KLSAgICAgICAgICBBdCB0aGlzIHBv aW50LCBpdCBkb2VzbuKAmXQgYXBwZWFyIHRoYXQgdGhlIGltcGxpY2F0aW9ucyBvZiBpbnRyb2R1 Y2luZyBPRFVDMSBpbnRvIEdNUExTIGFyZSBzdWZmaWNpZW50bHkgY2xlYXINCg0KLSAgICAgICAg ICBJdCB3b3VsZCBiZSBwcnVkZW50IHRvIGRlbGF5IHRoZSBkZWNpc2lvbiB3aGV0aGVyIGEgZnJh bWV3b3JrIGRvY3VtZW50IGlzIHJlcXVpcmVkIG9uY2UgdGVjaG5pY2FsIGNsYXJpZmljYXRpb24g aXMgYXZhaWxhYmxlLg0KDQpCZXN0DQoNCkdlcnQNCg== --_000_E84D89BEE1194123A7ABD4A1DA3AA71Fjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KaDQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCBDaGFyIjsNCgltYXJn aW4tdG9wOjIuMHB0Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglwYWdlLWJyZWFrLWFm dGVyOmF2b2lkOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGln aHQiOw0KCWNvbG9yOiMyRjU0OTY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 aXRhbGljO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhlYWRpbmc0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIExpZ2h0IjsNCgljb2xvcjojMkY1NDk2Ow0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnNwYW4u bXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIi Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJp O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46 NzAuODVwdCA3MC44NXB0IDU2LjdwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NjAzOTk4MDI0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo0NDY3NTExMjggLTU4OTI4NzQwMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzQ4MDM5 NzQ1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODEw Njc4MjE4IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjE5NTM3ODM5Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjU0ODgxNzE0OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpA bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BZnRlciB0aGUgY2NhbXAgbWVldGlu ZyBEYW5pZWxlIHN1Z2dlc3RlZCB0byBicmllZmx5IHN1bSB1cCB0aGUgaXNzdWVzIG9uIG1vcmUg ZGV0YWlsIG9uIHRoZSBsaXN0IHRvIHRyaWdnZXIgYSBkaXNjdXNzaW9uLiBBcyBGYXRhaSBtZW50 aW9uZWQsIE9EVTQgaXMgaW5jb21wYXRpYmxlIHdpdGggT0RVQzEgd2hpY2ggbG9va2VkIHN1cnBy aXNpbmcgdG8gbW9zdA0KIG9mIHVzLiBDb25zdWx0aW5nIDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTYtMTAtMDUtaXR1LXQt c2ctMTUtbXBscy1jY2FtcC1wY2UtbHMtb24tc2cxNS1vdG50LXN0YW5kYXJkaXphdGlvbi13b3Jr LXBsYW4tYXR0YWNobWVudC0zLnBkZiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9j dW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTEwLTA1LWl0dS10LXNnLTE1LW1wbHMtY2NhbXAt cGNlLWxzLW9uLXNnMTUtb3RudC1zdGFuZGFyZGl6YXRpb24td29yay1wbGFuLWF0dGFjaG1lbnQt My5wZGY8L2E+IGRpZG7igJl0IHByb3ZpZGUgbWFueSBtb3JlIGRldGFpbHM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgNXRoIGVkaXRpb24gb2YgUmVjb21t ZW5kYXRpb24gSVRVLVQgRy43MDkvWS4xMzMxIOKAnEludGVyZmFjZXMgZm9yIHRoZSBPcHRpY2Fs IFRyYW5zcG9ydCBOZXR3b3Jr4oCdLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+cHVibGlzaGVkIGluIEp1bmUgMjAxNiwgZW5hYmxlcyBvcHRpY2FsIHRy YW5zcG9ydCBhdCByYXRlcyBoaWdoZXIgdGhhbiAxMDAgR2JpdC9zICh0aGUgY29kZSBuYW1lIGlz IGJleW9uZCAxMDAgR2JpdC9zIG9yIEIxMDBHKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkRldGFpbHMgb2YgRy43MDkgYXJlIGdpdmVuIGluIFBhcnQgMSBvZiB0 aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TbyBzb21lIGNsYXJpdHkgYWJvdXQgd2hl dGhlciAxMDBHIGlzIGFjdHVhbGx5IGNvbnNpZGVyZWQg4oCcYmV5b25kIDEwMEfigJ0gaXMgYXBw cmVjaWF0ZWQuIElmIGluZGVlZCBPRFU0IGlzIGluY29tcGF0aWJsZSB3aXRoIE9EVUMxLCBpdCB3 b3VsZCBiZSBncmVhdCB0byBnZXQgc29tZSBjb2xvciBhYm91dCB3aHkgYm90aCBvcHRpb25zIGFy ZSBuZWVkZWQgYW5kDQogd2hhdCBhcmUgdGhlaXIgcGFydGljdWxhcml0aWVzLiBTdWNoIHVuZGVy c3RhbmRpbmcgd291bGQgcmVhbGx5IGhlbHAgdG8gZ2V0IHRoZSBjb250cm9sIHBsYW5lIHdvcmsg cmlnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ QmFzZWQgb24gbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nIChPRFU0IGFuZCBPRFVDMSBhcmUgaW5j b21wYXRpYmxlIHZlcnNpb25zIG9mIE9EVSkgaGVyZSBhIGZldyB0ZWNobmljYWwgcXVlc3Rpb25z IHRoYXQgd291bGQgbmVlZCB0byBiZSBhZGRyZXNzZWQgaW4gR01QTFM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+T0RVNCBhbmQgT0RVQzEgYXJlIGJvdGggMTAwRywgc28gd2hhdCB3aWxs IGJlIHRoZSBiYW5kd2lkdGggdG8gYmUgZW5jb2RlZD8gU2VlIFJGQzM0NzEgJm5ic3A7PGEgbmFt ZT0ic2VjdGlvbi0zLjEuMiI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMzNDcxI3NlY3Rpb24tMy4xLjIiPjxiPjMuMS4yPC9iPjwvYT48Yj4uDQogQmFuZHdpZHRo IEVuY29kaW5nPG86cD48L286cD48L2I+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwyIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2I+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWVtcyB0byBiZSBhIHNvbHZh YmxlIGlzc3VlPGI+PG86cD48L286cD48L2I+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+QSB1c2UgY2FzZSB0byBjb25zaWRlciBpczo8Yj48bzpwPjwv bzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTAwR0UgLS0tLXwtR01Q LU9EVTQtfC1PVFU0LS0tLS0tLS0tLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLS0t LS0tLS1PVFVDMS18LU9EVUMxLUdNUC18LS0tLTEwMEdFPG86cD48L286cD48L3NwYW4+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0Mzsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0t LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05F MSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUyICg9R1ctTkUp Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE5FMzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25zaWRlcmluZyBORTEgaXMgYW4gZXhpc3Rpbmcg R2VuLTEgZGV2aWNlIChPRFU0IG9ubHkpLCB3aGlsZSBORTImIzQzO05FMyBhcmUgbmV3IEdlbi0y IChPRFVDJiM0MztPRFU0IGNhcGFibGUpIGRldmljZXMuIFRoZSBzZXJ2aWNlIHByb3ZpZGVkIGlz IGEgMTAwRyBFdGhlcm5ldCBwMnAgc2VydmljZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMiBsZm8xIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkhvdyBpcyBzdWNoIGEgc2VydmljZSBzaWduYWxlZD8gKHJlbWFyazogQSBn b29kIHN0YXJ0aW5nIHBvaW50IGNvdWxkIGJlIHRoZSBzdGl0Y2hpbmcgbW9kZWwgdXNlZCBpbiBN UExTKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotMS41 aW47bXNvLXRleHQtaW5kZW50LWFsdDotOS4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwzIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+aS48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk9uZSBSU1ZQ IHNlc3Npb24gcGVyIHNlcnZpY2U/DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41 aW47dGV4dC1pbmRlbnQ6LTEuNWluO21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0 OmwyIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlpLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ T25lIFJTVlAgc2Vzc2lvbiBwZXIgT0RVIChhYnN0cmFjdGluZyBPRFU0L09EVUMxIGRldGFpbHM/ KSAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6 LTEuNWluO21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0OmwyIGxldmVsMyBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPmlpaS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlR3byBzZXBhcmF0ZSBzaWduYWxpbmcgc2Vz c2lvbnM6IE9EVTQgYW5kIE9EVUMxIGVhY2g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS41aW47dGV4dC1pbmRlbnQ6LTEuNWluO21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1s aXN0OmwyIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPml2LjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VGhyZWUgc2Vzc2lvbnM6IG9uZSBmb3IgdGhlIDEwMEdFIGFuZCB0d28gc2VydmVyIGxheWVy IHNlc3Npb25zIG9uZSBmb3IgZWFjaCBPRFU/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMSI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5Ib3cgZG9lcyBPRFUtT0FNIHdvcms/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0xLjVpbjttc28tdGV4dC1pbmRlbnQtYWx0Oi05LjBw dDttc28tbGlzdDpsMiBsZXZlbDMgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj5pLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SXMgdGhlcmUgYSBUQ00gc2Vzc2lvbiBhdmFpbGFibGUgZm9y IHRoZSBzZXJ2aWNlIGkuZS4gYmV0d2VlbiBpbmdyZXNzIG9uIE5FMSBhbmQgZWdyZXNzIG9uIE5F Mz88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LTEuNWlu O21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0OmwyIGxldmVsMyBsZm8xIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPmlpLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SG93IHdvdWxkIG90aGVyIE9EVSBP QU0gcHJvcGFnYXRlIGluIHRoZSBkYXRhIHBsYW5lPyBpLmUuIEFJUywgUkRJLCDigKY8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LTEuNWluO21zby10ZXh0 LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0OmwyIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlp aS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPklmIE9BTSBkb2VzbuKAmXQgcGFzcyBvbiB0aGUgZGF0ZS1wbGFuZSBp cyB0aGVyZSBhIG5lZWQgdG8gc3Vic3RpdHV0ZSBieSBjb250cm9sIHBsYW5lPyBpLmUuIGdlbmVy YXRlIHNvbWV0aGluZyBsaWtlIGFuIE9EVS1BSVMgaW4gR01QTFMgb25jZQ0KIG9uZSBvZiB0aGUg T0RVIHNlZ21lbnRzIGlzIGN1dCB0byBpbmZvcm0gdGhlIG90aGVyIE9EVSBzZWdtZW50Pzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDIgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SG93IHdvdWxkIHRoZSB3aG9sZSB0 aGluZyB3b3JrIGluIGNhc2Ugb2YgT0RVZmxleCBpcyB1c2VkPyAobnVtYmVyIG9mIHNlc3Npb25z LCBlbmNvZGluZyBldGMpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQt aW5kZW50Oi0xLjVpbjttc28tdGV4dC1pbmRlbnQtYWx0Oi05LjBwdDttc28tbGlzdDpsMiBsZXZl bDMgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5pLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+V291bGQgaXQgbWF0dGVyIGlmIGFuIE9EVWZsZXggaXMgcHV0IGluIGFuIE9UVTQgdnMgT1RV QzEgb3IgaXMgaXQgdGhlIHNhbWU/DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41 aW47dGV4dC1pbmRlbnQ6LTEuNWluO21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0 OmwyIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlpLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ V291bGQgYWxsIHRoZSBPRFVmbGV4LU9BTSBzdHVmZiBwYXNzIHRyYW5zcGFyZW50bHkgdGhyb3Vn aCBORTI/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ZC48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JZiBMTyBPRFVz IHN1Y2ggYXMgOCpPRFUyIGFyZSB0cmFuc3BvcnRlZCBvdmVyIGFuIE9EVTQvT0RVQzEsIGFyZSB0 aG9zZSBPRFUyIHN0aWxsIHRoZSBzYW1lIGkuZS4gcGFzcyB0cmFuc3BhcmVudGx5IHRocm91Z2gg dGhlIEdXLU5FIG9yIGlzIHRoZXJlIGFueXRoaW5nIHRvIGNvbnNpZGVyIG9uIE9EVTIgbGV2ZWwg dG9vPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmUuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RG8gd2UgbmVlZCB0 byBjb25zaWRlciByZS1wcm9ncmFtbWFibGUgaW50ZXJmYWNlcyB0aGF0IGNhbiBiZSBzZXQgdG8g T0RVNC9PVFU0IFhPUiBPRFVDMS9PVFVDMSBwcmlvciBvciBkdXJpbmcgdGhlIHNpZ25hbGluZyBw YXNzZXMgYWxvbmc/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMiBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9yIHdhdmVsZW5ndGggc3dpdGNoaW5nIGEgc2lt aWxhciBjb25jZXJuIGV4aXN0cyByZWxhdGVkIHRvIE9UVUMxIHZzIE9UVTQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMSI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5XaGF0IHdvdWxkIGJlIHRoZSBCVyBlbmNvZGluZyBmb3IgZWFjaD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMSI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5BIHJlZ2VuZXJhdG9yIGRldmljZSBtYXkgcmVnZW5lcmF0ZSBhbiBPRFU0L09UVTQgb24g aW5ncmVzcyB0byBPRFVDMS9PVFVDMSBvbiBlZ3Jlc3MuIEhvdyB3b3VsZCB0aGF0IGJlIHNpZ25h bGVkPyAoc2FtZSBkaXNjdXNzaW9uIGFzIGZvciBPRFUpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T1RVQ24g bWF5IGNvbnNpc3Qgb2Ygc2V2ZXJhbCBjYXJyaWVycyAoaS5lLiB3YXZlbGVuZ3RoLCB0aGluayBp dCBpcyBjYWxsZWQgT1RTaSk/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0xLjVp bjttc28tdGV4dC1pbmRlbnQtYWx0Oi05LjBwdDttc28tbGlzdDpsMiBsZXZlbDMgbGZvMSI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj5pLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgc28sIGFyZSB0aGUgYXZhaWxh YmxlIG1lY2hhbmlzbXMgaW4gR01QTFMgc3VmZmljaWVudCB0byBjby1yb3V0ZSB0aGVzZT8NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LTEuNWluO21zby10ZXh0LWluZGVudC1hbHQ6 LTkuMHB0O21zby1saXN0OmwyIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlpLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+V291bGQgaXQgdGhlbiBiZSBvbmUgUlNWUCBzZXNzaW9uIHBlciBjYXJyaWVyIG9yIG9uZSBw ZXIgT1RVQ24/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5UbyBzdW0gdXA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+S2VlcGluZyBHTVBMUyBpbiBzeW5jIHdpdGgg YXZhaWxhYmxlIGRhdGFwbGFuZSBzdGFuZGFyZHMgaXMgYSBnb29kIHdvcmtpbmcgcHJhY3RpY2Ug dGhhdCBzaG91bGQgY29udGludWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BdCB0aGlzIHBvaW50LCBpdCBkb2Vz buKAmXQgYXBwZWFyIHRoYXQgdGhlIGltcGxpY2F0aW9ucyBvZiBpbnRyb2R1Y2luZyBPRFVDMSBp bnRvIEdNUExTIGFyZSBzdWZmaWNpZW50bHkgY2xlYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JdCB3b3VsZCBi ZSBwcnVkZW50IHRvIGRlbGF5IHRoZSBkZWNpc2lvbiB3aGV0aGVyIGEgZnJhbWV3b3JrIGRvY3Vt ZW50IGlzIHJlcXVpcmVkIG9uY2UgdGVjaG5pY2FsIGNsYXJpZmljYXRpb24gaXMgYXZhaWxhYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QmVzdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+R2VydDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E84D89BEE1194123A7ABD4A1DA3AA71Fjunipernet_-- From nobody Thu Nov 17 01:20:39 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2951295A0 for ; Thu, 17 Nov 2016 01:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 Sxf-gVUS3p1w for ; Thu, 17 Nov 2016 01:20:35 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCD51296A9 for ; Thu, 17 Nov 2016 01:20:32 -0800 (PST) X-AuditID: c1b4fb30-593ff70000001942-74-582d765c54c8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 9C.9D.06466.C567D285; Thu, 17 Nov 2016 10:20:31 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 17 Nov 2016 10:20:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=foVB8KEBRGfXZPniFyrQ9Bh1H6I58IrQdgadR1hXhmQ=; b=mdazLz6jOYi1AX+ZHWR46zLkbE8ac9THgM6cRDZAljLLbObmyKyBcylMnkN/b2gbWKUQ7zrTXdmC2CrkGtxeLor/fx6P75C4xAVPXvdfCfp95B868JfhCvDedti+PO+RbxImoDl1UmeCKvQjmVofNopQWTadTIwa2E/Zj85yWxI= Received: from AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) by AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Thu, 17 Nov 2016 09:20:27 +0000 Received: from AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::c564:a3aa:7be6:30a6]) by AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::c564:a3aa:7be6:30a6%17]) with mapi id 15.01.0734.007; Thu, 17 Nov 2016 09:20:27 +0000 From: Jonas Ahlberg To: "ccamp@ietf.org" Thread-Topic: Microwave Radio Link - Framework & YANG Data Model Thread-Index: AdJAs71h7FnhEBeJTWarQCBHsP8lsQ== Date: Thu, 17 Nov 2016 09:20:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jonas.ahlberg@ericsson.com; x-originating-ip: [58.120.104.2] x-microsoft-exchange-diagnostics: 1; AM3PR07MB0536; 7:92fzBypNatN3Hdm7rBJFrExLZwYBzJ1GSmZuowX+qx7Ip6kFQBZEQ1xeQD9VUGVungE6NMkmzsA8jUYoBIF6dguV/f4GLCs27azS1Enk6MJ+7ffJBpTM7fqYs0u8+3obRV4np984hiL7ptWNGjKbecO2wBW0+IOC9w4S4oXvjIMW5vUWaxQP3cetlTNM3bfHMtQyw8uFQSybglQw444CiKLNXN/v/B5HuvqefvuexHjdoau0fEgPSHoNbeKjvy9JtltAmrKYHOCu1O4BLe5zTiAghrQEi+JxZHMn3B9HM8i4T3rPl5EUO+Kv7bPt7ifafLxLK9G3ebOjfv2Lz7kor4OWexeLhvKQZYN/S6G7FAQ= x-ms-office365-filtering-correlation-id: 91986926-48e2-4351-4572-08d40ecaf80c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB0536; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6061324)(6041223); SRVR:AM3PR07MB0536; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0536; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(53754006)(189002)(199003)(86362001)(101416001)(3660700001)(2501003)(3280700002)(33656002)(106356001)(189998001)(5250100002)(9686002)(105586002)(107886002)(2351001)(76576001)(68736007)(790700001)(102836003)(6116002)(3846002)(97736004)(5660300001)(66066001)(19609705001)(5640700001)(7736002)(110136003)(5630700001)(6916009)(54356999)(50986999)(7696004)(81156014)(81166006)(1730700003)(7846002)(8936002)(6506003)(74316002)(2900100001)(345774005)(87936001)(92566002)(450100001)(8676002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0536; H:AM3PR07MB0536.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB05363DBEF1303C3B4DCF45FC89B10AM3PR07MB0536eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 09:20:27.2327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0536 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUyM2K7q258mW6Ewa7N0hZP5txgcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq9Ds1kLPttXfNm6jqmB8bl5FyMnh4SAicT1t4/Yuxi5OIQE 1jFKXDt6kgnCOcEocezJBhYQh0Wgl1li8fZOqLLJTBKXv81kg3AeM0q8+H6JEWQYm4CBxJtX 89hAbBEBVYkzNy+CxYUFrCU2dy9mgog7SBx4dZAVwtaT+LDuFzOIzQJUP2/xP7BeXoEYieZn c8B6GQXEJL6fWgPWyywgLnHryXwmiMMFJJbsOc8MYYtKvHz8jxWiPlbi7YtXLBBxBYn1TY8Y QQ6VEFjALDGp6SUrRMJX4uV+iGUg9um3s6HsbIlnkxqhFlhJdEw8zgrRfJlR4vWXk1DNMhI7 X16FmrqDVeLQttlgHUICqRLL17ZCvSwlcfdKJ5QtI/Hizl5WiBfyJd6+g3iZV0BQ4uTMJywT GNVmIfluFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4qTcdCMjvdSi zOTi4vw8vbzUkk2MwIRzcMtvgx2ML587HmIU4GBU4uEtKNGJEGJNLCuuzD3EKMHBrCTC25ap GyHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDY9eDD8tX 3VTn9D6TNC1daAbvv3fNzVVhk+9tcTrB4VL7hG2T6e95P7XuWxyt3bWExT5tf+bGKez881w0 xFeuPzilwEzn1HXVm6vt7Hf8VUu8ONOrPTPmXc0VwX7X2Y1GDRPfX4viTGif+dMxxl9GxnCZ pvXrnMo66/NndQR8GZ9aOeUHuM1oV2Ipzkg01GIuKk4EAAR51Q40AwAA Archived-At: Subject: [CCAMP] Microwave Radio Link - Framework & YANG Data Model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:20:37 -0000 --_000_AM3PR07MB05363DBEF1303C3B4DCF45FC89B10AM3PR07MB0536eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Thank you for the feedback received at the CCAMP session today. The design team has decided to proceed as follows: - No additional work on the framework document until we have recei= ved more comments & feedback from the WG - We will focus on making the model complete, with the ambition to= submit a new revision in December. - Identified open topics to be resolved within two weeks from now - Compilation of a YANG model covering all use cases & requirements after = that - Review and submission of the new revision in December - The model is also planned to be stored in a public GitHub. Link = will be provided. - Working material can be distributed on request. We have also decided to change the weekly meeting time to Thursdays 9:00-10= :00 (CET) Regards JonasA --_000_AM3PR07MB05363DBEF1303C3B4DCF45FC89B10AM3PR07MB0536eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Thank you for the feedback received at the CCAMP ses= sion today.

 

The design team has decided to proceed as follows:

-     &= nbsp;    No additional work on the framework document until = we have received more comments & feedback from the WG

 

-     &= nbsp;    We will focus on making the model complete, with th= e ambition to submit a new revision in December.
-  Identified open topics to be resolved within two weeks from now
-  Compilation of a YANG model covering all use cases & requiremen= ts after that
-  Review and submission of the new revision in December

 

-     &= nbsp;    The model is also planned to be stored in a public = GitHub. Link will be provided.

 

-     &= nbsp;    Working material can be distributed on request.

 

 

We have also decided to change the weekly meeting ti= me to Thursdays 9:00-10:00 (CET)

 

Regards

JonasA

--_000_AM3PR07MB05363DBEF1303C3B4DCF45FC89B10AM3PR07MB0536eurp_-- From nobody Thu Nov 17 01:33:48 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E57C1295EB for ; Thu, 17 Nov 2016 01:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 J1tRPC4OGmlj for ; Thu, 17 Nov 2016 01:33:41 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9A3127058 for ; Thu, 17 Nov 2016 01:33:40 -0800 (PST) X-AuditID: c1b4fb3a-233ff70000005ff3-7b-582d79711a42 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 59.3F.24563.1797D285; Thu, 17 Nov 2016 10:33:39 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 17 Nov 2016 10:33:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gFECa8sqCjaZEx4aiZ2XxRlPlPrtBJrE08oGDo9yIw0=; b=GcOk5whI1wQTrH8XMLKGm5GcaKaO8wGN3N5Q/pe0REbhze9WcZfFA6wgcHfiMCGx4wZxd7/rAhkJeQSWeTt9TeT6h8LS/ybY8aN87ki9NShtYxRC/PehWoS9gllgiu1gFGWvGHgS166NkzqV7WoMBbChZ3QlNqSwpVJu/QzY6cs= Received: from AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) by AM3PR07MB0535.eurprd07.prod.outlook.com (10.141.47.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Thu, 17 Nov 2016 09:33:35 +0000 Received: from AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::c564:a3aa:7be6:30a6]) by AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::c564:a3aa:7be6:30a6%17]) with mapi id 15.01.0734.007; Thu, 17 Nov 2016 09:33:35 +0000 From: Jonas Ahlberg To: 'LUIS MIGUEL CONTRERAS MURILLO' , "'Yemin (Amy'" , "'Marko.Vaupotic@Aviatnet.com'" , "'jefftant.ietf@gmail.com'" , 'Koji Kawada' , "'Ippei Akiyoshi (i-akiyoshi@ah.jp.nec.com) (i-akiyoshi@ah.jp.nec.com)'" , 'Xi Li' , "'Martin Skorupski (External'" , "cjbc@it.uc3m.es" , "Rahman, Akbar" Thread-Topic: MDT meeting - YANG Data Model - November 24, 9:00-10:00 (CET) Thread-Index: AdJAtFnjzyV5lVmxR0qsbY8Utkpm1Q== Date: Thu, 17 Nov 2016 09:33:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jonas.ahlberg@ericsson.com; x-originating-ip: [58.120.104.2] x-microsoft-exchange-diagnostics: 1; AM3PR07MB0535; 7:WVTtbvtknW7HMatg0ZqUabENm0SH1Enwr9z02y9vUeto7qVPOTexJsoIL6Yna1ISswCgGF5l8p6KrNc4dARY+W2LtG9c7o4NTWjmdpYlXTpbNhkoCb0WW+TwNj36vbNORn4f90qcVYK1ZVxcBRx/LFlnq3mmYDa2LEybYU1bvLDQwF8Cb8rSSJxbsIt12+PDFUIkqdpTMCOyIMLdtBeYcvX/sN/V4oUhORm+c//R/HnLUamOpGE7lwuavKVRT8oN775H/5L37he2JAQgdQIfwQtIHBvgK5fBkpExn4RbbugBRT1rbSX8ShQNZ15AlPJf1LYebsbsHvAQ16Q4gdufak7G1wWrBaDjGJ/1f/WXck4= x-ms-office365-filtering-correlation-id: 40f82cda-31f9-43b5-6b2b-08d40eccce07 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB0535; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(209352067349851)(176712945974257)(77634252153581)(120264001924599)(189100400724070)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6061324)(6041223); SRVR:AM3PR07MB0535; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0535; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(3905003)(497574002)(189002)(199003)(53754006)(5250100002)(2501003)(19609705001)(3660700001)(76576001)(189998001)(81156014)(81166006)(87936001)(97736004)(105586002)(54356999)(5001770100001)(50986999)(3280700002)(8936002)(66066001)(106356001)(101416001)(8676002)(7696004)(2906002)(7066003)(2900100001)(5660300001)(4326007)(86362001)(9686002)(33656002)(7906003)(74316002)(6506003)(606004)(92566002)(102836003)(790700001)(68736007)(6116002)(3846002)(7736002)(7846002)(7416002)(921003)(1121003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0535; H:AM3PR07MB0536.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB053674DBB6977DFC33C0971789B10AM3PR07MB0536eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 09:33:35.7651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0535 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUYRSG+e42V2vgNrmcVKgGJCg1K4lbRFg/8oIlEURDZDrpRQdX5o6W gWC5oIYxtDmO66CO5VqmaVbmljtmppilCSnkCq4japszV8N/zznveQ/fe/hoXLZGOtCqcA2v DleGyilrIkNRw7kKMa4K9+kBml3T3sXYl8nPKXY86wvBJtZWYqyhL55kp5JXMVbX14azPT91 FKt7+kjCzjXocHZkoRPz3MFNGKpwrjmlFHGv9SMSLqFlluQKClYxrnAwieRMgy9ITtc6KeFS 1vGLVletTwXyoapoXn34tL91cEV2ERX5PuxWfP0oHocab6QiKxoYD5i9b6BSkTUtY8oRvJrP I8SiHUFX3Q/cXBBMGg6L/fMSUXmIQWnuN8LslzFjCIyJEjNTjDvMTOVYdtkwrQQU3xvGzALO OEPSYCdp5t3MOfjUW2Ex2zDe0N7VQYnsBukZJZZFxMb8zEKdhaXMNZh4kInMjBg7WOks3dxp D1/HczExBAMFbz/iItvC5NgfUpz3hdmJKULs74OKuz+Q+XHA5OFg/JVAicIFyHqi/8+LaVuG EEhrLkci5yAY1nqJ5s8I7mSPkqLgBK8nBza3VpNQ+3EZiXfhoagsEYmRHWCkP2WTnWBi+B0p RoiAlbU5iRYd0G9LpN8m6S0X2AUdGeOE2HeBvDcLlMiHwGiYxre4u2EM297PQ5JiZCvwghAW dPSoG69WBQhCRLhbOK+pRBs/srFq/WQtavx5pgkxNJLvlEZqXBQyUhktxIQ1IaBxuY0096ar QiYNVMbc5tURfuqoUF5oQo40IbeXHn82ekXGBCk1fAjPR/LqLRWjrRzikCs2MhSl9ZsPSl9F pt7H3aYy+6X8mp5S3xOexkxDvVdyYHwz0xLLfZdN+mebvGlZWb2v6jerLezNzVoqmcl/X5K4 GLCj/5iK3aPQmFBldbLjkE+m5koW39Ac55BB1YXVenpkz8UuX/9wdm9bh4vzZd/9Nmnrgz52 l/6uFASclxNCsPLIQVwtKP8BEu8qs40DAAA= Archived-At: Cc: "ccamp@ietf.org" Subject: [CCAMP] MDT meeting - YANG Data Model - November 24, 9:00-10:00 (CET) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:33:43 -0000 --_000_AM3PR07MB053674DBB6977DFC33C0971789B10AM3PR07MB0536eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This is the invite to the next MDT meeting. Please note that we start two hours later than what we've done in our previ= ous meetings. Will focus on resolving the open topics we have related to the YANG model. The proposed agenda: * Short recap of the feedback received at IETF 97 * Report of work done on the open topics * AOB /JonasA ...........................................................................= .............................................................. --> Join Skype Meeting This is an online meeting for Skype for Business, the professional meetings= and communications app formerly known as Lync. Join by phone +46107140000 (Sweden) Engli= sh (United States) 89925 (Sweden) English (United St= ates) Find a local number Conference ID: 39586629 Forgot your dial-in PIN? |Help To join a Lync / Skype for Business meeting from an Ericsson standard video= room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the= conference ID). To join from a video room outside of Ericsson add one o= f the domains after 77 and Conference ID (e.g. 771234567@ xxxx.ericsson.net= , where xxxx=3Demea/apac/amcs). For assistance contact the IT Service Desk= . [!OC([1033])!] ...........................................................................= .............................................................. --_000_AM3PR07MB053674DBB6977DFC33C0971789B10AM3PR07MB0536eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This is the invite to the next MDT meeting.

 

Please note that we start two hours later than what = we’ve done in our previous meetings.

 

Will focus on resolving the open topics we have rela= ted to the YANG model.

 

The proposed agenda:

 

·         Short recap of the feedback received at IETF= 97

·         Report of work done on the open topics<= /o:p>

·         AOB

 

/JonasA

 

 <= /o:p>

...................................................= ...........................................................................= ...........

&agr= ave; = Join Skype Meeting      

This is an online meeting= for Skype for Business, the professional meetings and communications app f= ormerly known as Lync.

Join by phone

 

+46107140000 (Swe= den)            &nbs= p;      English (United States)

89925 (Sweden)   =             &nb= sp;   English (United States)  =

 

Find a= local number

 

Conference ID: 39586629

Forgot your dial-in PIN?<= span lang=3D"EN" style=3D"font-size:3.0pt"> |Help  

 

 

To j= oin a Lync / Skype for Business meeting from an Ericsson standard video roo= m, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the con= ference ID).    To join from a video room outside of Ericsson add one of the domains after 77 and Conference ID (e.g= . 771234567@ xxxx.ericsson.net, where xxxx=3Demea/apac/amcs).  For ass= istance contact the IT Service Desk.

[!OC([1033])!]

= ...........................................................................= ..............................................................<= /p>

--_000_AM3PR07MB053674DBB6977DFC33C0971789B10AM3PR07MB0536eurp_-- From nobody Thu Nov 17 08:06:19 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F1E129624 for ; Thu, 17 Nov 2016 08:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 e4zwPgtQCcWG for ; Thu, 17 Nov 2016 08:06:16 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5662C129612 for ; Thu, 17 Nov 2016 08:06:16 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id f82so155446842wmf.1 for ; Thu, 17 Nov 2016 08:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=EvwK7cBy3cjYOZXNq46dW+3OLhKGBGy9cRXI4RmhOv0=; b=MV9Hx8ggtq6BqVE1LaCceXBOw74m5SZk1uWXgEg6RFNAnM85BOvhuD30hnaAFty6qO HPTcsaDDkRc8tZOM4/mqDW8sFSjHoUWFlmrXm6q9FKfuH+eduuNGpvd0B3ZdbOXbOuH8 a/NRUgWmPNGKo28gb5Zp179xES4oElsCGeW9xIMghNqxSej+EaHalnWW/8lQI6doIyfG lrs1GVIuk5y7tY3B95onXmuVe93h9kNRa23PQsSib4jQrkGjibkfZrHXptxurxtqNwJO +LWw2sN4Xm1LDQq8tafTbT/1wy5RjWUHSD8Ct8liDfwNdHsiZs25fv7OL73oZ39ddrf1 7pgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=EvwK7cBy3cjYOZXNq46dW+3OLhKGBGy9cRXI4RmhOv0=; b=ZLTMEp51KUzHVVhqZD0U05pr+rSQ0nT1RiZu+rOw8l+bfMfWX3N0cCLW8bvAcGjKT2 OgTkqp3kl5yNkw2XKNQZg2e86922pcWIQzh4ja6WxAy9DkciWUSLPoUVgMU1+lKm3FUR xZPI+MPGT9MHdbs+WS0wkTGMbadHyMGRccgly0ATAFS7K5WOPopb2p7Uyrs4KhSTVp3v EkcMNAJCNhxDiGTFvpluER429fpy9MrWDSrQYlC2lyLbt1eytF8cAEXWFpnfRfD+2Arp gRdLZCnGdh1u90hwqfHQ3tcYaMhRV4QxOQgKFqCoznNcNQoJacepSqCVdIgxbCaEhnkc Q1gA== X-Gm-Message-State: AKaTC01ZzDVK/0ZRp1s2p7qw0LbhbC3Erf3XixO0P3xKWTmdBr4MzsfJCmeU0EmTh3Z4vQ== X-Received: by 10.194.89.41 with SMTP id bl9mr2639020wjb.81.1479398774623; Thu, 17 Nov 2016 08:06:14 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id f67sm16359862wmd.13.2016.11.17.08.06.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 08:06:13 -0800 (PST) References: To: ccamp@ietf.org From: Huub van Helvoort Message-ID: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> Date: Thu, 17 Nov 2016 17:06:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 16:06:17 -0000
Hello Gert,

Your use case is not completely correct.

Instead of:

2.       A use case to consider is:

 

       +----------+             +----------------+               +-----------+

100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-|--100GE

       +----------+             +----------------+               +-----------+  

             NE1                    NE2 (=GW-NE)                       NE3


It should be:

       +----------+             +----------------+               +--------------------+

100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE

       +----------+             +----------------+               +--------------------+  

             NE1                    NE2 (=GW-NE)                       NE3

The ODUC1 from NE2 to NE3 tunnels the ODU4.

Regards, Huub.


-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Thu Nov 17 17:14:52 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE90129862; Thu, 17 Nov 2016 17:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 87IXCB4ko46z; Thu, 17 Nov 2016 17:14:27 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0C7129859; Thu, 17 Nov 2016 17:14:26 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 1C7094AD9841D; Fri, 18 Nov 2016 09:14:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAI1E6I8079130; Fri, 18 Nov 2016 09:14:06 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> To: huubatwork@gmail.com MIME-Version: 1.0 X-KeepSent: 05EF3A57:5E8F671C-4825806F:0006BBBA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Fri, 18 Nov 2016 09:14:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-18 09:14:06, Serialize complete at 2016-11-18 09:14:06 Content-Type: multipart/alternative; boundary="=_alternative 0006C8824825806F_=" X-MAIL: mse01.zte.com.cn uAI1E6I8079130 Archived-At: Cc: ccamp@ietf.org, CCAMP Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:14:33 -0000 This is a multipart message in MIME format. --=_alternative 0006C8824825806F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSHV1YiwNCg0KWW91IGFyZSBjb3JyZWN0Lg0KDQpUaGFua3MNClFpbGVpDQoNCg0KDQoNCkh1 dWIgdmFuIEhlbHZvb3J0IDxodXViYXR3b3JrQGdtYWlsLmNvbT4gDQq3orz+yMs6ICAiQ0NBTVAi IDxjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KMjAxNi8xMS8xOCAwMDowNg0Kx+u08Li0ILj4DQpo dXViYXR3b3JrQGdtYWlsLmNvbQ0KDQoNCsrVvP7Iyw0KY2NhbXBAaWV0Zi5vcmcsIA0Ks63LzQ0K DQrW98ziDQpSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNCg0KDQoNCg0K DQpIZWxsbyBHZXJ0LA0KDQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3Qu DQoNCkluc3RlYWQgb2Y6DQoNCjIuICAgICAgIEEgdXNlIGNhc2UgdG8gY29uc2lkZXIgaXM6DQog DQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICAgIA0KKy0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RV NC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC18LS0xMDBHRQ0K ICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAg ICAgICAgICANCistLS0tLS0tLS0tLSsgICANCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAg ICAgICAgIE5FMiAoPUdXLU5FKSAgICAgICAgICAgICAgICAgICAgICAgTkUzDQoNCkl0IHNob3Vs ZCBiZTogDQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0rICAgICAgICAgICAgICAgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoxMDBHRS0tfC1HTVAt T0RVNC18LU9UVTQtLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RV QzEtR01QLU9EVTQtR01QLXwtLTEwMEdFDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgIA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0t KyAgIA0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ctTkUpICAg ICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5FMyB0dW5u ZWxzIHRoZSBPRFU0Lg0KUmVnYXJkcywgSHV1Yi4NCg0KLS0gDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpBbHdheXMgcmVt ZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFp bGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA0KDQoNCg== --=_alternative 0006C8824825806F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEh1dWIsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Zb3UgYXJlIGNvcnJlY3QuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlFpbGVpPGJyPg0KPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkh1dWIgdmFuIEhlbHZv b3J0ICZsdDtodXViYXR3b3JrQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7JnF1b3Q7Q0NBTVAmcXVvdDsg Jmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTYvMTEvMTggMDA6MDY8L2ZvbnQ+DQo8dGFibGUgYm9yZGVyPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxkaXYgYWxpZ249Y2VudGVyPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7H67TwuLQguPg8YnI+DQpodXViYXR3b3JrQGdt YWlsLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjYW1wQGlldGYub3JnLCA8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbQ0NBTVBd IE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTM+SGVsbG8gR2VydCw8YnI+DQo8YnI+DQpZb3VyIHVzZSBj YXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3QuPGJyPg0KPGJyPg0KSW5zdGVhZCBvZjo8YnI+ DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxiPjIuJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L2I+QSB1c2UgY2FzZSB0byBjb25zaWRlciBp czo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjxiPiZuYnNwOzwvYj48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPjxiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS0tLS0t LS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCistLS0tLS0tLS0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KKy0tLS0tLS0tLS0tKzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjxi PjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMx LS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0U8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0rJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQorLS0tLS0tLS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCistLS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsgPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTI+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCk5FMiAoPUdXLU5FKSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KTkUzPC9iPjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz48YnI+DQpJdCBzaG91bGQgYmU6IDxi cj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQorLS0tLS0tLS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistLS0t LS0tLS0tLS0tLS0tLS0tLSs8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGI+MTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9E VUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0LUdNUC18LS0xMDBHRTwvYj48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistLS0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0t LS0tLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQorLS0tLS0tLS0tLS0t LS0tLS0tLS0rJm5ic3A7Jm5ic3A7IDwvYj48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+PGI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQpORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCk5FMiAoPUdXLU5FKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KTkUzPC9i PjwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5F MyB0dW5uZWxzIHRoZSBPRFU0LjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz5SZWdhcmRzLCBIdXVi LjwvZm9udD4NCjxwPg0KPHA+PHR0Pjxmb250IHNpemU9Mz4tLSA8YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K QWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZlcnlvbmUg ZWxzZS4uLjwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpD Q0FNUEBpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxwPg0K --=_alternative 0006C8824825806F_=-- From nobody Thu Nov 17 17:18:11 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C2D1294A9 for ; Thu, 17 Nov 2016 17:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 7JOvDK_3y6U0 for ; Thu, 17 Nov 2016 17:18:07 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA9126579 for ; Thu, 17 Nov 2016 17:18:06 -0800 (PST) Received: from out1.zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTPS id 7B9D12B1CB61E for ; Fri, 18 Nov 2016 09:18:03 +0800 (CST) X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20161118091733 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 18 Nov 2016 01:17:33 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAI1Hjuk087552; Fri, 18 Nov 2016 09:17:45 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: References: To: Gert Grammel , CCAMP MIME-Version: 1.0 X-KeepSent: 6D9B672F:7D5C77DE-4825806F:0006DDB0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Fri, 18 Nov 2016 09:18:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-18 09:17:45, Serialize complete at 2016-11-18 09:17:45 Content-Type: multipart/alternative; boundary="=_alternative 00071E154825806F_=" X-MAIL: mse01.zte.com.cn uAI1Hjuk087552 X-HQIP: 127.0.0.1 Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:18:09 -0000 This is a multipart message in MIME format. --=_alternative 00071E154825806F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR2VydCwNCg0KSXQgbG9va3MgbGlrZSB0aGVyZSBhcmUgbWFueSBpc3N1ZXMgbmVlZGVkIHRv IGJlIHJlc29sdmVkLiBJIHdpbGwgY2hlY2sgDQp3aXRoIG90aGVyIGV4cGVydHMgZmlyc3QgdG8g c2VlIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQgb3Igbm90LCBhbmQgDQp0aGVuIGdldCBi YWNrIHRvIHRoZSBsaXN0Lg0KDQpUaGFua3MNClFpbGVpDQoNCg0KDQoNCkdlcnQgR3JhbW1lbCA8 Z2dyYW1tZWxAanVuaXBlci5uZXQ+IA0Kt6K8/sjLOiAgIkNDQU1QIiA8Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZz4NCjIwMTYvMTEvMTcgMTY6MTgNCg0KytW8/sjLDQpDQ0FNUCA8Y2NhbXBAaWV0Zi5v cmc+LCANCrOty80NCg0K1vfM4g0KW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoN Cg0KDQoNCg0KDQogDQpBZnRlciB0aGUgY2NhbXAgbWVldGluZyBEYW5pZWxlIHN1Z2dlc3RlZCB0 byBicmllZmx5IHN1bSB1cCB0aGUgaXNzdWVzIG9uIA0KbW9yZSBkZXRhaWwgb24gdGhlIGxpc3Qg dG8gdHJpZ2dlciBhIGRpc2N1c3Npb24uIEFzIEZhdGFpIG1lbnRpb25lZCwgT0RVNCANCmlzIGlu Y29tcGF0aWJsZSB3aXRoIE9EVUMxIHdoaWNoIGxvb2tlZCBzdXJwcmlzaW5nIHRvIG1vc3Qgb2Yg dXMuIA0KQ29uc3VsdGluZyANCmh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMv TElBSVNPTi9saWFpc29uLTIwMTYtMTAtMDUtaXR1LXQtc2ctMTUtbXBscy1jY2FtcC1wY2UtbHMt b24tc2cxNS1vdG50LXN0YW5kYXJkaXphdGlvbi13b3JrLXBsYW4tYXR0YWNobWVudC0zLnBkZiAN CmRpZG6hr3QgcHJvdmlkZSBtYW55IG1vcmUgZGV0YWlsczoNClRoZSA1dGggZWRpdGlvbiBvZiBS ZWNvbW1lbmRhdGlvbiBJVFUtVCBHLjcwOS9ZLjEzMzEgobBJbnRlcmZhY2VzIGZvciB0aGUgDQpP cHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JrobEsIA0KcHVibGlzaGVkIGluIEp1bmUgMjAxNiwgZW5h YmxlcyBvcHRpY2FsIHRyYW5zcG9ydCBhdCByYXRlcyBoaWdoZXIgdGhhbiAxMDAgDQpHYml0L3Mg KHRoZSBjb2RlIG5hbWUgaXMgYmV5b25kIDEwMCBHYml0L3Mgb3IgQjEwMEcpLg0KRGV0YWlscyBv ZiBHLjcwOSBhcmUgZ2l2ZW4gaW4gUGFydCAxIG9mIHRoaXMgZG9jdW1lbnQuDQpTbyBzb21lIGNs YXJpdHkgYWJvdXQgd2hldGhlciAxMDBHIGlzIGFjdHVhbGx5IGNvbnNpZGVyZWQgobBiZXlvbmQg MTAwR6GxIA0KaXMgYXBwcmVjaWF0ZWQuIElmIGluZGVlZCBPRFU0IGlzIGluY29tcGF0aWJsZSB3 aXRoIE9EVUMxLCBpdCB3b3VsZCBiZSANCmdyZWF0IHRvIGdldCBzb21lIGNvbG9yIGFib3V0IHdo eSBib3RoIG9wdGlvbnMgYXJlIG5lZWRlZCBhbmQgd2hhdCBhcmUgDQp0aGVpciBwYXJ0aWN1bGFy aXRpZXMuIFN1Y2ggdW5kZXJzdGFuZGluZyB3b3VsZCByZWFsbHkgaGVscCB0byBnZXQgdGhlIA0K Y29udHJvbCBwbGFuZSB3b3JrIHJpZ2h0Lg0KIA0KQmFzZWQgb24gbXkgY3VycmVudCB1bmRlcnN0 YW5kaW5nIChPRFU0IGFuZCBPRFVDMSBhcmUgaW5jb21wYXRpYmxlIA0KdmVyc2lvbnMgb2YgT0RV KSBoZXJlIGEgZmV3IHRlY2huaWNhbCBxdWVzdGlvbnMgdGhhdCB3b3VsZCBuZWVkIHRvIGJlIA0K YWRkcmVzc2VkIGluIEdNUExTOg0KIA0KMS4gICAgICAgT0RVNCBhbmQgT0RVQzEgYXJlIGJvdGgg MTAwRywgc28gd2hhdCB3aWxsIGJlIHRoZSBiYW5kd2lkdGggdG8gYmUgDQplbmNvZGVkPyBTZWUg UkZDMzQ3MSAgMy4xLjIuIEJhbmR3aWR0aCBFbmNvZGluZw0KYS4gICAgICAgU2VlbXMgdG8gYmUg YSBzb2x2YWJsZSBpc3N1ZQ0KMi4gICAgICAgQSB1c2UgY2FzZSB0byBjb25zaWRlciBpczoNCiAN CiAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLSsgIA0KKy0tLS0tLS0tLS0tKw0KMTAwR0UgDQotLS0tfC1HTVAtT0RVNC18LU9UVTQtLS0t LS0tLS0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tLS0tLS0tLU9UVUMxLXwtT0RV QzEtR01QLXwtLS0tMTAwR0UNCiAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLSsgIA0KKy0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAg TkUxICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5FMiAoPUdXLU5FKSAgICAgICAgICAgICBO RTMNCiANCjMuICBDb25zaWRlcmluZyBORTEgaXMgYW4gZXhpc3RpbmcgR2VuLTEgZGV2aWNlIChP RFU0IG9ubHkpLCB3aGlsZSBORTIrTkUzIA0KYXJlIG5ldyBHZW4tMiAoT0RVQytPRFU0IGNhcGFi bGUpIGRldmljZXMuIFRoZSBzZXJ2aWNlIHByb3ZpZGVkIGlzIGEgMTAwRyANCkV0aGVybmV0IHAy cCBzZXJ2aWNlLg0KYS4gIEhvdyBpcyBzdWNoIGEgc2VydmljZSBzaWduYWxlZD8gKHJlbWFyazog QSBnb29kIHN0YXJ0aW5nIHBvaW50IGNvdWxkIA0KYmUgdGhlIHN0aXRjaGluZyBtb2RlbCB1c2Vk IGluIE1QTFMpDQogICAgICAgICAgICAgICAgICAgICAgICBpLiAgIE9uZSBSU1ZQIHNlc3Npb24g cGVyIHNlcnZpY2U/IA0KICAgICAgICAgICAgICAgICAgICAgIGlpLiAgIE9uZSBSU1ZQIHNlc3Np b24gcGVyIE9EVSAoYWJzdHJhY3RpbmcgDQpPRFU0L09EVUMxIGRldGFpbHM/KSANCiAgICAgICAg ICAgICAgICAgICAgaWlpLiAgIFR3byBzZXBhcmF0ZSBzaWduYWxpbmcgc2Vzc2lvbnM6IE9EVTQg YW5kIE9EVUMxIA0KZWFjaA0KICAgICAgICAgICAgICAgICAgICAgIGl2LiAgIFRocmVlIHNlc3Np b25zOiBvbmUgZm9yIHRoZSAxMDBHRSBhbmQgdHdvIA0Kc2VydmVyIGxheWVyIHNlc3Npb25zIG9u ZSBmb3IgZWFjaCBPRFU/DQpiLiAgSG93IGRvZXMgT0RVLU9BTSB3b3JrPw0KICAgICAgICAgICAg ICAgICAgICAgICAgaS4gICBJcyB0aGVyZSBhIFRDTSBzZXNzaW9uIGF2YWlsYWJsZSBmb3IgdGhl IA0Kc2VydmljZSBpLmUuIGJldHdlZW4gaW5ncmVzcyBvbiBORTEgYW5kIGVncmVzcyBvbiBORTM/ DQogICAgICAgICAgICAgICAgICAgICAgaWkuICAgSG93IHdvdWxkIG90aGVyIE9EVSBPQU0gcHJv cGFnYXRlIGluIHRoZSBkYXRhIA0KcGxhbmU/IGkuZS4gQUlTLCBSREksIKGtDQogICAgICAgICAg ICAgICAgICAgIGlpaS4gICBJZiBPQU0gZG9lc26hr3QgcGFzcyBvbiB0aGUgZGF0ZS1wbGFuZSBp cyB0aGVyZSANCmEgbmVlZCB0byBzdWJzdGl0dXRlIGJ5IGNvbnRyb2wgcGxhbmU/IGkuZS4gZ2Vu ZXJhdGUgc29tZXRoaW5nIGxpa2UgYW4gDQpPRFUtQUlTIGluIEdNUExTIG9uY2Ugb25lIG9mIHRo ZSBPRFUgc2VnbWVudHMgaXMgY3V0IHRvIGluZm9ybSB0aGUgb3RoZXIgDQpPRFUgc2VnbWVudD8N CmMuICBIb3cgd291bGQgdGhlIHdob2xlIHRoaW5nIHdvcmsgaW4gY2FzZSBvZiBPRFVmbGV4IGlz IHVzZWQ/IChudW1iZXIgb2YgDQpzZXNzaW9ucywgZW5jb2RpbmcgZXRjKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgaS4gICBXb3VsZCBpdCBtYXR0ZXIgaWYgYW4gT0RVZmxleCBpcyBwdXQgaW4g YW4gDQpPVFU0IHZzIE9UVUMxIG9yIGlzIGl0IHRoZSBzYW1lPyANCiAgICAgICAgICAgICAgICAg ICAgICBpaS4gICBXb3VsZCBhbGwgdGhlIE9EVWZsZXgtT0FNIHN0dWZmIHBhc3MgDQp0cmFuc3Bh cmVudGx5IHRocm91Z2ggTkUyPw0KZC4gIElmIExPIE9EVXMgc3VjaCBhcyA4Kk9EVTIgYXJlIHRy YW5zcG9ydGVkIG92ZXIgYW4gT0RVNC9PRFVDMSwgYXJlIA0KdGhvc2UgT0RVMiBzdGlsbCB0aGUg c2FtZSBpLmUuIHBhc3MgdHJhbnNwYXJlbnRseSB0aHJvdWdoIHRoZSBHVy1ORSBvciBpcyANCnRo ZXJlIGFueXRoaW5nIHRvIGNvbnNpZGVyIG9uIE9EVTIgbGV2ZWwgdG9vPw0KZS4gIERvIHdlIG5l ZWQgdG8gY29uc2lkZXIgcmUtcHJvZ3JhbW1hYmxlIGludGVyZmFjZXMgdGhhdCBjYW4gYmUgc2V0 IHRvIA0KT0RVNC9PVFU0IFhPUiBPRFVDMS9PVFVDMSBwcmlvciBvciBkdXJpbmcgdGhlIHNpZ25h bGluZyBwYXNzZXMgYWxvbmc/DQo0LiAgICAgICBGb3Igd2F2ZWxlbmd0aCBzd2l0Y2hpbmcgYSBz aW1pbGFyIGNvbmNlcm4gZXhpc3RzIHJlbGF0ZWQgdG8gDQpPVFVDMSB2cyBPVFU0DQphLiAgICAg ICBXaGF0IHdvdWxkIGJlIHRoZSBCVyBlbmNvZGluZyBmb3IgZWFjaD8NCmIuICAgICAgIEEgcmVn ZW5lcmF0b3IgZGV2aWNlIG1heSByZWdlbmVyYXRlIGFuIE9EVTQvT1RVNCBvbiBpbmdyZXNzIHRv IA0KT0RVQzEvT1RVQzEgb24gZWdyZXNzLiBIb3cgd291bGQgdGhhdCBiZSBzaWduYWxlZD8gKHNh bWUgZGlzY3Vzc2lvbiBhcyBmb3IgDQpPRFUpDQpjLiAgICAgICBPVFVDbiBtYXkgY29uc2lzdCBv ZiBzZXZlcmFsIGNhcnJpZXJzIChpLmUuIHdhdmVsZW5ndGgsIHRoaW5rIGl0IA0KaXMgY2FsbGVk IE9UU2kpPyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGkuICAgICAgSWYgDQpzbywgYXJlIHRoZSBhdmFpbGFibGUgbWVjaGFu aXNtcyBpbiBHTVBMUyBzdWZmaWNpZW50IHRvIGNvLXJvdXRlIHRoZXNlPyANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpaS4gV291 bGQgaXQgDQp0aGVuIGJlIG9uZSBSU1ZQIHNlc3Npb24gcGVyIGNhcnJpZXIgb3Igb25lIHBlciBP VFVDbj8gDQogDQpUbyBzdW0gdXA6DQotICAgICAgICAgIEtlZXBpbmcgR01QTFMgaW4gc3luYyB3 aXRoIGF2YWlsYWJsZSBkYXRhcGxhbmUgc3RhbmRhcmRzIGlzIGEgDQpnb29kIHdvcmtpbmcgcHJh Y3RpY2UgdGhhdCBzaG91bGQgY29udGludWUNCi0gICAgICAgICAgQXQgdGhpcyBwb2ludCwgaXQg ZG9lc26hr3QgYXBwZWFyIHRoYXQgdGhlIGltcGxpY2F0aW9ucyBvZiANCmludHJvZHVjaW5nIE9E VUMxIGludG8gR01QTFMgYXJlIHN1ZmZpY2llbnRseSBjbGVhcg0KLSAgICAgICAgICBJdCB3b3Vs ZCBiZSBwcnVkZW50IHRvIGRlbGF5IHRoZSBkZWNpc2lvbiB3aGV0aGVyIGEgZnJhbWV3b3JrIA0K ZG9jdW1lbnQgaXMgcmVxdWlyZWQgb25jZSB0ZWNobmljYWwgY2xhcmlmaWNhdGlvbiBpcyBhdmFp bGFibGUuDQogDQpCZXN0DQogDQpHZXJ0X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQo= --=_alternative 00071E154825806F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdlcnQsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCBsb29rcyBsaWtlIHRoZXJlIGFyZSBt YW55IGlzc3Vlcw0KbmVlZGVkIHRvIGJlIHJlc29sdmVkLiBJIHdpbGwgY2hlY2sgd2l0aCBvdGhl ciBleHBlcnRzIGZpcnN0IHRvIHNlZSBpZg0KbXkgdW5kZXJzdGFuZGluZyBpcyByaWdodCBvciBu b3QsIGFuZCB0aGVuIGdldCBiYWNrIHRvIHRoZSBsaXN0LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5RaWxlaTxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HZXJ0IEdyYW1tZWwgJmx0O2dncmFtbWVsQGp1 bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+t6K8/sjLOiAmbmJzcDsmcXVvdDtDQ0FNUCZxdW90OyAmbHQ7Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAx Ni8xMS8xNyAxNjoxODwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5DQ0FNUCAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7LCA8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltDQ0FNUF0gT0RV NCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkFmdGVyIHRoZSBjY2FtcCBtZWV0aW5nIERhbmllbGUg c3VnZ2VzdGVkDQp0byBicmllZmx5IHN1bSB1cCB0aGUgaXNzdWVzIG9uIG1vcmUgZGV0YWlsIG9u IHRoZSBsaXN0IHRvIHRyaWdnZXIgYSBkaXNjdXNzaW9uLg0KQXMgRmF0YWkgbWVudGlvbmVkLCBP RFU0IGlzIGluY29tcGF0aWJsZSB3aXRoIE9EVUMxIHdoaWNoIGxvb2tlZCBzdXJwcmlzaW5nDQp0 byBtb3N0IG9mIHVzLiBDb25zdWx0aW5nIDwvZm9udD48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTEwLTA1LWl0dS10LXNn LTE1LW1wbHMtY2NhbXAtcGNlLWxzLW9uLXNnMTUtb3RudC1zdGFuZGFyZGl6YXRpb24td29yay1w bGFuLWF0dGFjaG1lbnQtMy5wZGYiPjxmb250IHNpemU9MiBjb2xvcj0jMDA4MmJmIGZhY2U9IkNh bGlicmkiPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9s aWFpc29uLTIwMTYtMTAtMDUtaXR1LXQtc2ctMTUtbXBscy1jY2FtcC1wY2UtbHMtb24tc2cxNS1v dG50LXN0YW5kYXJkaXphdGlvbi13b3JrLXBsYW4tYXR0YWNobWVudC0zLnBkZjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4NCmRpZG6hr3QgcHJvdmlkZSBtYW55IG1v cmUgZGV0YWlsczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoZSA1 dGggZWRpdGlvbiBvZiBSZWNvbW1lbmRhdGlvbiBJVFUtVA0KRy43MDkvWS4xMzMxIKGwSW50ZXJm YWNlcyBmb3IgdGhlIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmuhsSwgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5wdWJsaXNoZWQgaW4gSnVuZSAyMDE2LCBlbmFibGVz IG9wdGljYWwNCnRyYW5zcG9ydCBhdCByYXRlcyBoaWdoZXIgdGhhbiAxMDAgR2JpdC9zICh0aGUg Y29kZSBuYW1lIGlzIGJleW9uZCAxMDANCkdiaXQvcyBvciBCMTAwRykuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5EZXRhaWxzIG9mIEcuNzA5IGFyZSBnaXZlbiBpbiBQ YXJ0IDEgb2YNCnRoaXMgZG9jdW1lbnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5TbyBzb21lIGNsYXJpdHkgYWJvdXQgd2hldGhlciAxMDBHIGlzIGFjdHVhbGx5DQpj b25zaWRlcmVkIKGwYmV5b25kIDEwMEehsSBpcyBhcHByZWNpYXRlZC4gSWYgaW5kZWVkIE9EVTQg aXMgaW5jb21wYXRpYmxlDQp3aXRoIE9EVUMxLCBpdCB3b3VsZCBiZSBncmVhdCB0byBnZXQgc29t ZSBjb2xvciBhYm91dCB3aHkgYm90aCBvcHRpb25zDQphcmUgbmVlZGVkIGFuZCB3aGF0IGFyZSB0 aGVpciBwYXJ0aWN1bGFyaXRpZXMuIFN1Y2ggdW5kZXJzdGFuZGluZyB3b3VsZA0KcmVhbGx5IGhl bHAgdG8gZ2V0IHRoZSBjb250cm9sIHBsYW5lIHdvcmsgcmlnaHQuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48Yj4mbmJzcDs8L2I+PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5CYXNlZCBvbiBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgKE9E VTQNCmFuZCBPRFVDMSBhcmUgaW5jb21wYXRpYmxlIHZlcnNpb25zIG9mIE9EVSkgaGVyZSBhIGZl dyB0ZWNobmljYWwgcXVlc3Rpb25zDQp0aGF0IHdvdWxkIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGlu IEdNUExTOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48Yj4xLiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8L2I+T0RVNCBhbmQNCk9EVUMxIGFyZSBib3RoIDEwMEcsIHNvIHdoYXQgd2lsbCBi ZSB0aGUgYmFuZHdpZHRoIHRvIGJlIGVuY29kZWQ/IFNlZSBSRkMzNDcxDQombmJzcDs8L2ZvbnQ+ PGEgbmFtZT0ic2VjdGlvbi0zLjEuMiI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzNDcxI3NlY3Rpb24tMy4xLjIiPjxmb250IHNpemU9MiBjb2xvcj0jMDA4MmJm IGZhY2U9IkNhbGlicmkiPjxiPjx1PjMuMS4yPC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj48Yj4uDQpCYW5kd2lkdGggRW5jb2Rpbmc8L2I+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48Yj5hLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 L2I+U2VlbXMgdG8NCmJlIGEgc29sdmFibGUgaXNzdWU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPjxiPjIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvYj5BIHVzZSBjYXNl DQp0byBjb25zaWRlciBpczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48Yj4mbmJzcDs8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KKy0tLS0tLS0tLS0r ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgKy0tLS0tLS0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0t LS0tLS0tLS0tKzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48Yj4xMDBHRSAtLS0tfC1HTVAtT0RVNC18LU9UVTQtLS0tLS0tLS0tLU9UVTQtfC1PRFU0LUdN UC1PRFVDMS18LU9UVUMxLS0tLS0tLS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLS0tMTAwR0U8L2I+ PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KKy0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgKy0t LS0tLS0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tKyAmbmJzcDsg PC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgTkUxICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtORTM8L2I+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7PC9iPjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjMuICZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Q29uc2lkZXJpbmcNCk5FMSBpcyBhbiBleGlzdGluZyBHZW4t MSBkZXZpY2UgKE9EVTQgb25seSksIHdoaWxlIE5FMitORTMgYXJlIG5ldyBHZW4tMg0KKE9EVUMr T0RVNCBjYXBhYmxlKSBkZXZpY2VzLiBUaGUgc2VydmljZSBwcm92aWRlZCBpcyBhIDEwMEcgRXRo ZXJuZXQgcDJwDQpzZXJ2aWNlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPmEuICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SG93DQpp cyBzdWNoIGEgc2VydmljZSBzaWduYWxlZD8gKHJlbWFyazogQSBnb29kIHN0YXJ0aW5nIHBvaW50 IGNvdWxkIGJlIHRoZQ0Kc3RpdGNoaW5nIG1vZGVsIHVzZWQgaW4gTVBMUyk8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgaS4gJm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+T25lDQpSU1ZQ IHNlc3Npb24gcGVyIHNlcnZpY2U/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlpLiAmbmJzcDsgPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5PbmUNClJTVlAgc2Vzc2lvbiBwZXIgT0RVIChhYnN0cmFjdGlu ZyBPRFU0L09EVUMxIGRldGFpbHM/KSAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlpaS4gJm5ic3A7IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+VHdvDQpzZXBhcmF0ZSBzaWduYWxpbmcgc2Vzc2lvbnM6IE9E VTQgYW5kIE9EVUMxIGVhY2g8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpdi4gJm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+VGhyZWUNCnNlc3Npb25zOiBvbmUgZm9yIHRoZSAxMDBHRSBhbmQgdHdv IHNlcnZlciBsYXllciBzZXNzaW9ucyBvbmUgZm9yIGVhY2gNCk9EVT88L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5iLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPkhvdw0KZG9lcyBPRFUtT0FNIHdvcms/PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGku ICZuYnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklzDQp0aGVyZSBhIFRD TSBzZXNzaW9uIGF2YWlsYWJsZSBmb3IgdGhlIHNlcnZpY2UgaS5lLiBiZXR3ZWVuIGluZ3Jlc3Mg b24gTkUxDQphbmQgZWdyZXNzIG9uIE5FMz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpaS4gJm5ic3A7IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SG93DQp3b3VsZCBvdGhlciBPRFUgT0FNIHByb3BhZ2F0 ZSBpbiB0aGUgZGF0YSBwbGFuZT8gaS5lLiBBSVMsIFJESSwgoa08L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlpaS4gJm5ic3A7IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SWYNCk9BTSBkb2VzbqGvdCBwYXNzIG9uIHRo ZSBkYXRlLXBsYW5lIGlzIHRoZXJlIGEgbmVlZCB0byBzdWJzdGl0dXRlIGJ5IGNvbnRyb2wNCnBs YW5lPyBpLmUuIGdlbmVyYXRlIHNvbWV0aGluZyBsaWtlIGFuIE9EVS1BSVMgaW4gR01QTFMgb25j ZSBvbmUgb2YgdGhlDQpPRFUgc2VnbWVudHMgaXMgY3V0IHRvIGluZm9ybSB0aGUgb3RoZXIgT0RV IHNlZ21lbnQ/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Yy4g Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Ib3cNCndvdWxkIHRoZSB3 aG9sZSB0aGluZyB3b3JrIGluIGNhc2Ugb2YgT0RVZmxleCBpcyB1c2VkPyAobnVtYmVyIG9mIHNl c3Npb25zLA0KZW5jb2RpbmcgZXRjKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpLiAmbmJzcDsgPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Xb3VsZA0KaXQgbWF0dGVyIGlmIGFuIE9EVWZsZXgg aXMgcHV0IGluIGFuIE9UVTQgdnMgT1RVQzEgb3IgaXMgaXQgdGhlIHNhbWU/IDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlp LiAmbmJzcDsgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Xb3VsZA0KYWxsIHRo ZSBPRFVmbGV4LU9BTSBzdHVmZiBwYXNzIHRyYW5zcGFyZW50bHkgdGhyb3VnaCBORTI/PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ZC4gJm5ic3A7PC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5JZg0KTE8gT0RVcyBzdWNoIGFzIDgqT0RVMiBhcmUg dHJhbnNwb3J0ZWQgb3ZlciBhbiBPRFU0L09EVUMxLCBhcmUgdGhvc2UgT0RVMg0Kc3RpbGwgdGhl IHNhbWUgaS5lLiBwYXNzIHRyYW5zcGFyZW50bHkgdGhyb3VnaCB0aGUgR1ctTkUgb3IgaXMgdGhl cmUgYW55dGhpbmcNCnRvIGNvbnNpZGVyIG9uIE9EVTIgbGV2ZWwgdG9vPzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPmUuICZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+RG8NCndlIG5lZWQgdG8gY29uc2lkZXIgcmUtcHJvZ3JhbW1hYmxl IGludGVyZmFjZXMgdGhhdCBjYW4gYmUgc2V0IHRvIE9EVTQvT1RVNA0KWE9SIE9EVUMxL09UVUMx IHByaW9yIG9yIGR1cmluZyB0aGUgc2lnbmFsaW5nIHBhc3NlcyBhbG9uZz88L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjQuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZvciB3 YXZlbGVuZ3RoDQpzd2l0Y2hpbmcgYSBzaW1pbGFyIGNvbmNlcm4gZXhpc3RzIHJlbGF0ZWQgdG8g T1RVQzEgdnMgT1RVNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+YS4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgV2hhdCB3b3VsZCBiZSB0aGUNCkJXIGVuY29kaW5nIGZvciBl YWNoPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Yi4gJm5ic3A7ICZu YnNwOyAmbmJzcDsgQSByZWdlbmVyYXRvciBkZXZpY2UNCm1heSByZWdlbmVyYXRlIGFuIE9EVTQv T1RVNCBvbiBpbmdyZXNzIHRvIE9EVUMxL09UVUMxIG9uIGVncmVzcy4gSG93IHdvdWxkDQp0aGF0 IGJlIHNpZ25hbGVkPyAoc2FtZSBkaXNjdXNzaW9uIGFzIGZvciBPRFUpPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5jLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPVFVDbiBt YXkgY29uc2lzdA0Kb2Ygc2V2ZXJhbCBjYXJyaWVycyAoaS5lLiB3YXZlbGVuZ3RoLCB0aGluayBp dCBpcyBjYWxsZWQgT1RTaSk/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2kuICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgc28sIGFyZSB0aGUgYXZhaWxhYmxlDQptZWNoYW5p c21zIGluIEdNUExTIHN1ZmZpY2llbnQgdG8gY28tcm91dGUgdGhlc2U/IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7aWkuICZuYnNwOyAmbmJzcDsgJm5ic3A7V291bGQgaXQgdGhlbiBi ZSBvbmUgUlNWUCBzZXNzaW9uDQpwZXIgY2FycmllciBvciBvbmUgcGVyIE9UVUNuPyA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxiPiZuYnNwOzwvYj48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRvIHN1bSB1cDo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPi0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0tlZXBpbmcNCkdNUExTIGluIHN5bmMgd2l0aCBhdmFpbGFibGUgZGF0YXBsYW5lIHN0YW5k YXJkcyBpcyBhIGdvb2Qgd29ya2luZyBwcmFjdGljZQ0KdGhhdCBzaG91bGQgY29udGludWU8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPi0gJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0F0DQp0aGlzIHBvaW50LCBpdCBkb2VzbqGvdCBhcHBlYXIgdGhhdCB0 aGUgaW1wbGljYXRpb25zIG9mIGludHJvZHVjaW5nIE9EVUMxDQppbnRvIEdNUExTIGFyZSBzdWZm aWNpZW50bHkgY2xlYXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPi0g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0l0DQp3b3VsZCBiZSBwcnVkZW50IHRv IGRlbGF5IHRoZSBkZWNpc2lvbiB3aGV0aGVyIGEgZnJhbWV3b3JrIGRvY3VtZW50IGlzDQpyZXF1 aXJlZCBvbmNlIHRlY2huaWNhbCBjbGFyaWZpY2F0aW9uIGlzIGF2YWlsYWJsZS48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+QmVzdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5H ZXJ0PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRm Lm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jY2FtcD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXA8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00071E154825806F_=-- From nobody Thu Nov 17 17:46:42 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3247E129622 for ; Thu, 17 Nov 2016 17:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 HyiVwEGAY_tq for ; Thu, 17 Nov 2016 17:46:37 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0104.outbound.protection.outlook.com [104.47.41.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F240129429 for ; Thu, 17 Nov 2016 17:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G3L4ivzXKgmNcmp8Hih3nXWLAnRdUar6PrE5hC30+Ag=; b=f64H+5rcBYyUgCN/O8D4D3S/eJehZlf8CgTjMMNyQqB3gz1b+moLW5kpi26f6W8xbN+sroV9Vjun8lZeUd935EK1ISr+FevrASSRy/PJiBlPQTb7I0LiplNvNd6O8dOZ/pwE5MjS5h8ze+FNa5FcZ/cwZoPDotR3KHriGEVcmGg= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1611.namprd05.prod.outlook.com (10.161.162.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 18 Nov 2016 01:46:35 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0747.004; Fri, 18 Nov 2016 01:46:35 +0000 From: Gert Grammel To: "wang.qilei@zte.com.cn" , CCAMP Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDd8fUAgACexIA= Date: Fri, 18 Nov 2016 01:46:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.188.14] x-ms-office365-filtering-correlation-id: e9505bb1-82ab-434d-f63a-08d40f54bafa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1611; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1611; 7:CWzunwlPfPHi4spq/iXnMEpROqbeCNuj9dq/QeQ5BbXLocDvIpWhVA17eXkYKR1m2Vrd/zHTdPSqyoBv2zdwx+mXenhn+JCF0Zti9r6covduYKzoEjRj6bwmHrMX5PrO8iiYaVsvy2e1Hjhmvi/9dWOWkO5uHkMhL0XMzwLK/oKqUozgk5CUqDGOpb+1BFzFiZXro7T2tQ3/DB0xpmZjtrav4R3FOkXOvq8DeEwdbwGnXcRa9ZddKnbtnTVxBewBmbMpZFobCEteuytHdMVmKLd38ZtaM3f0dUfc30ejmIEXstQk6iD3wSrfemoM987od0MVrzBdZRzgG3dGpsXlDgXhcxDlk12GeCsmh/3cJHbQWxEu4481A55m2I+OjmUqtAfVR+1A3lMxs8a+t9td93AUk9OtM6UGG/kkQX/kN3ni12v6Y0hXmfpCzZhZ8mjO+RXUYm4sA0vfEWua/pvm4g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041223)(6061324); SRVR:CY1PR0501MB1611; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1611; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(37854004)(189002)(199003)(57704003)(7906003)(50986999)(54356999)(76176999)(3660700001)(5001770100001)(6512003)(6506003)(606004)(97736004)(7736002)(7846002)(83506001)(101416001)(3280700002)(68736007)(36756003)(189998001)(4001350100001)(107886002)(82746002)(83716003)(87936001)(2906002)(229853002)(5890100001)(2501003)(2950100002)(66066001)(81156014)(8936002)(102836003)(3846002)(6116002)(81166006)(122556002)(5660300001)(86362001)(106356001)(105586002)(106116001)(33656002)(77096005)(8676002)(2900100001)(92566002)(99286002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1611; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D87D3EDE0EC24022B8A11C13E46923BAjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 01:46:35.2209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1611 Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:46:40 -0000 --_000_D87D3EDE0EC24022B8A11C13E46923BAjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBwbGVhc2UgZ28gYWhlYWQuIEFzIEh1dWIgbWVudGlvbmVkLCB0aGUgY2FzZSBtYXkgbm90 IGJlIDEwMCUgYWNjdXJhdGUgd2hpY2ggaXMgYWxyZWFkeSBhIGdvb2QgcG9pbnQgdG8gc3RhcnQg d2l0aC4gSXTigJlzIHJlYWxseSBhYm91dCBnZXR0aW5nIGEgY2xlYXIgcGljdHVyZS4NCg0KR2Vy dA0KDQpGcm9tOiAid2FuZy5xaWxlaUB6dGUuY29tLmNuIiA8d2FuZy5xaWxlaUB6dGUuY29tLmNu Pg0KRGF0ZTogRnJpZGF5IDE4IE5vdmVtYmVyIDIwMTYgYXQgMTA6MTgNClRvOiBHZXJ0IEdyYW1t ZWwgPGdncmFtbWVsQGp1bmlwZXIubmV0PiwgQ0NBTVAgPGNjYW1wQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpIaSBHZXJ0LA0KDQpJ dCBsb29rcyBsaWtlIHRoZXJlIGFyZSBtYW55IGlzc3VlcyBuZWVkZWQgdG8gYmUgcmVzb2x2ZWQu IEkgd2lsbCBjaGVjayB3aXRoIG90aGVyIGV4cGVydHMgZmlyc3QgdG8gc2VlIGlmIG15IHVuZGVy c3RhbmRpbmcgaXMgcmlnaHQgb3Igbm90LCBhbmQgdGhlbiBnZXQgYmFjayB0byB0aGUgbGlzdC4N Cg0KVGhhbmtzDQpRaWxlaQ0KDQoNCkdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+ DQrlj5Hku7bkuro6ICAiQ0NBTVAiIDxjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDE2LzEx LzE3IDE2OjE4DQoNCuaUtuS7tuS6ug0KDQpDQ0FNUCA8Y2NhbXBAaWV0Zi5vcmc+LA0KDQrmioTp gIENCg0K5Li76aKYDQoNCltDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQoNCg0K DQoNCg0KDQoNCkFmdGVyIHRoZSBjY2FtcCBtZWV0aW5nIERhbmllbGUgc3VnZ2VzdGVkIHRvIGJy aWVmbHkgc3VtIHVwIHRoZSBpc3N1ZXMgb24gbW9yZSBkZXRhaWwgb24gdGhlIGxpc3QgdG8gdHJp Z2dlciBhIGRpc2N1c3Npb24uIEFzIEZhdGFpIG1lbnRpb25lZCwgT0RVNCBpcyBpbmNvbXBhdGli bGUgd2l0aCBPRFVDMSB3aGljaCBsb29rZWQgc3VycHJpc2luZyB0byBtb3N0IG9mIHVzLiBDb25z dWx0aW5nIGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFp c29uLTIwMTYtMTAtMDUtaXR1LXQtc2ctMTUtbXBscy1jY2FtcC1wY2UtbHMtb24tc2cxNS1vdG50 LXN0YW5kYXJkaXphdGlvbi13b3JrLXBsYW4tYXR0YWNobWVudC0zLnBkZiBkaWRu4oCZdCBwcm92 aWRlIG1hbnkgbW9yZSBkZXRhaWxzOg0KVGhlIDV0aCBlZGl0aW9uIG9mIFJlY29tbWVuZGF0aW9u IElUVS1UIEcuNzA5L1kuMTMzMSDigJxJbnRlcmZhY2VzIGZvciB0aGUgT3B0aWNhbCBUcmFuc3Bv cnQgTmV0d29ya+KAnSwNCnB1Ymxpc2hlZCBpbiBKdW5lIDIwMTYsIGVuYWJsZXMgb3B0aWNhbCB0 cmFuc3BvcnQgYXQgcmF0ZXMgaGlnaGVyIHRoYW4gMTAwIEdiaXQvcyAodGhlIGNvZGUgbmFtZSBp cyBiZXlvbmQgMTAwIEdiaXQvcyBvciBCMTAwRykuDQpEZXRhaWxzIG9mIEcuNzA5IGFyZSBnaXZl biBpbiBQYXJ0IDEgb2YgdGhpcyBkb2N1bWVudC4NClNvIHNvbWUgY2xhcml0eSBhYm91dCB3aGV0 aGVyIDEwMEcgaXMgYWN0dWFsbHkgY29uc2lkZXJlZCDigJxiZXlvbmQgMTAwR+KAnSBpcyBhcHBy ZWNpYXRlZC4gSWYgaW5kZWVkIE9EVTQgaXMgaW5jb21wYXRpYmxlIHdpdGggT0RVQzEsIGl0IHdv dWxkIGJlIGdyZWF0IHRvIGdldCBzb21lIGNvbG9yIGFib3V0IHdoeSBib3RoIG9wdGlvbnMgYXJl IG5lZWRlZCBhbmQgd2hhdCBhcmUgdGhlaXIgcGFydGljdWxhcml0aWVzLiBTdWNoIHVuZGVyc3Rh bmRpbmcgd291bGQgcmVhbGx5IGhlbHAgdG8gZ2V0IHRoZSBjb250cm9sIHBsYW5lIHdvcmsgcmln aHQuDQoNCkJhc2VkIG9uIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZyAoT0RVNCBhbmQgT0RVQzEg YXJlIGluY29tcGF0aWJsZSB2ZXJzaW9ucyBvZiBPRFUpIGhlcmUgYSBmZXcgdGVjaG5pY2FsIHF1 ZXN0aW9ucyB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGluIEdNUExTOg0KDQoxLiAg ICAgICBPRFU0IGFuZCBPRFVDMSBhcmUgYm90aCAxMDBHLCBzbyB3aGF0IHdpbGwgYmUgdGhlIGJh bmR3aWR0aCB0byBiZSBlbmNvZGVkPyBTZWUgUkZDMzQ3MSAgMy4xLjI8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzM0NzEjc2VjdGlvbi0zLjEuMj4uIEJhbmR3aWR0aCBFbmNvZGluZw0K YS4gICAgICAgU2VlbXMgdG8gYmUgYSBzb2x2YWJsZSBpc3N1ZQ0KMi4gICAgICAgQSB1c2UgY2Fz ZSB0byBjb25zaWRlciBpczoNCg0KICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0rDQoxMDBHRSAtLS0tfC1HTVAtT0RVNC18LU9UVTQtLS0tLS0tLS0tLU9UVTQtfC1PRFU0LUdN UC1PRFVDMS18LU9UVUMxLS0tLS0tLS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLS0tMTAwR0UNCiAg ICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICBORTEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ctTkUpICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTkUzDQoNCjMuICBDb25zaWRlcmluZyBORTEgaXMgYW4gZXhpc3RpbmcgR2Vu LTEgZGV2aWNlIChPRFU0IG9ubHkpLCB3aGlsZSBORTIrTkUzIGFyZSBuZXcgR2VuLTIgKE9EVUMr T0RVNCBjYXBhYmxlKSBkZXZpY2VzLiBUaGUgc2VydmljZSBwcm92aWRlZCBpcyBhIDEwMEcgRXRo ZXJuZXQgcDJwIHNlcnZpY2UuDQphLiAgSG93IGlzIHN1Y2ggYSBzZXJ2aWNlIHNpZ25hbGVkPyAo cmVtYXJrOiBBIGdvb2Qgc3RhcnRpbmcgcG9pbnQgY291bGQgYmUgdGhlIHN0aXRjaGluZyBtb2Rl bCB1c2VkIGluIE1QTFMpDQogICAgICAgICAgICAgICAgICAgICAgICBpLiAgIE9uZSBSU1ZQIHNl c3Npb24gcGVyIHNlcnZpY2U/DQogICAgICAgICAgICAgICAgICAgICAgaWkuICAgT25lIFJTVlAg c2Vzc2lvbiBwZXIgT0RVIChhYnN0cmFjdGluZyBPRFU0L09EVUMxIGRldGFpbHM/KQ0KICAgICAg ICAgICAgICAgICAgICBpaWkuICAgVHdvIHNlcGFyYXRlIHNpZ25hbGluZyBzZXNzaW9uczogT0RV NCBhbmQgT0RVQzEgZWFjaA0KICAgICAgICAgICAgICAgICAgICAgIGl2LiAgIFRocmVlIHNlc3Np b25zOiBvbmUgZm9yIHRoZSAxMDBHRSBhbmQgdHdvIHNlcnZlciBsYXllciBzZXNzaW9ucyBvbmUg Zm9yIGVhY2ggT0RVPw0KYi4gIEhvdyBkb2VzIE9EVS1PQU0gd29yaz8NCiAgICAgICAgICAgICAg ICAgICAgICAgIGkuICAgSXMgdGhlcmUgYSBUQ00gc2Vzc2lvbiBhdmFpbGFibGUgZm9yIHRoZSBz ZXJ2aWNlIGkuZS4gYmV0d2VlbiBpbmdyZXNzIG9uIE5FMSBhbmQgZWdyZXNzIG9uIE5FMz8NCiAg ICAgICAgICAgICAgICAgICAgICBpaS4gICBIb3cgd291bGQgb3RoZXIgT0RVIE9BTSBwcm9wYWdh dGUgaW4gdGhlIGRhdGEgcGxhbmU/IGkuZS4gQUlTLCBSREksIOKApg0KICAgICAgICAgICAgICAg ICAgICBpaWkuICAgSWYgT0FNIGRvZXNu4oCZdCBwYXNzIG9uIHRoZSBkYXRlLXBsYW5lIGlzIHRo ZXJlIGEgbmVlZCB0byBzdWJzdGl0dXRlIGJ5IGNvbnRyb2wgcGxhbmU/IGkuZS4gZ2VuZXJhdGUg c29tZXRoaW5nIGxpa2UgYW4gT0RVLUFJUyBpbiBHTVBMUyBvbmNlIG9uZSBvZiB0aGUgT0RVIHNl Z21lbnRzIGlzIGN1dCB0byBpbmZvcm0gdGhlIG90aGVyIE9EVSBzZWdtZW50Pw0KYy4gIEhvdyB3 b3VsZCB0aGUgd2hvbGUgdGhpbmcgd29yayBpbiBjYXNlIG9mIE9EVWZsZXggaXMgdXNlZD8gKG51 bWJlciBvZiBzZXNzaW9ucywgZW5jb2RpbmcgZXRjKQ0KICAgICAgICAgICAgICAgICAgICAgICAg aS4gICBXb3VsZCBpdCBtYXR0ZXIgaWYgYW4gT0RVZmxleCBpcyBwdXQgaW4gYW4gT1RVNCB2cyBP VFVDMSBvciBpcyBpdCB0aGUgc2FtZT8NCiAgICAgICAgICAgICAgICAgICAgICBpaS4gICBXb3Vs ZCBhbGwgdGhlIE9EVWZsZXgtT0FNIHN0dWZmIHBhc3MgdHJhbnNwYXJlbnRseSB0aHJvdWdoIE5F Mj8NCmQuICBJZiBMTyBPRFVzIHN1Y2ggYXMgOCpPRFUyIGFyZSB0cmFuc3BvcnRlZCBvdmVyIGFu IE9EVTQvT0RVQzEsIGFyZSB0aG9zZSBPRFUyIHN0aWxsIHRoZSBzYW1lIGkuZS4gcGFzcyB0cmFu c3BhcmVudGx5IHRocm91Z2ggdGhlIEdXLU5FIG9yIGlzIHRoZXJlIGFueXRoaW5nIHRvIGNvbnNp ZGVyIG9uIE9EVTIgbGV2ZWwgdG9vPw0KZS4gIERvIHdlIG5lZWQgdG8gY29uc2lkZXIgcmUtcHJv Z3JhbW1hYmxlIGludGVyZmFjZXMgdGhhdCBjYW4gYmUgc2V0IHRvIE9EVTQvT1RVNCBYT1IgT0RV QzEvT1RVQzEgcHJpb3Igb3IgZHVyaW5nIHRoZSBzaWduYWxpbmcgcGFzc2VzIGFsb25nPw0KNC4g ICAgICAgRm9yIHdhdmVsZW5ndGggc3dpdGNoaW5nIGEgc2ltaWxhciBjb25jZXJuIGV4aXN0cyBy ZWxhdGVkIHRvIE9UVUMxIHZzIE9UVTQNCmEuICAgICAgIFdoYXQgd291bGQgYmUgdGhlIEJXIGVu Y29kaW5nIGZvciBlYWNoPw0KYi4gICAgICAgQSByZWdlbmVyYXRvciBkZXZpY2UgbWF5IHJlZ2Vu ZXJhdGUgYW4gT0RVNC9PVFU0IG9uIGluZ3Jlc3MgdG8gT0RVQzEvT1RVQzEgb24gZWdyZXNzLiBI b3cgd291bGQgdGhhdCBiZSBzaWduYWxlZD8gKHNhbWUgZGlzY3Vzc2lvbiBhcyBmb3IgT0RVKQ0K Yy4gICAgICAgT1RVQ24gbWF5IGNvbnNpc3Qgb2Ygc2V2ZXJhbCBjYXJyaWVycyAoaS5lLiB3YXZl bGVuZ3RoLCB0aGluayBpdCBpcyBjYWxsZWQgT1RTaSk/DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpLiAgICAgIElmIHNvLCBh cmUgdGhlIGF2YWlsYWJsZSBtZWNoYW5pc21zIGluIEdNUExTIHN1ZmZpY2llbnQgdG8gY28tcm91 dGUgdGhlc2U/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaWkuICAgICAgV291bGQgaXQgdGhlbiBiZSBvbmUgUlNWUCBzZXNzaW9u IHBlciBjYXJyaWVyIG9yIG9uZSBwZXIgT1RVQ24/DQoNClRvIHN1bSB1cDoNCi0gICAgICAgICAg S2VlcGluZyBHTVBMUyBpbiBzeW5jIHdpdGggYXZhaWxhYmxlIGRhdGFwbGFuZSBzdGFuZGFyZHMg aXMgYSBnb29kIHdvcmtpbmcgcHJhY3RpY2UgdGhhdCBzaG91bGQgY29udGludWUNCi0gICAgICAg ICAgQXQgdGhpcyBwb2ludCwgaXQgZG9lc27igJl0IGFwcGVhciB0aGF0IHRoZSBpbXBsaWNhdGlv bnMgb2YgaW50cm9kdWNpbmcgT0RVQzEgaW50byBHTVBMUyBhcmUgc3VmZmljaWVudGx5IGNsZWFy DQotICAgICAgICAgIEl0IHdvdWxkIGJlIHBydWRlbnQgdG8gZGVsYXkgdGhlIGRlY2lzaW9uIHdo ZXRoZXIgYSBmcmFtZXdvcmsgZG9jdW1lbnQgaXMgcmVxdWlyZWQgb25jZSB0ZWNobmljYWwgY2xh cmlmaWNhdGlvbiBpcyBhdmFpbGFibGUuDQoNCkJlc3QNCg0KR2VydF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1Q QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoN Cg0K --_000_D87D3EDE0EC24022B8A11C13E46923BAjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpzYW5zLXNlcmlm Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA1Ni43cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlllcywgcGxlYXNlIGdvIGFoZWFkLiBB cyBIdXViIG1lbnRpb25lZCwgdGhlIGNhc2UgbWF5IG5vdCBiZSAxMDAlIGFjY3VyYXRlIHdoaWNo IGlzIGFscmVhZHkgYSBnb29kIHBvaW50IHRvIHN0YXJ0IHdpdGguIEl04oCZcyByZWFsbHkgYWJv dXQgZ2V0dGluZyBhIGNsZWFyIHBpY3R1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+R2Vy dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6Ymxh Y2siPiZxdW90O3dhbmcucWlsZWlAenRlLmNvbS5jbiZxdW90OyAmbHQ7d2FuZy5xaWxlaUB6dGUu Y29tLmNuJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXkgMTggTm92ZW1iZXIgMjAxNiBhdCAx MDoxODxicj4NCjxiPlRvOiA8L2I+R2VydCBHcmFtbWVsICZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5l dCZndDssIENDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3Nh bnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhpIEdlcnQsPC9zcGFuPg0KPGJyPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fu cy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SXQgbG9va3MgbGlrZSB0aGVyZSBhcmUg bWFueSBpc3N1ZXMgbmVlZGVkIHRvIGJlIHJlc29sdmVkLiBJIHdpbGwgY2hlY2sgd2l0aCBvdGhl ciBleHBlcnRzIGZpcnN0IHRvIHNlZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHJpZ2h0IG9yIG5v dCwgYW5kIHRoZW4gZ2V0IGJhY2sgdG8gdGhlIGxpc3QuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmtzPC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5RaWxlaTxicj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0 ZCB3aWR0aD0iMzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjM2LjAlO3BhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5HZXJ0IEdyYW1tZWwgJmx0O2dncmFtbWVsQGp1bmlwZXIubmV0Jmd0 Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+5Y+R5Lu25Lq6PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1z ZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+OiAmbmJzcDsmcXVvdDtDQ0FNUCZxdW90OyAm bHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJp ZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MjAxNi8xMS8xNyAxNjoxODwvc3Bhbj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMlIiB2YWxpZ249InRvcCIgc3R5bGU9Indp ZHRoOjYzLjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUi IHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5pS25Lu2 5Lq6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5DQ0FNUCAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7LA0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7m ioTpgIE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWlu Y2hvJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTpTaW1TdW4iPumimDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+W0NDQU1QXSBPRFU0IGFuZCBP RFVDbiBkaXNjdXNzaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFmdGVyIHRoZSBjY2FtcCBtZWV0aW5nIERhbmll bGUgc3VnZ2VzdGVkIHRvIGJyaWVmbHkgc3VtIHVwIHRoZSBpc3N1ZXMgb24gbW9yZSBkZXRhaWwg b24gdGhlIGxpc3QgdG8gdHJpZ2dlciBhIGRpc2N1c3Npb24uIEFzIEZhdGFpIG1lbnRpb25lZCwg T0RVNCBpcyBpbmNvbXBhdGlibGUgd2l0aCBPRFVDMSB3aGljaCBsb29rZWQgc3VycHJpc2luZyB0 byBtb3N0DQogb2YgdXMuIENvbnN1bHRpbmcgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTYtMTAtMDUtaXR1LXQt c2ctMTUtbXBscy1jY2FtcC1wY2UtbHMtb24tc2cxNS1vdG50LXN0YW5kYXJkaXphdGlvbi13b3Jr LXBsYW4tYXR0YWNobWVudC0zLnBkZiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMDA4MkJGIj5odHRwczovL3d3dy5pZXRmLm9yZy9saWIv ZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTEwLTA1LWl0dS10LXNnLTE1LW1wbHMt Y2NhbXAtcGNlLWxzLW9uLXNnMTUtb3RudC1zdGFuZGFyZGl6YXRpb24td29yay1wbGFuLWF0dGFj aG1lbnQtMy5wZGY8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPg0KIGRpZG7igJl0IHByb3ZpZGUgbWFueSBtb3JlIGRldGFpbHM6PC9z cGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5UaGUgNXRoIGVkaXRpb24gb2YgUmVjb21tZW5kYXRpb24gSVRVLVQgRy43MDkvWS4xMzMx IOKAnEludGVyZmFjZXMgZm9yIHRoZSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jr4oCdLA0KPC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPnB1Ymxpc2hlZCBpbiBKdW5lIDIwMTYsIGVuYWJsZXMgb3B0aWNhbCB0cmFuc3BvcnQgYXQg cmF0ZXMgaGlnaGVyIHRoYW4gMTAwIEdiaXQvcyAodGhlIGNvZGUgbmFtZSBpcyBiZXlvbmQgMTAw IEdiaXQvcyBvciBCMTAwRykuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RGV0YWlscyBvZiBHLjcwOSBhcmUgZ2l2ZW4gaW4g UGFydCAxIG9mIHRoaXMgZG9jdW1lbnQuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+U28gc29tZSBjbGFyaXR5IGFib3V0IHdo ZXRoZXIgMTAwRyBpcyBhY3R1YWxseSBjb25zaWRlcmVkIOKAnGJleW9uZCAxMDBH4oCdIGlzIGFw cHJlY2lhdGVkLiBJZiBpbmRlZWQgT0RVNCBpcyBpbmNvbXBhdGlibGUgd2l0aCBPRFVDMSwgaXQg d291bGQgYmUgZ3JlYXQgdG8gZ2V0IHNvbWUgY29sb3IgYWJvdXQgd2h5IGJvdGggb3B0aW9ucyBh cmUgbmVlZGVkIGFuZCB3aGF0DQogYXJlIHRoZWlyIHBhcnRpY3VsYXJpdGllcy4gU3VjaCB1bmRl cnN0YW5kaW5nIHdvdWxkIHJlYWxseSBoZWxwIHRvIGdldCB0aGUgY29udHJvbCBwbGFuZSB3b3Jr IHJpZ2h0Ljwvc3Bhbj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48L2I+IDxicj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkJhc2VkIG9uIG15IGN1cnJlbnQg dW5kZXJzdGFuZGluZyAoT0RVNCBhbmQgT0RVQzEgYXJlIGluY29tcGF0aWJsZSB2ZXJzaW9ucyBv ZiBPRFUpIGhlcmUgYSBmZXcgdGVjaG5pY2FsIHF1ZXN0aW9ucyB0aGF0IHdvdWxkIG5lZWQgdG8g YmUgYWRkcmVzc2VkIGluIEdNUExTOjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+MS4gJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5PRFU0IGFuZCBPRFVDMSBhcmUgYm90aCAxMDBHLCBzbyB3aGF0 IHdpbGwgYmUgdGhlIGJhbmR3aWR0aCB0byBiZSBlbmNvZGVkPyBTZWUgUkZDMzQ3MSAmbmJzcDs8 L3NwYW4+PGEgbmFtZT0ic2VjdGlvbi0zLjEuMiI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmMzNDcxI3NlY3Rpb24tMy4xLjIiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzAwODJCRiI+My4xLjI8L3Nw YW4+PC9iPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj4uDQogQmFuZHdpZHRoIEVuY29kaW5nPC9zcGFuPjwvYj4gPGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+YS4gJm5ic3A7ICZu YnNwOyAmbmJzcDsgPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5TZWVtcyB0byBiZSBhIHNvbHZhYmxlIGlzc3VlPC9zcGFuPg0KPGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Mi4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlzOjwv c3Bhbj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9iPiA8YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0m IzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyYjNDM7LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48L2I+DQo8YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+MTAwR0UgLS0tLXwtR01QLU9EVTQtfC1PVFU0LS0tLS0tLS0tLS1PVFU0LXwtT0RVNC1HTVAt T0RVQzEtfC1PVFVDMS0tLS0tLS0tLS1PVFVDMS18LU9EVUMxLUdNUC18LS0tLTEwMEdFPC9zcGFu PjwvYj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0t LS0mIzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0tLS0tLSYjNDM7ICZuYnNwOw0K PC9zcGFuPjwvYj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5FMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7TkUzPC9zcGFuPjwvYj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PC9iPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+My4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkNvbnNpZGVyaW5nIE5FMSBpcyBhbiBl eGlzdGluZyBHZW4tMSBkZXZpY2UgKE9EVTQgb25seSksIHdoaWxlIE5FMiYjNDM7TkUzIGFyZSBu ZXcgR2VuLTIgKE9EVUMmIzQzO09EVTQgY2FwYWJsZSkgZGV2aWNlcy4gVGhlIHNlcnZpY2UgcHJv dmlkZWQgaXMNCiBhIDEwMEcgRXRoZXJuZXQgcDJwIHNlcnZpY2UuPC9zcGFuPiA8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+YS4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPkhvdyBpcyBzdWNoIGEgc2VydmljZSBzaWduYWxlZD8gKHJlbWFyazog QSBnb29kIHN0YXJ0aW5nIHBvaW50IGNvdWxkIGJlIHRoZSBzdGl0Y2hpbmcgbW9kZWwgdXNlZCBp biBNUExTKTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBpLiAmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5PbmUgUlNWUCBzZXNzaW9uIHBlciBzZXJ2aWNlPw0KPC9zcGFuPjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlpLiAmbmJzcDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PbmUgUlNWUCBzZXNz aW9uIHBlciBPRFUgKGFic3RyYWN0aW5nIE9EVTQvT0RVQzEgZGV0YWlscz8pICZuYnNwOzwvc3Bh bj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaWlpLiAmbmJzcDsNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Ud28gc2VwYXJh dGUgc2lnbmFsaW5nIHNlc3Npb25zOiBPRFU0IGFuZCBPRFVDMSBlYWNoPC9zcGFuPg0KPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXYuICZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRocmVlIHNlc3Npb25z OiBvbmUgZm9yIHRoZSAxMDBHRSBhbmQgdHdvIHNlcnZlciBsYXllciBzZXNzaW9ucyBvbmUgZm9y IGVhY2ggT0RVPzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5iLiAmbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SG93IGRvZXMgT0RV LU9BTSB3b3JrPzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBpLiAmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5JcyB0aGVyZSBhIFRDTSBzZXNzaW9uIGF2YWlsYWJsZSBmb3IgdGhl IHNlcnZpY2UgaS5lLiBiZXR3ZWVuIGluZ3Jlc3Mgb24gTkUxIGFuZCBlZ3Jlc3Mgb24gTkUzPzwv c3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlpLiAmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5I b3cgd291bGQgb3RoZXIgT0RVIE9BTSBwcm9wYWdhdGUgaW4gdGhlIGRhdGEgcGxhbmU/IGkuZS4g QUlTLCBSREksIOKApjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaWlpLiAm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5JZiBPQU0gZG9lc27igJl0IHBhc3Mgb24gdGhlIGRhdGUtcGxhbmUgaXMgdGhlcmUg YSBuZWVkIHRvIHN1YnN0aXR1dGUgYnkgY29udHJvbCBwbGFuZT8gaS5lLiBnZW5lcmF0ZSBzb21l dGhpbmcgbGlrZSBhbiBPRFUtQUlTIGluIEdNUExTIG9uY2Ugb25lIG9mIHRoZSBPRFUgc2VnbWVu dHMgaXMgY3V0IHRvIGluZm9ybSB0aGUgb3RoZXIgT0RVIHNlZ21lbnQ/PC9zcGFuPg0KPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPmMuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5Ib3cgd291bGQgdGhlIHdob2xlIHRoaW5nIHdvcmsgaW4gY2Fz ZSBvZiBPRFVmbGV4IGlzIHVzZWQ/IChudW1iZXIgb2Ygc2Vzc2lvbnMsIGVuY29kaW5nIGV0Yyk8 L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaS4gJm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+V291bGQgaXQgbWF0dGVyIGlmIGFuIE9EVWZsZXggaXMgcHV0IGluIGFuIE9UVTQgdnMg T1RVQzEgb3IgaXMgaXQgdGhlIHNhbWU/DQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgaWkuICZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPldvdWxkIGFsbCB0aGUgT0RVZmxleC1PQU0gc3R1ZmYg cGFzcyB0cmFuc3BhcmVudGx5IHRocm91Z2ggTkUyPzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5k LiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+SWYgTE8gT0RVcyBzdWNoIGFzIDgqT0RVMiBhcmUgdHJhbnNwb3J0ZWQgb3ZlciBh biBPRFU0L09EVUMxLCBhcmUgdGhvc2UgT0RVMiBzdGlsbCB0aGUgc2FtZSBpLmUuIHBhc3MgdHJh bnNwYXJlbnRseSB0aHJvdWdoIHRoZSBHVy1ORSBvciBpcw0KIHRoZXJlIGFueXRoaW5nIHRvIGNv bnNpZGVyIG9uIE9EVTIgbGV2ZWwgdG9vPzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmUuICZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5EbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIHJlLXByb2dyYW1tYWJsZSBpbnRlcmZhY2VzIHRoYXQg Y2FuIGJlIHNldCB0byBPRFU0L09UVTQgWE9SIE9EVUMxL09UVUMxIHByaW9yIG9yIGR1cmluZyB0 aGUgc2lnbmFsaW5nIHBhc3NlcyBhbG9uZz88L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj40LiAmbmJzcDsgJm5ic3A7ICZuYnNw OyBGb3Igd2F2ZWxlbmd0aCBzd2l0Y2hpbmcgYSBzaW1pbGFyIGNvbmNlcm4gZXhpc3RzIHJlbGF0 ZWQgdG8gT1RVQzEgdnMgT1RVNDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmEuICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdoYXQg d291bGQgYmUgdGhlIEJXIGVuY29kaW5nIGZvciBlYWNoPzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmIuICZuYnNwOyAmbmJz cDsgJm5ic3A7IEEgcmVnZW5lcmF0b3IgZGV2aWNlIG1heSByZWdlbmVyYXRlIGFuIE9EVTQvT1RV NCBvbiBpbmdyZXNzIHRvIE9EVUMxL09UVUMxIG9uIGVncmVzcy4gSG93IHdvdWxkIHRoYXQgYmUg c2lnbmFsZWQ/IChzYW1lIGRpc2N1c3Npb24gYXMgZm9yIE9EVSk8L3NwYW4+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5jLiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBPVFVDbiBtYXkgY29uc2lzdCBvZiBzZXZlcmFsIGNhcnJpZXJzIChpLmUu IHdhdmVsZW5ndGgsIHRoaW5rIGl0IGlzIGNhbGxlZCBPVFNpKT8NCjwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aS4gJm5ic3A7ICZuYnNw OyAmbmJzcDtJZiBzbywgYXJlIHRoZSBhdmFpbGFibGUgbWVjaGFuaXNtcyBpbiBHTVBMUyBzdWZm aWNpZW50IHRvIGNvLXJvdXRlIHRoZXNlPw0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lpLiAmbmJzcDsgJm5ic3A7ICZuYnNwO1dvdWxkIGl0IHRo ZW4gYmUgb25lIFJTVlAgc2Vzc2lvbiBwZXIgY2FycmllciBvciBvbmUgcGVyIE9UVUNuPw0KPC9z cGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOzwvc3Bhbj48L2I+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRvIHN1bSB1cDo8L3NwYW4+IDxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi0gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0tlZXBpbmcgR01QTFMgaW4gc3luYyB3aXRoIGF2YWlsYWJs ZSBkYXRhcGxhbmUgc3RhbmRhcmRzIGlzIGEgZ29vZCB3b3JraW5nIHByYWN0aWNlIHRoYXQgc2hv dWxkIGNvbnRpbnVlPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 QXQgdGhpcyBwb2ludCwgaXQgZG9lc27igJl0IGFwcGVhciB0aGF0IHRoZSBpbXBsaWNhdGlvbnMg b2YgaW50cm9kdWNpbmcgT0RVQzEgaW50byBHTVBMUyBhcmUgc3VmZmljaWVudGx5IGNsZWFyPC9z cGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXQgd291bGQgYmUgcHJ1 ZGVudCB0byBkZWxheSB0aGUgZGVjaXNpb24gd2hldGhlciBhIGZyYW1ld29yayBkb2N1bWVudCBp cyByZXF1aXJlZCBvbmNlIHRlY2huaWNhbCBjbGFyaWZpY2F0aW9uIGlzIGF2YWlsYWJsZS48L3Nw YW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPkJlc3Q8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+R2VydDwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5D Q0FNUCBtYWlsaW5nIGxpc3Q8L3R0Pjxicj4NCjx0dD5DQ0FNUEBpZXRmLm9yZzwvdHQ+PGJyPg0K PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXAiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvc3Bhbj48L3R0PjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K PC9zcGFuPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D87D3EDE0EC24022B8A11C13E46923BAjunipernet_-- From nobody Thu Nov 17 18:02:05 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9EA12985B; Thu, 17 Nov 2016 18:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 yIMK-fsgixl9; Thu, 17 Nov 2016 18:02:01 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED912129552; Thu, 17 Nov 2016 18:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CdTRZTF8BnSYfZGRSp1tH83QOoGpB1v5mwHKPlxFnjk=; b=CBDtz7QsVgAguLCWKUoJEOli8TZfDMw+2veT7xmf0TlRIs+IRypZACvf7z3T1iRy65ceJF6/vQ/qzqz+ELdYKQLUBMm5LceOKWPsPU0Ljt3Ke+lVomlEVVot+CEwmd6VBtvDeBIWb3c1Jeh/RoFlDZEQyXQWXXedY5B5/KuwCX8= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1611.namprd05.prod.outlook.com (10.161.162.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 18 Nov 2016 02:01:59 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0747.004; Fri, 18 Nov 2016 02:01:59 +0000 From: Gert Grammel To: "wang.qilei@zte.com.cn" , "huubatwork@gmail.com" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgACZP4CAAKQWAA== Date: Fri, 18 Nov 2016 02:01:59 +0000 Message-ID: <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.188.14] x-ms-office365-filtering-correlation-id: e61465b2-6247-4f97-3151-08d40f56e19e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1611; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1611; 7:06kAYGNbt1YgC/QlzJZ62I1WUqmMw4x4vgDhy3rnTuKLbIStGfz2OITbCvq4QsqeZ3O1RKC+nmsby8RMR3Cm54mAiawlaWiCTCxsI8dbyn4QXmw/6XskTI+Uhn4JCCjofP1Q8aVTox/EqZbthE1nJQE7UPhfGSMOBUz6DWIyKi2aKcuhOjD3aa44A0Lg+c07yddO7lxcZr4j/rx6lXqqbz0rfHYC4IkiqCHRtPg0m1sohKSItNGGjCGj+4suPfS1ix+wfW1MceNx2bZb8s2WFnCuYPq0TSOFDVuPNbCkB8feahjDa4EIRziZq5slK48VKM2p+nC3MZXQWFW9Zveh6gWu7vBEI7yY86q224b3rXd/BKrHnDqkRDE9iYW5/8xfSKRsH2/T/4FBOmaB6R+YS8NOmONQrAl3LNCwYTAOfMIV1p4eVVqBtcNHDVJDnX635rXXdYN5n7CrzrhybFwN0Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041223)(6061324); SRVR:CY1PR0501MB1611; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1611; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(122556002)(5660300001)(81156014)(66066001)(2950100002)(3846002)(6116002)(81166006)(8936002)(102836003)(92566002)(8676002)(2900100001)(99286002)(106356001)(86362001)(106116001)(33656002)(77096005)(105586002)(101416001)(36756003)(3280700002)(68736007)(3660700001)(4326007)(54356999)(7906003)(50986999)(76176999)(7736002)(7846002)(83506001)(6512003)(6506003)(5001770100001)(97736004)(606004)(82746002)(4001350100001)(83716003)(2501003)(87936001)(229853002)(2906002)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1611; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5AD93F3C54F449A5AF6A0205482D45B0junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 02:01:59.1766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1611 Archived-At: Cc: "ccamp@ietf.org" , CCAMP Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:02:03 -0000 --_000_5AD93F3C54F449A5AF6A0205482D45B0junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SHV1YiwNCg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nLiBUaGUgYWltIG9mIHRoaXMgdGhyZWFkIGlz IHRvIGNvbnZlcmdlIG9uIGEgY2xlYXIgcGljdHVyZSBzbyB0aGF0IHdlIGNhbiBnYXVnZSB3aGF0 4oCZcyBuZWVkZWQgb24gQ1AgbGV2ZWwgdG8gc3VwcG9ydC4NCkZyb20geW91ciBleHBsYW5hdGlv biBpdCBzZWVtcyB0aGVyZSBhcmUgMyBkaWZmZXJlbnQgd2F5cyB0byBtYXAgMTAwR0UgaW50byBh biBPRFUNCg0KwrcgICAgICAgICAxMDBHReKAlEdNUC0tLU9EVTQtLS1PVFU0DQoNCsK3ICAgICAg ICAgMTAwR0XigJRHTVAtLS1PRFVDMS0tLU9UVUMxDQoNCsK3ICAgICAgICAgMTAwR0UtLS1HTVAt LS1PRFU0LS0tT0RVQzEtLS1PVFVDMQ0KSXMgdGhhdCBjb3JyZWN0IG9yIGFyZSB0aGVyZSBzdGls bCBtb3JlIG9wdGlvbnMuIEkuZS4gbm90IHNvIGNsZWFyIGhvdyB0byBkZWFsIHdpdGggT0RVZmxl eCBvZiBzb21lIGtpbmQgYW5kIG1heWJlIEdGUC1GIG1hcHBpbmcgaXMgYWxzbyBzdGlsbCBhbiBv cHRpb24uIFByZXN1bWFibHkgdGhlcmUgYXJlIGFsc28gb3B0aW9ucyBsaWtlIG4gdGltZXMgT0RV MiBpbiBPRFVDMSAoaXMgbiBzdGlsbCBsaW1pdGVkIHRvIDggaW4gdGhpcyBjYXNlPykuDQoNClRo YW5rcw0KDQpHZXJ0DQoNCkZyb206IENDQU1QIDxjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBvbiBi ZWhhbGYgb2YgIndhbmcucWlsZWlAenRlLmNvbS5jbiIgPHdhbmcucWlsZWlAenRlLmNvbS5jbj4N CkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDEwOjE0DQpUbzogImh1dWJhdHdvcmtA Z21haWwuY29tIiA8aHV1YmF0d29ya0BnbWFpbC5jb20+DQpDYzogQ0NBTVAgPGNjYW1wQGlldGYu b3JnPiwgQ0NBTVAgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1Q XSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNCkhpIEh1dWIsDQoNCllvdSBhcmUgY29ycmVj dC4NCg0KVGhhbmtzDQpRaWxlaQ0KDQoNCkh1dWIgdmFuIEhlbHZvb3J0IDxodXViYXR3b3JrQGdt YWlsLmNvbT4NCuWPkeS7tuS6ujogICJDQ0FNUCIgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+DQoN CjIwMTYvMTEvMTggMDA6MDYNCuivt+etlOWkjSDnu5kNCmh1dWJhdHdvcmtAZ21haWwuY29tDQoN Cg0K5pS25Lu25Lq6DQoNCmNjYW1wQGlldGYub3JnLA0KDQrmioTpgIENCg0K5Li76aKYDQoNClJl OiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KSGVsbG8g R2VydCwNCg0KWW91ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Lg0KDQpJbnN0 ZWFkIG9mOg0KDQoyLiAgICAgICBBIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlzOg0KDQogICAgICAg Ky0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLSsNCjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdN UC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0t LS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ct TkUpICAgICAgICAgICAgICAgICAgICAgICBORTMNCg0KSXQgc2hvdWxkIGJlOg0KDQogICAgICAg Ky0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQt fC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0t MTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0r ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgTkUx ICAgICAgICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5F Mw0KDQpUaGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9EVTQuDQoNClJlZ2Fy ZHMsIEh1dWIuDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVu aXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== --_000_5AD93F3C54F449A5AF6A0205482D45B0junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <5B9A99F0F2675E4E8942E61212C8E752@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJ cGFub3NlLTE6MiAyIDUgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpzYW5zLXNlcmlmOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnR0DQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox NTk1NDMyODAwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMjA2MTA2Njg0OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MS4waW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuNWluOw0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyLjBpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoyLjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My4waW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjMuNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuMGluOw0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDo0LjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NS4waW47 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5IdXViLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyBmb3IgY2xhcmlmeWlu Zy4gVGhlIGFpbSBvZiB0aGlzIHRocmVhZCBpcyB0byBjb252ZXJnZSBvbiBhIGNsZWFyIHBpY3R1 cmUgc28gdGhhdCB3ZSBjYW4gZ2F1Z2Ugd2hhdOKAmXMgbmVlZGVkIG9uIENQIGxldmVsIHRvIHN1 cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbSB5b3VyIGV4 cGxhbmF0aW9uIGl0IHNlZW1zIHRoZXJlIGFyZSAzIGRpZmZlcmVudCB3YXlzIHRvIG1hcCAxMDBH RSBpbnRvIGFuIE9EVTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjEwMEdF4oCUR01QLS0tT0RVNC0tLU9UVTQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj4xMDBHReKAlEdNUC0tLU9EVUMxLS0tT1RVQzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4xMDBHRS0tLUdNUC0t LU9EVTQtLS1PRFVDMS0tLU9UVUMxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+SXMgdGhhdCBjb3JyZWN0IG9yIGFyZSB0aGVyZSBzdGlsbCBtb3JlIG9wdGlvbnMuIEkuZS4g bm90IHNvIGNsZWFyIGhvdyB0byBkZWFsIHdpdGggT0RVZmxleCBvZiBzb21lIGtpbmQgYW5kIG1h eWJlIEdGUC1GIG1hcHBpbmcgaXMgYWxzbyBzdGlsbCBhbiBvcHRpb24uIFByZXN1bWFibHkgdGhl cmUgYXJlIGFsc28gb3B0aW9ucw0KIGxpa2UgbiB0aW1lcyBPRFUyIGluIE9EVUMxIChpcyBuIHN0 aWxsIGxpbWl0ZWQgdG8gOCBpbiB0aGlzIGNhc2U/KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5HZXJ0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Q0NBTVAgJmx0O2NjYW1w LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDt3YW5nLnFpbGVpQHp0ZS5j b20uY24mcXVvdDsgJmx0O3dhbmcucWlsZWlAenRlLmNvbS5jbiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+RnJpZGF5IDE4IE5vdmVtYmVyIDIwMTYgYXQgMTA6MTQ8YnI+DQo8Yj5UbzogPC9iPiZxdW90 O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7ICZsdDtodXViYXR3b3JrQGdtYWlsLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPkNDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDssIENDQU1QICZsdDtj Y2FtcC1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0NDQU1Q XSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+SGkgSHV1Yiw8L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Zb3UgYXJlIGNvcnJlY3QuPC9zcGFuPg0KPGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1z ZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmtzPC9zcGFuPiA8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5RaWxlaTxicj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCB3aWR0aD0iMzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjM2LjAlO3BhZGRp bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IdXViIHZhbiBIZWx2b29ydCAmbHQ7aHV1YmF0d29ya0Bn bWFpbC5jb20mZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPC9zcGFu Pjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7l j5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij46ICZuYnNwOyZxdW90O0ND QU1QJnF1b3Q7ICZsdDtjY2FtcC1ib3VuY2VzQGlldGYub3JnJmd0Ozwvc3Bhbj4NCjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4yMDE2LzExLzE4IDAwOjA2PC9z cGFuPg0KPG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7o r7fnrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+57uZPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6UE1pbmdMaVUiPjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2Vy aWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmh1dWJhdHdvcmtAZ21haWwuY29tPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjYzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wJTtwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAl Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz dHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuaUtuS7tuS6ujwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Y2NhbXBAaWV0Zi5vcmcsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1 cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4 dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtNUyBNaW5jaG8mcXVvdDsiPuaKhOmAgTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0 Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0 IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuS4uzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+6aKYPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5SZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQpIZWxsbyBHZXJ0 LDxicj4NCjxicj4NCllvdXIgdXNlIGNhc2UgaXMgbm90IGNvbXBsZXRlbHkgY29ycmVjdC48YnI+ DQo8YnI+DQpJbnN0ZWFkIG9mOjxicj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjIuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+QSB1c2UgY2FzZSB0byBjb25zaWRlciBpczo8L3NwYW4+DQo8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvYj4gPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t LS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0t LS0tLS0tJiM0Mzs8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18 LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPg0KPGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0t LS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0t LS0tJiM0MzsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2I+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUyICg9R1ctTkUpJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE5FMzwvc3Bhbj48L2I+DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxicj4NCkl0IHNo b3VsZCBiZTogPGJyPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t LS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0t LS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEwMEdF LS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RV QzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0t LS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cD48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORTIgKD1HVy1ORSkmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTkUzPC9zcGFuPjwvYj48YnI+DQo8YnI+DQpUaGUgT0RVQzEgZnJvbSBORTIgdG8g TkUzIHR1bm5lbHMgdGhlIE9EVTQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+UmVnYXJkcywgSHV1Yi4g PG86cD48L286cD48L3A+DQo8cD48dHQ+LS0gPC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD49PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC90dD48YnI+DQo8dHQ+ QWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZlcnlvbmUg ZWxzZS4uLjwvdHQ+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPHR0PkNDQU1QIG1haWxpbmcgbGlzdDwvdHQ+PGJyPg0KPHR0PkNDQU1Q QGlldGYub3JnPC90dD48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPC9zcGFuPjwvdHQ+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5AD93F3C54F449A5AF6A0205482D45B0junipernet_-- From nobody Thu Nov 17 18:10:01 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD8A129552 for ; Thu, 17 Nov 2016 18:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 Ffrv-q0ZmKXa for ; Thu, 17 Nov 2016 18:09:59 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E30641294FD for ; Thu, 17 Nov 2016 18:09:58 -0800 (PST) Received: from out1.zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTPS id 5225DF28F7117 for ; Fri, 18 Nov 2016 10:09:55 +0800 (CST) X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20161118100925 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 18 Nov 2016 02:09:25 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAI29lxd022843; Fri, 18 Nov 2016 10:09:47 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> To: Gert Grammel , "huubatwork@gmail.com" MIME-Version: 1.0 X-KeepSent: 7CB64DAB:C387F804-4825806F:000B9E89; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Fri, 18 Nov 2016 10:10:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-18 10:09:47, Serialize complete at 2016-11-18 10:09:47 Content-Type: multipart/alternative; boundary="=_alternative 000BE1C04825806F_=" X-MAIL: mse01.zte.com.cn uAI29lxd022843 X-HQIP: 127.0.0.1 Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:10:01 -0000 This is a multipart message in MIME format. --=_alternative 000BE1C04825806F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR2VydCwNCg0KSSBkb24ndCB0aGluayB0aGUgc2Vjb25kIHdheSBpcyBjb3JyZWN0LiBCZWNh dXNlIGFzIGRlZmluZWQgaW4gRy43MDksIA0KT0RVQ24gY2FuIG9ubHkgYmUgdXNlZCB0byBjYXJy eSBPVE4gY2xpZW50cyhpLmUuLCBPRFUwLCBPRFUxLi4uLE9EVTQpLg0KDQpUaGFua3MNClFpbGVp DQoNCg0KDQoNCkdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+IA0KMjAxNi8xMS8x OCAxMDowMQ0KDQrK1bz+yMsNCiJ3YW5nLnFpbGVpQHp0ZS5jb20uY24iIDx3YW5nLnFpbGVpQHp0 ZS5jb20uY24+LCAiaHV1YmF0d29ya0BnbWFpbC5jb20iIA0KPGh1dWJhdHdvcmtAZ21haWwuY29t PiwgDQqzrcvNDQoiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4sIENDQU1QIDxjY2Ft cC1ib3VuY2VzQGlldGYub3JnPg0K1vfM4g0KUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlz Y3Vzc2lvbg0KDQoNCg0KDQoNCg0KSHV1YiwNCiANClRoYW5rcyBmb3IgY2xhcmlmeWluZy4gVGhl IGFpbSBvZiB0aGlzIHRocmVhZCBpcyB0byBjb252ZXJnZSBvbiBhIGNsZWFyIA0KcGljdHVyZSBz byB0aGF0IHdlIGNhbiBnYXVnZSB3aGF0oa9zIG5lZWRlZCBvbiBDUCBsZXZlbCB0byBzdXBwb3J0 Lg0KRnJvbSB5b3VyIGV4cGxhbmF0aW9uIGl0IHNlZW1zIHRoZXJlIGFyZSAzIGRpZmZlcmVudCB3 YXlzIHRvIG1hcCAxMDBHRSANCmludG8gYW4gT0RVDQqhpCAgICAgICAgIDEwMEdFoapHTVAtLS1P RFU0LS0tT1RVNA0KoaQgICAgICAgICAxMDBHRaGqR01QLS0tT0RVQzEtLS1PVFVDMQ0KoaQgICAg ICAgICAxMDBHRS0tLUdNUC0tLU9EVTQtLS1PRFVDMS0tLU9UVUMxDQpJcyB0aGF0IGNvcnJlY3Qg b3IgYXJlIHRoZXJlIHN0aWxsIG1vcmUgb3B0aW9ucy4gSS5lLiBub3Qgc28gY2xlYXIgaG93IHRv IA0KZGVhbCB3aXRoIE9EVWZsZXggb2Ygc29tZSBraW5kIGFuZCBtYXliZSBHRlAtRiBtYXBwaW5n IGlzIGFsc28gc3RpbGwgYW4gDQpvcHRpb24uIFByZXN1bWFibHkgdGhlcmUgYXJlIGFsc28gb3B0 aW9ucyBsaWtlIG4gdGltZXMgT0RVMiBpbiBPRFVDMSAoaXMgbiANCnN0aWxsIGxpbWl0ZWQgdG8g OCBpbiB0aGlzIGNhc2U/KS4NCiANClRoYW5rcw0KIA0KR2VydA0KIA0KRnJvbTogQ0NBTVAgPGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAid2FuZy5xaWxlaUB6dGUuY29tLmNu IiANCjx3YW5nLnFpbGVpQHp0ZS5jb20uY24+DQpEYXRlOiBGcmlkYXkgMTggTm92ZW1iZXIgMjAx NiBhdCAxMDoxNA0KVG86ICJodXViYXR3b3JrQGdtYWlsLmNvbSIgPGh1dWJhdHdvcmtAZ21haWwu Y29tPg0KQ2M6IENDQU1QIDxjY2FtcEBpZXRmLm9yZz4sIENDQU1QIDxjY2FtcC1ib3VuY2VzQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0K IA0KSGkgSHV1YiwgDQoNCllvdSBhcmUgY29ycmVjdC4gDQoNClRoYW5rcyANClFpbGVpDQoNCg0K DQpIdXViIHZhbiBIZWx2b29ydCA8aHV1YmF0d29ya0BnbWFpbC5jb20+IA0Kt6K8/sjLOiAgIkND QU1QIiA8Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gDQoyMDE2LzExLzE4IDAwOjA2IA0KDQoNCsfr tPC4tCC4+A0KaHV1YmF0d29ya0BnbWFpbC5jb20NCg0KDQoNCsrVvP7Iyw0KY2NhbXBAaWV0Zi5v cmcsIA0Ks63LzQ0KDQrW98ziDQpSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9u DQogDQoNCg0KDQoNCg0KDQoNCg0KSGVsbG8gR2VydCwNCg0KWW91ciB1c2UgY2FzZSBpcyBub3Qg Y29tcGxldGVseSBjb3JyZWN0Lg0KDQpJbnN0ZWFkIG9mOg0KDQoyLiAgICAgICBBIHVzZSBjYXNl IHRvIGNvbnNpZGVyIGlzOiANCiAgDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKyArLS0tLS0tLS0tLS0rIA0KMTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0 LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC18LS0x MDBHRSANCg0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LSsgKy0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAgICAgICAgIE5F MiAoPUdXLU5FKSAgICAgICAgICAgICAgICAgICAgICAgTkUzIA0KDQoNCkl0IHNob3VsZCBiZTog DQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICst LS0tLS0tLS0tLS0tLS0tLS0tLSsgDQoxMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwt T0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLU9EVTQtR01QLXwtLTEw MEdFIA0KDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t KyArLS0tLS0tLS0tLS0tLS0tLS0tLS0rICANCg0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAg ICAgICAgICAgTkUyICg9R1ctTkUpICAgICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9E VUMxIGZyb20gTkUyIHRvIE5FMyB0dW5uZWxzIHRoZSBPRFU0LiANClJlZ2FyZHMsIEh1dWIuIA0K LS0gDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3Qg bGlrZSBldmVyeW9uZSBlbHNlLi4uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQo= --=_alternative 000BE1C04825806F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdlcnQsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGRvbid0IHRoaW5rIHRoZSBzZWNvbmQg d2F5IGlzIGNvcnJlY3QuDQpCZWNhdXNlIGFzIGRlZmluZWQgaW4gRy43MDksIE9EVUNuIGNhbiBv bmx5IGJlIHVzZWQgdG8gY2FycnkgT1ROIGNsaWVudHMoaS5lLiwNCk9EVTAsIE9EVTEuLi4sT0RV NCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFu a3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlFpbGVpPGJyPg0K PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdl cnQgR3JhbW1lbCAmbHQ7Z2dyYW1tZWxAanVuaXBlci5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYvMTEvMTggMTA6MDE8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7d2Fu Zy5xaWxlaUB6dGUuY29tLmNuJnF1b3Q7ICZsdDt3YW5nLnFpbGVpQHp0ZS5jb20uY24mZ3Q7LA0K JnF1b3Q7aHV1YmF0d29ya0BnbWFpbC5jb20mcXVvdDsgJmx0O2h1dWJhdHdvcmtAZ21haWwuY29t Jmd0OywgPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtjY2FtcEBpZXRmLm9yZyZxdW90OyAmbHQ7 Y2NhbXBAaWV0Zi5vcmcmZ3Q7LA0KQ0NBTVAgJmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9u PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPkh1dWIsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoYW5rcyBm b3IgY2xhcmlmeWluZy4gVGhlIGFpbSBvZiB0aGlzDQp0aHJlYWQgaXMgdG8gY29udmVyZ2Ugb24g YSBjbGVhciBwaWN0dXJlIHNvIHRoYXQgd2UgY2FuIGdhdWdlIHdoYXShr3MNCm5lZWRlZCBvbiBD UCBsZXZlbCB0byBzdXBwb3J0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+RnJvbSB5b3VyIGV4cGxhbmF0aW9uIGl0IHNlZW1zIHRoZXJlIGFyZQ0KMyBkaWZmZXJlbnQg d2F5cyB0byBtYXAgMTAwR0UgaW50byBhbiBPRFU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IlN5bWJvbCI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+MTAwR0WhqkdNUC0tLU9EVTQtLS1PVFU0PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJTeW1ib2wiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjEwMEdFoapHTVAtLS1PRFVDMS0t LU9UVUMxPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJTeW1ib2wiPqGkICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjEw MEdFLS0tR01QLS0tT0RVNC0tLU9EVUMxLS0tT1RVQzE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPklzIHRoYXQgY29ycmVjdCBvciBhcmUgdGhlcmUgc3RpbGwgbW9yZQ0K b3B0aW9ucy4gSS5lLiBub3Qgc28gY2xlYXIgaG93IHRvIGRlYWwgd2l0aCBPRFVmbGV4IG9mIHNv bWUga2luZCBhbmQgbWF5YmUNCkdGUC1GIG1hcHBpbmcgaXMgYWxzbyBzdGlsbCBhbiBvcHRpb24u IFByZXN1bWFibHkgdGhlcmUgYXJlIGFsc28gb3B0aW9ucw0KbGlrZSBuIHRpbWVzIE9EVTIgaW4g T0RVQzEgKGlzIG4gc3RpbGwgbGltaXRlZCB0byA4IGluIHRoaXMgY2FzZT8pLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5UaGFua3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ R2VydDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48Yj5Gcm9tOiA8L2I+Q0NBTVAgJmx0 O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQpvbiBiZWhhbGYgb2YgJnF1b3Q7d2FuZy5xaWxl aUB6dGUuY29tLmNuJnF1b3Q7ICZsdDt3YW5nLnFpbGVpQHp0ZS5jb20uY24mZ3Q7PGI+PGJyPg0K RGF0ZTogPC9iPkZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDEwOjE0PGI+PGJyPg0KVG86IDwv Yj4mcXVvdDtodXViYXR3b3JrQGdtYWlsLmNvbSZxdW90OyAmbHQ7aHV1YmF0d29ya0BnbWFpbC5j b20mZ3Q7PGI+PGJyPg0KQ2M6IDwvYj5DQ0FNUCAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7LCBDQ0FN UCAmbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDs8Yj48YnI+DQpTdWJqZWN0OiA8L2I+UmU6 IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkhpIEh1dWIsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpZb3UgYXJlIGNvcnJlY3QuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NClRoYW5rczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpRaWxlaTwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTIlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5IdXViIHZhbiBIZWx2b29ydCAmbHQ7aHV1YmF0 d29ya0BnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pjxmb250IHNpemU9MT48YnI+DQq3orz+yMs8 L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjogJm5ic3A7JnF1b3Q7Q0NBTVAm cXVvdDsNCiZsdDtjY2FtcC1ib3VuY2VzQGlldGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDE2LzExLzE4IDAwOjA2PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xPsfr tPC4tDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0xPrj4PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpodXVi YXR3b3JrQGdtYWlsLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTQ3 JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MTMlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0iTVMgTWluY2hvIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9ODYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5jY2FtcEBpZXRmLm9yZywgPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJNUyBNaW5jaG8iPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9Ik1TIE1pbmNobyI+1vc8L2ZvbnQ+PGZvbnQgc2l6ZT0xPsziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1QXSBPRFU0 IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9mb250PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPGJyPg0KSGVsbG8g R2VydCw8YnI+DQo8YnI+DQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3Qu PGJyPg0KPGJyPg0KSW5zdGVhZCBvZjo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPjxiPjxicj4NCjIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvYj5BIHVzZSBjYXNlIHRv IGNvbnNpZGVyIGlzOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Yj48YnI+DQogPC9i PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGI+PGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICstLS0tLS0tLS0tKyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KKy0tLS0tLS0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLS0tLS0rPC9iPjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48Yj48YnI+DQoxMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RV NC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLTEwMEdFPC9iPjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Yj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Ky0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQor LS0tLS0tLS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICstLS0tLS0tLS0tLSsNCiZuYnNwOyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUxICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtORTIgKD1HVy1ORSkgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxicj4NCkl0IHNob3VsZCBiZTogPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tLS0tKyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KKy0tLS0tLS0tLS0tLS0t LS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0t LS0tLS0tLS0tLS0tLS0tLS0rPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPjxicj4N CjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMx LS0tT1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L2I+PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tLS0tKyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KKy0tLS0tLS0tLS0tLS0t LS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQombmJzcDsgPC9iPjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDtORTEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO05FMiAoPUdXLU5FKSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBORTM8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxicj4NCjxicj4NClRoZSBPRFVDMSBmcm9tIE5FMiB0byBORTMgdHVubmVscyB0aGUgT0RV NC4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+UmVnYXJk cywgSHV1Yi4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4tLSA8 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PGJyPg0KQWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5q dXN0IGxpa2UgZXZlcnlvbmUgZWxzZS4uLjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT48YnI+DQo8L3U+PC9mb250 PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcD48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvdT48L2ZvbnQ+PC9hPg0KPHA+DQo= --=_alternative 000BE1C04825806F_=-- From nobody Thu Nov 17 18:25:11 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078181299E6 for ; Thu, 17 Nov 2016 18:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 t7vY3YzOWMSv for ; Thu, 17 Nov 2016 18:25:08 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0130.outbound.protection.outlook.com [104.47.41.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156161295C8 for ; Thu, 17 Nov 2016 18:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xZgyDJaDrW6jamAAZ61Q4VTK16nPF1HCd9DT3owdxqY=; b=RO0hhvzDr7YOXrZiZqv9E7f04mEG4eedIkOAFZGSvnwGm37ar7xyuQBZX+vnRUqqQ6VgsG4/U742bUkDlYRUcIKYKXAFUxPkTEXO3AVZ5oYj3PXEDiRtk0eAc8dPKTSHeQBDvKtbXREnCQrjUDzr6IrT+gfxeUse+8LvJruNfnU= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 18 Nov 2016 02:25:06 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0747.004; Fri, 18 Nov 2016 02:25:06 +0000 From: Gert Grammel To: "wang.qilei@zte.com.cn" , "huubatwork@gmail.com" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgACZP4CAAKQWAP//a3qAgACa+gA= Date: Fri, 18 Nov 2016 02:25:06 +0000 Message-ID: <6E007860-6359-456F-B4BE-CEAC9198FC6C@juniper.net> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.188.14] x-ms-office365-filtering-correlation-id: 8cc41ec0-ced3-4a18-a834-08d40f5a1c37 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1609; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1609; 7:8qmivR7UyxQtdkOMszeWaB+LqVdfi0vSq1LTr4P3n+iLhu1+NjQuCGj+R8aINO5GzMdDhBxKeePOKJYpqzB7WfiLpPc66IzHIrWbxUcwgvgBCUCX8TTK29a6JhU9mPSftwL1z1bHG7Z5NfuhKtYZzR7MuxNe8si4pjL3ghGIG4WvEDuMqmQpRy6Doc+Y1t5ajji7r7mYTkscszGsL75t7E4R3+reMSsfku6nOuN+xyXKt8mtybmxjts35Q3y48gxUbbPaut3JEvYHeohoZXyk7W3oPWBMEV0SVMapway4lg7FOcGye9hnzMI6zebO4MHhFWcluVX+BEJ34a9Yc61TFxlrOzPgmLTDUEuCMykMDRrwtfEhc8CpCKcCYmf98sw1loqf5mslzFygLayuVrBzkfKm+ZZDZueMLmTZQCCkIN2oSvfaOsG7uhVZZVvwCfCUhWx5VJ6FlFA+DBttwLFLQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041223)(6061324); SRVR:CY1PR0501MB1609; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1609; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(189998001)(6506003)(606004)(6512003)(7846002)(8676002)(105586002)(106116001)(106356001)(81166006)(77096005)(229853002)(81156014)(7736002)(99286002)(5001770100001)(4001350100001)(33656002)(122556002)(97736004)(36756003)(101416001)(7906003)(50986999)(54356999)(82746002)(2906002)(83506001)(3660700001)(8936002)(76176999)(83716003)(5660300001)(4326007)(6116002)(3846002)(102836003)(2950100002)(66066001)(87936001)(3280700002)(2900100001)(2501003)(68736007)(93886004)(86362001)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1609; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6E0078606359456FB4BECEAC9198FC6Cjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 02:25:06.0435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1609 Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:25:10 -0000 --_000_6E0078606359456FB4BECEAC9198FC6Cjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UWlsZWksDQoNCkxvb2tpbmcgZm9yd2FyZCwgd291bGQgdGhhdCB0aGVuIG1lYW4gdGhhdCBhIDQw MEdFIHdvdWxkIG5lZWQgdG8gYmUgbWFwcGVkIGludG8gYW4gT0RVNSBiZWZvcmUgaXQgZ29lcyBp bnRvIGFuIE9EVUM0PyBJcyBzdWNoIE9EVTUgYWxyZWFkeSBkZWZpbmVkPyBJIGFtIHByb2JhYmx5 IGEgYml0IGNvbmZ1c2VkIGFib3V0IGFsbCB0aGUgb3B0aW9ucyBhbmQgZ3Vlc3MgdGhlIFdHIGlz IHNvIHRvby4gSSBsaWtlIHRvIHJlZnJhaW4gaGVyZSBmcm9tIGZ1cnRoZXIgZ3Vlc3NpbmcgYXMg aXQgbWF5IGV2ZW4gYWRkIHRvIGNvbmZ1c2lvbiBtdWNoIG1vcmUgdGhhbiBjbGFyaWZ5aW5nIGFu eXRoaW5nLiBJdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgYW5kL29yIEh1dWIgY291bGQgY29tZSB1 cCB3aXRoIGEgZGVzY3JpcHRpb24vcHJlc2VudGF0aW9uIHRoYXQgY2FuIGJlIGNvbnN1bWVkIG1v cmUgZWFzaWx5IHRoYW4gYW4gZW1haWwgdGhyZWFkIGFzIGEgYmFzaXMgZm9yIGZ1cnRoZXIgZGlz Y3Vzc2lvbi4gQXQgbGVhc3QgdGhpcyB3YXkgd2Ugd291bGQgaGF2ZSBhIHRlY2huaWNhbGx5IGNv cnJlY3QgdXNlIGNhc2UgdGhhdCBjYW4gYmUgdXNlZCBmb3IgZnVydGhlciBlbGFib3JhdGlvbi4N Cg0KVGhhbmtzDQpHZXJ0DQoNCkZyb206ICJ3YW5nLnFpbGVpQHp0ZS5jb20uY24iIDx3YW5nLnFp bGVpQHp0ZS5jb20uY24+DQpEYXRlOiBGcmlkYXkgMTggTm92ZW1iZXIgMjAxNiBhdCAxMToxMA0K VG86IEdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+LCAiaHV1YmF0d29ya0BnbWFp bC5jb20iIDxodXViYXR3b3JrQGdtYWlsLmNvbT4NCkNjOiBDQ0FNUCA8Y2NhbXBAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNCkhpIEdl cnQsDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHNlY29uZCB3YXkgaXMgY29ycmVjdC4gQmVjYXVzZSBh cyBkZWZpbmVkIGluIEcuNzA5LCBPRFVDbiBjYW4gb25seSBiZSB1c2VkIHRvIGNhcnJ5IE9UTiBj bGllbnRzKGkuZS4sIE9EVTAsIE9EVTEuLi4sT0RVNCkuDQoNClRoYW5rcw0KUWlsZWkNCg0KDQpH ZXJ0IEdyYW1tZWwgPGdncmFtbWVsQGp1bmlwZXIubmV0Pg0KDQoyMDE2LzExLzE4IDEwOjAxDQoN CuaUtuS7tuS6ug0KDQoid2FuZy5xaWxlaUB6dGUuY29tLmNuIiA8d2FuZy5xaWxlaUB6dGUuY29t LmNuPiwgImh1dWJhdHdvcmtAZ21haWwuY29tIiA8aHV1YmF0d29ya0BnbWFpbC5jb20+LA0KDQrm ioTpgIENCg0KImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+LCBDQ0FNUCA8Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZz4NCg0K5Li76aKYDQoNClJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNu IGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KSHV1YiwNCg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5n LiBUaGUgYWltIG9mIHRoaXMgdGhyZWFkIGlzIHRvIGNvbnZlcmdlIG9uIGEgY2xlYXIgcGljdHVy ZSBzbyB0aGF0IHdlIGNhbiBnYXVnZSB3aGF04oCZcyBuZWVkZWQgb24gQ1AgbGV2ZWwgdG8gc3Vw cG9ydC4NCkZyb20geW91ciBleHBsYW5hdGlvbiBpdCBzZWVtcyB0aGVyZSBhcmUgMyBkaWZmZXJl bnQgd2F5cyB0byBtYXAgMTAwR0UgaW50byBhbiBPRFUNCuKAoiAgICAgICAgIDEwMEdF4oCUR01Q LS0tT0RVNC0tLU9UVTQNCuKAoiAgICAgICAgIDEwMEdF4oCUR01QLS0tT0RVQzEtLS1PVFVDMQ0K 4oCiICAgICAgICAgMTAwR0UtLS1HTVAtLS1PRFU0LS0tT0RVQzEtLS1PVFVDMQ0KSXMgdGhhdCBj b3JyZWN0IG9yIGFyZSB0aGVyZSBzdGlsbCBtb3JlIG9wdGlvbnMuIEkuZS4gbm90IHNvIGNsZWFy IGhvdyB0byBkZWFsIHdpdGggT0RVZmxleCBvZiBzb21lIGtpbmQgYW5kIG1heWJlIEdGUC1GIG1h cHBpbmcgaXMgYWxzbyBzdGlsbCBhbiBvcHRpb24uIFByZXN1bWFibHkgdGhlcmUgYXJlIGFsc28g b3B0aW9ucyBsaWtlIG4gdGltZXMgT0RVMiBpbiBPRFVDMSAoaXMgbiBzdGlsbCBsaW1pdGVkIHRv IDggaW4gdGhpcyBjYXNlPykuDQoNClRoYW5rcw0KDQpHZXJ0DQoNCkZyb206IENDQU1QIDxjY2Ft cC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIndhbmcucWlsZWlAenRlLmNvbS5jbiIg PHdhbmcucWlsZWlAenRlLmNvbS5jbj4NCkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0 IDEwOjE0DQpUbzogImh1dWJhdHdvcmtAZ21haWwuY29tIiA8aHV1YmF0d29ya0BnbWFpbC5jb20+ DQpDYzogQ0NBTVAgPGNjYW1wQGlldGYub3JnPiwgQ0NBTVAgPGNjYW1wLWJvdW5jZXNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNCkhp IEh1dWIsDQoNCllvdSBhcmUgY29ycmVjdC4NCg0KVGhhbmtzDQpRaWxlaQ0KSHV1YiB2YW4gSGVs dm9vcnQgPGh1dWJhdHdvcmtAZ21haWwuY29tPg0K5Y+R5Lu25Lq6OiAgIkNDQU1QIiA8Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZz4NCg0KMjAxNi8xMS8xOCAwMDowNg0KDQoNCuivt+etlOWkjSDnu5kN Cmh1dWJhdHdvcmtAZ21haWwuY29tDQoNCg0KDQrmlLbku7bkuroNCg0KY2NhbXBAaWV0Zi5vcmcs DQoNCuaKhOmAgQ0KDQrkuLvpopgNCg0KUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vz c2lvbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhlbGxvIEdlcnQsDQoNCllvdXIgdXNlIGNhc2Ug aXMgbm90IGNvbXBsZXRlbHkgY29ycmVjdC4NCg0KSW5zdGVhZCBvZjoNCg0KMi4gICAgICAgQSB1 c2UgY2FzZSB0byBjb25zaWRlciBpczoNCg0KICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtfC0tMTAwR0UNCiAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICBO RTEgICAgICAgICAgICAgICAgICAgIE5FMiAoPUdXLU5FKSAgICAgICAgICAgICAgICAgICAgICAg TkUzDQoNCkl0IHNob3VsZCBiZToNCg0KICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjEw MEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0t T1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICstLS0tLS0tLS0tKyAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQoNCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAgICAgICAgIE5FMiAoPUdX LU5FKSAgICAgICAgICAgICAgICAgICAgICAgTkUzDQoNClRoZSBPRFVDMSBmcm9tIE5FMiB0byBO RTMgdHVubmVscyB0aGUgT0RVNC4NCg0KUmVnYXJkcywgSHV1Yi4NCg0KLS0NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkFs d2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVzdCBsaWtlIGV2ZXJ5b25lIGVs c2UuLi5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NB TVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcA0K --_000_6E0078606359456FB4BECEAC9198FC6Cjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <408FAA48FFD8B04DB968349FDAC004A9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpzYW5zLXNlcmlm Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu Lm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToi IjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCA1Ni43cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlFpbGVpLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPkxvb2tpbmcgZm9yd2FyZCwgd291bGQgdGhhdCB0aGVuIG1lYW4gdGhhdCBhIDQwMEdF IHdvdWxkIG5lZWQgdG8gYmUgbWFwcGVkIGludG8gYW4gT0RVNSBiZWZvcmUgaXQgZ29lcyBpbnRv IGFuIE9EVUM0PyBJcyBzdWNoIE9EVTUgYWxyZWFkeSBkZWZpbmVkPyBJIGFtIHByb2JhYmx5IGEg Yml0IGNvbmZ1c2VkIGFib3V0IGFsbA0KIHRoZSBvcHRpb25zIGFuZCBndWVzcyB0aGUgV0cgaXMg c28gdG9vLiBJIGxpa2UgdG8gcmVmcmFpbiBoZXJlIGZyb20gZnVydGhlciBndWVzc2luZyBhcyBp dCBtYXkgZXZlbiBhZGQgdG8gY29uZnVzaW9uIG11Y2ggbW9yZSB0aGFuIGNsYXJpZnlpbmcgYW55 dGhpbmcuIEl0IHdvdWxkIGJlIGdyZWF0IGlmIHlvdSBhbmQvb3IgSHV1YiBjb3VsZCBjb21lIHVw IHdpdGggYSBkZXNjcmlwdGlvbi9wcmVzZW50YXRpb24gdGhhdCBjYW4gYmUgY29uc3VtZWQNCiBt b3JlIGVhc2lseSB0aGFuIGFuIGVtYWlsIHRocmVhZCBhcyBhIGJhc2lzIGZvciBmdXJ0aGVyIGRp c2N1c3Npb24uIEF0IGxlYXN0IHRoaXMgd2F5IHdlIHdvdWxkIGhhdmUgYSB0ZWNobmljYWxseSBj b3JyZWN0IHVzZSBjYXNlIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGZ1cnRoZXIgZWxhYm9yYXRpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+R2VydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPiZxdW90O3dhbmcucWlsZWlAenRlLmNvbS5jbiZxdW90OyAm bHQ7d2FuZy5xaWxlaUB6dGUuY29tLmNuJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXkgMTgg Tm92ZW1iZXIgMjAxNiBhdCAxMToxMDxicj4NCjxiPlRvOiA8L2I+R2VydCBHcmFtbWVsICZsdDtn Z3JhbW1lbEBqdW5pcGVyLm5ldCZndDssICZxdW90O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7 ICZsdDtodXViYXR3b3JrQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkNDQU1QICZsdDtj Y2FtcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtDQ0FNUF0gT0RVNCBh bmQgT0RVQ24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkhpIEdlcnQsPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+SSBkb24ndCB0aGluayB0aGUgc2Vjb25kIHdheSBpcyBjb3JyZWN0LiBC ZWNhdXNlIGFzIGRlZmluZWQgaW4gRy43MDksIE9EVUNuIGNhbiBvbmx5IGJlIHVzZWQgdG8gY2Fy cnkgT1ROIGNsaWVudHMoaS5lLiwgT0RVMCwgT0RVMS4uLixPRFU0KS48L3NwYW4+DQo8YnI+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtzYW5z LXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGFua3M8L3NwYW4+IDxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPlFpbGVpPGJyPg0KPC9zcGFuPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHdpZHRoPSIzNiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MzYuMCU7cGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkdlcnQgR3JhbW1lbCAmbHQ7Z2dyYW1tZWxAanVuaXBl ci5uZXQmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4yMDE2LzExLzE4IDEw OjAxPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyUiIHZhbGln bj0idG9wIiBzdHlsZT0id2lkdGg6NjMuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw dCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWlu Y2hvJnF1b3Q7Ij7mlLbku7bkuro8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZxdW90O3dhbmcucWls ZWlAenRlLmNvbS5jbiZxdW90OyAmbHQ7d2FuZy5xaWxlaUB6dGUuY29tLmNuJmd0OywgJnF1b3Q7 aHV1YmF0d29ya0BnbWFpbC5jb20mcXVvdDsgJmx0O2h1dWJhdHdvcmtAZ21haWwuY29tJmd0OywN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+ 5oqE6YCBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNl cmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mcXVvdDtjY2FtcEBpZXRmLm9yZyZxdW90OyAm bHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7LCBDQ0FNUCAmbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZn dDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90 OyI+5Li7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6U2lt U3VuIj7popg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMt c2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNu IGRpc2N1c3Npb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4N Cjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SHV1Yiw8L3NwYW4+IDxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNw Ozwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+VGhhbmtzIGZvciBjbGFyaWZ5aW5nLiBUaGUgYWltIG9mIHRoaXMgdGhyZWFkIGlz IHRvIGNvbnZlcmdlIG9uIGEgY2xlYXIgcGljdHVyZSBzbyB0aGF0IHdlIGNhbiBnYXVnZSB3aGF0 4oCZcyBuZWVkZWQgb24gQ1AgbGV2ZWwgdG8gc3VwcG9ydC48L3NwYW4+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Gcm9tIHlvdXIgZXhw bGFuYXRpb24gaXQgc2VlbXMgdGhlcmUgYXJlIDMgZGlmZmVyZW50IHdheXMgdG8gbWFwIDEwMEdF IGludG8gYW4gT0RVPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sIj7CtyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2wiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjEwMEdF4oCUR01QLS0tT0RVNC0t LU9UVTQ8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wiPsK3IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+MTAwR0XigJRHTVAtLS1PRFVDMS0tLU9UVUMx PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 U3ltYm9sIj7CtyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjEwMEdFLS0tR01QLS0tT0RVNC0tLU9EVUMxLS0tT1RV QzE8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5JcyB0aGF0IGNvcnJlY3Qgb3IgYXJlIHRoZXJlIHN0aWxsIG1vcmUgb3B0aW9u cy4gSS5lLiBub3Qgc28gY2xlYXIgaG93IHRvIGRlYWwgd2l0aCBPRFVmbGV4IG9mIHNvbWUga2lu ZCBhbmQgbWF5YmUgR0ZQLUYgbWFwcGluZyBpcyBhbHNvIHN0aWxsIGFuIG9wdGlvbi4gUHJlc3Vt YWJseSB0aGVyZSBhcmUgYWxzbyBvcHRpb25zIGxpa2UgbiB0aW1lcyBPRFUyDQogaW4gT0RVQzEg KGlzIG4gc3RpbGwgbGltaXRlZCB0byA4IGluIHRoaXMgY2FzZT8pLjwvc3Bhbj4gPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9z cGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5UaGFua3M8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+R2VydDwvc3Bhbj4gPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFu PiA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Q0NBTVAgJmx0O2NjYW1wLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDt3YW5nLnFpbGVpQHp0ZS5jb20u Y24mcXVvdDsgJmx0O3dhbmcucWlsZWlAenRlLmNvbS5jbiZndDs8Yj48YnI+DQpEYXRlOiA8L2I+ RnJpZGF5IDE4IE5vdmVtYmVyIDIwMTYgYXQgMTA6MTQ8Yj48YnI+DQpUbzogPC9iPiZxdW90O2h1 dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7ICZsdDtodXViYXR3b3JrQGdtYWlsLmNvbSZndDs8Yj48 YnI+DQpDYzogPC9iPkNDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDssIENDQU1QICZsdDtjY2Ft cC1ib3VuY2VzQGlldGYub3JnJmd0OzxiPjxicj4NClN1YmplY3Q6IDwvYj5SZTogW0NDQU1QXSBP RFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPiA8YnI+DQombmJzcDsgPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+SGkgSHV1Yiw8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxicj4NCllvdSBhcmUgY29ycmVjdC48L3NwYW4+IDxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NClRoYW5rczwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyPg0KUWlsZWk8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIg c3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjUyJSIgdmFs aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo1Mi4wJTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ SHV1YiB2YW4gSGVsdm9vcnQgJmx0O2h1dWJhdHdvcmtAZ21haWwuY29tJmd0Ozwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTpTaW1TdW4iPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjog Jm5ic3A7JnF1b3Q7Q0NBTVAmcXVvdDsgJmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9z cGFuPg0KPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjIwMTYv MTEvMTggMDA6MDY8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+6K+3562U5aSNPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTpTaW1TdW4iPue7mTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxicj4NCmh1dWJhdHdvcmtAZ21haWwuY29tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgd2lkdGg9IjQ3JSIgdmFs aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo0Ny4wJTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIx MyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTMuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0 ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01TIE1pbmNobyZxdW90OyI+5pS25Lu25Lq6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjx0ZCB3aWR0aD0iODYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjg2LjAlO3Bh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5jY2FtcEBpZXRmLm9yZywNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5oqE6YCBPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5Li7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7popg8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPlJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Np b248L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIg c3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwPjxicj4NCjxicj4NCjxicj4NCjxicj4NCkhlbGxvIEdlcnQsPGJyPg0KPGJyPg0KWW91ciB1 c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Ljxicj4NCjxicj4NCkluc3RlYWQgb2Y6 PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PGJyPg0KMi4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BIHVzZSBjYXNlIHRvIGNvbnNp ZGVyIGlzOjwvc3Bhbj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8 L3NwYW4+PC9iPiZuYnNwOzxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0t LS0tLSYjNDM7PC9zcGFuPjwvYj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 YnI+DQoxMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEtfC1P VFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLTEwMEdFPC9zcGFuPjwvYj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0t LS0tLS0tLS0mIzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyA8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBORTEgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TkUy ICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9zcGFuPjwvYj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHA+PGJyPg0KSXQgc2hvdWxkIGJlOiA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0t LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48L2I+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KMTAwR0UtLXwt R01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18 LU9EVUMxLUdNUC1PRFU0LUdNUC18LS0xMDBHRTwvc3Bhbj48L2I+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0Mzsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0mIzQzOyAmbmJzcDsNCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ DQo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TkUxICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05FMiAoPUdXLU5F KSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5FMzwvc3Bhbj48L2I+PGJyPg0KPGJyPg0KVGhlIE9EVUMx IGZyb20gTkUyIHRvIE5FMyB0dW5uZWxzIHRoZSBPRFU0LiA8bzpwPjwvbzpwPjwvcD4NCjxwPlJl Z2FyZHMsIEh1dWIuIDxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLSA8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KQWx3YXlzIHJl bWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZlcnlvbmUgZWxzZS4uLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRmLm9yZzwvc3Bhbj48 dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvc3Bhbj48L2E+DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E0078606359456FB4BECEAC9198FC6Cjunipernet_-- From nobody Fri Nov 18 03:54:38 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA296129656; Fri, 18 Nov 2016 03:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7svsFBwYWOBX; Fri, 18 Nov 2016 03:54:34 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D772E129664; Fri, 18 Nov 2016 03:54:33 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g23so33215112wme.1; Fri, 18 Nov 2016 03:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=5nxrvkIq63cdba7r8pK2nvHXO0fV4Z6TGKlzz1rsIA0=; b=hTC6Ss8MyHCLLxwDBrpvr+CzTUamAH990d6TI4l/B3jv+22EAzwY183GltkOfjQQtk GKGR95n5ZwgQU16PwlUiiznvfM01JT3WMBUQAy35vIo0ZZvq8KY5OUdlUr6bo9+KDnWQ 0aWd2C7nmGJBUqemeqIDu11fXUgByp3Q/AG1pMAW1EVTMVneAx4ggHZc3ci6F9GlvnBt qjK559Bkbf+7hUV2hGrnlsaOKp/EHk25BQrA9+FOkZxISaWTKWfs48GXNShoNhx3z25s nShcgosTlals+dta4IrvTxtXsJMADaSFwTkFTq2i6KnEMlCmHLLlMsAmUmkkEEx30SQX 4t+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=5nxrvkIq63cdba7r8pK2nvHXO0fV4Z6TGKlzz1rsIA0=; b=W0zWFeilG9/LeN4XrQTupihfcmCf/fM2x946fqbqhKofIUUmH8DkXTvrAbG94pL8xy d4rWi/Xe/98JHXgqlCrSU9gYUQOtpn2daJSRhX1gVnsrqxPqIa5DvJeClJ/9JvX9AAhG 3kgOP7YlpXWj03YMhFz7Fn96wkbeJrniY6tBFFJoL5r2JbWa7V6NMFd8mBwoSPRLcm6G j1gPhKVmBEembchCuFYs4rWXnAiPxCgJJh+TMouxOXLJR8kuZ53K3OGtIVLx7E0CWToA bQxKF6+9e+h68VoSt3558WTkIaQCakDJcTkiQx5zyZ5PvTOGG+S0HrToXQF4py6lFkSb wLTQ== X-Gm-Message-State: ABUngve9JdIcpLwWAXeIfMZBFy50RzuExqzRw1IoMUTPzETc/Joev4LzVKIPtyPGu/3X+g== X-Received: by 10.28.71.137 with SMTP id m9mr20927788wmi.88.1479470072380; Fri, 18 Nov 2016 03:54:32 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id pd2sm8434144wjb.31.2016.11.18.03.54.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 03:54:31 -0800 (PST) References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> To: Gert Grammel , "wang.qilei@zte.com.cn" From: Huub van Helvoort Message-ID: <6d212142-a90f-0307-3df7-9e255044a259@gmail.com> Date: Fri, 18 Nov 2016 12:54:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ccamp@ietf.org" , CCAMP Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 11:54:36 -0000
Gert,

You reply:

Thanks for clarifying. The aim of this thread is to converge on a clear picture so that we can gauge what’s needed on CP level to support.

The clear picture you are looking for is Figure 7-1 of G.709 (2016).

From your explanation it seems there are 3 different ways to map 100GE into an ODU

·         100GE—GMP---ODU4---OTU4

OK.

·         100GE—GMP---ODUC1---OTUC1

No, not in G.709/Figure 7-1

·         100GE---GMP---ODU4---ODUC1---OTUC1

Almost correct. It is 100GE---GMP---ODU4---GMP---ODUC1---OTUC1 (as I mentioned in my previous email.

Is that correct or are there still more options.

That is the current situation.

I.e. not so clear how to deal with ODUflex of some kind and maybe GFP-F mapping is also still an option.

That is relevant only when you want to transport a client signal with a bandwidth
different from 100GE.

Presumably there are also options like n times ODU2 in ODUC1 (is n still limited to 8 in this case?).

Gain llok at G.709/Figure 7-1.

Regards, Huub.
 

From: CCAMP <ccamp-bounces@ietf.org> on behalf of "wang.qilei@zte.com.cn" <wang.qilei@zte.com.cn>
Date: Friday 18 November 2016 at 10:14
To: "huubatwork@gmail.com" <huubatwork@gmail.com>
Cc: CCAMP <ccamp@ietf.org>, CCAMP <ccamp-bounces@ietf.org>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

 

Hi Huub,

You are correct.

Thanks
Qilei


Huub van Helvoort <huubatwork@gmail.com>
发件人:  "CCAMP" <ccamp-bounces@ietf.org>

2016/11/18 00:06

请答复 给
huubatwork@gmail.com

收件人

ccamp@ietf.org,

抄送

主题

Re: [CCAMP] ODU4 and ODUCn discussion

 




Hello Gert,

Your use case is not completely correct.

Instead of:

2.       A use case to consider is:
 
       +----------+             +----------------+               +-----------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-|--100GE
       +----------+             +----------------+               +-----------+  
             NE1                    NE2 (=GW-NE)                       NE3


It should be:

       +----------+             +----------------+               +--------------------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE
       +----------+             +----------------+               +--------------------+  

             NE1                    NE2 (=GW-NE)                       NE3

The ODUC1 from NE2 to NE3 tunnels the ODU4.

Regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else..._______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp



-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Fri Nov 18 04:13:37 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D31129476 for ; Fri, 18 Nov 2016 04:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uwl7MXyX7A5h for ; Fri, 18 Nov 2016 04:13:35 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2051F12962D for ; Fri, 18 Nov 2016 04:13:35 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id t79so33673451wmt.0 for ; Fri, 18 Nov 2016 04:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Jw9I8uSMZrPz1aWApygCmuW67ojf+sIOUibrxv2GSvw=; b=YwHIpQs/2E5taZa3Ko6peQsRl53uuFZV1KKw+4bqPW3LRgn7vZEmSRP/rKRpVNmdTp 6ZsATf76ilB1LzK++wEokF67JzsMCahKil3l50WWBbNfkCCsy3DY++ME8ExaD49r0R+b 9Dtun9RUkjWLa6P/xRYNpBz0KBUVbViLwK1fsGYoqauWbjka2Xkaox/UtkDMM2bFk1SQ JefDhGz2ASod0tIdTXg7Q/lIwf/RWidrT8WEXgcMmFpqM4APrSZFV8VHUAh0C2Nf8slW kS5vUeLNVkBrmwu7dpBdVas1qHxuNSjCZ1sIymEliIv6kEYlAH2+RxqSR+HEGudDUyx9 GqRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Jw9I8uSMZrPz1aWApygCmuW67ojf+sIOUibrxv2GSvw=; b=jQOA7GhiKt8GfZeshVKpmzE4vyUnLLd12tH9RjkLTst2JXgUb0UQQCmIPbG8BEX4Yv PfTS5hbL7hmIvrXHXgE69Y/7ue3qR1kO3PhkOtzV4gMzB+yNL3GIud5LuiDpw2WX/H2H fbGLBEqOWo+PyTDs7gpEZpuhjQTQHVZcNTNJZwJGCR8r2wz095uufriZjo9FiXVDH/VW Ke2zo02K/RNZRoRuzboAdnaRRHPFcTNqEzXe8FA3/0k5piMm9K8pgy4mteIT1OROENiQ NE07Hyocic4SulM6uwaD3uVpuOnlC5+zBXXg1qtrbOpkcNvL+17QSaBZ3o1hlq/MGAIE i/+w== X-Gm-Message-State: ABUngve+3pFn4w+aRpYzLaphrMTm7wBkERVtyhLdUscAgrjx58Quk7JwJWm8xt1vlBzfxg== X-Received: by 10.28.143.68 with SMTP id r65mr10469101wmd.95.1479471213408; Fri, 18 Nov 2016 04:13:33 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id ua15sm8555685wjb.1.2016.11.18.04.13.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 04:13:32 -0800 (PST) References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <5AD93F3C-54F4-49A5-AF6A-0205482D45B0@juniper.net> <6E007860-6359-456F-B4BE-CEAC9198FC6C@juniper.net> To: Gert Grammel , "wang.qilei@zte.com.cn" From: Huub van Helvoort Message-ID: <78f988bc-adf5-c3d0-52b7-b42d39ad7616@gmail.com> Date: Fri, 18 Nov 2016 13:13:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6E007860-6359-456F-B4BE-CEAC9198FC6C@juniper.net> Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 12:13:36 -0000
Gert,

You wrote:
Looking forward, would that then mean that a 400GE would need to be mapped into an ODU5 before it goes into an ODUC4?
Why?
This is pure speculation.
IEEE has to define 400GE before ITU-T can describe the mapping.
IMHO the best option would be mapping the 400GE via GMP into an OPUC4.
I hope that they avoid an OPUC4e...
Is such ODU5 already defined?
No!  Read G.709 (2016) especially figure 7-1.
I am probably a bit confused about all the options and guess the WG is so too.
I hope this and my previous email makes it clear that there are only
two options for 100GE and there will be 1 solution for 400GE.
I like to refrain here from further guessing as it may even add to confusion much more than clarifying anything. It would be great if you and/or Huub could come up with a description/presentation that can be consumed more easily than an email thread as a basis for further discussion.
Because a picture can tell you more than a thousand words I recommend
to look at  G.709 (2016) Figure 7-1.

Regards, Huub.


-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Fri Nov 18 09:39:36 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0D112941C for ; Fri, 18 Nov 2016 09:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 Vgmz5Hm6fnTE for ; Fri, 18 Nov 2016 09:39:33 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72B0129453 for ; Fri, 18 Nov 2016 09:39:32 -0800 (PST) X-AuditID: c1b4fb25-adbff70000007ee2-8a-582f3cd0f1dd Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 4D.FD.32482.0DC3F285; Fri, 18 Nov 2016 18:39:31 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 18 Nov 2016 18:39:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RTBwySarlNm6sBmRawvvG8JgJE4joU2JPqFgi9tmmV0=; b=O89gwMACN/Zn84HuXDY3zBPjiZeurm6QWmOh0vnzXOe4LHk+9Y8YHUZYbYoi22fsVUGI9np0hBLEmtWYPkdGCvCZcMy6FXxHv3wbuU8UWLjqEzx+RDyIYJrdkrfB99+aI+wG0PK7gquFxf4HQKFlKZl3asfvieLxGDQXOXFWsCE= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0993.eurprd07.prod.outlook.com (10.162.37.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 18 Nov 2016 17:39:27 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0734.007; Fri, 18 Nov 2016 17:39:27 +0000 From: Daniele Ceccarelli To: "huubatwork@gmail.com" , "ccamp@ietf.org" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgAGrtCA= Date: Fri, 18 Nov 2016 17:39:27 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> In-Reply-To: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [88.128.80.42] x-ms-office365-filtering-correlation-id: 8cf1a26f-a659-4210-c7b3-08d40fd9d826 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0993; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0993; 7:8xdo2XjcRqv+0dYrv9/vZU36CBlucsWmkh3Q4G0CuEpuSoNX7Eiiz2HEpn/NSAP3JjamuGMPKsnSy91rfcPF1PlOjYpN91d7aK5+qA2qX9Ozgu3eOE71ZDB8v1v6khE7ZEMad2be2V0TPucDAXjQ73Y80YvrNm7wpsIjHq9dnntETLe6jlLJeJAsDGk9TIOdZL5Sj6ZydzR6L5M4bcNO/pVrYi/bCu+Yg3fr6PJJR9IF2BvVYAi4Kn+TstC6xwwym54hlKweoWMSFK0VzP/QUryDs/w9+WAu4WbzqMvRZ6gI7A8G+cvNzWPBZ1dcxl3UnGTNVo3WiWaoZNsbeRJfXNrt+4TE1w3AieavRsFHgVKWAWF15f3cr9v6h6APCK2sku6ytYg+KhfOnAdCxYLn+w2lKM84UvRIFdim/5SWdr7Aq8kQmoHkRmtrWODsYPdBgp+DxMdg7mGuoUmO8UyuLg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041223)(6061324); SRVR:AM2PR07MB0993; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0993; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(51914003)(86362001)(81156014)(50986999)(229853002)(101416001)(81166006)(66066001)(54356999)(76176999)(5001770100001)(76576001)(6506003)(2900100001)(77096005)(92566002)(105586002)(3280700002)(189998001)(3660700001)(68736007)(122556002)(2906002)(106116001)(9686002)(106356001)(8936002)(97736004)(3846002)(102836003)(790700001)(8676002)(7696004)(5660300001)(2501003)(2950100002)(87936001)(7736002)(74316002)(7846002)(107886002)(33656002)(6116002)(38730400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0993; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09947727F8473917709A6E50F0B00AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 17:39:27.3761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0993 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOfdlu64mp6n5aBY2sjRw841YzkKJwKBAg9QiyJk3HepmuyZq fvCDU9syldRSJ71gWZYNTGyKvQ0xjaJwBqWOFQ4pX9AsyKw0r1fBb7/n//yfc87/4TCkrJX2 Z7S6PNag02TLRRKqIeVJYqgjRpkS9qBSpHJbPlKq600OOpaI7250iuNbWn4TCcQpSUw6m63N Zw3Kg6mSzBcWI5G7YEIF1Z+WRSXIUo5MyIMBHAVXyky0CUkYGX6EoNPct1YMIFjqc60WFK4k 4VZpJyF06gh43PiQ4OdluB/BvyFvE2IYEY4Gt/0oj944CWqcRbzDCyugrPmDiGdvrIR+8yIS OBqWOy0kzxQOglHrIs2zFJ+GnslxUjj9PNifv129yQMfgM93p8U8I7wVfr0WXkBiXxhx3yCE NBhaet+RAvvAt/ElWvCngdVoW/MEQsfEqEjgY/B3uJRc5xlbvZiPCPgyBR0tP9cGsqC5ykUJ HA0VNa9oweRAMFc7S/CBAQfA7Lxa8Nyh4btbJQRgobXdiIRF+INz+NIaB8DXsad0NQpu3JBB YD2U/einGld3sQUGG9wrzKzoIWDtUQqWnVBr/iIWOBiMlmbxRv0mErchH47l0nIyIiIVrEF7 luP0OoWOzetAK9/nZeefIBtyTMfZEWaQfLM011eZIqM1+Vxhjh0BQ8q9pT3qFUmariksYg36 M4YL2SxnR9sYSu4r3XfflSzDGZo8Notlc1nDepdgPPxLkF/1iBxmqkI9CbeWm3zjtRilDkl0 TugWdher30fGDey/6jm1p65Jb0ufn5mTbCo4tFijwt3l9fawATJVoR090XUxtlAR3iWeOucc tManqq6NDbYXeW5vGwoO2VGsrhgyB7qSn0kyjH62pJPHNc57t4+kHo6nemNNEbsSyLwFOcVl asL3kgZO8x+b81SBOgMAAA== Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 17:39:35 -0000 --_000_AM2PR07MB09947727F8473917709A6E50F0B00AM2PR07MB0994eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY2xlYXIgZXhwbGFuYXRpb24gSHV1Yi4NCg0KSSBzZWUgdHdvIGRpZmZl cmVudCB1c2UgY2FzZXMgdGhhdCBib3RoIG1ha2Ugc2Vuc2UuIFRoZSBvbmUgcHJvcG9zZWQgYnkg R2VydCBpcyBzdGl0Y2hpbmcgb2YgYW4gT0RVNCBhbmQgT0RVQzEsIHdoaWxlIHRoZSBvbmUgeW91 IGFyZSBkZXNjcmliaW5nIGlzIHR1bm5lbGluZyBvZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwu DQpUaGV5IGJvdGggc2VlbXMgcmVhc29uYWJsZSB0byBtZSwgd2h5IHRoZSBzdGl0Y2hpbmcgaXMg bm90IGZlYXNpYmxlPw0KDQpDaGVlcnMNCkRhbmllbGUNCg0KRnJvbTogQ0NBTVAgW21haWx0bzpj Y2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHV1YiB2YW4gSGVsdm9vcnQNClNl bnQ6IGdpb3ZlZMOsIDE3IG5vdmVtYnJlIDIwMTYgMTc6MDYNClRvOiBjY2FtcEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpIZWxsbyBH ZXJ0LA0KDQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3QuDQoNCkluc3Rl YWQgb2Y6DQoNCjEuICAgICAgQSB1c2UgY2FzZSB0byBjb25zaWRlciBpczoNCg0KICAgICAgICst LS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0rDQoxMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RVNC1HTVAt T0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLTEwMEdFDQogICAgICAgKy0tLS0t LS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0t LS0tLS0tLSsNCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAgICAgICAgIE5FMiAoPUdXLU5F KSAgICAgICAgICAgICAgICAgICAgICAgTkUzDQoNCkl0IHNob3VsZCBiZToNCiAgICAgICArLS0t LS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9E VTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0LUdNUC18LS0xMDBH RQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgTkUxICAgICAg ICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5FMw0KDQpU aGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9EVTQuDQoNClJlZ2FyZHMsIEh1 dWIuDQoNCg0KDQotLQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUg dW5pcXVlLi4uanVzdCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCg== --_000_AM2PR07MB09947727F8473917709A6E50F0B00AM2PR07MB0994eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglwYW5vc2UtMToyIDE1IDMgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmg0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQgQ2hhciI7DQoJ bWFyZ2luLXRvcDoyLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJcGFnZS1icmVh ay1hZnRlcjphdm9pZDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IExpZ2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMyRjU0OTY7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6aXRhbGljO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSGVh ZGluZzRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCI7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzJGNTQ5NjsNCglmb250LXN0eWxl Oml0YWxpYzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjE5NTM3ODM5Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjU0ODgxNzE0OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iSVQiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtz IGZvciB0aGUgY2xlYXIgZXhwbGFuYXRpb24gSHV1Yi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90 aCBtYWtlIHNlbnNlLiBUaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFu IE9EVTQgYW5kIE9EVUMxLCB3aGlsZSB0aGUgb25lIHlvdSBhcmUgZGVzY3JpYmluZyBpcw0KIHR1 bm5lbGluZyBvZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo ZXkgYm90aCBzZWVtcyByZWFzb25hYmxlIHRvIG1lLCB3aHkgdGhlIHN0aXRjaGluZyBpcyBub3Qg ZmVhc2libGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+RGFuaWVsZSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6d2luZG93dGV4dCI+IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHV1YiB2YW4gSGVsdm9vcnQ8YnI+DQo8Yj5TZW50Ojwv Yj4gZ2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzowNjxicj4NCjxiPlRvOjwvYj4gY2NhbXBA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24g ZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhlbGxvIEdlcnQsPGJyPg0KPGJy Pg0KWW91ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Ljxicj4NCjxicj4NCklu c3RlYWQgb2Y6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+QSB1c2UgY2FzZSB0byBjb25zaWRlciBpczo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0 MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7PC9zcGFu PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4xMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEtfC1P VFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLTEwMEdFPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstLS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTkUyICg9R1ctTkUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMzwvc3Bhbj48L2I+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCkl0IHNob3VsZCBiZTogPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE5FMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBORTIgKD1HVy1ORSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUzPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48YnI+DQo8YnI+DQpUaGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9E VTQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+UmVnYXJkcywgSHV1Yi48bzpwPjwvbzpwPjwv cD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PG86cD48L286cD48L3ByZT4NCjxwcmU+QWx3YXlzIHJlbWVtYmVyIHRoYXQg eW91IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZlcnlvbmUgZWxzZS4uLjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM2PR07MB09947727F8473917709A6E50F0B00AM2PR07MB0994eurp_-- From nobody Fri Nov 18 10:31:00 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D5E12950B for ; Fri, 18 Nov 2016 10:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UVGtez74-b4F for ; Fri, 18 Nov 2016 10:30:57 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6569212949A for ; Fri, 18 Nov 2016 10:30:57 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id f82so54597970wmf.1 for ; Fri, 18 Nov 2016 10:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=MwicW5RTM56p/Gl7MuAg5M3Orp1hedY59D4ly8h1ANM=; b=wJhKqvVFqyXqHByxG1/msfcEV8FmGQJS51FdUIUK/yIqkZi84Dd+1RqBYnncgsb7hS NP6ug5fOqVqBESM9ZAAmmQuH83ZRCSeVMb2vaOFb363zHRTdawmGMHA1NxX4hXikY/Jy JCDmnidtpTweXvAfUXRwzWleQ1WeAp5/E6Egwg3uoUHQiQIZXsErrXLDTiFfxjKPQ127 26S7Fygv80QEqMXC63otcnJghn2hYabF8tCPeqsK144TO4IMttH7wM9JbNhB6PYKrfnH gYQiDh2K0ysfXbdhEf28VXqxzOThVXOBTY3cgG+InCRk6A1Gls7chR21u3tH9z4JWtyF 6tEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=MwicW5RTM56p/Gl7MuAg5M3Orp1hedY59D4ly8h1ANM=; b=Z78X9SYSjigY06sV8vYEIM8dePdRnNmFzn6rz2qCwwtEgRTOXBhcxa7Oh0RY9ljU4L 1IdmXDA3GS5LBqMeZeJTQ4jCOjQi2yb3ZkB1Uzh46Ng/N9WTz5nQyWvOhND0dIviRgPy ADsUrzbcktnfDXQ7DhhddbZNBhv8643iSUxT7tckdsELfLaldozZT2DlgIky2B26uVG7 xoYZWjvQCvLxsTpPPHmtRnxXg91Bq/vhjfQXFy9hJj88voCmqtuK6EiuVIP/yNdQPHEQ OleY6WEBr/ZI8Hiw34VgMFjKEsEDQlV5ALh4bokF5MgDGckZoa9dlGdn8jX9LSOKKbWn 4WDA== X-Gm-Message-State: AKaTC01+EXeKyp8eeIikvRqhi6bUkYJkBKoKGl8YtXCvHavaMXPJZvOGaIbhXDoNHWEjYg== X-Received: by 10.194.221.4 with SMTP id qa4mr808523wjc.179.1479493855988; Fri, 18 Nov 2016 10:30:55 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id k2sm10186710wjv.11.2016.11.18.10.30.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 10:30:55 -0800 (PST) References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> To: Daniele Ceccarelli , "ccamp@ietf.org" From: Huub van Helvoort Message-ID: <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> Date: Fri, 18 Nov 2016 19:30:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 18:30:59 -0000
Daniele,

You write:

Thanks for the clear explanation Huub.


You're welcome.

I see two different use cases that both make sense.


I have to disagree (again).

The one proposed by Gert is stitching of an ODU4 and ODUC1,


This use case is impossible. As you can see in G.709 (2016) figure 7-1
a lower order ODU4 is mapped into a higher order ODUC1, and this
means that they constitute different layers in the OTN.
And are impossible to stitch.

while the one you are describing is tunneling of ODU4 over an ODUC1 trail.


Correct.

They both seems reasonable to me, why the stitching is not feasible?


I tried to explain above.

Best regards, Huub.

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Huub van Helvoort
Sent: giovedì 17 novembre 2016 17:06
To: ccamp@ietf.org
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

 

Hello Gert,

Your use case is not completely correct.

Instead of:

1.      A use case to consider is:

 

       +----------+             +----------------+               +-----------+

100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-|--100GE

       +----------+             +----------------+               +-----------+  

             NE1                    NE2 (=GW-NE)                       NE3


It should be:

       +----------+             +----------------+               +--------------------+

100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE

       +----------+             +----------------+               +--------------------+  

             NE1                    NE2 (=GW-NE)                       NE3

The ODUC1 from NE2 to NE3 tunnels the ODU4.

Regards, Huub.

 



-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Fri Nov 18 11:03:04 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF351296AB for ; Fri, 18 Nov 2016 11:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 sZ9IBhnsu9Q1 for ; Fri, 18 Nov 2016 11:02:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF6E129621 for ; Fri, 18 Nov 2016 11:02:58 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-14-582f506081e1 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 1A.04.06466.0605F285; Fri, 18 Nov 2016 20:02:57 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 18 Nov 2016 20:02:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PY6C0uD8I/80If86O6Lqsoyf90BBL69LjXDLgo9NYTM=; b=AH7WwuUYV0p4UT9mWIis6RLk5x0XJCPUyR6UHk3Nf1cCUK1tz5k9d0QCA3cg2Ah1WbsXAH7cmyXL/UUJuCjTdYIlzs9dmw22hdg5/aOFFr5++rPI2OeZR1ZMixQOVUhN6QBdAGDYTKR7QcEHufrjH8w0HQIpkMpJLKy5pOJbXPk= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 18 Nov 2016 19:02:55 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0734.007; Fri, 18 Nov 2016 19:02:55 +0000 From: Daniele Ceccarelli To: "huubatwork@gmail.com" , "ccamp@ietf.org" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgAGrtCCAAA8PAIAACKjw Date: Fri, 18 Nov 2016 19:02:55 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> In-Reply-To: <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [88.128.80.100] x-ms-office365-filtering-correlation-id: 03a74525-4b81-471f-d928-08d40fe580f5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0996; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:7aDlv9vEmcf3+/au/8zmWh9ABi+Z8X1AbuQOpzuaBoTd9EwU5y+1XxiqWRvFaMSOHkLruvgw8rf51s33Mk54ITwGVivSZ72NryxqGUFngMTSq2HH92+V6jYEoi4PAFYoTnY02BDJztCvQMvsO4lWoQIGzh5MENrYeO4pp1CBad8pTZ4rRkyVKUaGQ5AkoUAPx3svWjN755fbMI0GZIm0OvAj/tMJRzt8F8/ViHuzrk5uMpHHzBRV1NVllFc+3z6+zN4ppUFfHB5ouKPrP5f2aVkhMKlm8qCh74pxyvoVs5BoZM1U4ATBgXju/nMLe4ukNgG7kRgHuEvQvLz4qFavZlNI4S2kbF/49aXmkmca5cDjozj/juk5V2vUH/cLsIfTfIrIUbHwG3y2sRjz2gqleyv5ZZSHJoozwDj1Ac2FenSjks0Xj/NA3+0J7VZEk7VJCnxZCenRPjWLqlzJclj0pQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041223)(6061324); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(51914003)(199003)(189002)(2900100001)(2950100002)(86362001)(9686002)(33656002)(105586002)(8936002)(101416001)(38730400001)(8676002)(107886002)(93886004)(66066001)(189998001)(68736007)(3280700002)(3660700001)(97736004)(5001770100001)(76576001)(2501003)(92566002)(7736002)(74316002)(7846002)(2906002)(87936001)(229853002)(50986999)(76176999)(54356999)(7696004)(5660300001)(606004)(6506003)(77096005)(122556002)(106116001)(102836003)(81156014)(6116002)(106356001)(790700001)(81166006)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09948E1BE03FF72D004CE2CDF0B00AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 19:02:55.0534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3fOdo6Xxeu87MGMcGCokFOLULvpl5CuZpRmQR3zeEmdeo6J +iGsmOa0MFyRU1PIMCUVbKXpgpo5U8x9ME0yS3OYfigvQeYly+1M8NvveZ7//334P7w0IWsQ e9IpqmyWUzFpCokjWRHbdmgXE6WMDVycI0MsVSNkyIPKQXG4KPKlboyKrKtbEkWJ4hz3J7Bp KTkspzx4yTH5oblLkmkwoFztjSWqABnakAY50ID3gL7TRGqQIy3DzQie6++LhOIdgntF9baC xLcJqP7yDwkTrQjmm8opoTAh6P+lW5fRtASHgcV4zIpu+CzcHcu3rnDFAVBYPSSxshtWgqlk GQl8GCZKJsVWJrEPaGobRVaW4gvQ0zhFCM8vItAMD9kMDvgAFGjGbYywByz2PbUZCCyHT5Ya kZAHQ53BTAjsDjOTa2JBHw8t6na7xhs62/VigY9Dr6UbbfDKnW5bYsClJExW1tkNqTDRXyYR +AhUjozb+4MIlpajrYEBe8Hswj7B2yyG1mEzadXIMAv1TWokXMITxj4U29kLpj+/EpchX92m DAJngHnoB6WzHcMFeisspG59BYH9oKVDKUi8QVsyQQnsC+qqampzvxZRjcidZ/n49KTg4ACW S7nM8xmqABWb3YrWP9Ab/UpgO5r5HmFEmEYKZ2mmXBkrEzM5fF66EQFNKNyk106st6QJTF4+ y2Vc5K6msbwRbaNJhVy6t+FrjAwnMdlsKstmstzGVEQ7eBYgp52m2e4ODfcnYT7x0TlVf2jW by3nExZGDNxy0yudQrfOGc5HJ7p0OFH+uW+znGMGugvTp58UT7XJA49+C5oJX7vu5zv68TR2 Maq3/+RinJxLPALKd7wI/SvbzYw/I4PjuqZ6rjzWjbTcPFNUs9Dqqo2Qj66ubukrPfka8hPf n1KQfDIT5E9wPPMf8pTp4jwDAAA= Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 19:03:02 -0000 --_000_AM2PR07MB09948E1BE03FF72D004CE2CDF0B00AM2PR07MB0994eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgSHV1YiwNCg0KQXV0aG9ycywgaWYgeW91IGNvdWxkIGhhdmUgYSBsaXR0bGUgcGllY2Ug b2YgdGV4dCBkZXNjcmliaW5nIHRoaXMgY29uc2lkZXJhdGlvbiBpbiB0aGUgZnJhbWV3b3JrIG9y IGluIG9uZSBvZiB0aGUgc29sdXRpb24gZG9jdW1lbnRzIChkZXBlbmRpbmcgd2hhdCBhcmUgdGhl IHBsYW5zIGZvciB0aGUgbWVyZ2UpIHRoYXQgd291bGQgYmUgZ3JlYXQuDQoNClRoYW5rcw0KRGFu aWVsZQ0KDQpGcm9tOiBIdXViIHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdvcmtAZ21haWwu Y29tXQ0KU2VudDogdmVuZXJkw6wgMTggbm92ZW1icmUgMjAxNiAxOTozMQ0KVG86IERhbmllbGUg Q2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT47IGNjYW1wQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNCkRh bmllbGUsDQoNCllvdSB3cml0ZToNClRoYW5rcyBmb3IgdGhlIGNsZWFyIGV4cGxhbmF0aW9uIEh1 dWIuDQoNCllvdSdyZSB3ZWxjb21lLg0KDQoNCkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2Vz IHRoYXQgYm90aCBtYWtlIHNlbnNlLg0KDQpJIGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS4NCg0K DQpUaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFuIE9EVTQgYW5kIE9E VUMxLA0KDQpUaGlzIHVzZSBjYXNlIGlzIGltcG9zc2libGUuIEFzIHlvdSBjYW4gc2VlIGluIEcu NzA5ICgyMDE2KSBmaWd1cmUgNy0xDQphIGxvd2VyIG9yZGVyIE9EVTQgaXMgbWFwcGVkIGludG8g YSBoaWdoZXIgb3JkZXIgT0RVQzEsIGFuZCB0aGlzDQptZWFucyB0aGF0IHRoZXkgY29uc3RpdHV0 ZSBkaWZmZXJlbnQgbGF5ZXJzIGluIHRoZSBPVE4uDQpBbmQgYXJlIGltcG9zc2libGUgdG8gc3Rp dGNoLg0KDQoNCndoaWxlIHRoZSBvbmUgeW91IGFyZSBkZXNjcmliaW5nIGlzIHR1bm5lbGluZyBv ZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwuDQoNCkNvcnJlY3QuDQoNCg0KVGhleSBib3RoIHNl ZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT8N Cg0KSSB0cmllZCB0byBleHBsYWluIGFib3ZlLg0KDQpCZXN0IHJlZ2FyZHMsIEh1dWIuDQoNCg0K DQpGcm9tOiBDQ0FNUCBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBIdXViIHZhbiBIZWx2b29ydA0KU2VudDogZ2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzow Ng0KVG86IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KSGVsbG8gR2VydCwNCg0KWW91 ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Lg0KDQpJbnN0ZWFkIG9mOg0KDQox LiAgICAgIEEgdXNlIGNhc2UgdG8gY29uc2lkZXIgaXM6DQoNCiAgICAgICArLS0tLS0tLS0tLSsg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t Kw0KMTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RV QzEtLS1PVFVDMS18LU9EVUMxLUdNUC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQog ICAgICAgICAgICAgTkUxICAgICAgICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAg ICAgICAgICAgICAgIE5FMw0KDQpJdCBzaG91bGQgYmU6DQogICAgICAgKy0tLS0tLS0tLS0rICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLSsNCjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVD MS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICAr LS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAg ICAgTkUyICg9R1ctTkUpICAgICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZy b20gTkUyIHRvIE5FMyB0dW5uZWxzIHRoZSBPRFU0Lg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0K DQoNCg0KLS0NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1 ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uDQo= --_000_AM2PR07MB09948E1BE03FF72D004CE2CDF0B00AM2PR07MB0994eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglwYW5vc2UtMToyIDE1IDMgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAw IDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxl LWxpbms6IkhlYWRpbmcgNCBDaGFyIjsNCgltYXJnaW4tdG9wOjIuMHB0Ow0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzJG NTQ5NjsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6Ymxh Y2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSGVhZGluZzRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGln aHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzJGNTQ5NjsNCglmb250LXN0eWxlOml0YWxpYzt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9 DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAu ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5NTM3ODM5Njc7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU0ODgxNzE0OCA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iSVQiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmsgSHV1Yiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkF1dGhvcnMsIGlmIHlvdSBjb3VsZCBoYXZlIGEgbGl0 dGxlIHBpZWNlIG9mIHRleHQgZGVzY3JpYmluZyB0aGlzIGNvbnNpZGVyYXRpb24gaW4gdGhlIGZy YW1ld29yayBvciBpbiBvbmUgb2YgdGhlIHNvbHV0aW9uIGRvY3VtZW50cyAoZGVwZW5kaW5nIHdo YXQNCiBhcmUgdGhlIHBsYW5zIGZvciB0aGUgbWVyZ2UpIHRoYXQgd291bGQgYmUgZ3JlYXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+RGFuaWVsZSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2lu ZG93dGV4dCI+IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gdmVuZXJkw6wgMTggbm92ZW1icmUgMjAxNiAxOTozMTxicj4N CjxiPlRvOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJp Y3Nzb24uY29tJmd0OzsgY2NhbXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtD Q0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PkRhbmllbGUsPGJyPg0KPGJyPg0KWW91IHdyaXRlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFu a3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCllvdSdyZSB3ZWxj b21lLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc2VlIHR3byBkaWZm ZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aCBtYWtlIHNlbnNlLg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KSSBoYXZl IHRvIGRpc2FncmVlIChhZ2FpbikuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+VGhlIG9uZSBwcm9wb3NlZCBieSBHZXJ0IGlzIHN0aXRjaGluZyBvZiBhbiBPRFU0IGFuZCBP RFVDMSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48YnI+DQpUaGlzIHVzZSBjYXNlIGlzIGltcG9zc2libGUuIEFzIHlvdSBjYW4g c2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1cmUgNy0xIDxicj4NCmEgbG93ZXIgb3JkZXIgT0RVNCBp cyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFVDMSwgYW5kIHRoaXMgPGJyPg0KbWVhbnMg dGhhdCB0aGV5IGNvbnN0aXR1dGUgZGlmZmVyZW50IGxheWVycyBpbiB0aGUgT1ROLiA8YnI+DQpB bmQgYXJlIGltcG9zc2libGUgdG8gc3RpdGNoLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPndoaWxlIHRoZSBvbmUgeW91IGFyZSBkZXNjcmliaW5nIGlzIHR1bm5lbGluZyBv ZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KQ29ycmVjdC48YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGV5IGJvdGggc2VlbXMgcmVhc29uYWJsZSB0 byBtZSwgd2h5IHRoZSBzdGl0Y2hpbmcgaXMgbm90IGZlYXNpYmxlPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCkkgdHJp ZWQgdG8gZXhwbGFpbiBhYm92ZS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsIEh1dWIuPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gQ0NBTVAgWzxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkh1dWIgdmFuIEhlbHZvb3J0PGJyPg0KPGI+U2VudDo8L2I+IGdpb3ZlZMOs IDE3IG5vdmVtYnJlIDIwMTYgMTc6MDY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpj Y2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5IZWxsbyBHZXJ0LDxicj4NCjxicj4NCllvdXIgdXNlIGNhc2UgaXMgbm90IGNvbXBsZXRl bHkgY29ycmVjdC48YnI+DQo8YnI+DQpJbnN0ZWFkIG9mOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkEgdXNlIGNh c2UgdG8gY29uc2lkZXIgaXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcgLHNlcmlmJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLHNlcmlmJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0Mzsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICxzZXJpZiZxdW90OyxzZXJpZiI+MTAwR0Ut LXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVD MS18LU9EVUMxLUdNUC18LS0xMDBHRTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyAsc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTkUyICg9R1ctTkUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMzwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCkl0IHNob3VsZCBiZTogPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLHNlcmlmJnF1b3Q7LHNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0t JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICxzZXJpZiZxdW90 OyxzZXJpZiI+MTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMx LXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0LUdNUC18LS0xMDBHRTwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsc2VyaWYmcXVvdDss c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0t LS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyAsc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORTEmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUyICg9R1ctTkUp Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KVGhlIE9EVUMx IGZyb20gTkUyIHRvIE5FMyB0dW5uZWxzIHRoZSBPRFU0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPlJlZ2FyZHMsIEh1dWIuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPi0t IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5B bHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBl bHNlLi4uPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_AM2PR07MB09948E1BE03FF72D004CE2CDF0B00AM2PR07MB0994eurp_-- From nobody Sun Nov 20 18:02:30 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E0A1294D5 for ; Sun, 20 Nov 2016 18:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com 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 mzgx3Hb7VN9I for ; Sun, 20 Nov 2016 18:02:25 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0081.outbound.protection.outlook.com [104.47.40.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3216129679 for ; Sun, 20 Nov 2016 18:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pXNPsZxxJHMGeOKLpvnVmRDbX5CEdkeE/SY5w/eAJH0=; b=fT2HIJr1/HiqvxG5c2pSJ1hyh6SkMNeNgnF5evHdlFtLL2cWh8ugYDhMAMd64cmpXSOH4IebsS7EsVeE5JNA1KG00XBHEYG6mdRftncO0lI9tfoFjPLaiHkIFhVwAzAE92Qz5jmPtPC1Jhnjn+4B9EGVPrKv9lynuMEWk+vcMFw= Received: from SN1PR10CA0069.namprd10.prod.outlook.com (10.164.10.165) by CY1PR10MB0298.namprd10.prod.outlook.com (10.160.152.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Mon, 21 Nov 2016 02:02:22 +0000 Received: from DM3NAM03FT004.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by SN1PR10CA0069.outlook.office365.com (2a01:111:e400:c47c::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8 via Frontend Transport; Mon, 21 Nov 2016 02:02:22 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.24) smtp.mailfrom=infinera.com; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.24 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.24; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.24) by DM3NAM03FT004.mail.protection.outlook.com (10.152.82.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4 via Frontend Transport; Mon, 21 Nov 2016 02:02:21 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1547; Count:19 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd2.infinera.com (10.100.103.229) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 20 Nov 2016 18:02:20 -0800 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Sun, 20 Nov 2016 18:02:20 -0800 From: Iftekhar Hussain To: Daniele Ceccarelli , "huubatwork@gmail.com" , "ccamp@ietf.org" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQc50OT/L5vhW6k2YsIK58n9Zp6Dir4Dw Date: Mon, 21 Nov 2016 02:02:20 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_dae2b07d9acf4854830617fe791eb681svex13prd1infineracom_" MIME-Version: 1.0 X-IncomingHeaderCount: 19 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.24; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(7916002)(2980300002)(438002)(189002)(51914003)(377454003)(37854004)(199003)(38730400001)(356003)(84326002)(7736002)(86362001)(606004)(7636002)(229853002)(7846002)(24736003)(2201001)(7696004)(93886004)(87936001)(5660300001)(4546004)(92566002)(108616004)(77096005)(33646002)(2950100002)(2900100001)(626004)(54356999)(76176999)(50986999)(106116001)(102836003)(53416004)(2501003)(106466001)(6116002)(512874002)(2906002)(5001770100001)(3846002)(8676002)(790700001)(107886002)(189998001)(8936002)(80792005)(246002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR10MB0298; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail2.infinera.com; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT004; 1:/iNEESoTzKxCIPU4LzAdw9ovg2U0ohIpfHQAL3GNsexAWeMOpfbnoh1VCKpDqQGaZAAlTbTKOckPUw1fcpUR2yupos0Bv342pAOElxi59USO0gGeNZJU7E1d1UOSbhO08DtH0MtfJVjOjgNhnB3tUpWymUtLruwMpra3zP316GMJOkwpcxpTXSfQU0CC3sRc89yIWGXyv2hQ8eUeX4E9QGDwD2HQbSyvOvezhorc1zyEhEwSHafgKT94bXgjDfT8s7T0cB4Zf04281cV7MGX8fNg132Et/Wv1OypQ9QpqGt+bJ7c/U6mr+YXW+YKsOnVbwO8axFbzSeJ0txKkM1gP/gii1AYkU6J31uACJsiPNoPY0a7U/bB354LGnEX1mNX3gWe8c7cTLLHyj4S+oLLHbJQEzHTE2HsLeso3OnwStHcEY/cJT3IOB1+fbs2rmorloCS4XRwn4b/ylY5RsaAqfLwiQEatkIfpf7iYpPhb6GaalVRIXbWeyG6Q0H8oYDQ+59J12Z4WBSpcQNPFp8Ty88CkKwUNZi5+HMt22P+QQwdA/WNxLt7wjQHEC7ppzlW X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0298; 2:BI6K6hpJJ1CthruxAu2KXVUg6l9TWgZiC4Ua4XdQIC+M8W/JoHcDeNpG6fTRl6Mhu0atXJiffvDGseBx2mls9H2l6XbjJyX7vqW+hxdD91N5g0MnPlrrhQV5qIykfk5Gp8zXmVLKCv8GTlSFl4YZyCsoiLCrp651RBRGpOMXNrg=; 3:ZCnPbflIwXr4dXaPI9LyweDIR804UnVL5cKI9nGMG21KFr0l9jVCnzTGRjLrODlhprGPDJ2Q0V4+WPUQk7Y3JQmLpK/1VNQFKTqBjlxiydM2+EG9mhvSe7v8WKcspyDDSae7vVUCIztnNiGtkwqojucZwBOYixy55LflPTPcnftIDX6RRJKL77bEv1zFRfGN3xIeP9eATVoYqUsIv1y6bs+hg9xOu4VVBJ/QWssV+I4/IZ69sfam+KnnBS4yVoAkz5XqFOb8BGTJHTCihrTeRteKS91XlduzL7jKIKpXNhc= X-MS-Office365-Filtering-Correlation-Id: 4a77d6f0-186d-4e9e-a7f1-08d411b26e7d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:CY1PR10MB0298; X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0298; 25:vkrgXRQEOqHRedSl7/Vumrt3iE3MPWJ4PgQODbmJDL/9UDS9qkMCoAO7/XIjHVw/rOrkgWfG62lsmAgopra/uovgte4gTnsXu44MnaYEL723t0yIe1SKv3kEi4yFM5+kJYBrQ5MfgFWd+fe2BpinoOcXvtt9gIPVYJcNOODZTxpSOyF5Woy9pMWzZva432OQeMeX9sj8IyG1yqxB1+rA27JoQ1AonbuZf6UnPuBShDs6tPfWa/WN0sGcIFAh08irU1iLMffjSM//0oCLMTpmdkk+9nbvicF5oRbZa6hrNJ/Dv+ol+6kXYIl+ogq2CWkErDZuTK6o67KBib4Mg4lEzJ0PL6ofOJQhIzwPJ/xsyldGKnOAMF/LSk2QAcrGv4dNdak8En+LNQbGikMYhrKxePlayN/e33W9UUDWpU+rsXTGXT9Vr+EaGzivaaGu49dMtMAs2TrxANppY3FgsrvXJA==; 31:+QFNLDZ3cwGEePH9jNpWuMTsRYc0m/hGI9DZDtvyIO+R4+eRpkDrLSDcOqmXPLQsvNvQOk3wT6ZuR0+tQpY/4M9NKf+yrOC1RdkMYzXYUD4XkUBekHmbaXU2+j/xEuDqPVODcDLtzkKc/i2nmgfx7Wnise5SUEYpckAL0qih4B6NadiARFaT5xUSWLgecH4/J/gqg+1OMe4X4SB/OoEtOgAFKrX8Btnr3HuwyR456Vpqko3XWaEqfyvilQSYM60iT9fFAuKlKO1Lx8B7MNRvdw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(13017025)(5005006)(13015025)(13023025)(13018025)(8121501046)(13024025)(10201501046)(3002001)(6041248)(6061324); SRVR:CY1PR10MB0298; BCL:0; PCL:0; RULEID:; SRVR:CY1PR10MB0298; X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0298; 4:t4q9tXWlWX0u09MDCEH8iqf1B58q6WGIb0zKeWkrO97ONAqi8HVtxFQrSMYEHdTgP2/fkmXc3RWvZiYBvI/DNm93PlXFDioEx5dO9feZSLoKzONI1ZOfWK9W5QjvaBdvcwM0i3LZJ7itqvUi0GlipAfo/9kk+M+CNxdp8/pLYKontONAJvebAaCs/1VpHa5KB2qNndauegKfMC5jbuoHnXS/Uugi9omw3Q045lUSrtt5cqdM76zkmEHA5FUzAjEOD+XMFc50LcZImLBOKq3sdHIZC6amvRN7JU8cj0TctLc9OD0ZSy4+eny1GCtlGN3UCLbHgQ8khIWyAV9NTH9gJ3BBzTRqXYjKer5xr8FkQS/4CC1TYPJ3EobREZFAMtOrVgzGf2qHk/zxlJelnG5/cztx6qEihwd+WnEVKYjyT0zfMUTs17XLvDxc7Nd373XNbuh5ASCA2rgIKOdbnKYj5rpM0IpMnY1Jm4aJ3AefECaRHDgjvBrZFlSroy4wDICS1YYXjMQpZ53roqFZRAu7vAl1zXxH9kd6oCTOtMhLhLzgjR/6g3dtX60N/r7YzwIe6+R+FBQ8J5brbw1Z7l1Egn7f678zo5WCwI8Oht+DSUF6mtm5JdiAZjEEoFxSMybHXX3rffAmYYFkFN1bLwCtDQ== X-Forefront-PRVS: 01334458E5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR10MB0298; 23:cvyS2Iv3JJdFjTp9MFQaJMe8ClczmB3NQ9tpUGIQl?= =?us-ascii?Q?wT4zr8x6hSCyTb4XFPKo2zsJ5/BMEsH487uef27F5PNaKzPZc46XI57/2IYk?= =?us-ascii?Q?4HFsKbNPaR6qFkFgYBfRXv7OM41ATm8jX74PK5u28EaWlKgYYKo0h2h//1Cj?= =?us-ascii?Q?A+uMJyDRaPbw2RD0dkLqn6jlFeptAcDg6VhU5WpcwP6bsqDdjFQ/GpBbvQzT?= =?us-ascii?Q?KmFbtQhk30wTmOML9PMgo9uT3liMaFNzBJeV7U4eb9ZE0Avnbb3xkJivmsiV?= =?us-ascii?Q?RPgQC3LucmhagqxEAm6U5ooFF1Wccs3b1v6maH8+HorGdQ06VG0NbA4hFKb5?= =?us-ascii?Q?6fT/4syuGnR5+pZpHCgBKKjuihTfngwpPyy/a47PZ/B3TzByE8QgwtpOd2Pn?= =?us-ascii?Q?N7acwMLPqtjbvysGWRettfp316qxMfceA43E3IpU9donF/CKqpeQcsJmx7OK?= =?us-ascii?Q?8HRY2JG1Mbn2yfIg3sklIyAXqCB9qlJwC4iUWN3Ur8wcFpMBrFSgKu8DGOhh?= =?us-ascii?Q?2Eo2wInYYLEH2hiW/e3YIo9kGCxYOpmUaujW27uKuOL9iYDjtQ0uff9QU+jy?= =?us-ascii?Q?LHsX8yJHHaD30D4Rcx5GvqREIUQwStLTmBtLuE4XTJ9E1f7aiY4b6VufP6Zw?= =?us-ascii?Q?Tqn0tblvnI/4pLQ7HeIqB+J7b5mpHlF/eQ5OfIaUzNnQH30XM93z/pwfEeSq?= =?us-ascii?Q?jFGZrC4x49Ttv50Miy4otmvVjqCHJwp1h8EO3L4ncP+Dh69b+SvB/Hcy9jo0?= =?us-ascii?Q?uik+NupdnvYYazq2hR+XeZC9RH/4LxPgnqAYeCvnHUUdy9YIyTkCHxXPabZR?= =?us-ascii?Q?wHnTFWdIwsF7/TbVMRMsB2gTvPs8ftSCCzyiedA71ZMxBW9VGhwn4KbRytsk?= =?us-ascii?Q?x9LhPt52QqxkPEFAeyOFogGHkXUjmFqhz9DPynFICZIe8OQc67AmV7GTkRoL?= =?us-ascii?Q?d2kQuwl/FXWC2iYI6umZxOCKgojOudq5MLK0ODPBSreQHyXX5n4TOXbwXp96?= =?us-ascii?Q?hJg8U7YRcpavqtrcs2ZBqxBUXil3FpLU5RBcBHWI1D1srdUts+JygcVE2vh4?= =?us-ascii?Q?Ix5nU/CgdtyTBibj84A3RfxXtY9yidM9Yqax4lMNA41iTbtoKhF/DHu5zlaZ?= =?us-ascii?Q?9gb8T3/RQiChCCXBP0BJ+7GiKQuwGL6Sf04a/AHJD9wNyKa9daCid5AyQMWD?= =?us-ascii?Q?ttbJysnblv452wfPo6slpjY2PR7gAsNjNN2H9yaoNvqYklZ0MrloKNAsMJfy?= =?us-ascii?Q?EY2uTJqw7P+NjaWOJk=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0298; 6:/jrvjAdIA6LlboVi387O5ITRe+iYK3C4xQ2XZ5vebmbpEiI91KdnrNHzimeFcX10LmeCPZZWO9w1J4yEV42KKkhL3b6QBsu6cEo/QI/uCQbEPwNgyPonaywluG06Tb616qmYqsEGldm4Yyk1nw/1C+5aCnQR3o9y11DtLUhjOqZjEkgmjvL5LrhwjmggjG5EudQZcpSdRCkwePX2TM79bPyR0JqAZ3jV+4tCM/TWzqGdiDGWv4Empi/bC9Rb3XPx/SCyVDns2TqJe3xP/dOYJwv/zRsdeVaylDERD/ZicphGepA9l/aaIGQBjn66deM7gitGVQUi3HB8zpTkb+v6OB5OW9F5TYwjzSWvVdXQojA=; 5:Pe2Y/8OsJmtsL6FXggaBrcvLaYUVo0ywIzftTNYBjcjU0h989IERcql9WqG3En88fZ4+eHs2zZzjhAbzVKOq3XPSPklj9yk0Sg2jfZpNxGyUEC+o0l/pgYSicfIRAozGKEHjm3KKKcoD+AK39LELSg==; 24:OebWm7p+4gl21BaPcObjQczDTrWozcHBwNOc4yb6CSqfyBOlBxN4KlW+9Ub4dhpdM1Oh0tIOYlNo+AhUhthhuWxIqR49AUagyW5okHANCGk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0298; 7:6X2tj3ZL6UoOgZA6pS2vs9UohbJPbhDlclRB7ExnY8qomne+AYviVY+eRqnr9+wg4vm5kdxAjSM3h0syPuUURs89EXO7y3jkOyKcMLpfRrl++ajj2yuAVCRIDVxo5AafG5bHVoSFFlZGYzrrHCOkzvJnmj7wUM3Z0FWIL4e6ElfTo0Q6aWfPkXF/SHr+iaejR29tCOHwxNtY2TS7HGdlD7YtQl64cMOSBP5kGCRy03yy55fLw/KwIyURSY5OxM2GIAWoNssxVBe7hhXZVqB5kraaAxrAA9TqPPCd+LIPU616NVP9qRY0OeW+pFFkCmHZkhwF6N6ag++NrjapejX8RX6xhPbOyJeSoU2oJlEkzmY= X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Nov 2016 02:02:21.9474 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.24]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR10MB0298 Archived-At: Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 02:02:28 -0000 --_000_dae2b07d9acf4854830617fe791eb681svex13prd1infineracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBjbGFyaWZ5IHRoZSBzY29wZSBvZiB0 aGUgcHJvcG9zZWQgc29sdXRpb24gKGUuZy4gaW5jbHVkZSBzb21lIHVzZSBjYXNlcykuIElkZWFs bHkgdGhpcyBzb3J0IG9mIGluZm8gc2hvdWxkIGJlIGluIGZyYW1ld29yayBkb2MuDQoNCkFsc28g aXMganVzdCBzcGVjaWZ5aW5nIHRoZSBzaWduYWwgdHlwZSBjb2RlIHBvaW50cyBzdWZmaWNpZW50 IGZvciB0aGUgb3ZlcmFsbCBHTVBMUyBSU1ZQLVRFIHNpZ25hbGluZyBzb2x1dGlvbiBmb3IgQmV5 b25kIDEwMEcgb3IgaXQgd291bGQgcmVxdWlyZSBhZGRpdGlvbmFsICBpbmZvIChlLmcuLCBtdWx0 aXBsZXhpbmcgc3RydWN0dXJlIGFzIGluIFJGQzQzMjggYW5kIFJGQzcxMzkpPw0KDQpUaGFua3Ms DQpJZnRla2hhcg0KDQpGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNl Y2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxOCwgMjAxNiAx MTowMyBBTQ0KVG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpUaGFuayBIdXViLA0K DQpBdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBwaWVjZSBvZiB0ZXh0IGRlc2Ny aWJpbmcgdGhpcyBjb25zaWRlcmF0aW9uIGluIHRoZSBmcmFtZXdvcmsgb3IgaW4gb25lIG9mIHRo ZSBzb2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGluZyB3aGF0IGFyZSB0aGUgcGxhbnMgZm9yIHRo ZSBtZXJnZSkgdGhhdCB3b3VsZCBiZSBncmVhdC4NCg0KVGhhbmtzDQpEYW5pZWxlDQoNCkZyb206 IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQpTZW50OiB2 ZW5lcmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMxDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxk YW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tPj47IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KRGFuaWVsZSwN Cg0KWW91IHdyaXRlOg0KVGhhbmtzIGZvciB0aGUgY2xlYXIgZXhwbGFuYXRpb24gSHV1Yi4NCg0K WW91J3JlIHdlbGNvbWUuDQoNCkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90 aCBtYWtlIHNlbnNlLg0KDQpJIGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS4NCg0KVGhlIG9uZSBw cm9wb3NlZCBieSBHZXJ0IGlzIHN0aXRjaGluZyBvZiBhbiBPRFU0IGFuZCBPRFVDMSwNCg0KVGhp cyB1c2UgY2FzZSBpcyBpbXBvc3NpYmxlLiBBcyB5b3UgY2FuIHNlZSBpbiBHLjcwOSAoMjAxNikg ZmlndXJlIDctMQ0KYSBsb3dlciBvcmRlciBPRFU0IGlzIG1hcHBlZCBpbnRvIGEgaGlnaGVyIG9y ZGVyIE9EVUMxLCBhbmQgdGhpcw0KbWVhbnMgdGhhdCB0aGV5IGNvbnN0aXR1dGUgZGlmZmVyZW50 IGxheWVycyBpbiB0aGUgT1ROLg0KQW5kIGFyZSBpbXBvc3NpYmxlIHRvIHN0aXRjaC4NCg0Kd2hp bGUgdGhlIG9uZSB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgdHVubmVsaW5nIG9mIE9EVTQgb3ZlciBh biBPRFVDMSB0cmFpbC4NCg0KQ29ycmVjdC4NCg0KVGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUg dG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT8NCg0KSSB0cmllZCB0byBl eHBsYWluIGFib3ZlLg0KDQpCZXN0IHJlZ2FyZHMsIEh1dWIuDQoNCg0KRnJvbTogQ0NBTVAgW21h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHV1YiB2YW4gSGVsdm9v cnQNClNlbnQ6IGdpb3ZlZMOsIDE3IG5vdmVtYnJlIDIwMTYgMTc6MDYNClRvOiBjY2FtcEBpZXRm Lm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFu ZCBPRFVDbiBkaXNjdXNzaW9uDQoNCkhlbGxvIEdlcnQsDQoNCllvdXIgdXNlIGNhc2UgaXMgbm90 IGNvbXBsZXRlbHkgY29ycmVjdC4NCg0KSW5zdGVhZCBvZjoNCg0KMS4gICAgICBBIHVzZSBjYXNl IHRvIGNvbnNpZGVyIGlzOg0KDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCjEwMEdFLS18LUdNUC1P RFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVD MS1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgIE5FMSAg ICAgICAgICAgICAgICAgICAgTkUyICg9R1ctTkUpICAgICAgICAgICAgICAgICAgICAgICBORTMN Cg0KSXQgc2hvdWxkIGJlOg0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoxMDBHRS0t fC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMx LXwtT0RVQzEtR01QLU9EVTQtR01QLXwtLTEwMEdFDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLSsNCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAgICAgICAgIE5FMiAoPUdXLU5FKSAg ICAgICAgICAgICAgICAgICAgICAgTkUzDQoNClRoZSBPRFVDMSBmcm9tIE5FMiB0byBORTMgdHVu bmVscyB0aGUgT0RVNC4NCg0KUmVnYXJkcywgSHV1Yi4NCg0KDQoNCg0KDQoNCi0tDQoNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg0KQWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZl cnlvbmUgZWxzZS4uLg0K --_000_dae2b07d9acf4854830617fe791eb681svex13prd1infineracom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglwYW5vc2UtMToyIDE1IDMgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAw IDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5 bGUtbGluazoiSGVhZGluZyA0IENoYXIiOw0KCW1hcmdpbi10b3A6Mi4wcHQ7DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMyRjU0OTY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5 NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBp bjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5IZWFkaW5nNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0 IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMy RjU0OTY7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox OTUzNzgzOTY3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czo1NDg4MTcxNDggNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+QWdy ZWUgd2l0aCB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBjbGFyaWZ5IHRoZSBzY29wZSBvZiB0aGUg cHJvcG9zZWQgc29sdXRpb24gKGUuZy4gaW5jbHVkZSBzb21lIHVzZSBjYXNlcykuIElkZWFsbHkg dGhpcyBzb3J0IG9mIGluZm8gc2hvdWxkIGJlIGluIGZyYW1ld29yayBkb2MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+QWxzbyBpcyBqdXN0IHNwZWNpZnlpbmcgdGhlIHNpZ25hbCB0eXBlIGNvZGUgcG9pbnRzIHN1 ZmZpY2llbnQgZm9yIHRoZSBvdmVyYWxsIEdNUExTIFJTVlAtVEUgc2lnbmFsaW5nIHNvbHV0aW9u IGZvciBCZXlvbmQgMTAwRyBvciBpdCB3b3VsZCByZXF1aXJlIGFkZGl0aW9uYWwgJm5ic3A7aW5m byAoZS5nLiwgbXVsdGlwbGV4aW5nIHN0cnVjdHVyZQ0KIGFzIGluIFJGQzQzMjggYW5kIFJGQzcx MzkpPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+SWZ0ZWtoYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOndpbmRvd3RleHQiPiBEYW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2Nh cmVsbGlAZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIg MTgsIDIwMTYgMTE6MDMgQU08YnI+DQo8Yj5Ubzo8L2I+IGh1dWJhdHdvcmtAZ21haWwuY29tOyBj Y2FtcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBPRFU0IGFuZCBP RFVDbiBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+VGhh bmsgSHV1Yiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5BdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBh IGxpdHRsZSBwaWVjZSBvZiB0ZXh0IGRlc2NyaWJpbmcgdGhpcyBjb25zaWRlcmF0aW9uIGluIHRo ZSBmcmFtZXdvcmsgb3IgaW4gb25lIG9mIHRoZSBzb2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGlu ZyB3aGF0IGFyZSB0aGUgcGxhbnMgZm9yIHRoZSBtZXJnZSkgdGhhdCB3b3VsZA0KIGJlIGdyZWF0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOndpbmRvd3RleHQiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRv d3RleHQiPkRhbmllbGUmbmJzcDsgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4g SHV1YiB2YW4gSGVsdm9vcnQgWzxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbSI+ bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiB2ZW5l cmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMxPGJyPg0KPGI+VG86PC9iPiBEYW5pZWxlIENlY2Nh cmVsbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t Ij5kYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWls dG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IklU Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJJVCI+RGFuaWVsZSw8 YnI+DQo8YnI+DQpZb3Ugd3JpdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndp bmRvd3RleHQiPlRoYW5rcyBmb3IgdGhlIGNsZWFyIGV4cGxhbmF0aW9uIEh1dWIuPC9zcGFuPjxz cGFuIGxhbmc9IklUIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IklUIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48YnI+DQpZb3UncmUgd2VsY29tZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2Vz IHRoYXQgYm90aCBtYWtlIHNlbnNlLg0KPC9zcGFuPjxzcGFuIGxhbmc9IklUIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpJIGhh dmUgdG8gZGlzYWdyZWUgKGFnYWluKS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOndpbmRvd3RleHQiPlRoZSBvbmUgcHJvcG9zZWQgYnkgR2VydCBpcyBzdGl0Y2hpbmcgb2Yg YW4gT0RVNCBhbmQgT0RVQzEsPC9zcGFuPjxzcGFuIGxhbmc9IklUIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpUaGlzIHVzZSBj YXNlIGlzIGltcG9zc2libGUuIEFzIHlvdSBjYW4gc2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1cmUg Ny0xIDxicj4NCmEgbG93ZXIgb3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRl ciBPRFVDMSwgYW5kIHRoaXMgPGJyPg0KbWVhbnMgdGhhdCB0aGV5IGNvbnN0aXR1dGUgZGlmZmVy ZW50IGxheWVycyBpbiB0aGUgT1ROLiA8YnI+DQpBbmQgYXJlIGltcG9zc2libGUgdG8gc3RpdGNo Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+d2hpbGUg dGhlIG9uZSB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgdHVubmVsaW5nIG9mIE9EVTQgb3ZlciBhbiBP RFVDMSB0cmFpbC48L3NwYW4+PHNwYW4gbGFuZz0iSVQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCkNvcnJlY3QuPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGV5IGJvdGggc2VlbXMg cmVhc29uYWJsZSB0byBtZSwgd2h5IHRoZSBzdGl0Y2hpbmcgaXMgbm90IGZlYXNpYmxlPzwvc3Bh bj48c3BhbiBsYW5nPSJJVCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJJVCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KSSB0cmllZCB0byBleHBsYWluIGFib3ZlLjxicj4NCjxi cj4NCkJlc3QgcmVnYXJkcywgSHV1Yi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNw YW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OndpbmRvd3RleHQiPiBDQ0FNUCBbPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+SHV1YiB2YW4gSGVsdm9vcnQ8YnI+DQo8Yj5TZW50OjwvYj4gZ2lvdmVkw6wgMTcgbm92ZW1i cmUgMjAxNiAxNzowNjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYu b3JnIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0g T0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvc3Bhbj48c3BhbiBsYW5nPSJJVCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IklUIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJJVCI+ SGVsbG8gR2VydCw8YnI+DQo8YnI+DQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNv cnJlY3QuPGJyPg0KPGJyPg0KSW5zdGVhZCBvZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxh bmc9IklUIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iSVQi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlzOjwvc3Bh bj48c3BhbiBsYW5nPSJJVCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3ICxzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJJVCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICxzZXJpZiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0t LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iSVQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyAsc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IklUIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJJVCIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLHNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0t LS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYj NDM7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IklUIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLHNlcmlmJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUxJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMiAoPUdXLU5FKSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBORTM8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IklUIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpJdCBz aG91bGQgYmU6IDwvc3Bhbj48c3BhbiBsYW5nPSJJVCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICxzZXJpZiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0t LS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iSVQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9U VUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IklUIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgLHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IklUIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcgLHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTkUxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE5FMiAoPUdXLU5FKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORTM8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpUaGUgT0RVQzEgZnJvbSBO RTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9EVTQuPC9zcGFuPjxzcGFuIGxhbmc9IklUIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJJVCI+UmVnYXJkcywgSHV1Yi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJJVCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iSVQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFu Zz0iSVQiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJJVCI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJJVCI+QWx3 YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZlcnlvbmUgZWxz ZS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_dae2b07d9acf4854830617fe791eb681svex13prd1infineracom_-- From nobody Mon Nov 21 01:31:27 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25B11298D5 for ; Mon, 21 Nov 2016 01:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 xd40SFnrpytP for ; Mon, 21 Nov 2016 01:31:23 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA151298C6 for ; Mon, 21 Nov 2016 01:31:22 -0800 (PST) Received: from out1.zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 3488B9EF4EFE5 for ; Mon, 21 Nov 2016 17:31:18 +0800 (CST) X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20161121173020 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 21 Nov 2016 09:30:20 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAL9Udvh039315; Mon, 21 Nov 2016 17:30:39 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> To: Daniele Ceccarelli , "huubatwork@gmail.com" MIME-Version: 1.0 X-KeepSent: 17B70B10:75E59BC6-48258072:00333FB6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Mon, 21 Nov 2016 17:30:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-21 17:30:27, Serialize complete at 2016-11-21 17:30:27 Content-Type: multipart/alternative; boundary="=_alternative 0034401B48258072_=" X-MAIL: mse01.zte.com.cn uAL9Udvh039315 X-HQIP: 127.0.0.1 Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:31:26 -0000 This is a multipart message in MIME format. --=_alternative 0034401B48258072_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhhbmsgRGFuaWVsZSBmb3IgeW91ciBzdWdnZXN0aW9uLiBXZSB3aWxsIGFkZCB0ZXh0IHRvIGRl c2NyaWJlIHRoZSANCmNvbnNpZGVyYXRpb24uDQpJIHRoaW5rIHdlIGF1dGhvcnMgbmVlZCB0byBk byBhIHRob3JvdWdoIGV2YWx1YXRpb24gb2YgT0RVQ24gYW5kIHN1Ym1pdCBhIA0KbmV3IHZlcnNp b24gdG8gY2xhcmlmeSB0aGUgY29uZnVzaW9uIGJlZm9yZSBuZXh0IElFVEYgbWVldGluZy4NCg0K QW5kIGFsc28gd2Ugd2lsbCBzcGxpdCB0aGUgc29sdXRpb24gaW50byBzZXBhcmF0ZSBkb2N1bWVu dHMgYmFzZSBvbiB5b3VyIA0Kc3VnZ2VzdGlvbi4NCg0KVGhhbmtzDQpRaWxlaQ0KDQoNCg0KDQpE YW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+IA0K5Y+R 5Lu25Lq6OiAgIkNDQU1QIiA8Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4NCjIwMTYvMTEvMTkgMDM6 MDINCg0K5pS25Lu25Lq6DQoiaHV1YmF0d29ya0BnbWFpbC5jb20iIDxodXViYXR3b3JrQGdtYWls LmNvbT4sICJjY2FtcEBpZXRmLm9yZyIgDQo8Y2NhbXBAaWV0Zi5vcmc+LCANCuaKhOmAgQ0KDQrk uLvpopgNClJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoN ClRoYW5rIEh1dWIsDQogDQpBdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBwaWVj ZSBvZiB0ZXh0IGRlc2NyaWJpbmcgdGhpcyANCmNvbnNpZGVyYXRpb24gaW4gdGhlIGZyYW1ld29y ayBvciBpbiBvbmUgb2YgdGhlIHNvbHV0aW9uIGRvY3VtZW50cyANCihkZXBlbmRpbmcgd2hhdCBh cmUgdGhlIHBsYW5zIGZvciB0aGUgbWVyZ2UpIHRoYXQgd291bGQgYmUgZ3JlYXQuDQogDQpUaGFu a3MNCkRhbmllbGUgDQogDQpGcm9tOiBIdXViIHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdv cmtAZ21haWwuY29tXSANClNlbnQ6IHZlbmVyZMOsIDE4IG5vdmVtYnJlIDIwMTYgMTk6MzENClRv OiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+OyBj Y2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vz c2lvbg0KIA0KRGFuaWVsZSwNCg0KWW91IHdyaXRlOg0KVGhhbmtzIGZvciB0aGUgY2xlYXIgZXhw bGFuYXRpb24gSHV1Yi4NCg0KWW91J3JlIHdlbGNvbWUuDQoNCg0KSSBzZWUgdHdvIGRpZmZlcmVu dCB1c2UgY2FzZXMgdGhhdCBib3RoIG1ha2Ugc2Vuc2UuIA0KDQpJIGhhdmUgdG8gZGlzYWdyZWUg KGFnYWluKS4NCg0KDQpUaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFu IE9EVTQgYW5kIE9EVUMxLA0KDQpUaGlzIHVzZSBjYXNlIGlzIGltcG9zc2libGUuIEFzIHlvdSBj YW4gc2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1cmUgNy0xIA0KYSBsb3dlciBvcmRlciBPRFU0IGlz IG1hcHBlZCBpbnRvIGEgaGlnaGVyIG9yZGVyIE9EVUMxLCBhbmQgdGhpcyANCm1lYW5zIHRoYXQg dGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXllcnMgaW4gdGhlIE9UTi4gDQpBbmQgYXJlIGlt cG9zc2libGUgdG8gc3RpdGNoLg0KDQoNCndoaWxlIHRoZSBvbmUgeW91IGFyZSBkZXNjcmliaW5n IGlzIHR1bm5lbGluZyBvZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwuDQoNCkNvcnJlY3QuDQoN Cg0KVGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5nIGlz IG5vdCBmZWFzaWJsZT8NCg0KSSB0cmllZCB0byBleHBsYWluIGFib3ZlLg0KDQpCZXN0IHJlZ2Fy ZHMsIEh1dWIuDQoNCg0KICANCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEh1dWIgdmFuIEhlbHZvb3J0DQpTZW50OiBnaW92ZWTDrCAxNyBu b3ZlbWJyZSAyMDE2IDE3OjA2DQpUbzogY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NB TVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCiANCkhlbGxvIEdlcnQsDQoNCllvdXIgdXNl IGNhc2UgaXMgbm90IGNvbXBsZXRlbHkgY29ycmVjdC4NCg0KSW5zdGVhZCBvZjoNCjEuICAgICAg QSB1c2UgY2FzZSB0byBjb25zaWRlciBpczoNCiANCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICstLS0tLS0tLS0tLSsNCjEwMEdFLS18LUdNUC1PRFU0 LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1H TVAtfC0tMTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0rICstLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgTkUxICAgICAgICAgICAgICAgICAg ICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5FMw0KDQpJdCBzaG91bGQgYmU6 IA0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgKy0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9E VTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0LUdNUC18LS0xMDBH RQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgKy0t LS0tLS0tLS0tLS0tLS0tLS0tKyAgDQoNCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAgICAg ICAgIE5FMiAoPUdXLU5FKSAgICAgICAgICAgICAgICAgICAgICAgTkUzDQoNClRoZSBPRFVDMSBm cm9tIE5FMiB0byBORTMgdHVubmVscyB0aGUgT0RVNC4NClJlZ2FyZHMsIEh1dWIuDQogDQogDQog DQotLSANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVz dCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0K --=_alternative 0034401B48258072_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIERhbmllbGUgZm9yIHlvdXIgc3Vn Z2VzdGlvbi4gV2Ugd2lsbA0KYWRkIHRleHQgdG8gZGVzY3JpYmUgdGhlIGNvbnNpZGVyYXRpb24u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIHdlIGF1 dGhvcnMgbmVlZCB0byBkbyBhIHRob3JvdWdoDQpldmFsdWF0aW9uIG9mIE9EVUNuIGFuZCBzdWJt aXQgYSBuZXcgdmVyc2lvbiB0byBjbGFyaWZ5IHRoZSBjb25mdXNpb24gYmVmb3JlDQpuZXh0IElF VEYgbWVldGluZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkFuZCBhbHNvIHdlIHdpbGwgc3BsaXQgdGhlIHNvbHV0aW9uDQppbnRvIHNlcGFyYXRlIGRv Y3VtZW50cyBiYXNlIG9uIHlvdXIgc3VnZ2VzdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+UWlsZWk8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxl LmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+5Y+R5Lu25Lq6OiAmbmJzcDsmcXVvdDtDQ0FNUCZxdW90OyAm bHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxNi8xMS8xOSAwMzowMjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5pS25Lu25Lq6PC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtodXViYXR3b3JrQGdtYWls LmNvbSZxdW90OyAmbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7LA0KJnF1b3Q7Y2NhbXBAaWV0 Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OywgPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7mioTpgIE8L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gT0RV NCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGFuayBIdXViLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5BdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBw aWVjZQ0Kb2YgdGV4dCBkZXNjcmliaW5nIHRoaXMgY29uc2lkZXJhdGlvbiBpbiB0aGUgZnJhbWV3 b3JrIG9yIGluIG9uZSBvZiB0aGUNCnNvbHV0aW9uIGRvY3VtZW50cyAoZGVwZW5kaW5nIHdoYXQg YXJlIHRoZSBwbGFucyBmb3IgdGhlIG1lcmdlKSB0aGF0IHdvdWxkDQpiZSBncmVhdC48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj5EYW5pZWxlICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij48Yj5Gcm9tOjwvYj4gSHV1YiB2YW4gSGVsdm9vcnQgWzwvZm9udD48YSBocmVmPW1haWx0bzpo dXViYXR3b3JrQGdtYWlsLmNvbT48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+bWFpbHRvOmh1 dWJhdHdvcmtAZ21haWwuY29tPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ XQ0KPGI+PGJyPg0KU2VudDo8L2I+IHZlbmVyZMOsIDE4IG5vdmVtYnJlIDIwMTYgMTk6MzE8Yj48 YnI+DQpUbzo8L2I+IERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVy aWNzc29uLmNvbSZndDs7IGNjYW1wQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBb Q0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2Fs aWJyaSI+RGFuaWVsZSw8YnI+DQo8YnI+DQpZb3Ugd3JpdGU6PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5UaGFua3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXVi LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpZ b3UncmUgd2VsY29tZS48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aA0KbWFrZSBz ZW5zZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxi cj4NCkkgaGF2ZSB0byBkaXNhZ3JlZSAoYWdhaW4pLjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhlIG9uZSBwcm9wb3NlZCBieSBHZXJ0IGlzIHN0 aXRjaGluZyBvZg0KYW4gT0RVNCBhbmQgT0RVQzEsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NClRoaXMgdXNlIGNhc2UgaXMgaW1wb3NzaWJsZS4g QXMgeW91IGNhbiBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTENCjxicj4NCmEgbG93ZXIg b3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFVDMSwgYW5kIHRoaXMg PGJyPg0KbWVhbnMgdGhhdCB0aGV5IGNvbnN0aXR1dGUgZGlmZmVyZW50IGxheWVycyBpbiB0aGUg T1ROLiA8YnI+DQpBbmQgYXJlIGltcG9zc2libGUgdG8gc3RpdGNoLjxicj4NCjxicj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+d2hpbGUgdGhlIG9uZSB5b3UgYXJl IGRlc2NyaWJpbmcgaXMgdHVubmVsaW5nDQpvZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCkNvcnJl Y3QuPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5U aGV5IGJvdGggc2VlbXMgcmVhc29uYWJsZSB0byBtZSwgd2h5IHRoZQ0Kc3RpdGNoaW5nIGlzIG5v dCBmZWFzaWJsZT88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PGJyPg0KSSB0cmllZCB0byBleHBsYWluIGFib3ZlLjxicj4NCjxicj4NCkJlc3QgcmVnYXJk cywgSHV1Yi48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48Yj5Gcm9tOjwv Yj4gQ0NBTVAgWzwvZm9udD48YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgyYmYgZmFjZT0iQ2FsaWJyaSI+PHU+bWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IdXViIHZhbiBIZWx2b29ydDxiPjxicj4NClNlbnQ6 PC9iPiBnaW92ZWTDrCAxNyBub3ZlbWJyZSAyMDE2IDE3OjA2PGI+PGJyPg0KVG86PC9iPiA8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgy YmYgZmFjZT0iQ2FsaWJyaSI+PHU+Y2NhbXBAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIE9E VTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+SGVs bG8gR2VydCw8YnI+DQo8YnI+DQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJl Y3QuPGJyPg0KPGJyPg0KSW5zdGVhZCBvZjo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNhbGlicmkiPjEuICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5BDQp1c2UgY2FzZSB0byBjb25zaWRlciBpczo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDs8L2I+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Ky0tLS0tLS0tLS0rDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAr LS0tLS0tLS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyArLS0tLS0tLS0tLS0rPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0 LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0U8L2I+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0rDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyArLS0tLS0tLS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLS0tLS0rICZuYnNwOyA8L2I+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO05FMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7TkUyICg9R1ct TkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5FMzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KSXQgc2hvdWxkIGJlOiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsrLS0tLS0tLS0tLSsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICstLS0tLS0tLS0tLS0tLS0tKyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tLS0tLS0tLS0tLS0tLSs8L2I+PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+MTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0 LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0 LUdNUC18LS0xMDBHRTwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0tLS0tLSsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tLS0tLS0tLS0tKyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tLS0t LS0tLS0tLS0tLSsgJm5ic3A7IDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7TkUxICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtORTIgKD1HVy1ORSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg TkUzPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8 YnI+DQpUaGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9EVTQuPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+UmVnYXJkcywgSHV1Yi48L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+LS0gPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4u anVzdA0KbGlrZSBldmVyeW9uZSBlbHNlLi4uPC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWls aW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcD48dHQ+PGZvbnQgc2l6ZT0y Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0034401B48258072_=-- From nobody Wed Nov 23 05:01:09 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C339D129D91 for ; Wed, 23 Nov 2016 05:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 cBWIoAaG4lzy for ; Wed, 23 Nov 2016 05:01:02 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0125.outbound.protection.outlook.com [104.47.34.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580BD129D98 for ; Wed, 23 Nov 2016 05:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jCvVVagfCg7xEzKEgh2K6K++yv8TgC+hsTWt4SD0H1A=; b=R+XV1fdoPlk9CdFmZnrtZhJ1qEZZCHr/S0zUz4zpaBes8nA5Il1GtLZsYk+R3P9AVG+lPrmD9VejbcpPDIn35tzmfA2ZKH//xL1U7Tol80o1f/UoTxYu7Gc3WKofNEn5C2gBGjaNAPI0mugLtuPtFqdI2avoTLC+InfQ2QRBcE0= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1610.namprd05.prod.outlook.com (10.161.162.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Wed, 23 Nov 2016 13:01:00 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0747.010; Wed, 23 Nov 2016 13:01:00 +0000 From: Gert Grammel To: Daniele Ceccarelli , "ccamp@ietf.org" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgAGrtCCAAA8PAIAACKjwgAeHm4A= Date: Wed, 23 Nov 2016 13:01:00 +0000 Message-ID: <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [77.2.225.210] x-ms-office365-filtering-correlation-id: 415f83b0-6fff-4524-d8d5-08d413a0c656 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1610; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1610; 7:guWu6w1onN/AEuDqJKFNah+SR5/L6ecYkWuMvJl1X1R2ePGm3JhttKLf9Kb3kz9xXfW+wagU0ZVLCmDXSDbeIVvLDdt3cFFw/e4yaOJm1AcZSSwPTcDeycy9oOLYSG/n928TFGcsnwwt0GyYgbE3T26DX9NBkRvbch6lXdBiRBQiK4ytWLIZE7S3erSZpZ/XYlwm8D60kx8BdxkXFLSQ059IzhCwPEunQ86EDA+kuQT0xUENYZ+egSnTw0x174M/ShxzZyuQ/I2grF9wJiOW443nNx8P1cFqtKE/PYWEdxVcXydU+W06nzb/k9WS6ojveTV74ZZ+wO1PpFMhBPuyuzuJJ6ZvRlWpHk+MY0x/MTGZeH1X2glvM98/0QGukwZ2aQ/HzQKwoFerLx9viYX3iVFSmaeXbYezV/gmh+hPiRFhNVvThR2pZ/K9tbPzwpMwJnl/QaDhw7KMuwfyENr5KQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(6061324); SRVR:CY1PR0501MB1610; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1610; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(51914003)(68736007)(8676002)(3280700002)(3660700001)(2950100002)(606004)(36756003)(122556002)(7846002)(7736002)(92566002)(33656002)(6506003)(54356999)(83716003)(2906002)(4326007)(50986999)(76176999)(39060400001)(38730400001)(5660300001)(6512003)(82746002)(83506001)(2501003)(229853002)(4001350100001)(8936002)(101416001)(99286002)(106356001)(106116001)(86362001)(81166006)(105586002)(93886004)(81156014)(3846002)(77096005)(6116002)(102836003)(5001770100001)(97736004)(2900100001)(66066001)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1610; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_78E76D3293DC4F9EB6EB3B25437EB356junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2016 13:01:00.7676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1610 Archived-At: Cc: "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 13:01:06 -0000 --_000_78E76D3293DC4F9EB6EB3B25437EB356junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGFuaWVsZSwgQXV0aG9ycywNCg0KQWZ0ZXIgb3VyIGluaXRpYWwgZW1haWwgZXhjaGFuZ2UgSSB0 b29rIGEgbW9yZSBkZXRhaWxlZCBsb29rIGluIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkuIElu IGVzc2VuY2UsIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkgd291bGQgaW1wYWN0IGNvbnRyb2wg cGxhbmUgd29yayBmb3IgRy43MDkgKFJGQzcxMzkpIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYx NjMpLiBUaGUgY29tcGxleCBuYXR1cmUgb2YgdGhvc2UgZGVmaW5pdGlvbnMgd2lsbCBjZXJ0YWlu bHkgbm90IGJlIGFuIGVhc3ktZ29pbmcgZXh0ZW5zaW9uIGFzIGl0IGhhZCBiZWVuIGVudmlzYWdl ZCBzbyBmYXIuIFdyaXRpbmcgYSDigJxsaXR0bGUgcGllY2Ugb2YgdGV4dOKAnSBsb29rcyB0byBt ZSBsaWtlIGEg4oCcbGl0dGxlIGJpdCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gSWYgdGhlIFdHIGlu dGVuZHMgdG8gd29yayBvbiB0aGUgc3ViamVjdCwgbXkgcGxlZGdlIHdvdWxkIGJlIHRvIHN0YXJ0 IGZyb20gYSBmcmFtZXdvcmsgZG9jdW1lbnQgdG8gY2FwdHVyZSB0aGUgbmV3IGNvbmNlcHRzIGJl Zm9yZSBkZWZpbmluZyBwcm90b2NvbCBleHRlbnNpb25zLg0KDQpCZXN0DQoNCkdlcnQNCg0KDQpC ZWxvdyBhIGxpc3Qgb2Ygb2JzZXJ2YXRpb25zIHRoYXQgaW5mbHVlbmNlZCB0aGlzIHZpZXc6DQoN CjEuICAgICAgIE9QVUNuLCBPRFVDbiBhbmQgT1RVQ24gYXJlIG5ldyBhbmQgdGhlIGxheWVyaW5n IHJlbGF0aW9uc2hpcCB0byB0aGUgZm9ybWVyIHN0cnVjdHVyZSBpcyBhIGJpdCBzdXJwcmlzaW5n LCBhcyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCAoc2VlIGJlbG93KSBzaG93ZWQuIEJldHRl ciB0byBnZXQgdGhpcyByaWdodCBlYXJseSBvbg0KDQoyLiAgICAgICBGaWd1cmUgNy0xIHNob3dz IHRoZSBPVE4gbXVsdGlwbGV4aW5nIGFuZCBtYXBwaW5nIHN0cnVjdHVyZXMgYnV0IGRvZXMgbm90 IGluZGljYXRlIGhvdyBlLmcuIGEgNDAwR0Ugd291bGQgYmUgbWFwcGVkIGludG8gdGhpcyBzdHJ1 Y3R1cmUuIEl0IGlzIG5vdCBzdXJwcmlzaW5nIGFzIDQwMEdFIGlzIHN0aWxsIGluIHRoZSBtYWtp bmdzLCBidXQgcmFpc2VzIGEgZmV3IHF1ZXN0aW9ucyBhYm91dCBob3cgaXQgaXMgcGxhbm5lZCB0 byBiZSBtYXBwZWQuIEhvd2V2ZXIgZ3VpZGFuY2UgZnJvbSBTRzE1IHdvdWxkIGhlbHAgdG8gZ2V0 IHRoZSBwcm90b2NvbCBhcmNoaXRlY3R1cmUgZnV0dXJlIHByb29mLg0KDQphLiAgICAgICBEb2Vz IGV2ZXJ5IGNsaWVudCBzaWduYWwgbmVlZCB0byBiZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVr IGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPyAtLT4gdGhp cyB3b3VsZCBtZWFuIHRvIGV4dGVuZCB0aGUgT0RVIHN0cnVjdHVyZSBieSBhbiBPRFU1LDYsNyBl dGMuIGZvciBjbGllbnRzID4gMTAwRw0KDQpiLiAgICAgICBXaWxsIG9ubHkgY2xpZW50IHNpZ25h bHMgPD0gMTAwRyBuZWVkIHRvIGJlIHdyYXBwZWQgaW4gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBj YW4gYmUgdHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPyAtLT4gdGhpcyB3b3VsZCBtZWFu IHRoYXQgdGhlcmUgd2lsbCBiZSBhIGJyZWFrIGluIHRoZSBtYXBwaW5ncyBhdCBhYm91dCAxMDBH IHNpZ25hbHMgYW5kIG5vIE9EVTUsNiw3IHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZA0KDQpjLiAg ICAgICBXaWxsIGZ1dHVyZSBjbGllbnRzIGJlIG1hcHBlZCBkaXJlY3RseSBpbnRvIE9QVUNuL09E VUNuIGFuZCB0aGUgc3BlY2lhbCBjYXNlIG9mIDEwMEdFLS0+T1BVay9PRFVrLS0+T1BVQ24vT0RV Q24gd2lsbCBiZWNvbWUganVzdCBhbm90aGVyIG9wdGlvbj8gKE5vdGU6IHRoZSBmaWd1cmUgZXhw bGljaXRseSBhbGxvd3MgZm9yIHByb3ByaWV0YXJ5IG1hcHBpbmdzIGRpcmVjdGx5IGludG8gT1BV Q24vT0RVQ24gd2hpY2ggbG9va3MgbGlrZSBhIHByYWN0aWNhbCB1c2UgY2FzZSwgYnV0IGl0IGxv b2tzIG9kZCB0aGF0IGl0IHJlbWFpbnMgcHJvcmlldGFyeSkNCg0KMy4gICAgICAgVGhlIHNlY3Rp b24g4oCcNy4xIE1hcHBpbmfigJ0gYW5kIOKAnDcuMiBXYXZlbGVuZ3RoIERpdmlzaW9uIE11bHRp cGxleOKAnSBjaGFuZ2VkIGEgYml0IGZyb20gdGhlIDIwMTIgdmVyc2lvbi4gQXMgYWNyb255bXMg aGF2ZSBjaGFuZ2VkIHRvbywgYSAxOjEgY29tcGFyaXNvbiBpcyBub3QgdG9vIHNpbXBsZS4gVGhl IHRha2Vhd2F5IGlzIHRoYXQgYW4gT1RVIGNhbiBiZSBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZl bGVuZ3RoIG9yIHNwcmVhZCBhY3Jvc3Mgc29tZSAoT1RMay5uIGFuZCBPVExDLm4pIHdoaWNoIG1l YW5zIGludmVyc2UgbXVsdGlwbGV4aW5nLiBTbyBmYXIgdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBj b25zaWRlcmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2My4NCg0KNC4gICAgICAgSW4gU2VjdGlvbiDi gJw2LjEuMSBPVE4gZGlnaXRhbCBzdHJ1Y3R1cmXigJ0gaXQgaXMgZXhwbGFpbmVkIHRoYXQgYW4g T1RVayBjb250YWlucyBhIEZFQywgYnV0IE9UVUNuIGRvZXMgbm90LCBsZWF2aW5nIGl0IHRvIHRo ZSBpbnRlcmZhY2UgdG8gYXBwbHkgc29tZS4gVGhpcyBiYXNpY2FsbHkgY3JlYXRlcyBhIEZFQyBs YXllciBiZWxvdyB0aGUgT1RVQ24gdGhhdCB3aWxsIG5vdCBiZSBkZWZpbmVkIGluIEcuNzA5LiBB IGNvbnRyb2wgcGxhbmUgd291bGQgbmVlZCB0byBjaGVjayBjb21wYXRpYmlsaXR5IG9mIHdhdmVs ZW5ndGgsIG1vZHVsYXRpb24sIGludGVyZmFjZXMgKGkuZS4gaG93IG1hbnkgbGFuZXMpIGFuZCBj b21wYXRpYmlsaXR5IG9mIEZFQywgYXMgd2VsbCBhcyB1c2FnZSBvZiBPVFVrIHZzIE9UVUNuLiBB bHNvIHRoaXMgY2FzZSBoYXMgbm90IGJlZW4gY29uc2lkZXJlZCBpbiBSRkM3MTM5IG9yIFJGQzYx NjMuDQoNCjUuICAgICAgIFRoZXJlIGlzIGFsc28gYSBuZXcgT01TIE1TSSAoc2VjdCAxNS40KSBv dmVyaGVhZCBkZWZpbmVkLCB3aGljaCBwcm92aWRlcyBhIGxpc3Qgb2YgT0NoIGFuZCBPVFNpQSBm cmVxdWVuY3kgc2xvdCxwb3J0IG51bWJlcnMgYW5kIGEgbGlzdCBvZiBtZWRpYSBjaGFubmVscyAo ZnJlcXVlbmN5IHNsb3QsIG1lZGlhIGNoYW5uZWwgcG9ydCBudW1iZXJzKSB0byBkZWNvZGUgdGhl IGxhbmVzIGNvcnJlY3RseS4gVGhpcyBtYXkgYWZmZWN0IFJGQzYxNjMNCg0KNi4gICAgICAgVGhl IHRlcm0g4oCcV2F2ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXjigJ0gaW4gdGhlIHNlY3Rpb25z IGFib3ZlIGRvZXNu4oCZdCBpbXBseSBhIHdhdmVsZW5ndGggY2FuIGJlIHJvdXRlZCB0aHJvdWdo IGEgRFdETSBuZXR3b3JrIHNpbmNlIHdlIGtub3cgdGhhdCBlLmcuIDEwMEcgaW50ZXJmYWNlcyBh cmUgbm90IHlldCBkZWZpbmVkIGJ5IFNHMTUgZm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9u cy4gV2l0aG91dCBhbXBsaWZpZXJzLCB0aGUgZGlzdGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2ggRFdE TSBpcyBsaWtlbHkgbGltaXRlZCB0byBiZWxvdyA4MC0xMDBrbS4gSXQgaXMgbm90IHlldCBjbGVh ciBieSB3aGVuIHRoaXMgbGltaXRhdGlvbiB3aWxsIGJlIGxpZnRlZCBieSBTRzE1IChzZWUgZHJh ZnQtbWFueS1jb2hlcmVudC1kd2RtLWlmLWNvbnRyb2wtMDApLiBBZnRlciBhbGwsIE9UVTQgYmFz ZWQgMTAwRyBpbnRlcmZhY2VzIGZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMgYXJlIGF2 YWlsYWJsZSBhbmQgaGF2ZSBldmVuIGJlZW4gcHJvdmVuIHRvIGJlIGludGVyb3BlcmFibGUgYW1v bmcgbXVsdGlwbGUgdmVuZG9ycyBjb3ZlcmluZyBkaXN0YW5jZXMgPjEwMDBrbS4gIEhvd2V2ZXIs IHRvIHN0YXkgaW4gdGhlIHN0YW5kYXJkcyBmcmFtZXdvcmsgZm9yIG5vdywgUkZDNjE2MyB3b3Vs ZCBuZWVkIHRvIGNvbnNpZGVyOg0KDQphLiAgICAgICBXaGlsZSBhIE9UVUNuIGNhbiBiZSBkaWdp dGFsbHkgY29uc3RydWN0ZWQgYW5kIG1hcHBlZCBpbnRvIGEgc2luZ2xlIHdhdmVsZW5ndGgsIGl0 IGNhbm5vdCBiZSByb3V0ZWQgaW4gV1NPTiAtLT4gbm8gMTAwRyBpbnRlcmZhY2VzIGluIGFtcGxp ZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KDQpiLiAgICAgICBBbiBPVFVD biBtYXkgYmUgYnJva2VuIGRvd24gaW50byA0IGxhbmVzIGF0IDI1RyAoT1RMNC40KSBidXQgc3Rp bGwgY2Fu4oCZdCBiZSByb3V0ZWQgaW4gV1NPTiAtLT4gbm8gMjVHIGludGVyZmFjZXMgaW4gYW1w bGlmaWVkIERXRE0gbmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5OC4yDQoNCmMuICAgICAgIEFuIE9U VTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93biBpbiBPVEwzLjQgcHJvdmlkaW5nIDQgbGFuZXMg YXQgMTBHIGVhY2ggLS0+IDEwRyBpbnRlcmZhY2VzIGFyZSBhbGxvd2VkIGluIGFtcGxpZmllZCBE V0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KDQoNCg0KDQoNCg0KRnJvbTogQ0NBTVAg PGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEYW5pZWxlIENlY2NhcmVsbGkg PGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+DQpEYXRlOiBGcmlkYXkgMTggTm92ZW1i ZXIgMjAxNiBhdCAyMDowMg0KVG86ICJodXViYXR3b3JrQGdtYWlsLmNvbSIgPGh1dWJhdHdvcmtA Z21haWwuY29tPiwgQ0NBTVAgPGNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0g T0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpUaGFuayBIdXViLA0KDQpBdXRob3JzLCBpZiB5 b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBwaWVjZSBvZiB0ZXh0IGRlc2NyaWJpbmcgdGhpcyBjb25z aWRlcmF0aW9uIGluIHRoZSBmcmFtZXdvcmsgb3IgaW4gb25lIG9mIHRoZSBzb2x1dGlvbiBkb2N1 bWVudHMgKGRlcGVuZGluZyB3aGF0IGFyZSB0aGUgcGxhbnMgZm9yIHRoZSBtZXJnZSkgdGhhdCB3 b3VsZCBiZSBncmVhdC4NCg0KVGhhbmtzDQpEYW5pZWxlDQoNCkZyb206IEh1dWIgdmFuIEhlbHZv b3J0IFttYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQpTZW50OiB2ZW5lcmTDrCAxOCBub3Zl bWJyZSAyMDE2IDE5OjMxDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tPjsgY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE9E VTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KRGFuaWVsZSwNCg0KWW91IHdyaXRlOg0KVGhhbmtz IGZvciB0aGUgY2xlYXIgZXhwbGFuYXRpb24gSHV1Yi4NCg0KWW91J3JlIHdlbGNvbWUuDQoNCg0K DQpJIHNlZSB0d28gZGlmZmVyZW50IHVzZSBjYXNlcyB0aGF0IGJvdGggbWFrZSBzZW5zZS4NCg0K SSBoYXZlIHRvIGRpc2FncmVlIChhZ2FpbikuDQoNCg0KDQpUaGUgb25lIHByb3Bvc2VkIGJ5IEdl cnQgaXMgc3RpdGNoaW5nIG9mIGFuIE9EVTQgYW5kIE9EVUMxLA0KDQpUaGlzIHVzZSBjYXNlIGlz IGltcG9zc2libGUuIEFzIHlvdSBjYW4gc2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1cmUgNy0xDQph IGxvd2VyIG9yZGVyIE9EVTQgaXMgbWFwcGVkIGludG8gYSBoaWdoZXIgb3JkZXIgT0RVQzEsIGFu ZCB0aGlzDQptZWFucyB0aGF0IHRoZXkgY29uc3RpdHV0ZSBkaWZmZXJlbnQgbGF5ZXJzIGluIHRo ZSBPVE4uDQpBbmQgYXJlIGltcG9zc2libGUgdG8gc3RpdGNoLg0KDQoNCg0Kd2hpbGUgdGhlIG9u ZSB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgdHVubmVsaW5nIG9mIE9EVTQgb3ZlciBhbiBPRFVDMSB0 cmFpbC4NCg0KQ29ycmVjdC4NCg0KDQoNClRoZXkgYm90aCBzZWVtcyByZWFzb25hYmxlIHRvIG1l LCB3aHkgdGhlIHN0aXRjaGluZyBpcyBub3QgZmVhc2libGU/DQoNCkkgdHJpZWQgdG8gZXhwbGFp biBhYm92ZS4NCg0KQmVzdCByZWdhcmRzLCBIdXViLg0KDQoNCg0KDQpGcm9tOiBDQ0FNUCBbbWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIdXViIHZhbiBIZWx2b29y dA0KU2VudDogZ2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzowNg0KVG86IGNjYW1wQGlldGYu b3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE9EVTQgYW5k IE9EVUNuIGRpc2N1c3Npb24NCg0KSGVsbG8gR2VydCwNCg0KWW91ciB1c2UgY2FzZSBpcyBub3Qg Y29tcGxldGVseSBjb3JyZWN0Lg0KDQpJbnN0ZWFkIG9mOg0KDQoxLiAgICAgIEEgdXNlIGNhc2Ug dG8gY29uc2lkZXIgaXM6DQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9E VTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMx LUdNUC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgTkUxICAg ICAgICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5FMw0K DQpJdCBzaG91bGQgYmU6DQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ctTkUpICAg ICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5FMyB0dW5u ZWxzIHRoZSBPRFU0Lg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0KDQoNCg0KLS0NCg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVy eW9uZSBlbHNlLi4uDQo= --_000_78E76D3293DC4F9EB6EB3B25437EB356junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <79F5215FF6BB834B804E8F81B5EE72EA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0KCXBhbm9zZS0xOjIgMTUgMyAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFwsc2VyaWYiO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjpibGFjazt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IENoYXIiOw0KCW1hcmdpbi10b3A6Mi4wcHQ7 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCI7DQoJY29sb3I6 IzJGNTQ5NjsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1 NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6YmxhY2s7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IZWFkaW5nNENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdo dCI7DQoJY29sb3I6IzJGNTQ5NjsNCglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTgxMDYyODgwOw0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzk0NzkwMjY2IDEz NDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5 IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwxDQoJe21zby1saXN0LWlkOjE5NTM3ODM5Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU0ODgxNzE0OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+RGFuaWVsZSwgQXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BZnRlciBvdXIgaW5p dGlhbCBlbWFpbCBleGNoYW5nZSBJIHRvb2sgYSBtb3JlIGRldGFpbGVkIGxvb2sgaW4gdGhlIDIw MTYgdmVyc2lvbiBvZiBHLjcwOS4gSW4gZXNzZW5jZSwgdGhlIDIwMTYgdmVyc2lvbiBvZiBHLjcw OSB3b3VsZCBpbXBhY3QgY29udHJvbCBwbGFuZSB3b3JrDQogZm9yIEcuNzA5IChSRkM3MTM5KSBh cyB3ZWxsIGFzIGZvciBXU09OIChSRkM2MTYzKS4gVGhlIGNvbXBsZXggbmF0dXJlIG9mIHRob3Nl IGRlZmluaXRpb25zIHdpbGwgY2VydGFpbmx5IG5vdCBiZSBhbiBlYXN5LWdvaW5nIGV4dGVuc2lv biBhcyBpdCBoYWQgYmVlbiBlbnZpc2FnZWQgc28gZmFyLiBXcml0aW5nIGEg4oCcPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5saXR0bGUNCiBwaWVjZSBvZiB0ZXh04oCdIGxv b2tzIHRvIG1lIGxpa2UgYSDigJxsaXR0bGUgYml0IG9mIHVuZGVyc3RhdGVtZW504oCdLiA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SWYgdGhlIFdHIGludGVuZHMgdG8gd29yayBvbiB0aGUgc3Vi amVjdCwgbXkgcGxlZGdlIHdvdWxkIGJlIHRvIHN0YXJ0IGZyb20gYSBmcmFtZXdvcmsgZG9jdW1l bnQgdG8gY2FwdHVyZSB0aGUNCiBuZXcgY29uY2VwdHMgYmVmb3JlIGRlZmluaW5nIHByb3RvY29s IGV4dGVuc2lvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4 dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkdlcnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZWxvdyBhIGxpc3Qgb2Ygb2JzZXJ2YXRpb25z IHRoYXQgaW5mbHVlbmNlZCB0aGlzIHZpZXc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ T1BVQ24sIE9EVUNuIGFuZCBPVFVDbiBhcmUgbmV3IGFuZCB0aGUgbGF5ZXJpbmcgcmVsYXRpb25z aGlwIHRvIHRoZSBmb3JtZXIgc3RydWN0dXJlIGlzIGEgYml0IHN1cnByaXNpbmcsIGFzIHRoZSBk aXNjdXNzaW9uIG9uIHRoZSBsaXN0IChzZWUgYmVsb3cpIHNob3dlZC4NCiBCZXR0ZXIgdG8gZ2V0 IHRoaXMgcmlnaHQgZWFybHkgb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GaWd1cmUg Ny0xIHNob3dzIHRoZSBPVE4gbXVsdGlwbGV4aW5nIGFuZCBtYXBwaW5nIHN0cnVjdHVyZXMgYnV0 IGRvZXMgbm90IGluZGljYXRlIGhvdyBlLmcuIGEgNDAwR0Ugd291bGQgYmUgbWFwcGVkIGludG8g dGhpcyBzdHJ1Y3R1cmUuIEl0IGlzIG5vdCBzdXJwcmlzaW5nDQogYXMgNDAwR0UgaXMgc3RpbGwg aW4gdGhlIG1ha2luZ3MsIGJ1dCByYWlzZXMgYSBmZXcgcXVlc3Rpb25zIGFib3V0IGhvdyBpdCBp cyBwbGFubmVkIHRvIGJlIG1hcHBlZC4gSG93ZXZlciBndWlkYW5jZSBmcm9tIFNHMTUgd291bGQg aGVscCB0byBnZXQgdGhlIHByb3RvY29sIGFyY2hpdGVjdHVyZSBmdXR1cmUgcHJvb2YuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZv MyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RG9lcyBldmVyeSBj bGllbnQgc2lnbmFsIG5lZWQgdG8gYmUgd3JhcHBlZCBpbnRvIGFuIE9QVWsvT0RVayBiZWZvcmUg aXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93 dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+IHRoaXMgd291bGQgbWVhbiB0byBleHRlbmQgdGhlIE9EVSBzdHJ1Y3R1cmUgYnkgYW4gT0RV NSw2LDcgZXRjLiBmb3IgY2xpZW50cw0KICZndDsgMTAwRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldpbGwgb25seSBjbGllbnQgc2lnbmFscyAmbHQ7 PSAxMDBHIG5lZWQgdG8gYmUgd3JhcHBlZCBpbiBhbiBPUFVrL09EVWsgYmVmb3JlIGl0IGNhbiBi ZSB0cmFuc3BvcnRlZCB2aWEgYW4gT1BVQ24vT0RVQ24/DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiB0aGlz IHdvdWxkIG1lYW4gdGhhdCB0aGVyZSB3aWxsIGJlIGEgYnJlYWsgaW4gdGhlIG1hcHBpbmdzIGF0 IGFib3V0IDEwMEcNCiBzaWduYWxzIGFuZCBubyBPRFU1LDYsNyB3b3VsZCBuZWVkIHRvIGJlIGRl ZmluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMiBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5X aWxsIGZ1dHVyZSBjbGllbnRzIGJlIG1hcHBlZCBkaXJlY3RseSBpbnRvIE9QVUNuL09EVUNuIGFu ZCB0aGUgc3BlY2lhbCBjYXNlIG9mIDEwMEdFPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5PUFVrL09EVWs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2Nv bG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPsOgPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPk9QVUNuL09EVUNuDQogd2lsbCBiZWNvbWUganVzdCBhbm90aGVyIG9wdGlv bj8gKE5vdGU6IHRoZSBmaWd1cmUgZXhwbGljaXRseSBhbGxvd3MgZm9yIHByb3ByaWV0YXJ5IG1h cHBpbmdzIGRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24gd2hpY2ggbG9va3MgbGlrZSBhIHByYWN0 aWNhbCB1c2UgY2FzZSwgYnV0IGl0IGxvb2tzIG9kZCB0aGF0IGl0IHJlbWFpbnMgcHJvcmlldGFy eSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3Rl eHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgc2VjdGlvbiDigJw3LjEgTWFwcGlu Z+KAnSBhbmQg4oCcNy4yIFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV44oCdIGNoYW5nZWQg YSBiaXQgZnJvbSB0aGUgMjAxMiB2ZXJzaW9uLiBBcyBhY3JvbnltcyBoYXZlIGNoYW5nZWQgdG9v LCBhIDE6MSBjb21wYXJpc29uIGlzDQogbm90IHRvbyBzaW1wbGUuIFRoZSB0YWtlYXdheSBpcyB0 aGF0IGFuIE9UVSBjYW4gYmUgbWFwcGVkIGludG8gYSBzaW5nbGUgd2F2ZWxlbmd0aCBvciBzcHJl YWQgYWNyb3NzIHNvbWUgKE9UTGsubiBhbmQgT1RMQy5uKSB3aGljaCBtZWFucyBpbnZlcnNlIG11 bHRpcGxleGluZy4gU28gZmFyIHRoaXMgY2FzZSBoYXMgbm90IGJlZW4gY29uc2lkZXJlZCBpbiBS RkM3MTM5IG9yIFJGQzYxNjMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gU2VjdGlv biDigJw2LjEuMSBPVE4gZGlnaXRhbCBzdHJ1Y3R1cmXigJ0gaXQgaXMgZXhwbGFpbmVkIHRoYXQg YW4gT1RVayBjb250YWlucyBhIEZFQywgYnV0IE9UVUNuIGRvZXMgbm90LCBsZWF2aW5nIGl0IHRv IHRoZSBpbnRlcmZhY2UgdG8gYXBwbHkgc29tZS4gVGhpcw0KIGJhc2ljYWxseSBjcmVhdGVzIGEg RkVDIGxheWVyIGJlbG93IHRoZSBPVFVDbiB0aGF0IHdpbGwgbm90IGJlIGRlZmluZWQgaW4gRy43 MDkuIEEgY29udHJvbCBwbGFuZSB3b3VsZCBuZWVkIHRvIGNoZWNrIGNvbXBhdGliaWxpdHkgb2Yg d2F2ZWxlbmd0aCwgbW9kdWxhdGlvbiwgaW50ZXJmYWNlcyAoaS5lLiBob3cgbWFueSBsYW5lcykg YW5kIGNvbXBhdGliaWxpdHkgb2YgRkVDLCBhcyB3ZWxsIGFzIHVzYWdlIG9mIE9UVWsgdnMgT1RV Q24uIEFsc28NCiB0aGlzIGNhc2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBv ciBSRkM2MTYzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+NS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJlIGlzIGFsc28gYSBu ZXcgT01TIE1TSSAoc2VjdCAxNS40KSBvdmVyaGVhZCBkZWZpbmVkLCB3aGljaCBwcm92aWRlcyBh IGxpc3Qgb2YgT0NoIGFuZCBPVFNpQSBmcmVxdWVuY3kgc2xvdCxwb3J0IG51bWJlcnMgYW5kIGEg bGlzdCBvZiBtZWRpYSBjaGFubmVscw0KIChmcmVxdWVuY3kgc2xvdCwgbWVkaWEgY2hhbm5lbCBw b3J0IG51bWJlcnMpIHRvIGRlY29kZSB0aGUgbGFuZXMgY29ycmVjdGx5LiBUaGlzIG1heSBhZmZl Y3QgUkZDNjE2MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Ni48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSB0ZXJtIOKAnFdhdmVs ZW5ndGggRGl2aXNpb24gTXVsdGlwbGV44oCdIGluIHRoZSBzZWN0aW9ucyBhYm92ZSBkb2VzbuKA mXQgaW1wbHkgYSB3YXZlbGVuZ3RoIGNhbiBiZSByb3V0ZWQgdGhyb3VnaCBhIERXRE0gbmV0d29y ayBzaW5jZSB3ZSBrbm93IHRoYXQgZS5nLg0KIDEwMEcgaW50ZXJmYWNlcyBhcmUgbm90IHlldCBk ZWZpbmVkIGJ5IFNHMTUgZm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucy4gV2l0aG91dCBh bXBsaWZpZXJzLCB0aGUgZGlzdGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2ggRFdETSBpcyBsaWtlbHkg bGltaXRlZCB0byBiZWxvdyA4MC0xMDBrbS4gSXQgaXMgbm90IHlldCBjbGVhciBieSB3aGVuIHRo aXMgbGltaXRhdGlvbiB3aWxsIGJlIGxpZnRlZCBieSBTRzE1IChzZWUgZHJhZnQtbWFueS1jb2hl cmVudC1kd2RtLWlmLWNvbnRyb2wtMDApLg0KIEFmdGVyIGFsbCwgT1RVNCBiYXNlZCAxMDBHIGlu dGVyZmFjZXMgZm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucyBhcmUgYXZhaWxhYmxlIGFu ZCBoYXZlIGV2ZW4gYmVlbiBwcm92ZW4gdG8gYmUgaW50ZXJvcGVyYWJsZSBhbW9uZyBtdWx0aXBs ZSB2ZW5kb3JzIGNvdmVyaW5nIGRpc3RhbmNlcyAmZ3Q7MTAwMGttLiAmbmJzcDtIb3dldmVyLCB0 byBzdGF5IGluIHRoZSBzdGFuZGFyZHMgZnJhbWV3b3JrIGZvciBub3csIFJGQzYxNjMgd291bGQg bmVlZCB0bw0KIGNvbnNpZGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPldoaWxlIGEgT1RVQ24gY2FuIGJlIGRpZ2l0YWxseSBjb25zdHJ1Y3RlZCBh bmQgbWFwcGVkIGludG8gYSBzaW5nbGUgd2F2ZWxlbmd0aCwgaXQgY2Fubm90IGJlIHJvdXRlZCBp biBXU09ODQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPsOg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiBubyAxMDBHIGludGVyZmFjZXMgaW4gYW1wbGlmaWVk IERXRE0gbmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5OC4yPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5i LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QW4gT1RVQ24gbWF5IGJlIGJyb2tlbiBkb3duIGlu dG8gNCBsYW5lcyBhdCAyNUcgKE9UTDQuNCkgYnV0IHN0aWxsIGNhbuKAmXQgYmUgcm91dGVkIGlu IFdTT04NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+w6A8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+IG5vIDI1RyBpbnRlcmZhY2VzIGluIGFtcGxpZmllZCBE V0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yy48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93 biBpbiBPVEwzLjQgcHJvdmlkaW5nIDQgbGFuZXMgYXQgMTBHIGVhY2gNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93 dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+IDEwRyBpbnRlcmZhY2VzIGFyZSBhbGxvd2VkIGluIGFtcGxpZmllZCBEV0RNIG5ldHdvcmtz IGRlZmluZWQgaW4gRy42OTguMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndp bmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 IDwvYj5DQ0FNUCAmbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERh bmllbGUgQ2VjY2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5IDE4IE5vdmVtYmVyIDIwMTYgYXQgMjA6MDI8YnI+DQo8 Yj5UbzogPC9iPiZxdW90O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7ICZsdDtodXViYXR3b3Jr QGdtYWlsLmNvbSZndDssIENDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFuayBIdXViLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4 dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXV0aG9ycywgaWYgeW91IGNvdWxkIGhhdmUg YSBsaXR0bGUgcGllY2Ugb2YgdGV4dCBkZXNjcmliaW5nIHRoaXMgY29uc2lkZXJhdGlvbiBpbiB0 aGUgZnJhbWV3b3JrIG9yIGluIG9uZSBvZiB0aGUgc29sdXRpb24gZG9jdW1lbnRzIChkZXBlbmRp bmcgd2hhdA0KIGFyZSB0aGUgcGxhbnMgZm9yIHRoZSBtZXJnZSkgdGhhdCB3b3VsZCBiZSBncmVh dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5EYW5pZWxlJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjp3aW5kb3d0ZXh0Ij4gSHV1YiB2YW4gSGVsdm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiB2ZW5lcmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMx PGJyPg0KPGI+VG86PC9iPiBEYW5pZWxlIENlY2NhcmVsbGkgJmx0O2RhbmllbGUuY2VjY2FyZWxs aUBlcmljc3Nvbi5jb20mZ3Q7OyBjY2FtcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+RGFuaWVsZSw8YnI+DQo8YnI+DQpZb3Ugd3JpdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlRoYW5rcyBmb3IgdGhlIGNsZWFyIGV4cGxhbmF0aW9uIEh1dWIuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PGJyPg0KWW91J3JlIHdlbGNv bWUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBzZWUgdHdv IGRpZmZlcmVudCB1c2UgY2FzZXMgdGhhdCBib3RoIG1ha2Ugc2Vuc2UuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48YnI+DQpJIGhhdmUg dG8gZGlzYWdyZWUgKGFnYWluKS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5UaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFuIE9EVTQg YW5kIE9EVUMxLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPjxicj4NClRoaXMgdXNlIGNhc2UgaXMgaW1wb3NzaWJsZS4gQXMgeW91IGNhbiBz ZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTEgPGJyPg0KYSBsb3dlciBvcmRlciBPRFU0IGlz IG1hcHBlZCBpbnRvIGEgaGlnaGVyIG9yZGVyIE9EVUMxLCBhbmQgdGhpcyA8YnI+DQptZWFucyB0 aGF0IHRoZXkgY29uc3RpdHV0ZSBkaWZmZXJlbnQgbGF5ZXJzIGluIHRoZSBPVE4uIDxicj4NCkFu ZCBhcmUgaW1wb3NzaWJsZSB0byBzdGl0Y2guPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+d2hpbGUgdGhlIG9uZSB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgdHVubmVs aW5nIG9mIE9EVTQgb3ZlciBhbiBPRFVDMSB0cmFpbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48YnI+DQpDb3JyZWN0Ljxicj4NCjxicj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRv d3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXkgYm90aCBzZWVtcyByZWFzb25h YmxlIHRvIG1lLCB3aHkgdGhlIHN0aXRjaGluZyBpcyBub3QgZmVhc2libGU/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PGJyPg0KSSB0cmll ZCB0byBleHBsYWluIGFib3ZlLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcywgSHV1Yi48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6d2luZG93dGV4dDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93 dGV4dCI+IENDQU1QIFs8YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IdXVi IHZhbiBIZWx2b29ydDxicj4NCjxiPlNlbnQ6PC9iPiBnaW92ZWTDrCAxNyBub3ZlbWJyZSAyMDE2 IDE3OjA2PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNj YW1wQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBPRFU0IGFu ZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGVsbG8gR2VydCw8 YnI+DQo8YnI+DQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3QuPGJyPg0K PGJyPg0KSW5zdGVhZCBvZjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlz Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0t LS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0t LSYjNDM7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3IFwsc2VyaWYmcXVvdDsiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0 LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0U8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUyICg9R1ctTkUpJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE5FMzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxicj4NCkl0IHNob3VsZCBiZTog PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0t LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bh bj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlm JnF1b3Q7Ij4xMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEt fC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLU9EVTQtR01QLXwtLTEwMEdFPC9zcGFuPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQz OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBc LHNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMiAoPUdXLU5FKSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBORTM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPjxicj4NCjxicj4NClRoZSBPRFVDMSBmcm9tIE5FMiB0byBORTMg dHVubmVscyB0aGUgT0RVNC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD5SZWdhcmRzLCBIdXVi LjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PG86cD48L286cD48L3ByZT4NCjxwcmU+QWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91 IGFyZSB1bmlxdWUuLi5qdXN0IGxpa2UgZXZlcnlvbmUgZWxzZS4uLjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_78E76D3293DC4F9EB6EB3B25437EB356junipernet_-- From nobody Wed Nov 23 07:38:45 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0181293FC for ; Wed, 23 Nov 2016 07:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 E_lOsdCvTeln for ; Wed, 23 Nov 2016 07:38:40 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC541295C3 for ; Wed, 23 Nov 2016 07:38:39 -0800 (PST) Received: from out1.zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 99A2716645F0F for ; Wed, 23 Nov 2016 23:38:33 +0800 (CST) X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20161123233718 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 23 Nov 2016 15:37:18 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uANFcTJi091135; Wed, 23 Nov 2016 23:38:29 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> To: Gert Grammel MIME-Version: 1.0 X-KeepSent: 09B71768:0B837461-48258074:0052E486; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Wed, 23 Nov 2016 23:38:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-23 23:38:10, Serialize complete at 2016-11-23 23:38:10 Content-Type: multipart/alternative; boundary="=_alternative 0055ECF048258074_=" X-MAIL: mse01.zte.com.cn uANFcTJi091135 X-HQIP: 127.0.0.1 Archived-At: Cc: "ccamp@ietf.org" , "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 15:38:43 -0000 This is a multipart message in MIME format. --=_alternative 0055ECF048258074_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgR2VydCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBGb2xsb3dpbmcgaXMgbXkgYW5z d2VyIHRvIHlvdXIgcHJldmlvdXMgbWFpbCBhbmQgDQp0aGlzIG9uZS4NCg0KKDEpLCBBYm91dCB0 aGUgcXVlc3Rpb25zIGluIHlvdXIgcHJldmlvdXMgbWFpbC4gSSB0aGluayB5b3UgYWxyZWFkeSBo YXZlIA0KbWFueSBvZiB0aGVtIHNvbHZlZC4gT0RVQ24gaGFzIGFsbW9zdCB0aGUgc2FtZSBvdmVy aGVhZCBhcyB0aGF0IG9mIE9EVWssIA0Kc28gSSBkb24ndCB0aGluayBzb21lIG1lY2hhbmlzbXMg b2YgT0RVQ24gKGUuZy4sIE9BTSBldGMpIGRpZmZlciBmcm9tIA0KdGhvc2Ugb2YgT0RVay4gSW4g dGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNob3VsZCBtYWlubHkgcGF5IGF0dGVudGlvbiAN CnRvIE9EVUNuJ3MgZmVhdHVyZSBhbmQgaXRzIGRpZmZlcmVuY2Ugd2l0aCBPRFVrIG5vdywgc3Vj aCBhcyBsYXllciBtb2RlbCANCm9mIE9EVUNuIGFuZCBzZXR1cCBvZiBPRFVDbiBjb25uZWN0aW9u Lg0KDQooMiksIEFib3V0IHRoZSBxdWVzdGlvbnMgaW4gdGhlIHNlY29uZCBpdGVtcyBvZiB0aGlz IHRocmVhZC4gSSB0aGluayBpdCdzIA0Kb3V0IG9mIHRoZSBzY29wZSBvZiBDQ0FNUC4gSSBjYW4n dCBnaXZlIGEgZGVmaW5pdGUgYW5zd2VyIHRvIHRoZXNlIA0KcXVlc3Rpb25zLiANCg0KKDMpLCBD b250cm9sIG9mIG9wdGljYWwgbmV0d29yayBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIGN1cnJlbnQg T0RVQ24gDQpkb2N1bWVudC4gV2Ugd2lsbCBub3QgaW52b2x2ZSB0aGlzIHBhcnQgaW4uIEFsc28g SSBzdWdnZXN0IHlvdSB0YWtlIGEgbG9vayANCmF0IFJGQzc2OTgsIHdoaWNoIG1haW5seSBmb2N1 cyBvbiB0aGUgY29udHJvbCBvZiBmbGV4aWJsZSBncmlkIG5ldHdvcmsuDQoNClRoYW5rcw0KUWls ZWkNCg0KDQoNCg0KR2VydCBHcmFtbWVsIDxnZ3JhbW1lbEBqdW5pcGVyLm5ldD4gDQrlj5Hku7bk uro6ICAiQ0NBTVAiIDxjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KMjAxNi8xMS8yMyAyMTowMQ0K DQrmlLbku7bkuroNCkRhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbT4sICJjY2FtcEBpZXRmLm9yZyIgDQo8Y2NhbXBAaWV0Zi5vcmc+LCANCuaKhOmAgQ0K Imh1dWJhdHdvcmtAZ21haWwuY29tIiA8aHV1YmF0d29ya0BnbWFpbC5jb20+DQrkuLvpopgNClJl OiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCkRhbmllbGUs IEF1dGhvcnMsDQogDQpBZnRlciBvdXIgaW5pdGlhbCBlbWFpbCBleGNoYW5nZSBJIHRvb2sgYSBt b3JlIGRldGFpbGVkIGxvb2sgaW4gdGhlIDIwMTYgDQp2ZXJzaW9uIG9mIEcuNzA5LiBJbiBlc3Nl bmNlLCB0aGUgMjAxNiB2ZXJzaW9uIG9mIEcuNzA5IHdvdWxkIGltcGFjdCANCmNvbnRyb2wgcGxh bmUgd29yayBmb3IgRy43MDkgKFJGQzcxMzkpIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYxNjMp LiBUaGUgDQpjb21wbGV4IG5hdHVyZSBvZiB0aG9zZSBkZWZpbml0aW9ucyB3aWxsIGNlcnRhaW5s eSBub3QgYmUgYW4gZWFzeS1nb2luZyANCmV4dGVuc2lvbiBhcyBpdCBoYWQgYmVlbiBlbnZpc2Fn ZWQgc28gZmFyLiBXcml0aW5nIGEg4oCcbGl0dGxlIHBpZWNlIG9mIA0KdGV4dOKAnSBsb29rcyB0 byBtZSBsaWtlIGEg4oCcbGl0dGxlIGJpdCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gSWYgdGhlIFdH IA0KaW50ZW5kcyB0byB3b3JrIG9uIHRoZSBzdWJqZWN0LCBteSBwbGVkZ2Ugd291bGQgYmUgdG8g c3RhcnQgZnJvbSBhIA0KZnJhbWV3b3JrIGRvY3VtZW50IHRvIGNhcHR1cmUgdGhlIG5ldyBjb25j ZXB0cyBiZWZvcmUgZGVmaW5pbmcgcHJvdG9jb2wgDQpleHRlbnNpb25zLg0KIA0KQmVzdA0KIA0K R2VydA0KIA0KIA0KQmVsb3cgYSBsaXN0IG9mIG9ic2VydmF0aW9ucyB0aGF0IGluZmx1ZW5jZWQg dGhpcyB2aWV3Og0KMS4gICAgICAgT1BVQ24sIE9EVUNuIGFuZCBPVFVDbiBhcmUgbmV3IGFuZCB0 aGUgbGF5ZXJpbmcgcmVsYXRpb25zaGlwIHRvIA0KdGhlIGZvcm1lciBzdHJ1Y3R1cmUgaXMgYSBi aXQgc3VycHJpc2luZywgYXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgDQooc2VlIGJlbG93 KSBzaG93ZWQuIEJldHRlciB0byBnZXQgdGhpcyByaWdodCBlYXJseSBvbg0KMi4gICAgICAgRmln dXJlIDctMSBzaG93cyB0aGUgT1ROIG11bHRpcGxleGluZyBhbmQgbWFwcGluZyBzdHJ1Y3R1cmVz IGJ1dCANCmRvZXMgbm90IGluZGljYXRlIGhvdyBlLmcuIGEgNDAwR0Ugd291bGQgYmUgbWFwcGVk IGludG8gdGhpcyBzdHJ1Y3R1cmUuIEl0IA0KaXMgbm90IHN1cnByaXNpbmcgYXMgNDAwR0UgaXMg c3RpbGwgaW4gdGhlIG1ha2luZ3MsIGJ1dCByYWlzZXMgYSBmZXcgDQpxdWVzdGlvbnMgYWJvdXQg aG93IGl0IGlzIHBsYW5uZWQgdG8gYmUgbWFwcGVkLiBIb3dldmVyIGd1aWRhbmNlIGZyb20gU0cx NSANCndvdWxkIGhlbHAgdG8gZ2V0IHRoZSBwcm90b2NvbCBhcmNoaXRlY3R1cmUgZnV0dXJlIHBy b29mLg0KYS4gICAgICAgRG9lcyBldmVyeSBjbGllbnQgc2lnbmFsIG5lZWQgdG8gYmUgd3JhcHBl ZCBpbnRvIGFuIE9QVWsvT0RVayANCmJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0ZWQgdmlhIGFu IE9QVUNuL09EVUNuPyDDoCB0aGlzIHdvdWxkIG1lYW4gdG8gDQpleHRlbmQgdGhlIE9EVSBzdHJ1 Y3R1cmUgYnkgYW4gT0RVNSw2LDcgZXRjLiBmb3IgY2xpZW50cyA+IDEwMEcNCmIuICAgICAgIFdp bGwgb25seSBjbGllbnQgc2lnbmFscyA8PSAxMDBHIG5lZWQgdG8gYmUgd3JhcHBlZCBpbiBhbiAN Ck9QVWsvT0RVayBiZWZvcmUgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVD bj8gw6AgdGhpcyB3b3VsZCANCm1lYW4gdGhhdCB0aGVyZSB3aWxsIGJlIGEgYnJlYWsgaW4gdGhl IG1hcHBpbmdzIGF0IGFib3V0IDEwMEcgc2lnbmFscyBhbmQgDQpubyBPRFU1LDYsNyB3b3VsZCBu ZWVkIHRvIGJlIGRlZmluZWQNCmMuICAgICAgIFdpbGwgZnV0dXJlIGNsaWVudHMgYmUgbWFwcGVk IGRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24gYW5kIHRoZSANCnNwZWNpYWwgY2FzZSBvZiAxMDBH RcOgT1BVay9PRFVrw6BPUFVDbi9PRFVDbiB3aWxsIGJlY29tZSBqdXN0IGFub3RoZXIgDQpvcHRp b24/IChOb3RlOiB0aGUgZmlndXJlIGV4cGxpY2l0bHkgYWxsb3dzIGZvciBwcm9wcmlldGFyeSBt YXBwaW5ncyANCmRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24gd2hpY2ggbG9va3MgbGlrZSBhIHBy YWN0aWNhbCB1c2UgY2FzZSwgYnV0IGl0IA0KbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlucyBwcm9y aWV0YXJ5KQ0KMy4gICAgICAgVGhlIHNlY3Rpb24g4oCcNy4xIE1hcHBpbmfigJ0gYW5kIOKAnDcu MiBXYXZlbGVuZ3RoIERpdmlzaW9uIA0KTXVsdGlwbGV44oCdIGNoYW5nZWQgYSBiaXQgZnJvbSB0 aGUgMjAxMiB2ZXJzaW9uLiBBcyBhY3JvbnltcyBoYXZlIGNoYW5nZWQgDQp0b28sIGEgMToxIGNv bXBhcmlzb24gaXMgbm90IHRvbyBzaW1wbGUuIFRoZSB0YWtlYXdheSBpcyB0aGF0IGFuIE9UVSBj YW4gDQpiZSBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoIG9yIHNwcmVhZCBhY3Jvc3Mg c29tZSAoT1RMay5uIGFuZCANCk9UTEMubikgd2hpY2ggbWVhbnMgaW52ZXJzZSBtdWx0aXBsZXhp bmcuIFNvIGZhciB0aGlzIGNhc2UgaGFzIG5vdCBiZWVuIA0KY29uc2lkZXJlZCBpbiBSRkM3MTM5 IG9yIFJGQzYxNjMuDQo0LiAgICAgICBJbiBTZWN0aW9uIOKAnDYuMS4xIE9UTiBkaWdpdGFsIHN0 cnVjdHVyZeKAnSBpdCBpcyBleHBsYWluZWQgdGhhdCANCmFuIE9UVWsgY29udGFpbnMgYSBGRUMs IGJ1dCBPVFVDbiBkb2VzIG5vdCwgbGVhdmluZyBpdCB0byB0aGUgaW50ZXJmYWNlIHRvIA0KYXBw bHkgc29tZS4gVGhpcyBiYXNpY2FsbHkgY3JlYXRlcyBhIEZFQyBsYXllciBiZWxvdyB0aGUgT1RV Q24gdGhhdCB3aWxsIA0Kbm90IGJlIGRlZmluZWQgaW4gRy43MDkuIEEgY29udHJvbCBwbGFuZSB3 b3VsZCBuZWVkIHRvIGNoZWNrIGNvbXBhdGliaWxpdHkgDQpvZiB3YXZlbGVuZ3RoLCBtb2R1bGF0 aW9uLCBpbnRlcmZhY2VzIChpLmUuIGhvdyBtYW55IGxhbmVzKSBhbmQgDQpjb21wYXRpYmlsaXR5 IG9mIEZFQywgYXMgd2VsbCBhcyB1c2FnZSBvZiBPVFVrIHZzIE9UVUNuLiBBbHNvIHRoaXMgY2Fz ZSANCmhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2My4NCjUuICAg ICAgIFRoZXJlIGlzIGFsc28gYSBuZXcgT01TIE1TSSAoc2VjdCAxNS40KSBvdmVyaGVhZCBkZWZp bmVkLCB3aGljaCANCnByb3ZpZGVzIGEgbGlzdCBvZiBPQ2ggYW5kIE9UU2lBIGZyZXF1ZW5jeSBz bG90LHBvcnQgbnVtYmVycyBhbmQgYSBsaXN0IG9mIA0KbWVkaWEgY2hhbm5lbHMgKGZyZXF1ZW5j eSBzbG90LCBtZWRpYSBjaGFubmVsIHBvcnQgbnVtYmVycykgdG8gZGVjb2RlIHRoZSANCmxhbmVz IGNvcnJlY3RseS4gVGhpcyBtYXkgYWZmZWN0IFJGQzYxNjMNCjYuICAgICAgIFRoZSB0ZXJtIOKA nFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV44oCdIGluIHRoZSBzZWN0aW9ucyBhYm92ZSAN CmRvZXNu4oCZdCBpbXBseSBhIHdhdmVsZW5ndGggY2FuIGJlIHJvdXRlZCB0aHJvdWdoIGEgRFdE TSBuZXR3b3JrIHNpbmNlIHdlIA0Ka25vdyB0aGF0IGUuZy4gMTAwRyBpbnRlcmZhY2VzIGFyZSBu b3QgeWV0IGRlZmluZWQgYnkgU0cxNSBmb3IgYW1wbGlmaWVkIA0KRFdETSBhcHBsaWNhdGlvbnMu IFdpdGhvdXQgYW1wbGlmaWVycywgdGhlIGRpc3RhbmNlIHN1cHBvcnRlZCBieSBzdWNoIERXRE0g DQppcyBsaWtlbHkgbGltaXRlZCB0byBiZWxvdyA4MC0xMDBrbS4gSXQgaXMgbm90IHlldCBjbGVh ciBieSB3aGVuIHRoaXMgDQpsaW1pdGF0aW9uIHdpbGwgYmUgbGlmdGVkIGJ5IFNHMTUgKHNlZSAN CmRyYWZ0LW1hbnktY29oZXJlbnQtZHdkbS1pZi1jb250cm9sLTAwKS4gQWZ0ZXIgYWxsLCBPVFU0 IGJhc2VkIDEwMEcgDQppbnRlcmZhY2VzIGZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMg YXJlIGF2YWlsYWJsZSBhbmQgaGF2ZSBldmVuIA0KYmVlbiBwcm92ZW4gdG8gYmUgaW50ZXJvcGVy YWJsZSBhbW9uZyBtdWx0aXBsZSB2ZW5kb3JzIGNvdmVyaW5nIGRpc3RhbmNlcyANCj4xMDAwa20u ICBIb3dldmVyLCB0byBzdGF5IGluIHRoZSBzdGFuZGFyZHMgZnJhbWV3b3JrIGZvciBub3csIFJG QzYxNjMgDQp3b3VsZCBuZWVkIHRvIGNvbnNpZGVyOg0KYS4gICAgICAgV2hpbGUgYSBPVFVDbiBj YW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQgaW50byBhIA0Kc2luZ2xlIHdh dmVsZW5ndGgsIGl0IGNhbm5vdCBiZSByb3V0ZWQgaW4gV1NPTiDDoCBubyAxMDBHIGludGVyZmFj ZXMgaW4gDQphbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjINCmIuICAg ICAgIEFuIE9UVUNuIG1heSBiZSBicm9rZW4gZG93biBpbnRvIDQgbGFuZXMgYXQgMjVHIChPVEw0 LjQpIGJ1dCANCnN0aWxsIGNhbuKAmXQgYmUgcm91dGVkIGluIFdTT04gw6Agbm8gMjVHIGludGVy ZmFjZXMgaW4gYW1wbGlmaWVkIERXRE0gDQpuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjINCmMu ICAgICAgIEFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93biBpbiBPVEwzLjQgcHJvdmlk aW5nIDQgbGFuZXMgYXQgDQoxMEcgZWFjaCDDoCAxMEcgaW50ZXJmYWNlcyBhcmUgYWxsb3dlZCBp biBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIA0KaW4gRy42OTguMg0KIA0KIA0KIA0K IA0KIA0KIA0KRnJvbTogQ0NBTVAgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBEYW5pZWxlIENlY2NhcmVsbGkgDQo8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4N CkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDIwOjAyDQpUbzogImh1dWJhdHdvcmtA Z21haWwuY29tIiA8aHV1YmF0d29ya0BnbWFpbC5jb20+LCBDQ0FNUCA8Y2NhbXBAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQogDQpUaGFu ayBIdXViLA0KIA0KQXV0aG9ycywgaWYgeW91IGNvdWxkIGhhdmUgYSBsaXR0bGUgcGllY2Ugb2Yg dGV4dCBkZXNjcmliaW5nIHRoaXMgDQpjb25zaWRlcmF0aW9uIGluIHRoZSBmcmFtZXdvcmsgb3Ig aW4gb25lIG9mIHRoZSBzb2x1dGlvbiBkb2N1bWVudHMgDQooZGVwZW5kaW5nIHdoYXQgYXJlIHRo ZSBwbGFucyBmb3IgdGhlIG1lcmdlKSB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0KIA0KVGhhbmtzDQpE YW5pZWxlIA0KIA0KRnJvbTogSHV1YiB2YW4gSGVsdm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdt YWlsLmNvbV0gDQpTZW50OiB2ZW5lcmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMxDQpUbzogRGFu aWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjsgY2NhbXBA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24N CiANCkRhbmllbGUsDQoNCllvdSB3cml0ZToNClRoYW5rcyBmb3IgdGhlIGNsZWFyIGV4cGxhbmF0 aW9uIEh1dWIuDQoNCllvdSdyZSB3ZWxjb21lLg0KDQoNCg0KSSBzZWUgdHdvIGRpZmZlcmVudCB1 c2UgY2FzZXMgdGhhdCBib3RoIG1ha2Ugc2Vuc2UuIA0KDQpJIGhhdmUgdG8gZGlzYWdyZWUgKGFn YWluKS4NCg0KDQoNClRoZSBvbmUgcHJvcG9zZWQgYnkgR2VydCBpcyBzdGl0Y2hpbmcgb2YgYW4g T0RVNCBhbmQgT0RVQzEsDQoNClRoaXMgdXNlIGNhc2UgaXMgaW1wb3NzaWJsZS4gQXMgeW91IGNh biBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTEgDQphIGxvd2VyIG9yZGVyIE9EVTQgaXMg bWFwcGVkIGludG8gYSBoaWdoZXIgb3JkZXIgT0RVQzEsIGFuZCB0aGlzIA0KbWVhbnMgdGhhdCB0 aGV5IGNvbnN0aXR1dGUgZGlmZmVyZW50IGxheWVycyBpbiB0aGUgT1ROLiANCkFuZCBhcmUgaW1w b3NzaWJsZSB0byBzdGl0Y2guDQoNCg0KDQp3aGlsZSB0aGUgb25lIHlvdSBhcmUgZGVzY3JpYmlu ZyBpcyB0dW5uZWxpbmcgb2YgT0RVNCBvdmVyIGFuIE9EVUMxIHRyYWlsLg0KDQpDb3JyZWN0Lg0K DQoNCg0KVGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5n IGlzIG5vdCBmZWFzaWJsZT8NCg0KSSB0cmllZCB0byBleHBsYWluIGFib3ZlLg0KDQpCZXN0IHJl Z2FyZHMsIEh1dWIuDQoNCg0KDQogIA0KRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHV1YiB2YW4gSGVsdm9vcnQNClNlbnQ6IGdpb3ZlZMOs IDE3IG5vdmVtYnJlIDIwMTYgMTc6MDYNClRvOiBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KIA0KSGVsbG8gR2VydCwNCg0KWW91 ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Lg0KDQpJbnN0ZWFkIG9mOg0KMS4g ICAgICBBIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlzOg0KIA0KICAgICAgICstLS0tLS0tLS0tKyAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01Q LU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9E VUMxLUdNUC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAg ICAgICAgIE5FMiAoPUdXLU5FKSAgICAgICAgICAgICAgICAgICAgICAgTkUzDQoNCkl0IHNob3Vs ZCBiZTogDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t KyArLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoxMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0 LXwtT0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLU9EVTQtR01QLXwt LTEwMEdFDQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t KyArLS0tLS0tLS0tLS0tLS0tLS0tLS0rICANCg0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAg ICAgICAgICAgTkUyICg9R1ctTkUpICAgICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9E VUMxIGZyb20gTkUyIHRvIE5FMyB0dW5uZWxzIHRoZSBPRFU0Lg0KUmVnYXJkcywgSHV1Yi4NCiAN CiANCiANCi0tIA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KQWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUu Li5qdXN0IGxpa2UgZXZlcnlvbmUgZWxzZS4uLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQo= --=_alternative 0055ECF048258074_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdlcnQsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMu IEZvbGxvd2luZw0KaXMgbXkgYW5zd2VyIHRvIHlvdXIgcHJldmlvdXMgbWFpbCBhbmQgdGhpcyBv bmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4oMSks IEFib3V0IHRoZSBxdWVzdGlvbnMgaW4geW91ciBwcmV2aW91cw0KbWFpbC4gSSB0aGluayB5b3Ug YWxyZWFkeSBoYXZlIG1hbnkgb2YgdGhlbSBzb2x2ZWQuIE9EVUNuIGhhcyBhbG1vc3QgdGhlDQpz YW1lIG92ZXJoZWFkIGFzIHRoYXQgb2YgT0RVaywgc28gSSBkb24ndCB0aGluayBzb21lIG1lY2hh bmlzbXMgb2YgT0RVQ24NCihlLmcuLCBPQU0gZXRjKSBkaWZmZXIgZnJvbSB0aG9zZSBvZiBPRFVr LiBJbiB0aGUgT0RVQ24gZHJhZnQsIEkgdGhpbmsNCndlIHNob3VsZCBtYWlubHkgcGF5IGF0dGVu dGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZmZXJlbmNlIHdpdGgNCk9EVWsgbm93 LCBzdWNoIGFzIGxheWVyIG1vZGVsIG9mIE9EVUNuIGFuZCBzZXR1cCBvZiBPRFVDbiBjb25uZWN0 aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDIp LCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHRoZSBzZWNvbmQNCml0ZW1zIG9mIHRoaXMgdGhyZWFk LiBJIHRoaW5rIGl0J3Mgb3V0IG9mIHRoZSBzY29wZSBvZiBDQ0FNUC4gSSBjYW4ndCBnaXZlDQph IGRlZmluaXRlIGFuc3dlciB0byB0aGVzZSBxdWVzdGlvbnMuIDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDMpLCBDb250cm9sIG9mIG9wdGljYWwgbmV0 d29yayBpcyBvdXQNCm9mIHRoZSBzY29wZSBvZiBjdXJyZW50IE9EVUNuIGRvY3VtZW50LiBXZSB3 aWxsIG5vdCBpbnZvbHZlIHRoaXMgcGFydCBpbi4NCkFsc28gSSBzdWdnZXN0IHlvdSB0YWtlIGEg bG9vayBhdCBSRkM3Njk4LCB3aGljaCBtYWlubHkgZm9jdXMgb24gdGhlIGNvbnRyb2wNCm9mIGZs ZXhpYmxlIGdyaWQgbmV0d29yay48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+UWlsZWk8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+R2VydCBHcmFtbWVsICZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8 L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuWPkeS7tuS6 ujogJm5ic3A7JnF1b3Q7Q0NBTVAmcXVvdDsgJmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYvMTEvMjMgMjE6 MDE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPuaUtuS7tuS6ujwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+RGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24u Y29tJmd0OywNCiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZn dDssIDwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5oqE6YCBPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtodXViYXR3b3JrQGdtYWlsLmNvbSZxdW90 OyAmbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvp opg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBb Q0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0 YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+RGFuaWVsZSwgQXV0 aG9ycyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QWZ0ZXIgb3VyIGluaXRpYWwgZW1h aWwgZXhjaGFuZ2UgSSB0b29rDQphIG1vcmUgZGV0YWlsZWQgbG9vayBpbiB0aGUgMjAxNiB2ZXJz aW9uIG9mIEcuNzA5LiBJbiBlc3NlbmNlLCB0aGUgMjAxNg0KdmVyc2lvbiBvZiBHLjcwOSB3b3Vs ZCBpbXBhY3QgY29udHJvbCBwbGFuZSB3b3JrIGZvciBHLjcwOSAoUkZDNzEzOSkgYXMNCndlbGwg YXMgZm9yIFdTT04gKFJGQzYxNjMpLiBUaGUgY29tcGxleCBuYXR1cmUgb2YgdGhvc2UgZGVmaW5p dGlvbnMgd2lsbA0KY2VydGFpbmx5IG5vdCBiZSBhbiBlYXN5LWdvaW5nIGV4dGVuc2lvbiBhcyBp dCBoYWQgYmVlbiBlbnZpc2FnZWQgc28gZmFyLg0KV3JpdGluZyBhIOKAnGxpdHRsZSBwaWVjZSBv ZiB0ZXh04oCdIGxvb2tzIHRvIG1lIGxpa2UgYSDigJxsaXR0bGUgYml0IG9mDQp1bmRlcnN0YXRl bWVudOKAnS4gSWYgdGhlIFdHIGludGVuZHMgdG8gd29yayBvbiB0aGUgc3ViamVjdCwgbXkgcGxl ZGdlDQp3b3VsZCBiZSB0byBzdGFydCBmcm9tIGEgZnJhbWV3b3JrIGRvY3VtZW50IHRvIGNhcHR1 cmUgdGhlIG5ldyBjb25jZXB0cw0KYmVmb3JlIGRlZmluaW5nIHByb3RvY29sIGV4dGVuc2lvbnMu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkJlc3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+R2VydDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkJlbG93IGEgbGlzdCBvZiBvYnNlcnZh dGlvbnMgdGhhdCBpbmZsdWVuY2VkDQp0aGlzIHZpZXc6PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4xLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPUFVDbiwgT0RVQ24gYW5k DQpPVFVDbiBhcmUgbmV3IGFuZCB0aGUgbGF5ZXJpbmcgcmVsYXRpb25zaGlwIHRvIHRoZSBmb3Jt ZXIgc3RydWN0dXJlIGlzDQphIGJpdCBzdXJwcmlzaW5nLCBhcyB0aGUgZGlzY3Vzc2lvbiBvbiB0 aGUgbGlzdCAoc2VlIGJlbG93KSBzaG93ZWQuIEJldHRlcg0KdG8gZ2V0IHRoaXMgcmlnaHQgZWFy bHkgb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjIuICZuYnNwOyAm bmJzcDsgJm5ic3A7IEZpZ3VyZSA3LTEgc2hvd3MNCnRoZSBPVE4gbXVsdGlwbGV4aW5nIGFuZCBt YXBwaW5nIHN0cnVjdHVyZXMgYnV0IGRvZXMgbm90IGluZGljYXRlIGhvdyBlLmcuDQphIDQwMEdF IHdvdWxkIGJlIG1hcHBlZCBpbnRvIHRoaXMgc3RydWN0dXJlLiBJdCBpcyBub3Qgc3VycHJpc2lu ZyBhcyA0MDBHRQ0KaXMgc3RpbGwgaW4gdGhlIG1ha2luZ3MsIGJ1dCByYWlzZXMgYSBmZXcgcXVl c3Rpb25zIGFib3V0IGhvdyBpdCBpcyBwbGFubmVkDQp0byBiZSBtYXBwZWQuIEhvd2V2ZXIgZ3Vp ZGFuY2UgZnJvbSBTRzE1IHdvdWxkIGhlbHAgdG8gZ2V0IHRoZSBwcm90b2NvbA0KYXJjaGl0ZWN0 dXJlIGZ1dHVyZSBwcm9vZi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PmEuICZuYnNwOyAmbmJzcDsgJm5ic3A7IERvZXMgZXZlcnkgY2xpZW50DQpzaWduYWwgbmVlZCB0 byBiZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0 ZWQNCnZpYSBhbiBPUFVDbi9PRFVDbj8gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJXaW5nZGlu Z3MiPsOgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4NCnRoaXMgd291bGQgbWVh biB0byBleHRlbmQgdGhlIE9EVSBzdHJ1Y3R1cmUgYnkgYW4gT0RVNSw2LDcgZXRjLiBmb3IgY2xp ZW50cw0KJmd0OyAxMDBHPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5i LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaWxsIG9ubHkgY2xpZW50DQpzaWduYWxzICZsdDs9IDEw MEcgbmVlZCB0byBiZSB3cmFwcGVkIGluIGFuIE9QVWsvT0RVayBiZWZvcmUgaXQgY2FuIGJlDQp0 cmFuc3BvcnRlZCB2aWEgYW4gT1BVQ24vT0RVQ24/IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i V2luZ2RpbmdzIj7DoDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+DQp0aGlzIHdv dWxkIG1lYW4gdGhhdCB0aGVyZSB3aWxsIGJlIGEgYnJlYWsgaW4gdGhlIG1hcHBpbmdzIGF0IGFi b3V0IDEwMEcNCnNpZ25hbHMgYW5kIG5vIE9EVTUsNiw3IHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5l ZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Yy4gJm5ic3A7ICZuYnNw OyAmbmJzcDsgV2lsbCBmdXR1cmUgY2xpZW50cw0KYmUgbWFwcGVkIGRpcmVjdGx5IGludG8gT1BV Q24vT0RVQ24gYW5kIHRoZSBzcGVjaWFsIGNhc2Ugb2YgMTAwR0U8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IldpbmdkaW5ncyI+w6A8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPk9Q VWsvT0RVazwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iV2luZ2RpbmdzIj7DoDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+T1BVQ24vT0RVQ24NCndpbGwgYmVjb21lIGp1c3QgYW5v dGhlciBvcHRpb24/IChOb3RlOiB0aGUgZmlndXJlIGV4cGxpY2l0bHkgYWxsb3dzIGZvcg0KcHJv cHJpZXRhcnkgbWFwcGluZ3MgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBs aWtlIGEgcHJhY3RpY2FsDQp1c2UgY2FzZSwgYnV0IGl0IGxvb2tzIG9kZCB0aGF0IGl0IHJlbWFp bnMgcHJvcmlldGFyeSk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjMu ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBzZWN0aW9uIOKAnDcuMQ0KTWFwcGluZ+KAnSBhbmQg 4oCcNy4yIFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV44oCdIGNoYW5nZWQgYSBiaXQgZnJv bQ0KdGhlIDIwMTIgdmVyc2lvbi4gQXMgYWNyb255bXMgaGF2ZSBjaGFuZ2VkIHRvbywgYSAxOjEg Y29tcGFyaXNvbiBpcyBub3QNCnRvbyBzaW1wbGUuIFRoZSB0YWtlYXdheSBpcyB0aGF0IGFuIE9U VSBjYW4gYmUgbWFwcGVkIGludG8gYSBzaW5nbGUgd2F2ZWxlbmd0aA0Kb3Igc3ByZWFkIGFjcm9z cyBzb21lIChPVExrLm4gYW5kIE9UTEMubikgd2hpY2ggbWVhbnMgaW52ZXJzZSBtdWx0aXBsZXhp bmcuDQpTbyBmYXIgdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkg b3IgUkZDNjE2My48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjQuICZu YnNwOyAmbmJzcDsgJm5ic3A7IEluIFNlY3Rpb24g4oCcNi4xLjENCk9UTiBkaWdpdGFsIHN0cnVj dHVyZeKAnSBpdCBpcyBleHBsYWluZWQgdGhhdCBhbiBPVFVrIGNvbnRhaW5zIGEgRkVDLCBidXQN Ck9UVUNuIGRvZXMgbm90LCBsZWF2aW5nIGl0IHRvIHRoZSBpbnRlcmZhY2UgdG8gYXBwbHkgc29t ZS4gVGhpcyBiYXNpY2FsbHkNCmNyZWF0ZXMgYSBGRUMgbGF5ZXIgYmVsb3cgdGhlIE9UVUNuIHRo YXQgd2lsbCBub3QgYmUgZGVmaW5lZCBpbiBHLjcwOS4NCkEgY29udHJvbCBwbGFuZSB3b3VsZCBu ZWVkIHRvIGNoZWNrIGNvbXBhdGliaWxpdHkgb2Ygd2F2ZWxlbmd0aCwgbW9kdWxhdGlvbiwNCmlu dGVyZmFjZXMgKGkuZS4gaG93IG1hbnkgbGFuZXMpIGFuZCBjb21wYXRpYmlsaXR5IG9mIEZFQywg YXMgd2VsbCBhcyB1c2FnZQ0Kb2YgT1RVayB2cyBPVFVDbi4gQWxzbyB0aGlzIGNhc2UgaGFzIG5v dCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvcg0KUkZDNjE2My48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjUuICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZXJlIGlz IGFsc28gYQ0KbmV3IE9NUyBNU0kgKHNlY3QgMTUuNCkgb3ZlcmhlYWQgZGVmaW5lZCwgd2hpY2gg cHJvdmlkZXMgYSBsaXN0IG9mIE9DaA0KYW5kIE9UU2lBIGZyZXF1ZW5jeSBzbG90LHBvcnQgbnVt YmVycyBhbmQgYSBsaXN0IG9mIG1lZGlhIGNoYW5uZWxzIChmcmVxdWVuY3kNCnNsb3QsIG1lZGlh IGNoYW5uZWwgcG9ydCBudW1iZXJzKSB0byBkZWNvZGUgdGhlIGxhbmVzIGNvcnJlY3RseS4gVGhp cyBtYXkNCmFmZmVjdCBSRkM2MTYzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj42LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgdGVybSDigJxXYXZlbGVuZ3RoDQpEaXZp c2lvbiBNdWx0aXBsZXjigJ0gaW4gdGhlIHNlY3Rpb25zIGFib3ZlIGRvZXNu4oCZdCBpbXBseSBh IHdhdmVsZW5ndGgNCmNhbiBiZSByb3V0ZWQgdGhyb3VnaCBhIERXRE0gbmV0d29yayBzaW5jZSB3 ZSBrbm93IHRoYXQgZS5nLiAxMDBHIGludGVyZmFjZXMNCmFyZSBub3QgeWV0IGRlZmluZWQgYnkg U0cxNSBmb3IgYW1wbGlmaWVkIERXRE0gYXBwbGljYXRpb25zLiBXaXRob3V0IGFtcGxpZmllcnMs DQp0aGUgZGlzdGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2ggRFdETSBpcyBsaWtlbHkgbGltaXRlZCB0 byBiZWxvdyA4MC0xMDBrbS4NCkl0IGlzIG5vdCB5ZXQgY2xlYXIgYnkgd2hlbiB0aGlzIGxpbWl0 YXRpb24gd2lsbCBiZSBsaWZ0ZWQgYnkgU0cxNSAoc2VlDQpkcmFmdC1tYW55LWNvaGVyZW50LWR3 ZG0taWYtY29udHJvbC0wMCkuIEFmdGVyIGFsbCwgT1RVNCBiYXNlZCAxMDBHIGludGVyZmFjZXMN CmZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhbmQgaGF2ZSBl dmVuIGJlZW4gcHJvdmVuDQp0byBiZSBpbnRlcm9wZXJhYmxlIGFtb25nIG11bHRpcGxlIHZlbmRv cnMgY292ZXJpbmcgZGlzdGFuY2VzICZndDsxMDAwa20uDQombmJzcDtIb3dldmVyLCB0byBzdGF5 IGluIHRoZSBzdGFuZGFyZHMgZnJhbWV3b3JrIGZvciBub3csIFJGQzYxNjMgd291bGQNCm5lZWQg dG8gY29uc2lkZXI6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5hLiAm bmJzcDsgJm5ic3A7ICZuYnNwOyBXaGlsZSBhIE9UVUNuIGNhbg0KYmUgZGlnaXRhbGx5IGNvbnN0 cnVjdGVkIGFuZCBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QNCmJl IHJvdXRlZCBpbiBXU09OIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iV2luZ2RpbmdzIj7DoDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+DQpubyAxMDBHIGludGVyZmFjZXMgaW4g YW1wbGlmaWVkIERXRE0gbmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5OC4yPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5iLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbiBPVFVD biBtYXkgYmUNCmJyb2tlbiBkb3duIGludG8gNCBsYW5lcyBhdCAyNUcgKE9UTDQuNCkgYnV0IHN0 aWxsIGNhbuKAmXQgYmUgcm91dGVkIGluDQpXU09OIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i V2luZ2RpbmdzIj7DoDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+DQpubyAyNUcg aW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjI8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPmMuICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEFuIE9UVTMgKD00MEcpDQpjYW4gYmUgYnJva2VuIGRvd24gaW4gT1RMMy40IHByb3Zp ZGluZyA0IGxhbmVzIGF0IDEwRyBlYWNoIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iV2luZ2Rp bmdzIj7DoDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+DQoxMEcgaW50ZXJmYWNl cyBhcmUgYWxsb3dlZCBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4 LjI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPjxiPkZyb206IDwvYj5DQ0FN UCAmbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDsNCm9uIGJlaGFsZiBvZiBEYW5pZWxlIENl Y2NhcmVsbGkgJmx0O2RhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20mZ3Q7PGI+PGJyPg0K RGF0ZTogPC9iPkZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDIwOjAyPGI+PGJyPg0KVG86IDwv Yj4mcXVvdDtodXViYXR3b3JrQGdtYWlsLmNvbSZxdW90OyAmbHQ7aHV1YmF0d29ya0BnbWFpbC5j b20mZ3Q7LA0KQ0NBTVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OzxiPjxicj4NClN1YmplY3Q6IDwv Yj5SZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhhbmsgSHV1Yiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+QXV0aG9ycywgaWYgeW91IGNvdWxkIGhhdmUgYSBsaXR0bGUgcGllY2UNCm9mIHRleHQg ZGVzY3JpYmluZyB0aGlzIGNvbnNpZGVyYXRpb24gaW4gdGhlIGZyYW1ld29yayBvciBpbiBvbmUg b2YgdGhlDQpzb2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGluZyB3aGF0IGFyZSB0aGUgcGxhbnMg Zm9yIHRoZSBtZXJnZSkgdGhhdCB3b3VsZA0KYmUgZ3JlYXQuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ RGFuaWVsZSAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGI+RnJvbTo8L2I+ IEh1dWIgdmFuIEhlbHZvb3J0IFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aHV1YmF0d29ya0BnbWFp bC5jb20+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPm1haWx0bzpodXViYXR3b3JrQGdtYWls LmNvbTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPl0NCjxiPjxicj4NClNl bnQ6PC9iPiB2ZW5lcmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMxPGI+PGJyPg0KVG86PC9iPiBE YW5pZWxlIENlY2NhcmVsbGkgJmx0O2RhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20mZ3Q7 OyBjY2FtcEBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBPRFU0IGFu ZCBPRFVDbiBkaXNjdXNzaW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkRhbmllbGUs PGJyPg0KPGJyPg0KWW91IHdyaXRlOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+VGhhbmtzIGZvciB0aGUgY2xlYXIgZXhwbGFuYXRpb24gSHV1Yi48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KWW91J3JlIHdlbGNvbWUu PGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5JIHNlZSB0d28gZGlmZmVyZW50IHVzZSBjYXNlcyB0aGF0IGJvdGgNCm1ha2Ugc2Vuc2UuIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpJIGhh dmUgdG8gZGlzYWdyZWUgKGFnYWluKS48YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoZSBvbmUgcHJvcG9zZWQgYnkgR2VydCBpcyBzdGl0 Y2hpbmcgb2YNCmFuIE9EVTQgYW5kIE9EVUMxLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpUaGlzIHVzZSBjYXNlIGlzIGltcG9zc2libGUuIEFz IHlvdSBjYW4gc2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1cmUgNy0xDQo8YnI+DQphIGxvd2VyIG9y ZGVyIE9EVTQgaXMgbWFwcGVkIGludG8gYSBoaWdoZXIgb3JkZXIgT0RVQzEsIGFuZCB0aGlzIDxi cj4NCm1lYW5zIHRoYXQgdGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXllcnMgaW4gdGhlIE9U Ti4gPGJyPg0KQW5kIGFyZSBpbXBvc3NpYmxlIHRvIHN0aXRjaC48YnI+DQo8YnI+DQo8YnI+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPndoaWxlIHRoZSBvbmUgeW91 IGFyZSBkZXNjcmliaW5nIGlzIHR1bm5lbGluZw0Kb2YgT0RVNCBvdmVyIGFuIE9EVUMxIHRyYWls LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpD b3JyZWN0Ljxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+VGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUNCnN0aXRj aGluZyBpcyBub3QgZmVhc2libGU/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxicj4NCkkgdHJpZWQgdG8gZXhwbGFpbiBhYm92ZS48YnI+DQo8YnI+DQpC ZXN0IHJlZ2FyZHMsIEh1dWIuPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+PGI+RnJvbTo8L2I+IENDQU1QIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj0jMDA4MmJmIGZhY2U9IkNhbGlicmki Pjx1Pm1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHV1YiB2YW4gSGVsdm9v cnQ8Yj48YnI+DQpTZW50OjwvYj4gZ2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzowNjxiPjxi cj4NClRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmNjYW1wQGlldGYub3JnPjxmb250IHNp emU9MiBjb2xvcj0jMDA4MmJmIGZhY2U9IkNhbGlicmkiPjx1PmNjYW1wQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxiPjxicj4NClN1YmplY3Q6PC9i PiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNhbGlicmkiPkhlbGxvIEdlcnQsPGJyPg0KPGJyPg0KWW91ciB1c2UgY2FzZSBpcyBub3Qg Y29tcGxldGVseSBjb3JyZWN0Ljxicj4NCjxicj4NCkluc3RlYWQgb2Y6PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4xLiAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QQ0KdXNlIGNhc2UgdG8gY29uc2lkZXIgaXM6PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7PC9iPjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOystLS0tLS0tLS0tKw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0tLS0tKzwvYj48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4xMDBHRS0tfC1HTVAtT0RVNC18LU9U VTQtLS1PVFU0LXwtT0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLXwt LTEwMEdFPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLS0tLS0tKw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0tLS0tLS0tLS0rICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0tLS0tKyAmbmJz cDsgPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtORTEgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwO05FMiAoPUdXLU5FKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBORTM8L2I+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCkl0IHNob3VsZCBi ZTogPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0rDQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC9i PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0t LS0tLS0rDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0t LS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyArLS0tLS0tLS0tLS0tLS0tLS0tLS0rICZuYnNwOyA8L2I+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwO05FMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IE5FMzwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGJyPg0KPGJyPg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5FMyB0dW5uZWxzIHRo ZSBPRFU0LjwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJl Z2FyZHMsIEh1dWIuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPi0tIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5BbHdheXMgcmVtZW1iZXIgdGhhdCB5 b3UgYXJlIHVuaXF1ZS4uLmp1c3QNCmxpa2UgZXZlcnlvbmUgZWxzZS4uLjwvZm9udD48dHQ+PGZv bnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA+ PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8 YnI+DQo= --=_alternative 0055ECF048258074_=-- From nobody Wed Nov 23 08:50:41 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E4B129F9C for ; Wed, 23 Nov 2016 08:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8Dof6timxPtm for ; Wed, 23 Nov 2016 08:50:32 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79184129F9B for ; Wed, 23 Nov 2016 08:50:31 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 157B73A3B72AD; Wed, 23 Nov 2016 16:50:26 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uANGoRTX018639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Nov 2016 16:50:28 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uANGoOKL023573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Nov 2016 16:50:25 GMT Received: from [149.204.106.204] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Nov 2016 17:50:11 +0100 To: , Gert Grammel References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> From: Dieter Beller Organization: Nokia Message-ID: <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> Date: Wed, 23 Nov 2016 17:50:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Cc: "ccamp@ietf.org" , "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 16:50:39 -0000 Hi all,

I would submit that we need a document similar to RFC 7139 (GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport
Networks) for the new ODUCn signal types.

RFC 7139 contains sufficient information and descriptions regaqrding the new G.709 signal types introduced in the Feb 2012 revision of G.709.

I don't think we need to take a different approach for the latest 2016 evolution of G.709.


Thanks,
Dieter

On 23.11.2016 16:38, wang.qilei@zte.com.cn wrote:
Hi Gert,

Thanks for your comments. Following is my answer to your previous mail and this one.

(1), About the questions in your previous mail. I think you already have many of them solved. ODUCn has almost the same overhead as that of ODUk, so I don't think some mechanisms of ODUCn (e.g., OAM etc) differ from those of ODUk. In the ODUCn draft, I think we should mainly pay attention to ODUCn's feature and its difference with ODUk now, such as layer model of ODUCn and setup of ODUCn connection.

(2), About the questions in the second items of this thread. I think it's out of the scope of CCAMP. I can't give a definite answer to these questions.

(3), Control of optical network is out of the scope of current ODUCn document. We will not involve this part in. Also I suggest you take a look at RFC7698, which mainly focus on the control of flexible grid network.

Thanks
Qilei


Gert Grammel <ggrammel@juniper.net>
发件人:  "CCAMP" <ccamp-bounces@ietf.org>

2016/11/23 21:01

收件人
 Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "ccamp@ietf.org" <ccamp@ietf.org>,
抄送
 "huubatwork@gmail.com" <huubatwork@gmail.com>
主题
 Re: [CCAMP] ODU4 and ODUCn discussion







Daniele, Authors,
 
After our initial email exchange I took a more detailed look in the 2016 version of G.709. In essence, the 2016 version of G.709 would impact control plane work for G.709 (RFC7139) as well as for WSON (RFC6163). The complex nature of those definitions will certainly not be an easy-going extension as it had been envisaged so far. Writing a “little piece of text” looks to me like a “little bit of understatement”. If the WG intends to work on the subject, my pledge would be to start from a framework document to capture the new concepts before defining protocol extensions.
 
Best
 
Gert
 
 
Below a list of observations that influenced this view:
1.       OPUCn, ODUCn and OTUCn are new and the layering relationship to the former structure is a bit surprising, as the discussion on the list (see below) showed. Better to get this right early on
2.       Figure 7-1 shows the OTN multiplexing and mapping structures but does not indicate how e.g. a 400GE would be mapped into this structure. It is not surprising as 400GE is still in the makings, but raises a few questions about how it is planned to be mapped. However guidance from SG15 would help to get the protocol architecture future proof.
a.       Does every client signal need to be wrapped into an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? → this would mean to extend the ODU structure by an ODU5,6,7 etc. for clients > 100G
b.       Will only client signals <= 100G need to be wrapped in an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? → this would mean that there will be a break in the mappings at about 100G signals and no ODU5,6,7 would need to be defined
c.       Will future clients be mapped directly into OPUCn/ODUCn and the special case of 100GE→OPUk/ODUk→OPUCn/ODUCn will become just another option? (Note: the figure explicitly allows for proprietary mappings directly into OPUCn/ODUCn which looks like a practical use case, but it looks odd that it remains prorietary)
3.       The section “7.1 Mapping” and “7.2 Wavelength Division Multiplex” changed a bit from the 2012 version. As acronyms have changed too, a 1:1 comparison is not too simple. The takeaway is that an OTU can be mapped into a single wavelength or spread across some (OTLk.n and OTLC.n) which means inverse multiplexing. So far this case has not been considered in RFC7139 or RFC6163.
4.       In Section “6.1.1 OTN digital structure” it is explained that an OTUk contains a FEC, but OTUCn does not, leaving it to the interface to apply some. This basically creates a FEC layer below the OTUCn that will not be defined in G.709. A control plane would need to check compatibility of wavelength, modulation, interfaces (i.e. how many lanes) and compatibility of FEC, as well as usage of OTUk vs OTUCn. Also this case has not been considered in RFC7139 or RFC6163.
5.       There is also a new OMS MSI (sect 15.4) overhead defined, which provides a list of OCh and OTSiA frequency slot,port numbers and a list of media channels (frequency slot, media channel port numbers) to decode the lanes correctly. This may affect RFC6163
6.       The term “Wavelength Division Multiplex” in the sections above doesn’t imply a wavelength can be routed through a DWDM network since we know that e.g. 100G interfaces are not yet defined by SG15 for amplified DWDM applications. Without amplifiers, the distance supported by such DWDM is likely limited to below 80-100km. It is not yet clear by when this limitation will be lifted by SG15 (see draft-many-coherent-dwdm-if-control-00). After all, OTU4 based 100G interfaces for amplified DWDM applications are available and have even been proven to be interoperable among multiple vendors covering distances >1000km.  However, to stay in the standards framework for now, RFC6163 would need to consider:
a.       While a OTUCn can be digitally constructed and mapped into a single wavelength, it cannot be routed in WSON → no 100G interfaces in amplified DWDM networks defined in G.698.2
b.       An OTUCn may be broken down into 4 lanes at 25G (OTL4.4) but still can’t be routed in WSON → no 25G interfaces in amplified DWDM networks defined in G.698.2
c.       An OTU3 (=40G) can be broken down in OTL3.4 providing 4 lanes at 10G each → 10G interfaces are allowed in amplified DWDM networks defined in G.698.2
 
 
 
 
 
 
From: CCAMP <ccamp-bounces@ietf.org> on behalf of Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Date: Friday 18 November 2016 at 20:02
To: "huubatwork@gmail.com" <huubatwork@gmail.com>, CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Thank Huub,
 
Authors, if you could have a little piece of text describing this consideration in the framework or in one of the solution documents (depending what are the plans for the merge) that would be great.
 
Thanks
Daniele  
 
From: Huub van Helvoort [mailto:huubatwork@gmail.com]
Sent: venerdì 18 novembre 2016 19:31
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; ccamp@ietf.org
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Daniele,

You write:
Thanks for the clear explanation Huub.

You're welcome.
I see two different use cases that both make sense.

I have to disagree (again).
The one proposed by Gert is stitching of an ODU4 and ODUC1,

This use case is impossible. As you can see in G.709 (2016) figure 7-1
a lower order ODU4 is mapped into a higher order ODUC1, and this
means that they constitute different layers in the OTN.
And are impossible to stitch.
while the one you are describing is tunneling of ODU4 over an ODUC1 trail.

Correct.
They both seems reasonable to me, why the stitching is not feasible?

I tried to explain above.

Best regards, Huub.
 
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Huub van Helvoort
Sent: giovedì 17 novembre 2016 17:06
To: ccamp@ietf.org
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Hello Gert,

Your use case is not completely correct.

Instead of:
1.      A use case to consider is:
 
       +----------+             +----------------+               +-----------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-|--100GE
       +----------+             +----------------+               +-----------+  
             NE1                    NE2 (=GW-NE)                       NE3

It should be:
       +----------+             +----------------+               +--------------------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE
       +----------+             +----------------+               +--------------------+  
             NE1                    NE2 (=GW-NE)                       NE3

The ODUC1 from NE2 to NE3 tunnels the ODU4.

Regards, Huub.

 
 

 
--
================================================================
Always remember that you are unique...just like everyone else..._______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
 


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From nobody Wed Nov 23 10:52:48 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9131295F5 for ; Wed, 23 Nov 2016 10:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 8ju4OIUZ08Rw for ; Wed, 23 Nov 2016 10:52:42 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0111.outbound.protection.outlook.com [104.47.32.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931E5129A0E for ; Wed, 23 Nov 2016 10:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sN5ovdBjbNUsSxbCykPzagfv3mUejpk3RGKTE1z34FM=; b=J6Yv85c/LfMqpOSme8F7QL6PPok4KhE70L9Em083NIjJJHuiwjCgvVZ3uMy84XcMbaySCKhpXCrL51n875Cv9azo4z1DHTnCSGtxYiR3ZFn1RGKaA4359XjVCRYNXstUHpbhjQ2/QeBBftRI1V9PRIv8gMkWFuKlivGrQiiONFw= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Wed, 23 Nov 2016 18:52:26 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0747.010; Wed, 23 Nov 2016 18:52:26 +0000 From: Gert Grammel To: Dieter Beller , "wang.qilei@zte.com.cn" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgAGrtCCAAA8PAIAACKjwgAeHm4CAABtbAIAAE+UAgAAy6gA= Date: Wed, 23 Nov 2016 18:52:26 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> In-Reply-To: <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-ms-office365-filtering-correlation-id: 143dbd69-3f9d-40d8-576b-08d413d1de8b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1612; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 7:fmk4Kn0sImLmX3aAxocm4p7totHCs+ueVylzvjmFbDN9xpMhK5SIr9vGOLltGCZcrDxDTR6TU843C11b0coSBN7KESLH5aXLjgMbNwp7lHNSMUIo1D4B8YtYti3GwaPWD5SVNuPOENZ6ui/aNITOk5xwq8hsn+emBlNiB134nVFsZkvSV9QplacT8hXxmu6Y+Rksdd7C3v++tKlbw57p2dzpSWNe2NTWyW2i6ltt6yt944G2jv0eEudC5JBZ+nXMMJY8a1fVun7c7cty2Xv6dRkwM2G5xmVYxEestNDcGbOM6TYWTXsFV6bAT1xeKHQffg3XcEUimYn83A852OrlVgRIanyy14mRQItmFxJpavj5UV6erro3upHutolhoFpF/WV8ugeJ18/JRtHkEcWwSMLUnG5hC2zhUrXet3Wy6NUW/2yjAgQkUerxcAwt6qaAcqku1qe1SioB3/SqINxfSA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(138986009662008)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041248); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(51914003)(24454002)(53754006)(8676002)(122556002)(189998001)(2950100002)(97736004)(229853002)(38730400001)(39060400001)(2900100001)(82746002)(7846002)(77096005)(92566002)(7906003)(83506001)(2906002)(2501003)(86362001)(4001350100001)(83716003)(81166006)(7736002)(68736007)(81156014)(4326007)(8936002)(5001770100001)(93886004)(5660300001)(6512003)(36756003)(3660700001)(102836003)(33656002)(6116002)(606004)(3280700002)(66066001)(3846002)(101416001)(6506003)(99286002)(50986999)(105586002)(106116001)(54356999)(106356001)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F52DEAEE2EB2447E9E366AA8E179916Ajunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2016 18:52:26.7948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612 Archived-At: Cc: "ccamp@ietf.org" , "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 18:52:46 -0000 --_000_F52DEAEE2EB2447E9E366AA8E179916Ajunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGlldGVyLCBRaWxlaQ0KDQpkb27igJl0IGZvcmdldCB0byBhZGQgdGhlIE9UVUNuIHNpZ25h bCB0eXBlcyAoT1RVNCB3YXMgaW5jbHVkZWQgaW4gUkZDIDcxMzk8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzcxMzk+KSBhbmQgYWRkaXRpb25hbCBtYXBwaW5ncyBpbnRvIE9EVUNuL09U VUNuIGFuZCBjb25zaWRlciBob3cgdG8gc2lnbmFsIHRoZSBGRUMgd2hpY2ggaXMgbm93IGZvdW5k IG91dHNpZGUgT1RVQ24g4oCmDQoNClRoZSBpbXBvcnRhbnQgcGFydCBpcyB0aGF0IHRoZSBzdWJ0 bGUgZGlmZmVyZW5jZXMgYXJlIHdlbGwgdW5kZXJzdG9vZCBhbmQgdGFrZW4gY2FyZSBvZi4gTmFy cm93aW5nIGRvd24gdGhlIGRpc2N1c3Npb24gaW50byDigJxob3cgdG8gc2lnbmFsIE9EVUNu4oCd IGFwcGVhcnMgdG8gbWUgYXMgb3Zlci1zaW1wbGlmaWNhdGlvbi4gQ2FzZSBpbiBwb2ludCwgUWls ZWkgbWVudGlvbmVkIFJGQzc2OTggd2hpY2ggaXMgYSBmcmFtZXdvcmsgdGhhdCBiZWNhbWUgbmVj ZXNzYXJ5IGJlY2F1c2Ugb2YgZmxleGdyaWQgYW5kIG11bHRpLWxhbmUgaW50ZXJmYWNlcy4gSSBm aW5kIFJGQzc2OTggcXVpdGUgYmVuZWZpY2lhbCBhbmQgZmVlbCBhIHNpbWlsYXIgZnJhbWV3b3Jr IGRvY3VtZW50IHdvdWxkIGJlIG5lZWRlZCBvbiB0aGUgZGlnaXRhbCBwYXJ0IG9uY2UgZmxleGli bGUgc2l6ZWQgT1RVQ24gYW5kIE9EVUNuIGFyZSBpbnRyb2R1Y2VkLCB3aGlsZSBzd2FwcGluZyBG RUMgb3V0IG9mIHRoZSBPVFUgZGVmaW5pdGlvbi4NCg0KSWYgeW91IHRoaW5rIHlvdSBjYW4gY292 ZXIgZXZlcnl0aGluZyBpbiBleHRlbmRpbmcgbm9uLWZyYW1ld29yayBkb2N1bWVudHMsIGZlZWwg ZnJlZSB0byBnbyBhaGVhZC4gV2Ugd2lsbCBzZWUgb3ZlciB0aW1lIHdoZXRoZXIgbGFja2luZyB0 aGUgZnJhbWV3b3JrIHdpbGwgYnVyZGVuIHRoZSBwcm9ncmVzcy4NCg0KDQpHZXJ0DQoNCg0KDQoN Cg0KDQoNCkZyb206IERpZXRlciBCZWxsZXIgPERpZXRlci5CZWxsZXJAbm9raWEuY29tPg0KT3Jn YW5pemF0aW9uOiBOb2tpYQ0KRGF0ZTogV2VkbmVzZGF5IDIzIE5vdmVtYmVyIDIwMTYgYXQgMTc6 NTANClRvOiAid2FuZy5xaWxlaUB6dGUuY29tLmNuIiA8d2FuZy5xaWxlaUB6dGUuY29tLmNuPiwg R2VydCBHcmFtbWVsIDxnZ3JhbW1lbEBqdW5pcGVyLm5ldD4NCkNjOiBDQ0FNUCA8Y2NhbXBAaWV0 Zi5vcmc+LCAiaHV1YmF0d29ya0BnbWFpbC5jb20iIDxodXViYXR3b3JrQGdtYWlsLmNvbT4NClN1 YmplY3Q6IFJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KSGkgYWxsLA0K DQpJIHdvdWxkIHN1Ym1pdCB0aGF0IHdlIG5lZWQgYSBkb2N1bWVudCBzaW1pbGFyIHRvIFJGQyA3 MTM5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTM5PiAoR01QTFMgU2lnbmFsaW5n IEV4dGVuc2lvbnMgZm9yIENvbnRyb2wgb2YgRXZvbHZpbmcgRy43MDkgT3B0aWNhbCBUcmFuc3Bv cnQNCk5ldHdvcmtzKSBmb3IgdGhlIG5ldyBPRFVDbiBzaWduYWwgdHlwZXMuDQoNClJGQyA3MTM5 PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTM5PiBjb250YWlucyBzdWZmaWNpZW50 IGluZm9ybWF0aW9uIGFuZCBkZXNjcmlwdGlvbnMgcmVnYXFyZGluZyB0aGUgbmV3IEcuNzA5IHNp Z25hbCB0eXBlcyBpbnRyb2R1Y2VkIGluIHRoZSBGZWIgMjAxMiByZXZpc2lvbiBvZiBHLjcwOS4N Cg0KSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHRha2UgYSBkaWZmZXJlbnQgYXBwcm9hY2ggZm9y IHRoZSBsYXRlc3QgMjAxNiBldm9sdXRpb24gb2YgRy43MDkuDQoNCg0KVGhhbmtzLA0KRGlldGVy DQpPbiAyMy4xMS4yMDE2IDE2OjM4LCB3YW5nLnFpbGVpQHp0ZS5jb20uY248bWFpbHRvOndhbmcu cWlsZWlAenRlLmNvbS5jbj4gd3JvdGU6DQpIaSBHZXJ0LA0KDQpUaGFua3MgZm9yIHlvdXIgY29t bWVudHMuIEZvbGxvd2luZyBpcyBteSBhbnN3ZXIgdG8geW91ciBwcmV2aW91cyBtYWlsIGFuZCB0 aGlzIG9uZS4NCg0KKDEpLCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHlvdXIgcHJldmlvdXMgbWFp bC4gSSB0aGluayB5b3UgYWxyZWFkeSBoYXZlIG1hbnkgb2YgdGhlbSBzb2x2ZWQuIE9EVUNuIGhh cyBhbG1vc3QgdGhlIHNhbWUgb3ZlcmhlYWQgYXMgdGhhdCBvZiBPRFVrLCBzbyBJIGRvbid0IHRo aW5rIHNvbWUgbWVjaGFuaXNtcyBvZiBPRFVDbiAoZS5nLiwgT0FNIGV0YykgZGlmZmVyIGZyb20g dGhvc2Ugb2YgT0RVay4gSW4gdGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNob3VsZCBtYWlu bHkgcGF5IGF0dGVudGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZmZXJlbmNlIHdp dGggT0RVayBub3csIHN1Y2ggYXMgbGF5ZXIgbW9kZWwgb2YgT0RVQ24gYW5kIHNldHVwIG9mIE9E VUNuIGNvbm5lY3Rpb24uDQoNCigyKSwgQWJvdXQgdGhlIHF1ZXN0aW9ucyBpbiB0aGUgc2Vjb25k IGl0ZW1zIG9mIHRoaXMgdGhyZWFkLiBJIHRoaW5rIGl0J3Mgb3V0IG9mIHRoZSBzY29wZSBvZiBD Q0FNUC4gSSBjYW4ndCBnaXZlIGEgZGVmaW5pdGUgYW5zd2VyIHRvIHRoZXNlIHF1ZXN0aW9ucy4N Cg0KKDMpLCBDb250cm9sIG9mIG9wdGljYWwgbmV0d29yayBpcyBvdXQgb2YgdGhlIHNjb3BlIG9m IGN1cnJlbnQgT0RVQ24gZG9jdW1lbnQuIFdlIHdpbGwgbm90IGludm9sdmUgdGhpcyBwYXJ0IGlu LiBBbHNvIEkgc3VnZ2VzdCB5b3UgdGFrZSBhIGxvb2sgYXQgUkZDNzY5OCwgd2hpY2ggbWFpbmx5 IGZvY3VzIG9uIHRoZSBjb250cm9sIG9mIGZsZXhpYmxlIGdyaWQgbmV0d29yay4NCg0KVGhhbmtz DQpRaWxlaQ0KDQoNCkdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+PG1haWx0bzpn Z3JhbW1lbEBqdW5pcGVyLm5ldD4NCuWPkeS7tuS6ujogICJDQ0FNUCIgPGNjYW1wLWJvdW5jZXNA aWV0Zi5vcmc+PG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDE2LzExLzIzIDIx OjAxDQoNCuaUtuS7tuS6ug0KDQpEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxs aUBlcmljc3Nvbi5jb20+PG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPiwg ImNjYW1wQGlldGYub3JnIjxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IDxjY2FtcEBpZXRmLm9yZz48 bWFpbHRvOmNjYW1wQGlldGYub3JnPiwNCg0K5oqE6YCBDQoNCiJodXViYXR3b3JrQGdtYWlsLmNv bSI8bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiA8aHV1YmF0d29ya0BnbWFpbC5jb20+PG1h aWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4NCg0K5Li76aKYDQoNClJlOiBbQ0NBTVBdIE9EVTQg YW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KRGFuaWVsZSwgQXV0aG9ycywNCg0K QWZ0ZXIgb3VyIGluaXRpYWwgZW1haWwgZXhjaGFuZ2UgSSB0b29rIGEgbW9yZSBkZXRhaWxlZCBs b29rIGluIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkuIEluIGVzc2VuY2UsIHRoZSAyMDE2IHZl cnNpb24gb2YgRy43MDkgd291bGQgaW1wYWN0IGNvbnRyb2wgcGxhbmUgd29yayBmb3IgRy43MDkg KFJGQzcxMzkpIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYxNjMpLiBUaGUgY29tcGxleCBuYXR1 cmUgb2YgdGhvc2UgZGVmaW5pdGlvbnMgd2lsbCBjZXJ0YWlubHkgbm90IGJlIGFuIGVhc3ktZ29p bmcgZXh0ZW5zaW9uIGFzIGl0IGhhZCBiZWVuIGVudmlzYWdlZCBzbyBmYXIuIFdyaXRpbmcgYSDi gJxsaXR0bGUgcGllY2Ugb2YgdGV4dOKAnSBsb29rcyB0byBtZSBsaWtlIGEg4oCcbGl0dGxlIGJp dCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gSWYgdGhlIFdHIGludGVuZHMgdG8gd29yayBvbiB0aGUg c3ViamVjdCwgbXkgcGxlZGdlIHdvdWxkIGJlIHRvIHN0YXJ0IGZyb20gYSBmcmFtZXdvcmsgZG9j dW1lbnQgdG8gY2FwdHVyZSB0aGUgbmV3IGNvbmNlcHRzIGJlZm9yZSBkZWZpbmluZyBwcm90b2Nv bCBleHRlbnNpb25zLg0KDQpCZXN0DQoNCkdlcnQNCg0KDQpCZWxvdyBhIGxpc3Qgb2Ygb2JzZXJ2 YXRpb25zIHRoYXQgaW5mbHVlbmNlZCB0aGlzIHZpZXc6DQoxLiAgICAgICBPUFVDbiwgT0RVQ24g YW5kIE9UVUNuIGFyZSBuZXcgYW5kIHRoZSBsYXllcmluZyByZWxhdGlvbnNoaXAgdG8gdGhlIGZv cm1lciBzdHJ1Y3R1cmUgaXMgYSBiaXQgc3VycHJpc2luZywgYXMgdGhlIGRpc2N1c3Npb24gb24g dGhlIGxpc3QgKHNlZSBiZWxvdykgc2hvd2VkLiBCZXR0ZXIgdG8gZ2V0IHRoaXMgcmlnaHQgZWFy bHkgb24NCjIuICAgICAgIEZpZ3VyZSA3LTEgc2hvd3MgdGhlIE9UTiBtdWx0aXBsZXhpbmcgYW5k IG1hcHBpbmcgc3RydWN0dXJlcyBidXQgZG9lcyBub3QgaW5kaWNhdGUgaG93IGUuZy4gYSA0MDBH RSB3b3VsZCBiZSBtYXBwZWQgaW50byB0aGlzIHN0cnVjdHVyZS4gSXQgaXMgbm90IHN1cnByaXNp bmcgYXMgNDAwR0UgaXMgc3RpbGwgaW4gdGhlIG1ha2luZ3MsIGJ1dCByYWlzZXMgYSBmZXcgcXVl c3Rpb25zIGFib3V0IGhvdyBpdCBpcyBwbGFubmVkIHRvIGJlIG1hcHBlZC4gSG93ZXZlciBndWlk YW5jZSBmcm9tIFNHMTUgd291bGQgaGVscCB0byBnZXQgdGhlIHByb3RvY29sIGFyY2hpdGVjdHVy ZSBmdXR1cmUgcHJvb2YuDQphLiAgICAgICBEb2VzIGV2ZXJ5IGNsaWVudCBzaWduYWwgbmVlZCB0 byBiZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0 ZWQgdmlhIGFuIE9QVUNuL09EVUNuPyDihpIgdGhpcyB3b3VsZCBtZWFuIHRvIGV4dGVuZCB0aGUg T0RVIHN0cnVjdHVyZSBieSBhbiBPRFU1LDYsNyBldGMuIGZvciBjbGllbnRzID4gMTAwRw0KYi4g ICAgICAgV2lsbCBvbmx5IGNsaWVudCBzaWduYWxzIDw9IDEwMEcgbmVlZCB0byBiZSB3cmFwcGVk IGluIGFuIE9QVWsvT0RVayBiZWZvcmUgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVD bi9PRFVDbj8g4oaSIHRoaXMgd291bGQgbWVhbiB0aGF0IHRoZXJlIHdpbGwgYmUgYSBicmVhayBp biB0aGUgbWFwcGluZ3MgYXQgYWJvdXQgMTAwRyBzaWduYWxzIGFuZCBubyBPRFU1LDYsNyB3b3Vs ZCBuZWVkIHRvIGJlIGRlZmluZWQNCmMuICAgICAgIFdpbGwgZnV0dXJlIGNsaWVudHMgYmUgbWFw cGVkIGRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24gYW5kIHRoZSBzcGVjaWFsIGNhc2Ugb2YgMTAw R0XihpJPUFVrL09EVWvihpJPUFVDbi9PRFVDbiB3aWxsIGJlY29tZSBqdXN0IGFub3RoZXIgb3B0 aW9uPyAoTm90ZTogdGhlIGZpZ3VyZSBleHBsaWNpdGx5IGFsbG93cyBmb3IgcHJvcHJpZXRhcnkg bWFwcGluZ3MgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBsaWtlIGEgcHJh Y3RpY2FsIHVzZSBjYXNlLCBidXQgaXQgbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlucyBwcm9yaWV0 YXJ5KQ0KMy4gICAgICAgVGhlIHNlY3Rpb24g4oCcNy4xIE1hcHBpbmfigJ0gYW5kIOKAnDcuMiBX YXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleOKAnSBjaGFuZ2VkIGEgYml0IGZyb20gdGhlIDIw MTIgdmVyc2lvbi4gQXMgYWNyb255bXMgaGF2ZSBjaGFuZ2VkIHRvbywgYSAxOjEgY29tcGFyaXNv biBpcyBub3QgdG9vIHNpbXBsZS4gVGhlIHRha2Vhd2F5IGlzIHRoYXQgYW4gT1RVIGNhbiBiZSBt YXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoIG9yIHNwcmVhZCBhY3Jvc3Mgc29tZSAoT1RM ay5uIGFuZCBPVExDLm4pIHdoaWNoIG1lYW5zIGludmVyc2UgbXVsdGlwbGV4aW5nLiBTbyBmYXIg dGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2My4N CjQuICAgICAgIEluIFNlY3Rpb24g4oCcNi4xLjEgT1ROIGRpZ2l0YWwgc3RydWN0dXJl4oCdIGl0 IGlzIGV4cGxhaW5lZCB0aGF0IGFuIE9UVWsgY29udGFpbnMgYSBGRUMsIGJ1dCBPVFVDbiBkb2Vz IG5vdCwgbGVhdmluZyBpdCB0byB0aGUgaW50ZXJmYWNlIHRvIGFwcGx5IHNvbWUuIFRoaXMgYmFz aWNhbGx5IGNyZWF0ZXMgYSBGRUMgbGF5ZXIgYmVsb3cgdGhlIE9UVUNuIHRoYXQgd2lsbCBub3Qg YmUgZGVmaW5lZCBpbiBHLjcwOS4gQSBjb250cm9sIHBsYW5lIHdvdWxkIG5lZWQgdG8gY2hlY2sg Y29tcGF0aWJpbGl0eSBvZiB3YXZlbGVuZ3RoLCBtb2R1bGF0aW9uLCBpbnRlcmZhY2VzIChpLmUu IGhvdyBtYW55IGxhbmVzKSBhbmQgY29tcGF0aWJpbGl0eSBvZiBGRUMsIGFzIHdlbGwgYXMgdXNh Z2Ugb2YgT1RVayB2cyBPVFVDbi4gQWxzbyB0aGlzIGNhc2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVy ZWQgaW4gUkZDNzEzOSBvciBSRkM2MTYzLg0KNS4gICAgICAgVGhlcmUgaXMgYWxzbyBhIG5ldyBP TVMgTVNJIChzZWN0IDE1LjQpIG92ZXJoZWFkIGRlZmluZWQsIHdoaWNoIHByb3ZpZGVzIGEgbGlz dCBvZiBPQ2ggYW5kIE9UU2lBIGZyZXF1ZW5jeSBzbG90LHBvcnQgbnVtYmVycyBhbmQgYSBsaXN0 IG9mIG1lZGlhIGNoYW5uZWxzIChmcmVxdWVuY3kgc2xvdCwgbWVkaWEgY2hhbm5lbCBwb3J0IG51 bWJlcnMpIHRvIGRlY29kZSB0aGUgbGFuZXMgY29ycmVjdGx5LiBUaGlzIG1heSBhZmZlY3QgUkZD NjE2Mw0KNi4gICAgICAgVGhlIHRlcm0g4oCcV2F2ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXji gJ0gaW4gdGhlIHNlY3Rpb25zIGFib3ZlIGRvZXNu4oCZdCBpbXBseSBhIHdhdmVsZW5ndGggY2Fu IGJlIHJvdXRlZCB0aHJvdWdoIGEgRFdETSBuZXR3b3JrIHNpbmNlIHdlIGtub3cgdGhhdCBlLmcu IDEwMEcgaW50ZXJmYWNlcyBhcmUgbm90IHlldCBkZWZpbmVkIGJ5IFNHMTUgZm9yIGFtcGxpZmll ZCBEV0RNIGFwcGxpY2F0aW9ucy4gV2l0aG91dCBhbXBsaWZpZXJzLCB0aGUgZGlzdGFuY2Ugc3Vw cG9ydGVkIGJ5IHN1Y2ggRFdETSBpcyBsaWtlbHkgbGltaXRlZCB0byBiZWxvdyA4MC0xMDBrbS4g SXQgaXMgbm90IHlldCBjbGVhciBieSB3aGVuIHRoaXMgbGltaXRhdGlvbiB3aWxsIGJlIGxpZnRl ZCBieSBTRzE1IChzZWUgZHJhZnQtbWFueS1jb2hlcmVudC1kd2RtLWlmLWNvbnRyb2wtMDApLiBB ZnRlciBhbGwsIE9UVTQgYmFzZWQgMTAwRyBpbnRlcmZhY2VzIGZvciBhbXBsaWZpZWQgRFdETSBh cHBsaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhbmQgaGF2ZSBldmVuIGJlZW4gcHJvdmVuIHRvIGJl IGludGVyb3BlcmFibGUgYW1vbmcgbXVsdGlwbGUgdmVuZG9ycyBjb3ZlcmluZyBkaXN0YW5jZXMg PjEwMDBrbS4gIEhvd2V2ZXIsIHRvIHN0YXkgaW4gdGhlIHN0YW5kYXJkcyBmcmFtZXdvcmsgZm9y IG5vdywgUkZDNjE2MyB3b3VsZCBuZWVkIHRvIGNvbnNpZGVyOg0KYS4gICAgICAgV2hpbGUgYSBP VFVDbiBjYW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQgaW50byBhIHNpbmds ZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QgYmUgcm91dGVkIGluIFdTT04g4oaSIG5vIDEwMEcgaW50 ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjINCmIu ICAgICAgIEFuIE9UVUNuIG1heSBiZSBicm9rZW4gZG93biBpbnRvIDQgbGFuZXMgYXQgMjVHIChP VEw0LjQpIGJ1dCBzdGlsbCBjYW7igJl0IGJlIHJvdXRlZCBpbiBXU09OIOKGkiBubyAyNUcgaW50 ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjINCmMu ICAgICAgIEFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93biBpbiBPVEwzLjQgcHJvdmlk aW5nIDQgbGFuZXMgYXQgMTBHIGVhY2gg4oaSIDEwRyBpbnRlcmZhY2VzIGFyZSBhbGxvd2VkIGlu IGFtcGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KDQoNCg0KDQoNCg0K RnJvbTogQ0NBTVAgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2Nh cmVsbGlAZXJpY3Nzb24uY29tPjxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bT4NCkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDIwOjAyDQpUbzogImh1dWJhdHdv cmtAZ21haWwuY29tIjxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+IDxodXViYXR3b3JrQGdt YWlsLmNvbT48bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiwgQ0NBTVAgPGNjYW1wQGlldGYu b3JnPjxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFu ZCBPRFVDbiBkaXNjdXNzaW9uDQoNClRoYW5rIEh1dWIsDQoNCkF1dGhvcnMsIGlmIHlvdSBjb3Vs ZCBoYXZlIGEgbGl0dGxlIHBpZWNlIG9mIHRleHQgZGVzY3JpYmluZyB0aGlzIGNvbnNpZGVyYXRp b24gaW4gdGhlIGZyYW1ld29yayBvciBpbiBvbmUgb2YgdGhlIHNvbHV0aW9uIGRvY3VtZW50cyAo ZGVwZW5kaW5nIHdoYXQgYXJlIHRoZSBwbGFucyBmb3IgdGhlIG1lcmdlKSB0aGF0IHdvdWxkIGJl IGdyZWF0Lg0KDQpUaGFua3MNCkRhbmllbGUNCg0KRnJvbTogSHV1YiB2YW4gSGVsdm9vcnQgW21h aWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NClNlbnQ6IHZlbmVyZMOsIDE4IG5vdmVtYnJlIDIw MTYgMTk6MzENClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmlj c3Nvbi5jb20+PG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjsgY2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RV NCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpEYW5pZWxlLA0KDQpZb3Ugd3JpdGU6DQpUaGFua3Mg Zm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLg0KDQpZb3UncmUgd2VsY29tZS4NCg0KDQoN Ckkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aCBtYWtlIHNlbnNlLg0KDQpJ IGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS4NCg0KDQoNClRoZSBvbmUgcHJvcG9zZWQgYnkgR2Vy dCBpcyBzdGl0Y2hpbmcgb2YgYW4gT0RVNCBhbmQgT0RVQzEsDQoNClRoaXMgdXNlIGNhc2UgaXMg aW1wb3NzaWJsZS4gQXMgeW91IGNhbiBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTENCmEg bG93ZXIgb3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFVDMSwgYW5k IHRoaXMNCm1lYW5zIHRoYXQgdGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXllcnMgaW4gdGhl IE9UTi4NCkFuZCBhcmUgaW1wb3NzaWJsZSB0byBzdGl0Y2guDQoNCg0KDQp3aGlsZSB0aGUgb25l IHlvdSBhcmUgZGVzY3JpYmluZyBpcyB0dW5uZWxpbmcgb2YgT0RVNCBvdmVyIGFuIE9EVUMxIHRy YWlsLg0KDQpDb3JyZWN0Lg0KDQoNCg0KVGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUs IHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT8NCg0KSSB0cmllZCB0byBleHBsYWlu IGFib3ZlLg0KDQpCZXN0IHJlZ2FyZHMsIEh1dWIuDQoNCg0KDQoNCkZyb206IENDQU1QIFttYWls dG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1dWIgdmFuIEhlbHZvb3J0 DQpTZW50OiBnaW92ZWTDrCAxNyBub3ZlbWJyZSAyMDE2IDE3OjA2DQpUbzogY2NhbXBAaWV0Zi5v cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQg T0RVQ24gZGlzY3Vzc2lvbg0KDQpIZWxsbyBHZXJ0LA0KDQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBj b21wbGV0ZWx5IGNvcnJlY3QuDQoNCkluc3RlYWQgb2Y6DQoxLiAgICAgIEEgdXNlIGNhc2UgdG8g Y29uc2lkZXIgaXM6DQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9EVTQt fC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdN UC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgTkUxICAgICAg ICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5FMw0KDQpJ dCBzaG91bGQgYmU6DQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjEwMEdFLS18LUdN UC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1P RFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ctTkUpICAgICAg ICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5FMyB0dW5uZWxz IHRoZSBPRFU0Lg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0KDQoNCi0tDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpBbHdh eXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNl Li4uX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1Q IG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDQ0FNUCBtYWlsaW5n IGxpc3QNCg0KQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0K --_000_F52DEAEE2EB2447E9E366AA8E179916Ajunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <34A8B82F3F2BB741A60819BE48C87B09@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpzYW5zLXNlcmlm Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTppbmhlcml0Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiVGltZXNcMDAwQSAgICAgICAgTmV3IFJvbWFuIjsNCglwYW5vc2Ut MTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KdHQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh bi5ncmV5DQoJe21zby1zdHlsZS1uYW1lOmdyZXk7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpIERpZXRlciwgUWlsZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5kb27igJl0IGZv cmdldCB0byBhZGQgdGhlIE9UVUNuIHNpZ25hbCB0eXBlcyAoT1RVNCB3YXMgaW5jbHVkZWQgaW4N CjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTM5Ij5SRkMgNzEzOTwv YT4pIGFuZCBhZGRpdGlvbmFsIG1hcHBpbmdzIGludG8gT0RVQ24vT1RVQ24gYW5kIGNvbnNpZGVy IGhvdyB0byBzaWduYWwgdGhlIEZFQyB3aGljaCBpcyBub3cgZm91bmQgb3V0c2lkZSBPVFVDbiDi gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgaW1wb3J0YW50IHBhcnQgaXMgdGhhdCB0aGUg c3VidGxlIGRpZmZlcmVuY2VzIGFyZSB3ZWxsIHVuZGVyc3Rvb2QgYW5kIHRha2VuIGNhcmUgb2Yu IE5hcnJvd2luZyBkb3duIHRoZSBkaXNjdXNzaW9uIGludG8g4oCcaG93IHRvIHNpZ25hbCBPRFVD buKAnSBhcHBlYXJzIHRvIG1lDQogYXMgb3Zlci1zaW1wbGlmaWNhdGlvbi4gQ2FzZSBpbiBwb2lu dCwgUWlsZWkgbWVudGlvbmVkIFJGQzc2OTggd2hpY2ggaXMgYSBmcmFtZXdvcmsgdGhhdCBiZWNh bWUgbmVjZXNzYXJ5IGJlY2F1c2Ugb2YgZmxleGdyaWQgYW5kIG11bHRpLWxhbmUgaW50ZXJmYWNl cy4gSSBmaW5kIFJGQzc2OTggcXVpdGUgYmVuZWZpY2lhbCBhbmQgZmVlbCBhIHNpbWlsYXIgZnJh bWV3b3JrIGRvY3VtZW50IHdvdWxkIGJlIG5lZWRlZCBvbiB0aGUgZGlnaXRhbCBwYXJ0DQogb25j ZSBmbGV4aWJsZSBzaXplZCBPVFVDbiBhbmQgT0RVQ24gYXJlIGludHJvZHVjZWQsIHdoaWxlIHN3 YXBwaW5nIEZFQyBvdXQgb2YgdGhlIE9UVSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPklmIHlvdSB0aGluayB5b3UgY2FuIGNvdmVyIGV2ZXJ5dGhpbmcgaW4gZXh0ZW5kaW5nIG5v bi1mcmFtZXdvcmsgZG9jdW1lbnRzLCBmZWVsIGZyZWUgdG8gZ28gYWhlYWQuIFdlIHdpbGwgc2Vl IG92ZXIgdGltZSB3aGV0aGVyIGxhY2tpbmcgdGhlIGZyYW1ld29yayB3aWxsIGJ1cmRlbg0KIHRo ZSBwcm9ncmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5HZXJ0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj ayI+RGlldGVyIEJlbGxlciAmbHQ7RGlldGVyLkJlbGxlckBub2tpYS5jb20mZ3Q7PGJyPg0KPGI+ T3JnYW5pemF0aW9uOiA8L2I+Tm9raWE8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5IDIzIE5v dmVtYmVyIDIwMTYgYXQgMTc6NTA8YnI+DQo8Yj5UbzogPC9iPiZxdW90O3dhbmcucWlsZWlAenRl LmNvbS5jbiZxdW90OyAmbHQ7d2FuZy5xaWxlaUB6dGUuY29tLmNuJmd0OywgR2VydCBHcmFtbWVs ICZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5DYzogPC9iPkNDQU1QICZsdDtj Y2FtcEBpZXRmLm9yZyZndDssICZxdW90O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7ICZsdDto dXViYXR3b3JrQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtDQ0FNUF0g T0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIGFs bCw8YnI+DQo8YnI+DQpJIHdvdWxkIHN1Ym1pdCB0aGF0IHdlIG5lZWQgYSBkb2N1bWVudCBzaW1p bGFyIHRvIDxzcGFuIGNsYXNzPSJncmV5Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzEzOSI+UkZDIDcxMzk8L2E+IChHTVBMUyBTaWduYWxpbmcgRXh0ZW5zaW9ucyBm b3IgQ29udHJvbCBvZiBFdm9sdmluZyBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydDwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iZ3JleSI+TmV0d29ya3MpIGZvciB0aGUgbmV3IE9EVUNuIHNpZ25hbCB0 eXBlcy4gPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJncmV5Ij48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzEzOSI+UkZDIDcxMzk8L2E+PC9zcGFuPiBjb250 YWlucyBzdWZmaWNpZW50IGluZm9ybWF0aW9uIGFuZCBkZXNjcmlwdGlvbnMgcmVnYXFyZGluZyB0 aGUgbmV3IEcuNzA5IHNpZ25hbCB0eXBlcyBpbnRyb2R1Y2VkIGluIHRoZSBGZWIgMjAxMiByZXZp c2lvbiBvZiBHLjcwOS4NCjxicj4NCjxicj4NCkkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB0YWtl IGEgZGlmZmVyZW50IGFwcHJvYWNoIGZvciB0aGUgbGF0ZXN0IDIwMTYgZXZvbHV0aW9uIG9mIEcu NzA5Ljxicj4NCjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpEaWV0ZXI8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMy4xMS4yMDE2IDE2OjM4LCA8YSBocmVm PSJtYWlsdG86d2FuZy5xaWxlaUB6dGUuY29tLmNuIj4NCndhbmcucWlsZWlAenRlLmNvbS5jbjwv YT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5I aSBHZXJ0LDwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRo YW5rcyBmb3IgeW91ciBjb21tZW50cy4gRm9sbG93aW5nIGlzIG15IGFuc3dlciB0byB5b3VyIHBy ZXZpb3VzIG1haWwgYW5kIHRoaXMgb25lLjwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPigxKSwgQWJvdXQgdGhlIHF1ZXN0aW9ucyBpbiB5b3VyIHByZXZpb3Vz IG1haWwuIEkgdGhpbmsgeW91IGFscmVhZHkgaGF2ZSBtYW55IG9mIHRoZW0gc29sdmVkLiBPRFVD biBoYXMgYWxtb3N0IHRoZSBzYW1lIG92ZXJoZWFkIGFzIHRoYXQgb2YgT0RVaywgc28gSSBkb24n dCB0aGluayBzb21lIG1lY2hhbmlzbXMgb2YgT0RVQ24gKGUuZy4sDQogT0FNIGV0YykgZGlmZmVy IGZyb20gdGhvc2Ugb2YgT0RVay4gSW4gdGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNob3Vs ZCBtYWlubHkgcGF5IGF0dGVudGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZmZXJl bmNlIHdpdGggT0RVayBub3csIHN1Y2ggYXMgbGF5ZXIgbW9kZWwgb2YgT0RVQ24gYW5kIHNldHVw IG9mIE9EVUNuIGNvbm5lY3Rpb24uPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+KDIpLCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHRoZSBzZWNvbmQgaXRlbXMg b2YgdGhpcyB0aHJlYWQuIEkgdGhpbmsgaXQncyBvdXQgb2YgdGhlIHNjb3BlIG9mIENDQU1QLiBJ IGNhbid0IGdpdmUgYSBkZWZpbml0ZSBhbnN3ZXIgdG8gdGhlc2UgcXVlc3Rpb25zLg0KPC9zcGFu Pjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPigzKSwgQ29udHJvbCBvZiBv cHRpY2FsIG5ldHdvcmsgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBjdXJyZW50IE9EVUNuIGRvY3Vt ZW50LiBXZSB3aWxsIG5vdCBpbnZvbHZlIHRoaXMgcGFydCBpbi4gQWxzbyBJIHN1Z2dlc3QgeW91 IHRha2UgYSBsb29rIGF0IFJGQzc2OTgsIHdoaWNoIG1haW5seSBmb2N1cyBvbiB0aGUgY29udHJv bCBvZg0KIGZsZXhpYmxlIGdyaWQgbmV0d29yay48L3NwYW4+IDxicj4NCjxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPlRoYW5rczwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+UWlsZWk8YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lk dGg9IjM2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDozNi4wJTtwYWRkaW5nOi43NXB0IC43 NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+R2VydCBHcmFtbWVsDQo8YSBocmVmPSJtYWlsdG86Z2dyYW1tZWxAanVuaXBl ci5uZXQiPiZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8L2E+PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij46ICZuYnNwOyZxdW90O0NDQU1QJnF1b3Q7DQo8YSBocmVmPSJtYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZyI+Jmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9hPjwv c3Bhbj4gPG86cD4NCjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MjAx Ni8xMS8yMyAyMTowMTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i NjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjYzLjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5 Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVw dCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0 LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01TIE1pbmNobyZxdW90OyI+5pS25Lu25Lq6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5EYW5p ZWxlIENlY2NhcmVsbGkNCjxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tIj4mbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZndDs8L2E+LA0KPGEg aHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj4mcXVvdDtjY2FtcEBpZXRmLm9yZyZxdW90Ozwv YT4gPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj4NCiZsdDtjY2FtcEBpZXRmLm9yZyZn dDs8L2E+LCA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8m cXVvdDsiPuaKhOmAgTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmh1dWJh dHdvcmtAZ21haWwuY29tIj4mcXVvdDtodXViYXR3b3JrQGdtYWlsLmNvbSZxdW90OzwvYT4NCjxh IGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbSI+Jmx0O2h1dWJhdHdvcmtAZ21haWwu Y29tJmd0OzwvYT48L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWlu Y2hvJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTpTaW1TdW4iPumimDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UmU6IFtDQ0FNUF0gT0RVNCBh bmQgT0RVQ24gZGlzY3Vzc2lvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+RGFuaWVsZSwgQXV0aG9ycyw8L3NwYW4+IDxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4g PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ QWZ0ZXIgb3VyIGluaXRpYWwgZW1haWwgZXhjaGFuZ2UgSSB0b29rIGEgbW9yZSBkZXRhaWxlZCBs b29rIGluIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkuIEluIGVzc2VuY2UsIHRoZSAyMDE2IHZl cnNpb24gb2YgRy43MDkgd291bGQgaW1wYWN0IGNvbnRyb2wgcGxhbmUgd29yayBmb3IgRy43MDkg KFJGQzcxMzkpIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYxNjMpLg0KIFRoZSBjb21wbGV4IG5h dHVyZSBvZiB0aG9zZSBkZWZpbml0aW9ucyB3aWxsIGNlcnRhaW5seSBub3QgYmUgYW4gZWFzeS1n b2luZyBleHRlbnNpb24gYXMgaXQgaGFkIGJlZW4gZW52aXNhZ2VkIHNvIGZhci4gV3JpdGluZyBh IOKAnGxpdHRsZSBwaWVjZSBvZiB0ZXh04oCdIGxvb2tzIHRvIG1lIGxpa2UgYSDigJxsaXR0bGUg Yml0IG9mIHVuZGVyc3RhdGVtZW504oCdLiBJZiB0aGUgV0cgaW50ZW5kcyB0byB3b3JrIG9uIHRo ZSBzdWJqZWN0LCBteSBwbGVkZ2Ugd291bGQNCiBiZSB0byBzdGFydCBmcm9tIGEgZnJhbWV3b3Jr IGRvY3VtZW50IHRvIGNhcHR1cmUgdGhlIG5ldyBjb25jZXB0cyBiZWZvcmUgZGVmaW5pbmcgcHJv dG9jb2wgZXh0ZW5zaW9ucy48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkJlc3Q8L3NwYW4+IDxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNw Ozwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+R2VydDwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkJlbG93IGEg bGlzdCBvZiBvYnNlcnZhdGlvbnMgdGhhdCBpbmZsdWVuY2VkIHRoaXMgdmlldzo8L3NwYW4+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4x LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPUFVDbiwgT0RVQ24gYW5kIE9UVUNuIGFyZSBuZXcgYW5k IHRoZSBsYXllcmluZyByZWxhdGlvbnNoaXAgdG8gdGhlIGZvcm1lciBzdHJ1Y3R1cmUgaXMgYSBi aXQgc3VycHJpc2luZywgYXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgKHNlZSBiZWxvdykg c2hvd2VkLiBCZXR0ZXIgdG8gZ2V0IHRoaXMgcmlnaHQgZWFybHkgb248L3NwYW4+DQo8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4yLiAmbmJz cDsgJm5ic3A7ICZuYnNwOyBGaWd1cmUgNy0xIHNob3dzIHRoZSBPVE4gbXVsdGlwbGV4aW5nIGFu ZCBtYXBwaW5nIHN0cnVjdHVyZXMgYnV0IGRvZXMgbm90IGluZGljYXRlIGhvdyBlLmcuIGEgNDAw R0Ugd291bGQgYmUgbWFwcGVkIGludG8gdGhpcyBzdHJ1Y3R1cmUuIEl0IGlzIG5vdCBzdXJwcmlz aW5nIGFzIDQwMEdFIGlzIHN0aWxsIGluIHRoZSBtYWtpbmdzLCBidXQgcmFpc2VzDQogYSBmZXcg cXVlc3Rpb25zIGFib3V0IGhvdyBpdCBpcyBwbGFubmVkIHRvIGJlIG1hcHBlZC4gSG93ZXZlciBn dWlkYW5jZSBmcm9tIFNHMTUgd291bGQgaGVscCB0byBnZXQgdGhlIHByb3RvY29sIGFyY2hpdGVj dHVyZSBmdXR1cmUgcHJvb2YuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+YS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgRG9lcyBl dmVyeSBjbGllbnQgc2lnbmFsIG5lZWQgdG8gYmUgd3JhcHBlZCBpbnRvIGFuIE9QVWsvT0RVayBi ZWZvcmUgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8NCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtpbmhlcml0JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7ihpI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IHRoaXMgd291bGQgbWVhbiB0byBleHRlbmQgdGhl IE9EVSBzdHJ1Y3R1cmUgYnkgYW4gT0RVNSw2LDcgZXRjLiBmb3IgY2xpZW50cyAmZ3Q7IDEwMEc8 L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5iLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaWxsIG9ubHkgY2xpZW50IHNpZ25hbHMg Jmx0Oz0gMTAwRyBuZWVkIHRvIGJlIHdyYXBwZWQgaW4gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBj YW4gYmUgdHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2luaGVyaXQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPuKGkjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4gdGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhlcmUgd2lsbCBiZSBhIGJy ZWFrIGluIHRoZSBtYXBwaW5ncyBhdCBhYm91dCAxMDBHIHNpZ25hbHMgYW5kIG5vIE9EVTUsNiw3 IHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmMuICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFdpbGwgZnV0dXJlIGNsaWVudHMgYmUgbWFwcGVkIGRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24g YW5kIHRoZSBzcGVjaWFsIGNhc2Ugb2YgMTAwR0U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7aW5oZXJpdCZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+4oaSPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPk9QVWsvT0RVazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtpbmhlcml0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7ihpI8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+T1BVQ24v T0RVQ24NCiB3aWxsIGJlY29tZSBqdXN0IGFub3RoZXIgb3B0aW9uPyAoTm90ZTogdGhlIGZpZ3Vy ZSBleHBsaWNpdGx5IGFsbG93cyBmb3IgcHJvcHJpZXRhcnkgbWFwcGluZ3MgZGlyZWN0bHkgaW50 byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBsaWtlIGEgcHJhY3RpY2FsIHVzZSBjYXNlLCBidXQg aXQgbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlucyBwcm9yaWV0YXJ5KTwvc3Bhbj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjMuICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRoZSBzZWN0aW9uIOKAnDcuMSBNYXBwaW5n4oCdIGFuZCDigJw3LjIg V2F2ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXjigJ0gY2hhbmdlZCBhIGJpdCBmcm9tIHRoZSAy MDEyIHZlcnNpb24uIEFzIGFjcm9ueW1zIGhhdmUgY2hhbmdlZCB0b28sIGEgMToxIGNvbXBhcmlz b24gaXMgbm90IHRvbyBzaW1wbGUuIFRoZSB0YWtlYXdheSBpcyB0aGF0IGFuIE9UVQ0KIGNhbiBi ZSBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoIG9yIHNwcmVhZCBhY3Jvc3Mgc29tZSAo T1RMay5uIGFuZCBPVExDLm4pIHdoaWNoIG1lYW5zIGludmVyc2UgbXVsdGlwbGV4aW5nLiBTbyBm YXIgdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2 My48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj40LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbiBTZWN0aW9uIOKAnDYuMS4xIE9U TiBkaWdpdGFsIHN0cnVjdHVyZeKAnSBpdCBpcyBleHBsYWluZWQgdGhhdCBhbiBPVFVrIGNvbnRh aW5zIGEgRkVDLCBidXQgT1RVQ24gZG9lcyBub3QsIGxlYXZpbmcgaXQgdG8gdGhlIGludGVyZmFj ZSB0byBhcHBseSBzb21lLiBUaGlzIGJhc2ljYWxseSBjcmVhdGVzIGEgRkVDIGxheWVyIGJlbG93 IHRoZSBPVFVDbg0KIHRoYXQgd2lsbCBub3QgYmUgZGVmaW5lZCBpbiBHLjcwOS4gQSBjb250cm9s IHBsYW5lIHdvdWxkIG5lZWQgdG8gY2hlY2sgY29tcGF0aWJpbGl0eSBvZiB3YXZlbGVuZ3RoLCBt b2R1bGF0aW9uLCBpbnRlcmZhY2VzIChpLmUuIGhvdyBtYW55IGxhbmVzKSBhbmQgY29tcGF0aWJp bGl0eSBvZiBGRUMsIGFzIHdlbGwgYXMgdXNhZ2Ugb2YgT1RVayB2cyBPVFVDbi4gQWxzbyB0aGlz IGNhc2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOQ0KIG9yIFJGQzYxNjMuPC9z cGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj41LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSBpcyBhbHNvIGEgbmV3IE9NUyBNU0kg KHNlY3QgMTUuNCkgb3ZlcmhlYWQgZGVmaW5lZCwgd2hpY2ggcHJvdmlkZXMgYSBsaXN0IG9mIE9D aCBhbmQgT1RTaUEgZnJlcXVlbmN5IHNsb3QscG9ydCBudW1iZXJzIGFuZCBhIGxpc3Qgb2YgbWVk aWEgY2hhbm5lbHMgKGZyZXF1ZW5jeSBzbG90LCBtZWRpYSBjaGFubmVsIHBvcnQgbnVtYmVycykN CiB0byBkZWNvZGUgdGhlIGxhbmVzIGNvcnJlY3RseS4gVGhpcyBtYXkgYWZmZWN0IFJGQzYxNjM8 L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjYuICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSB0ZXJtIOKAnFdhdmVsZW5ndGggRGl2 aXNpb24gTXVsdGlwbGV44oCdIGluIHRoZSBzZWN0aW9ucyBhYm92ZSBkb2VzbuKAmXQgaW1wbHkg YSB3YXZlbGVuZ3RoIGNhbiBiZSByb3V0ZWQgdGhyb3VnaCBhIERXRE0gbmV0d29yayBzaW5jZSB3 ZSBrbm93IHRoYXQgZS5nLiAxMDBHIGludGVyZmFjZXMgYXJlIG5vdCB5ZXQgZGVmaW5lZCBieSBT RzE1IGZvcg0KIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucy4gV2l0aG91dCBhbXBsaWZpZXJz LCB0aGUgZGlzdGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2ggRFdETSBpcyBsaWtlbHkgbGltaXRlZCB0 byBiZWxvdyA4MC0xMDBrbS4gSXQgaXMgbm90IHlldCBjbGVhciBieSB3aGVuIHRoaXMgbGltaXRh dGlvbiB3aWxsIGJlIGxpZnRlZCBieSBTRzE1IChzZWUgZHJhZnQtbWFueS1jb2hlcmVudC1kd2Rt LWlmLWNvbnRyb2wtMDApLiBBZnRlciBhbGwsIE9UVTQgYmFzZWQNCiAxMDBHIGludGVyZmFjZXMg Zm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucyBhcmUgYXZhaWxhYmxlIGFuZCBoYXZlIGV2 ZW4gYmVlbiBwcm92ZW4gdG8gYmUgaW50ZXJvcGVyYWJsZSBhbW9uZyBtdWx0aXBsZSB2ZW5kb3Jz IGNvdmVyaW5nIGRpc3RhbmNlcyAmZ3Q7MTAwMGttLiAmbmJzcDtIb3dldmVyLCB0byBzdGF5IGlu IHRoZSBzdGFuZGFyZHMgZnJhbWV3b3JrIGZvciBub3csIFJGQzYxNjMgd291bGQgbmVlZCB0byBj b25zaWRlcjo8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5hLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGlsZSBhIE9UVUNuIGNh biBiZSBkaWdpdGFsbHkgY29uc3RydWN0ZWQgYW5kIG1hcHBlZCBpbnRvIGEgc2luZ2xlIHdhdmVs ZW5ndGgsIGl0IGNhbm5vdCBiZSByb3V0ZWQgaW4gV1NPTg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2luaGVyaXQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPuKGkjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4gbm8gMTAwRyBpbnRlcmZhY2VzIGluIGFtcGxpZmllZCBEV0RNIG5ldHdv cmtzIGRlZmluZWQgaW4gRy42OTguMjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFu IE9UVUNuIG1heSBiZSBicm9rZW4gZG93biBpbnRvIDQgbGFuZXMgYXQgMjVHIChPVEw0LjQpIGJ1 dCBzdGlsbCBjYW7igJl0IGJlIHJvdXRlZCBpbiBXU09ODQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7aW5oZXJpdCZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+4oaSPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPiBubyAyNUcgaW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3Jr cyBkZWZpbmVkIGluIEcuNjk4LjI8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5jLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbiBP VFUzICg9NDBHKSBjYW4gYmUgYnJva2VuIGRvd24gaW4gT1RMMy40IHByb3ZpZGluZyA0IGxhbmVz IGF0IDEwRyBlYWNoDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7aW5oZXJpdCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oaSPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiAxMEcgaW50 ZXJmYWNlcyBhcmUgYWxsb3dlZCBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGlu IEcuNjk4LjI8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFu PiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Q0NBTVANCjxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnIj4mbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9uIGJlaGFs ZiBvZiBEYW5pZWxlIENlY2NhcmVsbGkNCjxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tIj4mbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZndDs8 L2E+PGI+PGJyPg0KRGF0ZTogPC9iPkZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDIwOjAyPGI+ PGJyPg0KVG86IDwvYj48YSBocmVmPSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPiZxdW90 O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86aHV1YmF0d29y a0BnbWFpbC5jb20iPg0KJmx0O2h1dWJhdHdvcmtAZ21haWwuY29tJmd0OzwvYT4sIENDQU1QIDxh IGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Jmx0O2NjYW1wQGlldGYub3JnJmd0OzwvYT48 Yj48YnI+DQpTdWJqZWN0OiA8L2I+UmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lv bjwvc3Bhbj4gPGJyPg0KJm5ic3A7IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rIEh1dWIsPC9zcGFuPiA8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkF1 dGhvcnMsIGlmIHlvdSBjb3VsZCBoYXZlIGEgbGl0dGxlIHBpZWNlIG9mIHRleHQgZGVzY3JpYmlu ZyB0aGlzIGNvbnNpZGVyYXRpb24gaW4gdGhlIGZyYW1ld29yayBvciBpbiBvbmUgb2YgdGhlIHNv bHV0aW9uIGRvY3VtZW50cyAoZGVwZW5kaW5nIHdoYXQgYXJlIHRoZSBwbGFucyBmb3IgdGhlIG1l cmdlKSB0aGF0IHdvdWxkIGJlIGdyZWF0Ljwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzPC9z cGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5EYW5pZWxlICZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IEh1 dWIgdmFuIEhlbHZvb3J0IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmh1dWJhdHdvcmtAZ21haWwu Y29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5t YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPl0NCjxiPjxicj4NClNlbnQ6PC9iPiB2ZW5l cmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMxPGI+PGJyPg0KVG86PC9iPiBEYW5pZWxlIENlY2Nh cmVsbGkgPGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPiZs dDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzwvYT47DQo8YSBocmVmPSJtYWls dG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPjxiPjxicj4NClN1YmplY3Q6PC9i PiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPiA8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+RGFuaWVsZSw8YnI+DQo8YnI+DQpZb3Ugd3JpdGU6 PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5UaGFua3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLjwvc3Bhbj4NCjxi cj4NCjxicj4NCllvdSdyZSB3ZWxjb21lLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgc2VlIHR3byBkaWZm ZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aCBtYWtlIHNlbnNlLg0KPC9zcGFuPjxicj4NCjxicj4N CkkgaGF2ZSB0byBkaXNhZ3JlZSAoYWdhaW4pLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoZSBvbmUgcHJv cG9zZWQgYnkgR2VydCBpcyBzdGl0Y2hpbmcgb2YgYW4gT0RVNCBhbmQgT0RVQzEsPC9zcGFuPg0K PGJyPg0KPGJyPg0KVGhpcyB1c2UgY2FzZSBpcyBpbXBvc3NpYmxlLiBBcyB5b3UgY2FuIHNlZSBp biBHLjcwOSAoMjAxNikgZmlndXJlIDctMSA8YnI+DQphIGxvd2VyIG9yZGVyIE9EVTQgaXMgbWFw cGVkIGludG8gYSBoaWdoZXIgb3JkZXIgT0RVQzEsIGFuZCB0aGlzIDxicj4NCm1lYW5zIHRoYXQg dGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXllcnMgaW4gdGhlIE9UTi4gPGJyPg0KQW5kIGFy ZSBpbXBvc3NpYmxlIHRvIHN0aXRjaC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj53aGlsZSB0aGUgb25lIHlv dSBhcmUgZGVzY3JpYmluZyBpcyB0dW5uZWxpbmcgb2YgT0RVNCBvdmVyIGFuIE9EVUMxIHRyYWls Ljwvc3Bhbj4NCjxicj4NCjxicj4NCkNvcnJlY3QuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhleSBib3Ro IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJs ZT88L3NwYW4+DQo8YnI+DQo8YnI+DQpJIHRyaWVkIHRvIGV4cGxhaW4gYWJvdmUuPGJyPg0KPGJy Pg0KQmVzdCByZWdhcmRzLCBIdXViLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzCiAgICAgICAgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4N Cjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IENDQU1QIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6IzAwODJCRiI+bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHV1YiB2YW4gSGVsdm9vcnQ8Yj48YnI+DQpTZW50 OjwvYj4gZ2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzowNjxiPjxicj4NClRvOjwvYj4gPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMDA4MkJGIj5jY2FtcEBpZXRmLm9y Zzwvc3Bhbj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PGJyPg0KU3ViamVjdDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBk aXNjdXNzaW9uPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhl bGxvIEdlcnQsPGJyPg0KPGJyPg0KWW91ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3Jy ZWN0Ljxicj4NCjxicj4NCkluc3RlYWQgb2Y6PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSI+MS4gJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QSB1c2UgY2FzZSB0byBj b25zaWRlciBpczo8L3NwYW4+DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvYj4g PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0t LS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7 LS0tLS0tLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPg0KPGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVD MS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPg0KPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYj NDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0t LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7DQo8L3NwYW4+PC9iPjxicj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtORTEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9z cGFuPjwvYj4NCjxicj4NCjxicj4NCkl0IHNob3VsZCBiZTogPGJyPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0t LS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEw MEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0t T1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPg0KPGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0t LS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7DQo8L3NwYW4+PC9iPjxi cj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtORTEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg TkUzPC9zcGFuPjwvYj48YnI+DQo8YnI+DQpUaGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5l bHMgdGhlIE9EVTQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+UmVnYXJkcywgSHV1Yi4gPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDsgPGJyPg0KJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDsgPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tIDwvc3Bhbj48 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbHdheXMgcmVt ZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uPHR0 Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC90dD48YnI+ DQo8dHQ+Q0NBTVAgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+PGEgaHJlZj0ibWFpbHRvOkND QU1QQGlldGYub3JnIj5DQ0FNUEBpZXRmLm9yZzwvYT48L3R0Pjxicj4NCjwvc3Bhbj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wIj48dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXA8L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNDQU1QIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpDQ0FNUEBpZXRmLm9yZyI+Q0NBTVBAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_F52DEAEE2EB2447E9E366AA8E179916Ajunipernet_-- From nobody Wed Nov 23 11:00:53 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F5F12A37C for ; Wed, 23 Nov 2016 11:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 n1WPXkMoKnlc for ; Wed, 23 Nov 2016 11:00:48 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0099.outbound.protection.outlook.com [104.47.32.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7EF12A388 for ; Wed, 23 Nov 2016 11:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CL48t0j5Ko0xVxr/NpjKAl51/lJeww7i88UWryyvxPE=; b=Ioj09JL2j26zF9BCcB1KpwupaVUUOdCg9fPNTX8i7VSgFf22LIRMUepAHTY6KPW8krRBWIGpqPwiYocMcSUENkfRuuSWhzTY9xiEby/g0MtqAvdeWlOIRedHVTLlDrx1VeXn+71CGCzx7sZc0UDqipaKIoZ47/ke5wRB6uUVjz0= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Wed, 23 Nov 2016 19:00:41 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0747.010; Wed, 23 Nov 2016 19:00:41 +0000 From: Gert Grammel To: "wang.qilei@zte.com.cn" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgAGrtCCAAA8PAIAACKjwgAeHm4CAABtbAIAASR2A Date: Wed, 23 Nov 2016 19:00:41 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-ms-office365-filtering-correlation-id: 6ec4151f-e66b-452d-d483-08d413d3058b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1612; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 7:hz6zZ3epd0qPFDL+Pn/UIop/GU0A+MGuClhuFFYMxWMkQGfPijQZzWwvBsZAdPIDxUYm+VZPmKi+Y+Uno1dmlYgCcSBILlaA6H71OLfRY8pIA1OAayNRgzAXi4h1PMDSCKVf3V6BNDsRUCUueuvrNJksvT8ZcyTH4T5Ag1oVFLTtOFjc+RPXbF67L+OzThHP+auO9k3hfVzSG4RflWRGxhHtkb1xUuEHsnCOpRJ4CW9/56pmulmRdXbbfFQC9eFTF0OyGAw/IktPL1ZjFNARGg4Fmng2fDYgwDTETwx+xRFNrSu2ImGwOvPaGchQBjgfJztqJtd9XXYwgqTGIkDHlIdWdd5Q5VP68EYCXuO4K/TN4zt7IHhslJXv96ktEJcopDl6LozE/JbXVRpXDDanXeJ2tT7kt5cO0xDRHAjzpwJ6GXXwG31BBmqvzVBN95/dprR0GV6tZImzACeKtBqSZA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041248)(6042181); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(51914003)(199003)(66066001)(3846002)(6506003)(101416001)(3660700001)(36756003)(3280700002)(33656002)(6116002)(606004)(102836003)(105586002)(50986999)(76176999)(106356001)(54356999)(106116001)(99286002)(2351001)(7846002)(77096005)(92566002)(82746002)(2900100001)(83506001)(2906002)(2501003)(7906003)(2950100002)(8676002)(122556002)(189998001)(110136003)(229853002)(38730400001)(39060400001)(6916009)(97736004)(5660300001)(93886004)(6512003)(83716003)(4001350100001)(81166006)(86362001)(4326007)(8936002)(68736007)(81156014)(7736002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B50A706B1C8045E18FBB0FFA857BDD9Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2016 19:00:41.6548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612 Archived-At: Cc: "ccamp@ietf.org" , "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 19:00:52 -0000 --_000_B50A706B1C8045E18FBB0FFA857BDD9Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UWlsZWksDQoNCk15IGxhc3QgZW1haWwgY29udGFpbmVkIGEgZmV3IG9ic2VydmF0aW9ucyB0aGF0 IHdlcmUgaW50ZW5kZWQgdG8gYWxsb3cgZmVsbG93IGNjYW1wLWVycyB0byBmb2xsb3cgd2hhdCB0 aGUgZGlzY3Vzc2lvbiBpcyBhYm91dC4gSSBkaWQgbm90IGV4cGVjdCBmZWVkYmFjayBvbiB0aG9z ZSBidXQgcmF0aGVyIGlmIGZvbGtzIGZlZWwgYSBmcmFtZXdvcmsgaXMgdGhlIHJpZ2h0IHRoaW5n IHRvIGRvIG9yIG5vdC4gWW91ciBvcGluaW9uIGFib3V0IHRoaXMgc3ViamVjdCBpcyB3ZWxjb21l ZA0KDQpHZXJ0DQoNCkZyb206ICJ3YW5nLnFpbGVpQHp0ZS5jb20uY24iIDx3YW5nLnFpbGVpQHp0 ZS5jb20uY24+DQpEYXRlOiBXZWRuZXNkYXkgMjMgTm92ZW1iZXIgMjAxNiBhdCAxNjozOA0KVG86 IEdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+DQpDYzogQ0NBTVAgPGNjYW1wQGll dGYub3JnPiwgRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24u Y29tPiwgImh1dWJhdHdvcmtAZ21haWwuY29tIiA8aHV1YmF0d29ya0BnbWFpbC5jb20+DQpTdWJq ZWN0OiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNCkhpIEdlcnQsDQoN ClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gRm9sbG93aW5nIGlzIG15IGFuc3dlciB0byB5b3Vy IHByZXZpb3VzIG1haWwgYW5kIHRoaXMgb25lLg0KDQooMSksIEFib3V0IHRoZSBxdWVzdGlvbnMg aW4geW91ciBwcmV2aW91cyBtYWlsLiBJIHRoaW5rIHlvdSBhbHJlYWR5IGhhdmUgbWFueSBvZiB0 aGVtIHNvbHZlZC4gT0RVQ24gaGFzIGFsbW9zdCB0aGUgc2FtZSBvdmVyaGVhZCBhcyB0aGF0IG9m IE9EVWssIHNvIEkgZG9uJ3QgdGhpbmsgc29tZSBtZWNoYW5pc21zIG9mIE9EVUNuIChlLmcuLCBP QU0gZXRjKSBkaWZmZXIgZnJvbSB0aG9zZSBvZiBPRFVrLiBJbiB0aGUgT0RVQ24gZHJhZnQsIEkg dGhpbmsgd2Ugc2hvdWxkIG1haW5seSBwYXkgYXR0ZW50aW9uIHRvIE9EVUNuJ3MgZmVhdHVyZSBh bmQgaXRzIGRpZmZlcmVuY2Ugd2l0aCBPRFVrIG5vdywgc3VjaCBhcyBsYXllciBtb2RlbCBvZiBP RFVDbiBhbmQgc2V0dXAgb2YgT0RVQ24gY29ubmVjdGlvbi4NCg0KKDIpLCBBYm91dCB0aGUgcXVl c3Rpb25zIGluIHRoZSBzZWNvbmQgaXRlbXMgb2YgdGhpcyB0aHJlYWQuIEkgdGhpbmsgaXQncyBv dXQgb2YgdGhlIHNjb3BlIG9mIENDQU1QLiBJIGNhbid0IGdpdmUgYSBkZWZpbml0ZSBhbnN3ZXIg dG8gdGhlc2UgcXVlc3Rpb25zLg0KDQooMyksIENvbnRyb2wgb2Ygb3B0aWNhbCBuZXR3b3JrIGlz IG91dCBvZiB0aGUgc2NvcGUgb2YgY3VycmVudCBPRFVDbiBkb2N1bWVudC4gV2Ugd2lsbCBub3Qg aW52b2x2ZSB0aGlzIHBhcnQgaW4uIEFsc28gSSBzdWdnZXN0IHlvdSB0YWtlIGEgbG9vayBhdCBS RkM3Njk4LCB3aGljaCBtYWlubHkgZm9jdXMgb24gdGhlIGNvbnRyb2wgb2YgZmxleGlibGUgZ3Jp ZCBuZXR3b3JrLg0KDQpUaGFua3MNClFpbGVpDQoNCg0KR2VydCBHcmFtbWVsIDxnZ3JhbW1lbEBq dW5pcGVyLm5ldD4NCuWPkeS7tuS6ujogICJDQ0FNUCIgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+ DQoNCjIwMTYvMTEvMjMgMjE6MDENCg0K5pS25Lu25Lq6DQoNCkRhbmllbGUgQ2VjY2FyZWxsaSA8 ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4sICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1w QGlldGYub3JnPiwNCg0K5oqE6YCBDQoNCiJodXViYXR3b3JrQGdtYWlsLmNvbSIgPGh1dWJhdHdv cmtAZ21haWwuY29tPg0KDQrkuLvpopgNCg0KUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlz Y3Vzc2lvbg0KDQoNCg0KDQoNCg0KDQpEYW5pZWxlLCBBdXRob3JzLA0KDQpBZnRlciBvdXIgaW5p dGlhbCBlbWFpbCBleGNoYW5nZSBJIHRvb2sgYSBtb3JlIGRldGFpbGVkIGxvb2sgaW4gdGhlIDIw MTYgdmVyc2lvbiBvZiBHLjcwOS4gSW4gZXNzZW5jZSwgdGhlIDIwMTYgdmVyc2lvbiBvZiBHLjcw OSB3b3VsZCBpbXBhY3QgY29udHJvbCBwbGFuZSB3b3JrIGZvciBHLjcwOSAoUkZDNzEzOSkgYXMg d2VsbCBhcyBmb3IgV1NPTiAoUkZDNjE2MykuIFRoZSBjb21wbGV4IG5hdHVyZSBvZiB0aG9zZSBk ZWZpbml0aW9ucyB3aWxsIGNlcnRhaW5seSBub3QgYmUgYW4gZWFzeS1nb2luZyBleHRlbnNpb24g YXMgaXQgaGFkIGJlZW4gZW52aXNhZ2VkIHNvIGZhci4gV3JpdGluZyBhIOKAnGxpdHRsZSBwaWVj ZSBvZiB0ZXh04oCdIGxvb2tzIHRvIG1lIGxpa2UgYSDigJxsaXR0bGUgYml0IG9mIHVuZGVyc3Rh dGVtZW504oCdLiBJZiB0aGUgV0cgaW50ZW5kcyB0byB3b3JrIG9uIHRoZSBzdWJqZWN0LCBteSBw bGVkZ2Ugd291bGQgYmUgdG8gc3RhcnQgZnJvbSBhIGZyYW1ld29yayBkb2N1bWVudCB0byBjYXB0 dXJlIHRoZSBuZXcgY29uY2VwdHMgYmVmb3JlIGRlZmluaW5nIHByb3RvY29sIGV4dGVuc2lvbnMu DQoNCkJlc3QNCg0KR2VydA0KDQoNCkJlbG93IGEgbGlzdCBvZiBvYnNlcnZhdGlvbnMgdGhhdCBp bmZsdWVuY2VkIHRoaXMgdmlldzoNCjEuICAgICAgIE9QVUNuLCBPRFVDbiBhbmQgT1RVQ24gYXJl IG5ldyBhbmQgdGhlIGxheWVyaW5nIHJlbGF0aW9uc2hpcCB0byB0aGUgZm9ybWVyIHN0cnVjdHVy ZSBpcyBhIGJpdCBzdXJwcmlzaW5nLCBhcyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCAoc2Vl IGJlbG93KSBzaG93ZWQuIEJldHRlciB0byBnZXQgdGhpcyByaWdodCBlYXJseSBvbg0KMi4gICAg ICAgRmlndXJlIDctMSBzaG93cyB0aGUgT1ROIG11bHRpcGxleGluZyBhbmQgbWFwcGluZyBzdHJ1 Y3R1cmVzIGJ1dCBkb2VzIG5vdCBpbmRpY2F0ZSBob3cgZS5nLiBhIDQwMEdFIHdvdWxkIGJlIG1h cHBlZCBpbnRvIHRoaXMgc3RydWN0dXJlLiBJdCBpcyBub3Qgc3VycHJpc2luZyBhcyA0MDBHRSBp cyBzdGlsbCBpbiB0aGUgbWFraW5ncywgYnV0IHJhaXNlcyBhIGZldyBxdWVzdGlvbnMgYWJvdXQg aG93IGl0IGlzIHBsYW5uZWQgdG8gYmUgbWFwcGVkLiBIb3dldmVyIGd1aWRhbmNlIGZyb20gU0cx NSB3b3VsZCBoZWxwIHRvIGdldCB0aGUgcHJvdG9jb2wgYXJjaGl0ZWN0dXJlIGZ1dHVyZSBwcm9v Zi4NCmEuICAgICAgIERvZXMgZXZlcnkgY2xpZW50IHNpZ25hbCBuZWVkIHRvIGJlIHdyYXBwZWQg aW50byBhbiBPUFVrL09EVWsgYmVmb3JlIGl0IGNhbiBiZSB0cmFuc3BvcnRlZCB2aWEgYW4gT1BV Q24vT0RVQ24/IC0tPiB0aGlzIHdvdWxkIG1lYW4gdG8gZXh0ZW5kIHRoZSBPRFUgc3RydWN0dXJl IGJ5IGFuIE9EVTUsNiw3IGV0Yy4gZm9yIGNsaWVudHMgPiAxMDBHDQpiLiAgICAgICBXaWxsIG9u bHkgY2xpZW50IHNpZ25hbHMgPD0gMTAwRyBuZWVkIHRvIGJlIHdyYXBwZWQgaW4gYW4gT1BVay9P RFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPyAtLT4g dGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhlcmUgd2lsbCBiZSBhIGJyZWFrIGluIHRoZSBtYXBwaW5n cyBhdCBhYm91dCAxMDBHIHNpZ25hbHMgYW5kIG5vIE9EVTUsNiw3IHdvdWxkIG5lZWQgdG8gYmUg ZGVmaW5lZA0KYy4gICAgICAgV2lsbCBmdXR1cmUgY2xpZW50cyBiZSBtYXBwZWQgZGlyZWN0bHkg aW50byBPUFVDbi9PRFVDbiBhbmQgdGhlIHNwZWNpYWwgY2FzZSBvZiAxMDBHRS0tPk9QVWsvT0RV ay0tPk9QVUNuL09EVUNuIHdpbGwgYmVjb21lIGp1c3QgYW5vdGhlciBvcHRpb24/IChOb3RlOiB0 aGUgZmlndXJlIGV4cGxpY2l0bHkgYWxsb3dzIGZvciBwcm9wcmlldGFyeSBtYXBwaW5ncyBkaXJl Y3RseSBpbnRvIE9QVUNuL09EVUNuIHdoaWNoIGxvb2tzIGxpa2UgYSBwcmFjdGljYWwgdXNlIGNh c2UsIGJ1dCBpdCBsb29rcyBvZGQgdGhhdCBpdCByZW1haW5zIHByb3JpZXRhcnkpDQozLiAgICAg ICBUaGUgc2VjdGlvbiDigJw3LjEgTWFwcGluZ+KAnSBhbmQg4oCcNy4yIFdhdmVsZW5ndGggRGl2 aXNpb24gTXVsdGlwbGV44oCdIGNoYW5nZWQgYSBiaXQgZnJvbSB0aGUgMjAxMiB2ZXJzaW9uLiBB cyBhY3JvbnltcyBoYXZlIGNoYW5nZWQgdG9vLCBhIDE6MSBjb21wYXJpc29uIGlzIG5vdCB0b28g c2ltcGxlLiBUaGUgdGFrZWF3YXkgaXMgdGhhdCBhbiBPVFUgY2FuIGJlIG1hcHBlZCBpbnRvIGEg c2luZ2xlIHdhdmVsZW5ndGggb3Igc3ByZWFkIGFjcm9zcyBzb21lIChPVExrLm4gYW5kIE9UTEMu bikgd2hpY2ggbWVhbnMgaW52ZXJzZSBtdWx0aXBsZXhpbmcuIFNvIGZhciB0aGlzIGNhc2UgaGFz IG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvciBSRkM2MTYzLg0KNC4gICAgICAgSW4g U2VjdGlvbiDigJw2LjEuMSBPVE4gZGlnaXRhbCBzdHJ1Y3R1cmXigJ0gaXQgaXMgZXhwbGFpbmVk IHRoYXQgYW4gT1RVayBjb250YWlucyBhIEZFQywgYnV0IE9UVUNuIGRvZXMgbm90LCBsZWF2aW5n IGl0IHRvIHRoZSBpbnRlcmZhY2UgdG8gYXBwbHkgc29tZS4gVGhpcyBiYXNpY2FsbHkgY3JlYXRl cyBhIEZFQyBsYXllciBiZWxvdyB0aGUgT1RVQ24gdGhhdCB3aWxsIG5vdCBiZSBkZWZpbmVkIGlu IEcuNzA5LiBBIGNvbnRyb2wgcGxhbmUgd291bGQgbmVlZCB0byBjaGVjayBjb21wYXRpYmlsaXR5 IG9mIHdhdmVsZW5ndGgsIG1vZHVsYXRpb24sIGludGVyZmFjZXMgKGkuZS4gaG93IG1hbnkgbGFu ZXMpIGFuZCBjb21wYXRpYmlsaXR5IG9mIEZFQywgYXMgd2VsbCBhcyB1c2FnZSBvZiBPVFVrIHZz IE9UVUNuLiBBbHNvIHRoaXMgY2FzZSBoYXMgbm90IGJlZW4gY29uc2lkZXJlZCBpbiBSRkM3MTM5 IG9yIFJGQzYxNjMuDQo1LiAgICAgICBUaGVyZSBpcyBhbHNvIGEgbmV3IE9NUyBNU0kgKHNlY3Qg MTUuNCkgb3ZlcmhlYWQgZGVmaW5lZCwgd2hpY2ggcHJvdmlkZXMgYSBsaXN0IG9mIE9DaCBhbmQg T1RTaUEgZnJlcXVlbmN5IHNsb3QscG9ydCBudW1iZXJzIGFuZCBhIGxpc3Qgb2YgbWVkaWEgY2hh bm5lbHMgKGZyZXF1ZW5jeSBzbG90LCBtZWRpYSBjaGFubmVsIHBvcnQgbnVtYmVycykgdG8gZGVj b2RlIHRoZSBsYW5lcyBjb3JyZWN0bHkuIFRoaXMgbWF5IGFmZmVjdCBSRkM2MTYzDQo2LiAgICAg ICBUaGUgdGVybSDigJxXYXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleOKAnSBpbiB0aGUgc2Vj dGlvbnMgYWJvdmUgZG9lc27igJl0IGltcGx5IGEgd2F2ZWxlbmd0aCBjYW4gYmUgcm91dGVkIHRo cm91Z2ggYSBEV0RNIG5ldHdvcmsgc2luY2Ugd2Uga25vdyB0aGF0IGUuZy4gMTAwRyBpbnRlcmZh Y2VzIGFyZSBub3QgeWV0IGRlZmluZWQgYnkgU0cxNSBmb3IgYW1wbGlmaWVkIERXRE0gYXBwbGlj YXRpb25zLiBXaXRob3V0IGFtcGxpZmllcnMsIHRoZSBkaXN0YW5jZSBzdXBwb3J0ZWQgYnkgc3Vj aCBEV0RNIGlzIGxpa2VseSBsaW1pdGVkIHRvIGJlbG93IDgwLTEwMGttLiBJdCBpcyBub3QgeWV0 IGNsZWFyIGJ5IHdoZW4gdGhpcyBsaW1pdGF0aW9uIHdpbGwgYmUgbGlmdGVkIGJ5IFNHMTUgKHNl ZSBkcmFmdC1tYW55LWNvaGVyZW50LWR3ZG0taWYtY29udHJvbC0wMCkuIEFmdGVyIGFsbCwgT1RV NCBiYXNlZCAxMDBHIGludGVyZmFjZXMgZm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucyBh cmUgYXZhaWxhYmxlIGFuZCBoYXZlIGV2ZW4gYmVlbiBwcm92ZW4gdG8gYmUgaW50ZXJvcGVyYWJs ZSBhbW9uZyBtdWx0aXBsZSB2ZW5kb3JzIGNvdmVyaW5nIGRpc3RhbmNlcyA+MTAwMGttLiAgSG93 ZXZlciwgdG8gc3RheSBpbiB0aGUgc3RhbmRhcmRzIGZyYW1ld29yayBmb3Igbm93LCBSRkM2MTYz IHdvdWxkIG5lZWQgdG8gY29uc2lkZXI6DQphLiAgICAgICBXaGlsZSBhIE9UVUNuIGNhbiBiZSBk aWdpdGFsbHkgY29uc3RydWN0ZWQgYW5kIG1hcHBlZCBpbnRvIGEgc2luZ2xlIHdhdmVsZW5ndGgs IGl0IGNhbm5vdCBiZSByb3V0ZWQgaW4gV1NPTiAtLT4gbm8gMTAwRyBpbnRlcmZhY2VzIGluIGFt cGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KYi4gICAgICAgQW4gT1RV Q24gbWF5IGJlIGJyb2tlbiBkb3duIGludG8gNCBsYW5lcyBhdCAyNUcgKE9UTDQuNCkgYnV0IHN0 aWxsIGNhbuKAmXQgYmUgcm91dGVkIGluIFdTT04gLS0+IG5vIDI1RyBpbnRlcmZhY2VzIGluIGFt cGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KYy4gICAgICAgQW4gT1RV MyAoPTQwRykgY2FuIGJlIGJyb2tlbiBkb3duIGluIE9UTDMuNCBwcm92aWRpbmcgNCBsYW5lcyBh dCAxMEcgZWFjaCAtLT4gMTBHIGludGVyZmFjZXMgYXJlIGFsbG93ZWQgaW4gYW1wbGlmaWVkIERX RE0gbmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5OC4yDQoNCg0KDQoNCg0KDQpGcm9tOiBDQ0FNUCA8 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERhbmllbGUgQ2VjY2FyZWxsaSA8 ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4NCkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJl ciAyMDE2IGF0IDIwOjAyDQpUbzogImh1dWJhdHdvcmtAZ21haWwuY29tIiA8aHV1YmF0d29ya0Bn bWFpbC5jb20+LCBDQ0FNUCA8Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBP RFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNClRoYW5rIEh1dWIsDQoNCkF1dGhvcnMsIGlmIHlv dSBjb3VsZCBoYXZlIGEgbGl0dGxlIHBpZWNlIG9mIHRleHQgZGVzY3JpYmluZyB0aGlzIGNvbnNp ZGVyYXRpb24gaW4gdGhlIGZyYW1ld29yayBvciBpbiBvbmUgb2YgdGhlIHNvbHV0aW9uIGRvY3Vt ZW50cyAoZGVwZW5kaW5nIHdoYXQgYXJlIHRoZSBwbGFucyBmb3IgdGhlIG1lcmdlKSB0aGF0IHdv dWxkIGJlIGdyZWF0Lg0KDQpUaGFua3MNCkRhbmllbGUNCg0KRnJvbTogSHV1YiB2YW4gSGVsdm9v cnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NClNlbnQ6IHZlbmVyZMOsIDE4IG5vdmVt YnJlIDIwMTYgMTk6MzENClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxs aUBlcmljc3Nvbi5jb20+OyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RV NCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpEYW5pZWxlLA0KDQpZb3Ugd3JpdGU6DQpUaGFua3Mg Zm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLg0KDQpZb3UncmUgd2VsY29tZS4NCg0KDQoN Ckkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aCBtYWtlIHNlbnNlLg0KDQpJ IGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS4NCg0KDQoNClRoZSBvbmUgcHJvcG9zZWQgYnkgR2Vy dCBpcyBzdGl0Y2hpbmcgb2YgYW4gT0RVNCBhbmQgT0RVQzEsDQoNClRoaXMgdXNlIGNhc2UgaXMg aW1wb3NzaWJsZS4gQXMgeW91IGNhbiBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTENCmEg bG93ZXIgb3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFVDMSwgYW5k IHRoaXMNCm1lYW5zIHRoYXQgdGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXllcnMgaW4gdGhl IE9UTi4NCkFuZCBhcmUgaW1wb3NzaWJsZSB0byBzdGl0Y2guDQoNCg0KDQp3aGlsZSB0aGUgb25l IHlvdSBhcmUgZGVzY3JpYmluZyBpcyB0dW5uZWxpbmcgb2YgT0RVNCBvdmVyIGFuIE9EVUMxIHRy YWlsLg0KDQpDb3JyZWN0Lg0KDQoNCg0KVGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUs IHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT8NCg0KSSB0cmllZCB0byBleHBsYWlu IGFib3ZlLg0KDQpCZXN0IHJlZ2FyZHMsIEh1dWIuDQoNCg0KDQoNCkZyb206IENDQU1QIFttYWls dG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1dWIgdmFuIEhlbHZvb3J0 DQpTZW50OiBnaW92ZWTDrCAxNyBub3ZlbWJyZSAyMDE2IDE3OjA2DQpUbzogY2NhbXBAaWV0Zi5v cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQg T0RVQ24gZGlzY3Vzc2lvbg0KDQpIZWxsbyBHZXJ0LA0KDQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBj b21wbGV0ZWx5IGNvcnJlY3QuDQoNCkluc3RlYWQgb2Y6DQoxLiAgICAgIEEgdXNlIGNhc2UgdG8g Y29uc2lkZXIgaXM6DQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9EVTQt fC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdN UC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgTkUxICAgICAg ICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5FMw0KDQpJ dCBzaG91bGQgYmU6DQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjEwMEdFLS18LUdN UC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1P RFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ctTkUpICAgICAg ICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5FMyB0dW5uZWxz IHRoZSBPRFU0Lg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0KDQoNCi0tDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpBbHdh eXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNl Li4uX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1Q IG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2NhbXANCg== --_000_B50A706B1C8045E18FBB0FFA857BDD9Fjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <225052F90CF21F4AB49A23A2F9DECF97@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7 DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OnNhbnMtc2VyaWY7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQy LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5RaWxlaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NeSBsYXN0IGVt YWlsIGNvbnRhaW5lZCBhIGZldyBvYnNlcnZhdGlvbnMgdGhhdCB3ZXJlIGludGVuZGVkIHRvIGFs bG93IGZlbGxvdyBjY2FtcC1lcnMgdG8gZm9sbG93IHdoYXQgdGhlIGRpc2N1c3Npb24gaXMgYWJv dXQuIEkgZGlkIG5vdCBleHBlY3QgZmVlZGJhY2sgb24gdGhvc2UNCiBidXQgcmF0aGVyIGlmIGZv bGtzIGZlZWwgYSBmcmFtZXdvcmsgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIG9yIG5vdC4gWW91 ciBvcGluaW9uIGFib3V0IHRoaXMgc3ViamVjdCBpcyB3ZWxjb21lZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkdlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mcXVvdDt3YW5nLnFpbGVp QHp0ZS5jb20uY24mcXVvdDsgJmx0O3dhbmcucWlsZWlAenRlLmNvbS5jbiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+V2VkbmVzZGF5IDIzIE5vdmVtYmVyIDIwMTYgYXQgMTY6Mzg8YnI+DQo8Yj5Ubzog PC9iPkdlcnQgR3JhbW1lbCAmbHQ7Z2dyYW1tZWxAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj5DQ0FNUCAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7LCBEYW5pZWxlIENlY2NhcmVsbGkgJmx0 O2RhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20mZ3Q7LCAmcXVvdDtodXViYXR3b3JrQGdt YWlsLmNvbSZxdW90OyAmbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IaSBHZXJ0LDwvc3Bhbj4N Cjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoYW5rcyBmb3IgeW91ciBj b21tZW50cy4gRm9sbG93aW5nIGlzIG15IGFuc3dlciB0byB5b3VyIHByZXZpb3VzIG1haWwgYW5k IHRoaXMgb25lLjwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PigxKSwgQWJvdXQgdGhlIHF1ZXN0aW9ucyBpbiB5b3VyIHByZXZpb3VzIG1haWwuIEkgdGhpbmsg eW91IGFscmVhZHkgaGF2ZSBtYW55IG9mIHRoZW0gc29sdmVkLiBPRFVDbiBoYXMgYWxtb3N0IHRo ZSBzYW1lIG92ZXJoZWFkIGFzIHRoYXQgb2YgT0RVaywgc28gSSBkb24ndCB0aGluayBzb21lIG1l Y2hhbmlzbXMgb2YgT0RVQ24gKGUuZy4sDQogT0FNIGV0YykgZGlmZmVyIGZyb20gdGhvc2Ugb2Yg T0RVay4gSW4gdGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNob3VsZCBtYWlubHkgcGF5IGF0 dGVudGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZmZXJlbmNlIHdpdGggT0RVayBu b3csIHN1Y2ggYXMgbGF5ZXIgbW9kZWwgb2YgT0RVQ24gYW5kIHNldHVwIG9mIE9EVUNuIGNvbm5l Y3Rpb24uPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+KDIp LCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHRoZSBzZWNvbmQgaXRlbXMgb2YgdGhpcyB0aHJlYWQu IEkgdGhpbmsgaXQncyBvdXQgb2YgdGhlIHNjb3BlIG9mIENDQU1QLiBJIGNhbid0IGdpdmUgYSBk ZWZpbml0ZSBhbnN3ZXIgdG8gdGhlc2UgcXVlc3Rpb25zLg0KPC9zcGFuPjxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPigzKSwgQ29udHJvbCBvZiBvcHRpY2FsIG5ldHdvcmsg aXMgb3V0IG9mIHRoZSBzY29wZSBvZiBjdXJyZW50IE9EVUNuIGRvY3VtZW50LiBXZSB3aWxsIG5v dCBpbnZvbHZlIHRoaXMgcGFydCBpbi4gQWxzbyBJIHN1Z2dlc3QgeW91IHRha2UgYSBsb29rIGF0 IFJGQzc2OTgsIHdoaWNoIG1haW5seSBmb2N1cyBvbiB0aGUgY29udHJvbCBvZg0KIGZsZXhpYmxl IGdyaWQgbmV0d29yay48L3NwYW4+IDxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPlRoYW5rczwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UWlsZWk8 YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5 bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjM2JSIgdmFsaWdu PSJ0b3AiIHN0eWxlPSJ3aWR0aDozNi4wJTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+R2Vy dCBHcmFtbWVsICZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTpTaW1TdW4iPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjogJm5ic3A7JnF1b3Q7Q0NBTVAmcXVvdDsgJmx0O2NjYW1wLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O3NhbnMtc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjIwMTYvMTEvMjMgMjE6MDE8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjYzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wJTtwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAl Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz dHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuaUtuS7tuS6ujwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7c2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+RGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24u Y29tJmd0OywgJnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0 OywNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90 OyI+5oqE6YCBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIg c3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5z LXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mcXVvdDtodXViYXR3b3JrQGdtYWlsLmNv bSZxdW90OyAmbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PC9zcGFuPg0KPG86cD48L286cD48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuS4uzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+6aKYPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5SZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0K PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+ PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5EYW5pZWxlLCBBdXRo b3JzLDwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BZnRlciBvdXIgaW5pdGlhbCBlbWFpbCBleGNoYW5n ZSBJIHRvb2sgYSBtb3JlIGRldGFpbGVkIGxvb2sgaW4gdGhlIDIwMTYgdmVyc2lvbiBvZiBHLjcw OS4gSW4gZXNzZW5jZSwgdGhlIDIwMTYgdmVyc2lvbiBvZiBHLjcwOSB3b3VsZCBpbXBhY3QgY29u dHJvbCBwbGFuZSB3b3JrIGZvciBHLjcwOSAoUkZDNzEzOSkgYXMgd2VsbCBhcyBmb3IgV1NPTiAo UkZDNjE2MykuDQogVGhlIGNvbXBsZXggbmF0dXJlIG9mIHRob3NlIGRlZmluaXRpb25zIHdpbGwg Y2VydGFpbmx5IG5vdCBiZSBhbiBlYXN5LWdvaW5nIGV4dGVuc2lvbiBhcyBpdCBoYWQgYmVlbiBl bnZpc2FnZWQgc28gZmFyLiBXcml0aW5nIGEg4oCcbGl0dGxlIHBpZWNlIG9mIHRleHTigJ0gbG9v a3MgdG8gbWUgbGlrZSBhIOKAnGxpdHRsZSBiaXQgb2YgdW5kZXJzdGF0ZW1lbnTigJ0uIElmIHRo ZSBXRyBpbnRlbmRzIHRvIHdvcmsgb24gdGhlIHN1YmplY3QsIG15IHBsZWRnZSB3b3VsZA0KIGJl IHRvIHN0YXJ0IGZyb20gYSBmcmFtZXdvcmsgZG9jdW1lbnQgdG8gY2FwdHVyZSB0aGUgbmV3IGNv bmNlcHRzIGJlZm9yZSBkZWZpbmluZyBwcm90b2NvbCBleHRlbnNpb25zLjwvc3Bhbj4NCjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNw Ozwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+QmVzdDwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5HZXJ0PC9zcGFuPiA8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3Nw YW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+QmVsb3cgYSBsaXN0IG9mIG9ic2VydmF0aW9ucyB0aGF0IGluZmx1 ZW5jZWQgdGhpcyB2aWV3Ojwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjEuICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9QVUNuLCBP RFVDbiBhbmQgT1RVQ24gYXJlIG5ldyBhbmQgdGhlIGxheWVyaW5nIHJlbGF0aW9uc2hpcCB0byB0 aGUgZm9ybWVyIHN0cnVjdHVyZSBpcyBhIGJpdCBzdXJwcmlzaW5nLCBhcyB0aGUgZGlzY3Vzc2lv biBvbiB0aGUgbGlzdCAoc2VlIGJlbG93KSBzaG93ZWQuIEJldHRlciB0byBnZXQgdGhpcyByaWdo dCBlYXJseSBvbjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpZ3VyZSA3LTEgc2hv d3MgdGhlIE9UTiBtdWx0aXBsZXhpbmcgYW5kIG1hcHBpbmcgc3RydWN0dXJlcyBidXQgZG9lcyBu b3QgaW5kaWNhdGUgaG93IGUuZy4gYSA0MDBHRSB3b3VsZCBiZSBtYXBwZWQgaW50byB0aGlzIHN0 cnVjdHVyZS4gSXQgaXMgbm90IHN1cnByaXNpbmcgYXMgNDAwR0UgaXMgc3RpbGwgaW4gdGhlIG1h a2luZ3MsIGJ1dCByYWlzZXMNCiBhIGZldyBxdWVzdGlvbnMgYWJvdXQgaG93IGl0IGlzIHBsYW5u ZWQgdG8gYmUgbWFwcGVkLiBIb3dldmVyIGd1aWRhbmNlIGZyb20gU0cxNSB3b3VsZCBoZWxwIHRv IGdldCB0aGUgcHJvdG9jb2wgYXJjaGl0ZWN0dXJlIGZ1dHVyZSBwcm9vZi48L3NwYW4+DQo8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5hLiAm bmJzcDsgJm5ic3A7ICZuYnNwOyBEb2VzIGV2ZXJ5IGNsaWVudCBzaWduYWwgbmVlZCB0byBiZSB3 cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0ZWQgdmlh IGFuIE9QVUNuL09EVUNuPw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IHRoaXMgd291bGQgbWVhbiB0byBleHRlbmQgdGhlIE9E VSBzdHJ1Y3R1cmUgYnkgYW4gT0RVNSw2LDcgZXRjLiBmb3IgY2xpZW50cyAmZ3Q7IDEwMEc8L3Nw YW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5iLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaWxsIG9ubHkgY2xpZW50IHNpZ25hbHMgJmx0 Oz0gMTAwRyBuZWVkIHRvIGJlIHdyYXBwZWQgaW4gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4g YmUgdHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w6A8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IHRoaXMgd291bGQgbWVh biB0aGF0IHRoZXJlIHdpbGwgYmUgYSBicmVhayBpbiB0aGUgbWFwcGluZ3MgYXQgYWJvdXQgMTAw RyBzaWduYWxzIGFuZCBubyBPRFU1LDYsNyB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQ8L3NwYW4+ DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5jLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaWxsIGZ1dHVyZSBjbGllbnRzIGJlIG1hcHBlZCBk aXJlY3RseSBpbnRvIE9QVUNuL09EVUNuIGFuZCB0aGUgc3BlY2lhbCBjYXNlIG9mIDEwMEdFPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+ w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+T1BVay9PRFVrPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+T1BVQ24vT0RVQ24NCiB3aWxsIGJlY29tZSBqdXN0IGFub3RoZXIg b3B0aW9uPyAoTm90ZTogdGhlIGZpZ3VyZSBleHBsaWNpdGx5IGFsbG93cyBmb3IgcHJvcHJpZXRh cnkgbWFwcGluZ3MgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBsaWtlIGEg cHJhY3RpY2FsIHVzZSBjYXNlLCBidXQgaXQgbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlucyBwcm9y aWV0YXJ5KTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjMuICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBzZWN0aW9uIOKAnDcu MSBNYXBwaW5n4oCdIGFuZCDigJw3LjIgV2F2ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXjigJ0g Y2hhbmdlZCBhIGJpdCBmcm9tIHRoZSAyMDEyIHZlcnNpb24uIEFzIGFjcm9ueW1zIGhhdmUgY2hh bmdlZCB0b28sIGEgMToxIGNvbXBhcmlzb24gaXMgbm90IHRvbyBzaW1wbGUuIFRoZSB0YWtlYXdh eSBpcyB0aGF0IGFuIE9UVQ0KIGNhbiBiZSBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3Ro IG9yIHNwcmVhZCBhY3Jvc3Mgc29tZSAoT1RMay5uIGFuZCBPVExDLm4pIHdoaWNoIG1lYW5zIGlu dmVyc2UgbXVsdGlwbGV4aW5nLiBTbyBmYXIgdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRl cmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2My48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj40LiAmbmJzcDsgJm5ic3A7ICZuYnNw OyBJbiBTZWN0aW9uIOKAnDYuMS4xIE9UTiBkaWdpdGFsIHN0cnVjdHVyZeKAnSBpdCBpcyBleHBs YWluZWQgdGhhdCBhbiBPVFVrIGNvbnRhaW5zIGEgRkVDLCBidXQgT1RVQ24gZG9lcyBub3QsIGxl YXZpbmcgaXQgdG8gdGhlIGludGVyZmFjZSB0byBhcHBseSBzb21lLiBUaGlzIGJhc2ljYWxseSBj cmVhdGVzIGEgRkVDIGxheWVyIGJlbG93IHRoZSBPVFVDbg0KIHRoYXQgd2lsbCBub3QgYmUgZGVm aW5lZCBpbiBHLjcwOS4gQSBjb250cm9sIHBsYW5lIHdvdWxkIG5lZWQgdG8gY2hlY2sgY29tcGF0 aWJpbGl0eSBvZiB3YXZlbGVuZ3RoLCBtb2R1bGF0aW9uLCBpbnRlcmZhY2VzIChpLmUuIGhvdyBt YW55IGxhbmVzKSBhbmQgY29tcGF0aWJpbGl0eSBvZiBGRUMsIGFzIHdlbGwgYXMgdXNhZ2Ugb2Yg T1RVayB2cyBPVFVDbi4gQWxzbyB0aGlzIGNhc2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4g UkZDNzEzOQ0KIG9yIFJGQzYxNjMuPC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj41LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVy ZSBpcyBhbHNvIGEgbmV3IE9NUyBNU0kgKHNlY3QgMTUuNCkgb3ZlcmhlYWQgZGVmaW5lZCwgd2hp Y2ggcHJvdmlkZXMgYSBsaXN0IG9mIE9DaCBhbmQgT1RTaUEgZnJlcXVlbmN5IHNsb3QscG9ydCBu dW1iZXJzIGFuZCBhIGxpc3Qgb2YgbWVkaWEgY2hhbm5lbHMgKGZyZXF1ZW5jeSBzbG90LCBtZWRp YSBjaGFubmVsIHBvcnQgbnVtYmVycykNCiB0byBkZWNvZGUgdGhlIGxhbmVzIGNvcnJlY3RseS4g VGhpcyBtYXkgYWZmZWN0IFJGQzYxNjM8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjYuICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRo ZSB0ZXJtIOKAnFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV44oCdIGluIHRoZSBzZWN0aW9u cyBhYm92ZSBkb2VzbuKAmXQgaW1wbHkgYSB3YXZlbGVuZ3RoIGNhbiBiZSByb3V0ZWQgdGhyb3Vn aCBhIERXRE0gbmV0d29yayBzaW5jZSB3ZSBrbm93IHRoYXQgZS5nLiAxMDBHIGludGVyZmFjZXMg YXJlIG5vdCB5ZXQgZGVmaW5lZCBieSBTRzE1IGZvcg0KIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0 aW9ucy4gV2l0aG91dCBhbXBsaWZpZXJzLCB0aGUgZGlzdGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2gg RFdETSBpcyBsaWtlbHkgbGltaXRlZCB0byBiZWxvdyA4MC0xMDBrbS4gSXQgaXMgbm90IHlldCBj bGVhciBieSB3aGVuIHRoaXMgbGltaXRhdGlvbiB3aWxsIGJlIGxpZnRlZCBieSBTRzE1IChzZWUg ZHJhZnQtbWFueS1jb2hlcmVudC1kd2RtLWlmLWNvbnRyb2wtMDApLiBBZnRlciBhbGwsIE9UVTQg YmFzZWQNCiAxMDBHIGludGVyZmFjZXMgZm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucyBh cmUgYXZhaWxhYmxlIGFuZCBoYXZlIGV2ZW4gYmVlbiBwcm92ZW4gdG8gYmUgaW50ZXJvcGVyYWJs ZSBhbW9uZyBtdWx0aXBsZSB2ZW5kb3JzIGNvdmVyaW5nIGRpc3RhbmNlcyAmZ3Q7MTAwMGttLiAm bmJzcDtIb3dldmVyLCB0byBzdGF5IGluIHRoZSBzdGFuZGFyZHMgZnJhbWV3b3JrIGZvciBub3cs IFJGQzYxNjMgd291bGQgbmVlZCB0byBjb25zaWRlcjo8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5hLiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBXaGlsZSBhIE9UVUNuIGNhbiBiZSBkaWdpdGFsbHkgY29uc3RydWN0ZWQgYW5kIG1h cHBlZCBpbnRvIGEgc2luZ2xlIHdhdmVsZW5ndGgsIGl0IGNhbm5vdCBiZSByb3V0ZWQgaW4gV1NP Tg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+IG5vIDEwMEcgaW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBk ZWZpbmVkIGluIEcuNjk4LjI8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5iLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbiBPVFVD biBtYXkgYmUgYnJva2VuIGRvd24gaW50byA0IGxhbmVzIGF0IDI1RyAoT1RMNC40KSBidXQgc3Rp bGwgY2Fu4oCZdCBiZSByb3V0ZWQgaW4gV1NPTg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IG5vIDI1RyBpbnRlcmZhY2VzIGlu IGFtcGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMjwvc3Bhbj4NCjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmMuICZu YnNwOyAmbmJzcDsgJm5ic3A7IEFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93biBpbiBP VEwzLjQgcHJvdmlkaW5nIDQgbGFuZXMgYXQgMTBHIGVhY2gNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPsOgPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiAxMEcgaW50ZXJmYWNl cyBhcmUgYWxsb3dlZCBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4 LjI8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz cDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSI+Q0NBTVAgJmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9u IGJlaGFsZiBvZiBEYW5pZWxlIENlY2NhcmVsbGkgJmx0O2RhbmllbGUuY2VjY2FyZWxsaUBlcmlj c3Nvbi5jb20mZ3Q7PGI+PGJyPg0KRGF0ZTogPC9iPkZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0 IDIwOjAyPGI+PGJyPg0KVG86IDwvYj4mcXVvdDtodXViYXR3b3JrQGdtYWlsLmNvbSZxdW90OyAm bHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7LCBDQ0FNUCAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7 PGI+PGJyPg0KU3ViamVjdDogPC9iPlJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Np b248L3NwYW4+IDxicj4NCiZuYnNwOyA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFuayBIdXViLDwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPiA8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5B dXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBwaWVjZSBvZiB0ZXh0IGRlc2NyaWJp bmcgdGhpcyBjb25zaWRlcmF0aW9uIGluIHRoZSBmcmFtZXdvcmsgb3IgaW4gb25lIG9mIHRoZSBz b2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGluZyB3aGF0IGFyZSB0aGUgcGxhbnMgZm9yIHRoZSBt ZXJnZSkgdGhhdCB3b3VsZCBiZSBncmVhdC48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+IDxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rczwv c3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+RGFuaWVsZSAmbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiBI dXViIHZhbiBIZWx2b29ydCBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWls LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4gdmVu ZXJkw6wgMTggbm92ZW1icmUgMjAxNiAxOTozMTxiPjxicj4NClRvOjwvYj4gRGFuaWVsZSBDZWNj YXJlbGxpICZsdDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzsgY2NhbXBAaWV0 Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlz Y3Vzc2lvbjwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkRhbmll bGUsPGJyPg0KPGJyPg0KWW91IHdyaXRlOjwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzIGZvciB0aGUgY2xlYXIgZXhw bGFuYXRpb24gSHV1Yi48L3NwYW4+DQo8YnI+DQo8YnI+DQpZb3UncmUgd2VsY29tZS48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5JIHNlZSB0d28gZGlmZmVyZW50IHVzZSBjYXNlcyB0aGF0IGJvdGggbWFrZSBz ZW5zZS4NCjwvc3Bhbj48YnI+DQo8YnI+DQpJIGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5UaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFu IE9EVTQgYW5kIE9EVUMxLDwvc3Bhbj4NCjxicj4NCjxicj4NClRoaXMgdXNlIGNhc2UgaXMgaW1w b3NzaWJsZS4gQXMgeW91IGNhbiBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTEgPGJyPg0K YSBsb3dlciBvcmRlciBPRFU0IGlzIG1hcHBlZCBpbnRvIGEgaGlnaGVyIG9yZGVyIE9EVUMxLCBh bmQgdGhpcyA8YnI+DQptZWFucyB0aGF0IHRoZXkgY29uc3RpdHV0ZSBkaWZmZXJlbnQgbGF5ZXJz IGluIHRoZSBPVE4uIDxicj4NCkFuZCBhcmUgaW1wb3NzaWJsZSB0byBzdGl0Y2guPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+d2hpbGUgdGhlIG9uZSB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgdHVubmVsaW5nIG9m IE9EVTQgb3ZlciBhbiBPRFVDMSB0cmFpbC48L3NwYW4+DQo8YnI+DQo8YnI+DQpDb3JyZWN0Ljxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPlRoZXkgYm90aCBzZWVtcyByZWFzb25hYmxlIHRvIG1lLCB3aHkgdGhl IHN0aXRjaGluZyBpcyBub3QgZmVhc2libGU/PC9zcGFuPg0KPGJyPg0KPGJyPg0KSSB0cmllZCB0 byBleHBsYWluIGFib3ZlLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcywgSHV1Yi48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFu PiA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+IENDQU1QIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6IzAwODJCRiI+bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+SHV1YiB2YW4gSGVsdm9vcnQ8Yj48YnI+DQpTZW50OjwvYj4g Z2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzowNjxiPjxicj4NClRvOjwvYj4gPC9zcGFuPjxh IGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMDA4MkJGIj5jY2FtcEBpZXRmLm9yZzwvc3Bh bj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PGJyPg0KU3ViamVjdDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNz aW9uPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNw Ozwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhlbGxvIEdl cnQsPGJyPg0KPGJyPg0KWW91ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Ljxi cj4NCjxicj4NCkluc3RlYWQgb2Y6PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+MS4gJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QSB1c2UgY2FzZSB0byBjb25zaWRl ciBpczo8L3NwYW4+DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvYj4gPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYj NDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0t LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9U VUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0t LS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmIzQzOy0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7DQo8L3NwYW4+PC9iPjxicj4NCjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtORTEg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9zcGFuPjwv Yj4NCjxicj4NCjxicj4NCkl0IHNob3VsZCBiZTogPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0t LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPg0KPGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0t LSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7DQo8L3NwYW4+PC9iPjxicj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtORTEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9z cGFuPjwvYj48YnI+DQo8YnI+DQpUaGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5lbHMgdGhl IE9EVTQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+UmVnYXJkcywgSHV1Yi4gPG86cD48L286cD48L3A+ DQo8cD4mbmJzcDsgPGJyPg0KJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij4mbmJzcDsgPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tIDwvc3Bhbj48YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbHdheXMgcmVtZW1iZXIg dGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uPHR0Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC90dD48YnI+DQo8dHQ+ Q0NBTVAgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+Q0NBTVBAaWV0Zi5vcmc8L3R0Pjxicj4N Cjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L3NwYW4+PC90dD48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B50A706B1C8045E18FBB0FFA857BDD9Fjunipernet_-- From nobody Wed Nov 23 13:57:57 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CFE129518 for ; Wed, 23 Nov 2016 13:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com 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 jO5gOekyUpmS for ; Wed, 23 Nov 2016 13:57:52 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0072.outbound.protection.outlook.com [104.47.32.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB4312007C for ; Wed, 23 Nov 2016 13:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+lyMnGWDsc0RSu4bfE9eatN8+tnBzKJZB3DT/0tNeDc=; b=rfLfsmpzLc7A0jMAGjTKxr8TgN97VkdxgZh6IMSLBUpSMaKO2KU8M4XFVC/8H5MbCTAwDEYxsX/kQzyRzTtYdTODrM31A/L3DOhd90UBKvh33MvhKFSd0yegOTejEqc5AFPvfLplU9ObIHBKyUsAHnyS4wBBShgpJkPpt/i9VQM= Received: from CY1PR1001CA0027.namprd10.prod.outlook.com (10.163.136.37) by CY1PR10MB0729.namprd10.prod.outlook.com (10.163.235.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Wed, 23 Nov 2016 21:57:49 +0000 Received: from DM3NAM03FT028.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::208) by CY1PR1001CA0027.outlook.office365.com (2a01:111:e400:5311::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8 via Frontend Transport; Wed, 23 Nov 2016 21:57:49 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=bestguesspass action=none header.from=infinera.com;nokia.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by DM3NAM03FT028.mail.protection.outlook.com (10.152.82.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4 via Frontend Transport; Wed, 23 Nov 2016 21:57:49 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1769; Count:20 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 23 Nov 2016 13:57:47 -0800 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Wed, 23 Nov 2016 13:57:47 -0800 From: Iftekhar Hussain To: Dieter Beller , "wang.qilei@zte.com.cn" , Gert Grammel Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSRbrMOT/L5vhW6k2YsIK58n9Zp6DnG1lg Date: Wed, 23 Nov 2016 21:57:47 +0000 Message-ID: <4dfbb368423649d88f9bcf6a07af062e@sv-ex13-prd1.infinera.com> References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> In-Reply-To: <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_4dfbb368423649d88f9bcf6a07af062esvex13prd1infineracom_" MIME-Version: 1.0 X-IncomingHeaderCount: 20 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(7916002)(2980300002)(438002)(199003)(53754006)(189002)(51914003)(377454003)(24454002)(246002)(7696004)(2501003)(102836003)(5660300001)(30436002)(4546004)(84326002)(356003)(512874002)(2950100002)(7636002)(7736002)(106466001)(7846002)(7906003)(8666005)(106116001)(8936002)(2900100001)(3846002)(626004)(8676002)(4326007)(93886004)(790700001)(54356999)(50986999)(76176999)(38730400001)(229853002)(53416004)(86362001)(108616004)(33646002)(606004)(5001770100001)(92566002)(24736003)(6116002)(189998001)(2906002)(80792005)(39060400001)(77096005)(1941001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR10MB0729; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT028; 1:NDOO+rzoLc/mzTNJ5IyeVEsKBTYA8CIjZFadIum7FDnfoHtRTxelZ9Axagbk2E5BWv9rPZNU4yEwDK13ulcZWe6NvpT/EV7BVAtPC7otak1PZ4ElacfI66y+dgigmHigcilJlMn7iR53uw+AvvXgoq21ODUJrsQM4iHTZTLy/D8g+Oe364F0vlwOqhC5AidD440flvOGXBsEAiBfQsFxAvswZSoluPUWzP80wicxpIlTh5dZMRPlyKxTfTL7LUIdggmaamvjIt/5yi70L1BktmEbl3dKx4xeVzvjmpJAk8fz9D6vLf0ADUbNPv2hspuJ4IwJyyiTJc9qPkD2s495eSTFBQceOyxZH24gqQ4bMYo7pCTP4OpVr1+z5IktUdXe4AkUCWvRwK27dVHl/gKYcilONHbB0bQYAvEuzbu70vmPCqdoaSweypalTnrQ5StLHdDeuM59aRdzCPpt4chddBUpzph0FYHmJ7r/FVWGlFPGoouEzLT46HsqwAy4AHetYz4B6lrrDiXtPWuXOK3ejo6jy5km3n2pvOZu1OaH07RlJD688LrcVGv8tmly5yet X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0729; 2:9hoPwdxpkF5TCrzHjXYcYTh0U6GD+lWPR70cEpPfaNzqLW2nsvw5eXISb49/KkfMaY1b5ZPLYo0XGvPH7Bv1demjK0SONcCGXd00qThJi+Qt5d3omo+ltIkdrQXKsGeF/zqPhgMYs1L71tkcuhX8FJe6OAnOi6nPNASd7EpMHtE=; 3:uQvvJwLCigI915fK/JtGPkJoucqQXX4lHWyFGvkxtU+R5xeitAt3FsCQWollIXC5LtwUpfRrIYMavwD+JwGZaz8DHFXmSUYVvPcf5b8Xe5jyOoCz6zAPMaDbowLsEPuc38ykdqWzKJU7cJg4GoU1KHWliO/ZXUQeD4HS+3PSOFCaKT9uJz9rwrzn5GQxALXTa5Y8KFxDtIMhHZ+FAa5rchg//68vRl9MS4kT3zh1mTa+sViC88iiwtiAnbaVK/YEutjF8IM7Dw7JMGKkcX7ILmriZvmotO10RgL1NiipNQY= X-MS-Office365-Filtering-Correlation-Id: df69a82b-0be1-433e-2b42-08d413ebc41a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:CY1PR10MB0729; X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0729; 25:fTXQUyIo3pBJxMTXgdyA2I9sVDW1iJZwwPOtRva600BuRldbUnreuwndt2GBcRYqwPdW9V0+/C3W4EmFJe5eHaycPmAtaAX9tw58qo8Exa1l1YlBCvrfwysNwbcf97poVYO84+ZIWde4vBTvrJMZM+v5I4OUTCRRgOXlzZpsGaRxt7nRjTmi2dSgS7UhTpfmZYjN1EsXWuB/6qYoVLQBaGlXk62D2dn7ekMSe7hL5uv2f22BfiSMrvb73IwdxsskNHjaPgfRHz7zkgX4r/iULE+Yxfxwj7bY4NURXQTejWD95toffhUmpBhywRuh54lZ2ziGxcAgTJoUpla7ehpqZNcSjQ5nlFpN8W35iViU8blN0tDmbeCxNBrYUdLOIVSWCUct0n/iCM5MpgXdK0oPNXJDYln186dRTc+fx9PyOp9rosLonNiqdm/vITDWUrpXZAnedDOX3hypsN0NMnojPQ==; 31:cjuUgWop1T9YWE8JpVZVR2cdLMOSWg0aTvbEJAUQLZfFWX9JUO8RQI5XmiBx6Ewnonpmzd1165K4NMvEW7hPq2jyMyXgCjKl2Yo8Mt4Fx2bmGwEBXidEUIjHJqMCBZBBYqB2gVdAxc8GjxGGTq3rJW5ec9UFCGq5YVXrXWwGcZneCJKlXHT01fCC4BbXKNvucGthNXV8mZ/YmuL+HG8ZOW1s6HWsco7mSDRPbRfsXB9HkMF+HDHsKtL8dWwvehNYhsup2j3LEqfjC+e32f7iZg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(278428928389397)(138986009662008)(82608151540597)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6045199)(6040307)(6060326)(601004)(2401047)(13018025)(13024025)(13015025)(13023025)(13017025)(8121501046)(5005006)(3002001)(10201501046)(6041248)(6061324)(6042181); SRVR:CY1PR10MB0729; BCL:0; PCL:0; RULEID:; SRVR:CY1PR10MB0729; X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0729; 4:zWohwFCG1/WPwlxhkAJxJzp/swiIpRxNLucaa5lzzsAlFqO8KFLqNchZVXEiYnGBEjC+Yb2Xr4pQoNm0e1EC8vS4XMqW4uaimHoFmV5EGUHuAijiMgUSTrM5cZehJURqYOGKitGKIVTZBxby2GTqOLnwzgJM2v8NPf42kL165qR5ZXJPLA1WyvlB5MZQn/0V10nrnWweHE8wgZFSUscDpr5oMOmuYCWjk2ZCn5Mv3EGtqiX+4b6Q7A4jzs3YJuHDs9aZHOycm6dw49KsDS4sOKs2jqd8Lo1dVsCYp09saYzWlNmn6Xfr52HKTfoB4Ny5/uMBSF1mIULxHyd/RdxzeRPKGC6Vx8Looa55L0JhhJUionPQPMjknXN0/yDNGH1mRtH3pY1gXj6qOXddqDUw3HBQTfgBqU7FSdztjyUKQIuS/i+pbCVD83mqaIHSnyBe+y9s/4FvVAukR9gGqg+pEM0IBY1KwcgdZTLb+TzX8Sml+Zf0t1S28ojSQ3iAQX4XHAc5voEkHrN/2gwCLh4r93Qr/0lqgV01+5hvz+xh4qo58GxO4v3dOd1TqCy+FQLs3hn4ryuWNLX5nxWcsPNt6ixZB7E7tvepTWuQJRTcZ53ZYD8mA8S3xgCgMVKJNqqISJ1VwE7n5p7EnbbLjSFAHH4m7XlqAuAimncTuReLBmbeqBBz3PWgJ79ow5xLizrSRWvLCobZqh6wOud43rtK4yip5636bw59VL5HIQuwky5FwGHjw9dZBcmocpDiRsO+WaK2aI8dh4CgYehS2pYUxA== X-Forefront-PRVS: 013568035E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR10MB0729; 23:P219bRFWfqMyRIZQapChkcBKutZCC501FCf0YziII?= =?us-ascii?Q?Fo+17gvmZLoqcpnCgB06JxqR4FwPsxQuo0I2S2hdKK+wTDprT3E5X9lEn9k2?= =?us-ascii?Q?7EMyl1ZnHJjrAsetO2HvQCXgU0d5TpFIB2PJJ43Nmb4Me4wqXGaCKS1CFvze?= =?us-ascii?Q?fd/29clTQy7qITIADPseLhpFmVci6sZ2g4RXmEjwjMo5WVvwc+OVFg6GXskq?= =?us-ascii?Q?MvqjsVauJmGkVvMpEqP2BE8nTBwWACZdnGCb9JzjRqY02xrq8joaFhS5p4Mt?= =?us-ascii?Q?01AtVjsy4vIA/ZdnijT2p/zeV+si787vvSJxHtt8mR3RrCeX2i1qEnvRk+Z5?= =?us-ascii?Q?UG/uWrlnrb4usiYUajKpEerHO2dkLr1n+qJ7qjJezTW3tP9EytDts8VupYyx?= =?us-ascii?Q?p02h9PAsq+1gbjsnsbsswWKebbVOKXyD3R/JdychvZKIdO6BXhtUedIlcluN?= =?us-ascii?Q?jcC8+2RNei1OsRtuQPMV/be6JgWhmiM6+m2K+JVMhAZjrp7/6Yi+y/cb2JuA?= =?us-ascii?Q?EhLgaJ4gCTnLTR+iGuutRw+va3+uGPIBhquIzQdRZN3BSeF5Cs7EYhMf7BOd?= =?us-ascii?Q?8EBg/5bGHjHw8jDhtPuvlID9F+4YpucQs3MlYP14kTEsg+PtFqD9CQi9RV4f?= =?us-ascii?Q?igSUg0tEK9SLQ8vQQGzBekYx+USkdGJUxVeR6KW6MdFFS+MhsgtvQn4w5q05?= =?us-ascii?Q?aligqkVpC3s4XuIWx4tDXY7Z+8ErNU9BoqKf/FgoUvkpurl+an4xu35beyxi?= =?us-ascii?Q?SibLwNJZG3I575glHwqfzDt68Mt3E3x5nkjuP3J/kTPXEOa+LletflyWY0oa?= =?us-ascii?Q?QNEv4yvO7Q+fRV+KWuwPmp1YnPJU+4hxs9238z/Ce2RkMLS/W3xPLTkIt13T?= =?us-ascii?Q?h7hmBAOpcgTt1iwAfBVurvFOvBBnb66amhyvTmwmFigqT1nLIXyrhQkzUZE7?= =?us-ascii?Q?ZvIPbV/1y9uzZ6b1DAeXQYq1N8HLZTcxjZFnOhFBSpnBOSgx5RDYgB6TNgGo?= =?us-ascii?Q?iHU61l63Zoiqq/8VAXfYyMLuPuhzb9hV9HFkfRu6CFefzV0dfxlALABevEKV?= =?us-ascii?Q?itzw5MXPy1Z5Nkn+mOtpCFQncPAgcRp3I3DydF0m5FRYqJ/btR50mSwv0aEa?= =?us-ascii?Q?rWpfxprcsC1THFi843PEx20rfh3cc4EDaE5qNoKAZWjA0+Dt+Gri8Jb4q6gU?= =?us-ascii?Q?GTGKYvBjjnQmgLAA1XcmoVh3KCTax5ErWpj+OcTm2WKfQzmr6SLi3vHvodlE?= =?us-ascii?Q?nsJCYBvHILiTdmMkaaTBfrTohEgQRKAVMzynKOJVpo7HXFmllJTABCcmPnNt?= =?us-ascii?Q?7XHzlZKz2g4eocfcHsf9QvCUrY36q8cCE9aX4XE4THh?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0729; 6:qvi6MbVV9HRAIhgYeFXUsLQw/Ou0/3tswMFH02deXAEdAQD/Wtjlhj7+a17NOO2EHWH7wU7Prk29a70V8M1r/LDXVK2jyzMCoOu8kPTrO2SylT5tY2ZeZ7pt8pRgX1n7/b0e+eXG5Va4E/piaSoCboq56YJXZ0inn5zv1OBfJx8UOVD/64uAuQ1sO36engcZH9nJUh/cKOrC3l6fEJUG6p7XGr2QWhuox66xpx5+N0U2iVmzjqOR/syPrykfM6/YmJldx33tDKVNAlwSGRNY1W3ImpshcYfBI81ZTGrC1+XRYeeYsrf8jNqY+XSUhypPzC80v9pv3NU8yLVaTgjfPa8Xjoe9g+6AAokkmOgu7C0=; 5:PsJaCecSYdVEzQR2R8hSBCTX7mZt4sKwCHrxsNg69uWU5QXIotTu4jDnKSwZRjg/ng/zhBpSBDAhglQeoCRTa5nOmFdWUMstE88ccwniRs0b8gZmqclapFZI46eAO4K+gv5Y0N7QIS4J3cZG2QB2PcQoOLAlt8ak6BPCIhimBIE=; 24:X+/mFswyY+BOG6AN4KQc7XSuft+QY7yli7to83S/axz2hZdBFSVckMAv5/KbcvOiKkvx70GQOu81o+LhlHvsM3uI0fMrwdjtVdMDxvBQzEk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0729; 7:8+jT0d3M+QxMEXWSnuaxbHAI/Qyw9E8s+4+qU2NvAYtGCLYt/zwKJnhTH6o78llHUfEHc3UWZJe4dEsBZA/V1xDR3puyNPoGAUQSueOCMz1V4N+73z7pApFow2mTzHWRtweymK5tI3YXV/uJ87x86QXTRyMiyo6BaLwxdsLBofSrxu3JDJJbnxPfMDCQSeQNmFkRBdQsUHkBCs9BCEVe/JdJLam5mzke/rqC8pnb8tGjzEUx/7pn8T8WzZ/QdXuIKhAK+i8oipO3FmLMp6Dnr/isW5N1AS2Wx9bOzYAcn8tiJaJIead38uz1jWB4Qrn+ceNryg3ce83AJ+Kvs5lJ/MwvcxtKihIrfy47L7DFaJI= X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2016 21:57:49.1249 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR10MB0729 Archived-At: Cc: "ccamp@ietf.org" , "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 21:57:56 -0000 --_000_4dfbb368423649d88f9bcf6a07af062esvex13prd1infineracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBhZ3JlZSBpdCBzaG91bGQgbGV2ZXJhZ2UgUkZDIDcxMzkgYXMgbXVjaCBhcyBwb3NzaWJs ZSBhbmQgZm9sbG93IHNpbWlsYXIgYXBwcm9hY2guICBUbyBiZWdpbiB3aXRoIHNob3VsZCBzdGFy dCB3aXRoIHVzZSBjYXNlcywgcmVxdWlyZW1lbnRzLCBhbmQgbmVjZXNzYXJ5IHNvbHV0aW9ucyAo R01QTFMgc2lnbmFsaW5nIGFuZCByZXF1aXJlZCBleHRlbnNpb24pLg0KDQpJZnRla2hhcg0KRnJv bTogRGlldGVyIEJlbGxlciBbbWFpbHRvOkRpZXRlci5CZWxsZXJAbm9raWEuY29tXQ0KU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAyMywgMjAxNiA4OjUwIEFNDQpUbzogd2FuZy5xaWxlaUB6dGUu Y29tLmNuOyBHZXJ0IEdyYW1tZWwNCkNjOiBjY2FtcEBpZXRmLm9yZzsgaHV1YmF0d29ya0BnbWFp bC5jb20NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0K SGkgYWxsLA0KDQpJIHdvdWxkIHN1Ym1pdCB0aGF0IHdlIG5lZWQgYSBkb2N1bWVudCBzaW1pbGFy IHRvIFJGQyA3MTM5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTM5PiAoR01QTFMg U2lnbmFsaW5nIEV4dGVuc2lvbnMgZm9yIENvbnRyb2wgb2YgRXZvbHZpbmcgRy43MDkgT3B0aWNh bCBUcmFuc3BvcnQNCk5ldHdvcmtzKSBmb3IgdGhlIG5ldyBPRFVDbiBzaWduYWwgdHlwZXMuDQoN ClJGQyA3MTM5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTM5PiBjb250YWlucyBz dWZmaWNpZW50IGluZm9ybWF0aW9uIGFuZCBkZXNjcmlwdGlvbnMgcmVnYXFyZGluZyB0aGUgbmV3 IEcuNzA5IHNpZ25hbCB0eXBlcyBpbnRyb2R1Y2VkIGluIHRoZSBGZWIgMjAxMiByZXZpc2lvbiBv ZiBHLjcwOS4NCg0KSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHRha2UgYSBkaWZmZXJlbnQgYXBw cm9hY2ggZm9yIHRoZSBsYXRlc3QgMjAxNiBldm9sdXRpb24gb2YgRy43MDkuDQoNCg0KVGhhbmtz LA0KRGlldGVyDQpPbiAyMy4xMS4yMDE2IDE2OjM4LCB3YW5nLnFpbGVpQHp0ZS5jb20uY248bWFp bHRvOndhbmcucWlsZWlAenRlLmNvbS5jbj4gd3JvdGU6DQpIaSBHZXJ0LA0KDQpUaGFua3MgZm9y IHlvdXIgY29tbWVudHMuIEZvbGxvd2luZyBpcyBteSBhbnN3ZXIgdG8geW91ciBwcmV2aW91cyBt YWlsIGFuZCB0aGlzIG9uZS4NCg0KKDEpLCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHlvdXIgcHJl dmlvdXMgbWFpbC4gSSB0aGluayB5b3UgYWxyZWFkeSBoYXZlIG1hbnkgb2YgdGhlbSBzb2x2ZWQu IE9EVUNuIGhhcyBhbG1vc3QgdGhlIHNhbWUgb3ZlcmhlYWQgYXMgdGhhdCBvZiBPRFVrLCBzbyBJ IGRvbid0IHRoaW5rIHNvbWUgbWVjaGFuaXNtcyBvZiBPRFVDbiAoZS5nLiwgT0FNIGV0YykgZGlm ZmVyIGZyb20gdGhvc2Ugb2YgT0RVay4gSW4gdGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNo b3VsZCBtYWlubHkgcGF5IGF0dGVudGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZm ZXJlbmNlIHdpdGggT0RVayBub3csIHN1Y2ggYXMgbGF5ZXIgbW9kZWwgb2YgT0RVQ24gYW5kIHNl dHVwIG9mIE9EVUNuIGNvbm5lY3Rpb24uDQoNCigyKSwgQWJvdXQgdGhlIHF1ZXN0aW9ucyBpbiB0 aGUgc2Vjb25kIGl0ZW1zIG9mIHRoaXMgdGhyZWFkLiBJIHRoaW5rIGl0J3Mgb3V0IG9mIHRoZSBz Y29wZSBvZiBDQ0FNUC4gSSBjYW4ndCBnaXZlIGEgZGVmaW5pdGUgYW5zd2VyIHRvIHRoZXNlIHF1 ZXN0aW9ucy4NCg0KKDMpLCBDb250cm9sIG9mIG9wdGljYWwgbmV0d29yayBpcyBvdXQgb2YgdGhl IHNjb3BlIG9mIGN1cnJlbnQgT0RVQ24gZG9jdW1lbnQuIFdlIHdpbGwgbm90IGludm9sdmUgdGhp cyBwYXJ0IGluLiBBbHNvIEkgc3VnZ2VzdCB5b3UgdGFrZSBhIGxvb2sgYXQgUkZDNzY5OCwgd2hp Y2ggbWFpbmx5IGZvY3VzIG9uIHRoZSBjb250cm9sIG9mIGZsZXhpYmxlIGdyaWQgbmV0d29yay4N Cg0KVGhhbmtzDQpRaWxlaQ0KDQoNCkdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+ PG1haWx0bzpnZ3JhbW1lbEBqdW5pcGVyLm5ldD4NCuWPkeS7tuS6ujogICJDQ0FNUCIgPGNjYW1w LWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDE2 LzExLzIzIDIxOjAxDQoNCuaUtuS7tuS6ug0KDQpEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+PG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tPiwgImNjYW1wQGlldGYub3JnIjxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IDxjY2FtcEBp ZXRmLm9yZz48bWFpbHRvOmNjYW1wQGlldGYub3JnPiwNCg0K5oqE6YCBDQoNCiJodXViYXR3b3Jr QGdtYWlsLmNvbSI8bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiA8aHV1YmF0d29ya0BnbWFp bC5jb20+PG1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4NCg0K5Li76aKYDQoNClJlOiBbQ0NB TVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KRGFuaWVsZSwgQXV0 aG9ycywNCg0KQWZ0ZXIgb3VyIGluaXRpYWwgZW1haWwgZXhjaGFuZ2UgSSB0b29rIGEgbW9yZSBk ZXRhaWxlZCBsb29rIGluIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkuIEluIGVzc2VuY2UsIHRo ZSAyMDE2IHZlcnNpb24gb2YgRy43MDkgd291bGQgaW1wYWN0IGNvbnRyb2wgcGxhbmUgd29yayBm b3IgRy43MDkgKFJGQzcxMzkpIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYxNjMpLiBUaGUgY29t cGxleCBuYXR1cmUgb2YgdGhvc2UgZGVmaW5pdGlvbnMgd2lsbCBjZXJ0YWlubHkgbm90IGJlIGFu IGVhc3ktZ29pbmcgZXh0ZW5zaW9uIGFzIGl0IGhhZCBiZWVuIGVudmlzYWdlZCBzbyBmYXIuIFdy aXRpbmcgYSDigJxsaXR0bGUgcGllY2Ugb2YgdGV4dOKAnSBsb29rcyB0byBtZSBsaWtlIGEg4oCc bGl0dGxlIGJpdCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gSWYgdGhlIFdHIGludGVuZHMgdG8gd29y ayBvbiB0aGUgc3ViamVjdCwgbXkgcGxlZGdlIHdvdWxkIGJlIHRvIHN0YXJ0IGZyb20gYSBmcmFt ZXdvcmsgZG9jdW1lbnQgdG8gY2FwdHVyZSB0aGUgbmV3IGNvbmNlcHRzIGJlZm9yZSBkZWZpbmlu ZyBwcm90b2NvbCBleHRlbnNpb25zLg0KDQpCZXN0DQoNCkdlcnQNCg0KDQpCZWxvdyBhIGxpc3Qg b2Ygb2JzZXJ2YXRpb25zIHRoYXQgaW5mbHVlbmNlZCB0aGlzIHZpZXc6DQoxLiAgICAgICBPUFVD biwgT0RVQ24gYW5kIE9UVUNuIGFyZSBuZXcgYW5kIHRoZSBsYXllcmluZyByZWxhdGlvbnNoaXAg dG8gdGhlIGZvcm1lciBzdHJ1Y3R1cmUgaXMgYSBiaXQgc3VycHJpc2luZywgYXMgdGhlIGRpc2N1 c3Npb24gb24gdGhlIGxpc3QgKHNlZSBiZWxvdykgc2hvd2VkLiBCZXR0ZXIgdG8gZ2V0IHRoaXMg cmlnaHQgZWFybHkgb24NCjIuICAgICAgIEZpZ3VyZSA3LTEgc2hvd3MgdGhlIE9UTiBtdWx0aXBs ZXhpbmcgYW5kIG1hcHBpbmcgc3RydWN0dXJlcyBidXQgZG9lcyBub3QgaW5kaWNhdGUgaG93IGUu Zy4gYSA0MDBHRSB3b3VsZCBiZSBtYXBwZWQgaW50byB0aGlzIHN0cnVjdHVyZS4gSXQgaXMgbm90 IHN1cnByaXNpbmcgYXMgNDAwR0UgaXMgc3RpbGwgaW4gdGhlIG1ha2luZ3MsIGJ1dCByYWlzZXMg YSBmZXcgcXVlc3Rpb25zIGFib3V0IGhvdyBpdCBpcyBwbGFubmVkIHRvIGJlIG1hcHBlZC4gSG93 ZXZlciBndWlkYW5jZSBmcm9tIFNHMTUgd291bGQgaGVscCB0byBnZXQgdGhlIHByb3RvY29sIGFy Y2hpdGVjdHVyZSBmdXR1cmUgcHJvb2YuDQphLiAgICAgICBEb2VzIGV2ZXJ5IGNsaWVudCBzaWdu YWwgbmVlZCB0byBiZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUg dHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPyDihpIgdGhpcyB3b3VsZCBtZWFuIHRvIGV4 dGVuZCB0aGUgT0RVIHN0cnVjdHVyZSBieSBhbiBPRFU1LDYsNyBldGMuIGZvciBjbGllbnRzID4g MTAwRw0KYi4gICAgICAgV2lsbCBvbmx5IGNsaWVudCBzaWduYWxzIDw9IDEwMEcgbmVlZCB0byBi ZSB3cmFwcGVkIGluIGFuIE9QVWsvT0RVayBiZWZvcmUgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZp YSBhbiBPUFVDbi9PRFVDbj8g4oaSIHRoaXMgd291bGQgbWVhbiB0aGF0IHRoZXJlIHdpbGwgYmUg YSBicmVhayBpbiB0aGUgbWFwcGluZ3MgYXQgYWJvdXQgMTAwRyBzaWduYWxzIGFuZCBubyBPRFU1 LDYsNyB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQNCmMuICAgICAgIFdpbGwgZnV0dXJlIGNsaWVu dHMgYmUgbWFwcGVkIGRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24gYW5kIHRoZSBzcGVjaWFsIGNh c2Ugb2YgMTAwR0XihpJPUFVrL09EVWvihpJPUFVDbi9PRFVDbiB3aWxsIGJlY29tZSBqdXN0IGFu b3RoZXIgb3B0aW9uPyAoTm90ZTogdGhlIGZpZ3VyZSBleHBsaWNpdGx5IGFsbG93cyBmb3IgcHJv cHJpZXRhcnkgbWFwcGluZ3MgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBs aWtlIGEgcHJhY3RpY2FsIHVzZSBjYXNlLCBidXQgaXQgbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlu cyBwcm9yaWV0YXJ5KQ0KMy4gICAgICAgVGhlIHNlY3Rpb24g4oCcNy4xIE1hcHBpbmfigJ0gYW5k IOKAnDcuMiBXYXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleOKAnSBjaGFuZ2VkIGEgYml0IGZy b20gdGhlIDIwMTIgdmVyc2lvbi4gQXMgYWNyb255bXMgaGF2ZSBjaGFuZ2VkIHRvbywgYSAxOjEg Y29tcGFyaXNvbiBpcyBub3QgdG9vIHNpbXBsZS4gVGhlIHRha2Vhd2F5IGlzIHRoYXQgYW4gT1RV IGNhbiBiZSBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoIG9yIHNwcmVhZCBhY3Jvc3Mg c29tZSAoT1RMay5uIGFuZCBPVExDLm4pIHdoaWNoIG1lYW5zIGludmVyc2UgbXVsdGlwbGV4aW5n LiBTbyBmYXIgdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkgb3Ig UkZDNjE2My4NCjQuICAgICAgIEluIFNlY3Rpb24g4oCcNi4xLjEgT1ROIGRpZ2l0YWwgc3RydWN0 dXJl4oCdIGl0IGlzIGV4cGxhaW5lZCB0aGF0IGFuIE9UVWsgY29udGFpbnMgYSBGRUMsIGJ1dCBP VFVDbiBkb2VzIG5vdCwgbGVhdmluZyBpdCB0byB0aGUgaW50ZXJmYWNlIHRvIGFwcGx5IHNvbWUu IFRoaXMgYmFzaWNhbGx5IGNyZWF0ZXMgYSBGRUMgbGF5ZXIgYmVsb3cgdGhlIE9UVUNuIHRoYXQg d2lsbCBub3QgYmUgZGVmaW5lZCBpbiBHLjcwOS4gQSBjb250cm9sIHBsYW5lIHdvdWxkIG5lZWQg dG8gY2hlY2sgY29tcGF0aWJpbGl0eSBvZiB3YXZlbGVuZ3RoLCBtb2R1bGF0aW9uLCBpbnRlcmZh Y2VzIChpLmUuIGhvdyBtYW55IGxhbmVzKSBhbmQgY29tcGF0aWJpbGl0eSBvZiBGRUMsIGFzIHdl bGwgYXMgdXNhZ2Ugb2YgT1RVayB2cyBPVFVDbi4gQWxzbyB0aGlzIGNhc2UgaGFzIG5vdCBiZWVu IGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvciBSRkM2MTYzLg0KNS4gICAgICAgVGhlcmUgaXMgYWxz byBhIG5ldyBPTVMgTVNJIChzZWN0IDE1LjQpIG92ZXJoZWFkIGRlZmluZWQsIHdoaWNoIHByb3Zp ZGVzIGEgbGlzdCBvZiBPQ2ggYW5kIE9UU2lBIGZyZXF1ZW5jeSBzbG90LHBvcnQgbnVtYmVycyBh bmQgYSBsaXN0IG9mIG1lZGlhIGNoYW5uZWxzIChmcmVxdWVuY3kgc2xvdCwgbWVkaWEgY2hhbm5l bCBwb3J0IG51bWJlcnMpIHRvIGRlY29kZSB0aGUgbGFuZXMgY29ycmVjdGx5LiBUaGlzIG1heSBh ZmZlY3QgUkZDNjE2Mw0KNi4gICAgICAgVGhlIHRlcm0g4oCcV2F2ZWxlbmd0aCBEaXZpc2lvbiBN dWx0aXBsZXjigJ0gaW4gdGhlIHNlY3Rpb25zIGFib3ZlIGRvZXNu4oCZdCBpbXBseSBhIHdhdmVs ZW5ndGggY2FuIGJlIHJvdXRlZCB0aHJvdWdoIGEgRFdETSBuZXR3b3JrIHNpbmNlIHdlIGtub3cg dGhhdCBlLmcuIDEwMEcgaW50ZXJmYWNlcyBhcmUgbm90IHlldCBkZWZpbmVkIGJ5IFNHMTUgZm9y IGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucy4gV2l0aG91dCBhbXBsaWZpZXJzLCB0aGUgZGlz dGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2ggRFdETSBpcyBsaWtlbHkgbGltaXRlZCB0byBiZWxvdyA4 MC0xMDBrbS4gSXQgaXMgbm90IHlldCBjbGVhciBieSB3aGVuIHRoaXMgbGltaXRhdGlvbiB3aWxs IGJlIGxpZnRlZCBieSBTRzE1IChzZWUgZHJhZnQtbWFueS1jb2hlcmVudC1kd2RtLWlmLWNvbnRy b2wtMDApLiBBZnRlciBhbGwsIE9UVTQgYmFzZWQgMTAwRyBpbnRlcmZhY2VzIGZvciBhbXBsaWZp ZWQgRFdETSBhcHBsaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhbmQgaGF2ZSBldmVuIGJlZW4gcHJv dmVuIHRvIGJlIGludGVyb3BlcmFibGUgYW1vbmcgbXVsdGlwbGUgdmVuZG9ycyBjb3ZlcmluZyBk aXN0YW5jZXMgPjEwMDBrbS4gIEhvd2V2ZXIsIHRvIHN0YXkgaW4gdGhlIHN0YW5kYXJkcyBmcmFt ZXdvcmsgZm9yIG5vdywgUkZDNjE2MyB3b3VsZCBuZWVkIHRvIGNvbnNpZGVyOg0KYS4gICAgICAg V2hpbGUgYSBPVFVDbiBjYW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQgaW50 byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QgYmUgcm91dGVkIGluIFdTT04g4oaSIG5v IDEwMEcgaW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcu Njk4LjINCmIuICAgICAgIEFuIE9UVUNuIG1heSBiZSBicm9rZW4gZG93biBpbnRvIDQgbGFuZXMg YXQgMjVHIChPVEw0LjQpIGJ1dCBzdGlsbCBjYW7igJl0IGJlIHJvdXRlZCBpbiBXU09OIOKGkiBu byAyNUcgaW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcu Njk4LjINCmMuICAgICAgIEFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93biBpbiBPVEwz LjQgcHJvdmlkaW5nIDQgbGFuZXMgYXQgMTBHIGVhY2gg4oaSIDEwRyBpbnRlcmZhY2VzIGFyZSBh bGxvd2VkIGluIGFtcGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KDQoN Cg0KDQoNCg0KRnJvbTogQ0NBTVAgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpjY2Ft cC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5p ZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVy aWNzc29uLmNvbT4NCkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDIwOjAyDQpUbzog Imh1dWJhdHdvcmtAZ21haWwuY29tIjxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+IDxodXVi YXR3b3JrQGdtYWlsLmNvbT48bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiwgQ0NBTVAgPGNj YW1wQGlldGYub3JnPjxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1Q XSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNClRoYW5rIEh1dWIsDQoNCkF1dGhvcnMsIGlm IHlvdSBjb3VsZCBoYXZlIGEgbGl0dGxlIHBpZWNlIG9mIHRleHQgZGVzY3JpYmluZyB0aGlzIGNv bnNpZGVyYXRpb24gaW4gdGhlIGZyYW1ld29yayBvciBpbiBvbmUgb2YgdGhlIHNvbHV0aW9uIGRv Y3VtZW50cyAoZGVwZW5kaW5nIHdoYXQgYXJlIHRoZSBwbGFucyBmb3IgdGhlIG1lcmdlKSB0aGF0 IHdvdWxkIGJlIGdyZWF0Lg0KDQpUaGFua3MNCkRhbmllbGUNCg0KRnJvbTogSHV1YiB2YW4gSGVs dm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NClNlbnQ6IHZlbmVyZMOsIDE4IG5v dmVtYnJlIDIwMTYgMTk6MzENClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb20+PG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t PjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtD Q0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpEYW5pZWxlLA0KDQpZb3Ugd3JpdGU6 DQpUaGFua3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLg0KDQpZb3UncmUgd2VsY29t ZS4NCg0KDQoNCkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aCBtYWtlIHNl bnNlLg0KDQpJIGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS4NCg0KDQoNClRoZSBvbmUgcHJvcG9z ZWQgYnkgR2VydCBpcyBzdGl0Y2hpbmcgb2YgYW4gT0RVNCBhbmQgT0RVQzEsDQoNClRoaXMgdXNl IGNhc2UgaXMgaW1wb3NzaWJsZS4gQXMgeW91IGNhbiBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3Vy ZSA3LTENCmEgbG93ZXIgb3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBP RFVDMSwgYW5kIHRoaXMNCm1lYW5zIHRoYXQgdGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXll cnMgaW4gdGhlIE9UTi4NCkFuZCBhcmUgaW1wb3NzaWJsZSB0byBzdGl0Y2guDQoNCg0KDQp3aGls ZSB0aGUgb25lIHlvdSBhcmUgZGVzY3JpYmluZyBpcyB0dW5uZWxpbmcgb2YgT0RVNCBvdmVyIGFu IE9EVUMxIHRyYWlsLg0KDQpDb3JyZWN0Lg0KDQoNCg0KVGhleSBib3RoIHNlZW1zIHJlYXNvbmFi bGUgdG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT8NCg0KSSB0cmllZCB0 byBleHBsYWluIGFib3ZlLg0KDQpCZXN0IHJlZ2FyZHMsIEh1dWIuDQoNCg0KDQoNCkZyb206IEND QU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1dWIgdmFu IEhlbHZvb3J0DQpTZW50OiBnaW92ZWTDrCAxNyBub3ZlbWJyZSAyMDE2IDE3OjA2DQpUbzogY2Nh bXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0g T0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpIZWxsbyBHZXJ0LA0KDQpZb3VyIHVzZSBjYXNl IGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3QuDQoNCkluc3RlYWQgb2Y6DQoxLiAgICAgIEEgdXNl IGNhc2UgdG8gY29uc2lkZXIgaXM6DQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KMTAwR0UtLXwt R01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18 LU9EVUMxLUdNUC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAg TkUxICAgICAgICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAg IE5FMw0KDQpJdCBzaG91bGQgYmU6DQogICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCjEw MEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0t T1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0tLS0tLS0tLSsg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAgTkUyICg9R1ct TkUpICAgICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5F MyB0dW5uZWxzIHRoZSBPRFU0Lg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0KDQoNCi0tDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVy eW9uZSBlbHNlLi4uX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDQ0FN UCBtYWlsaW5nIGxpc3QNCg0KQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg== --_000_4dfbb368423649d88f9bcf6a07af062esvex13prd1infineracom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6aW5oZXJpdDsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzXDAwMERcMDAwQSAgICAgICAgTmV3IFJvbWFuIjsNCglw YW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1pY3Jvc29mdCBKaGVuZ0hlaSI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaWNyb3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA TVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmdyZXkNCgl7bXNvLXN0eWxlLW5hbWU6Z3JleTt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj azt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+WWVzLCBhZ3JlZSBpdCBzaG91bGQgbGV2ZXJhZ2UgUkZDIDcxMzkgYXMgbXVj aCBhcyBwb3NzaWJsZSBhbmQgZm9sbG93IHNpbWlsYXIgYXBwcm9hY2guJm5ic3A7IFRvIGJlZ2lu IHdpdGggc2hvdWxkIHN0YXJ0IHdpdGggdXNlIGNhc2VzLCByZXF1aXJlbWVudHMsIGFuZCBuZWNl c3NhcnkNCiBzb2x1dGlvbnMgKEdNUExTIHNpZ25hbGluZyBhbmQgcmVxdWlyZWQgZXh0ZW5zaW9u KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklmdGVraGFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaWV0ZXIgQmVsbGVyIFtt YWlsdG86RGlldGVyLkJlbGxlckBub2tpYS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBOb3ZlbWJlciAyMywgMjAxNiA4OjUwIEFNPGJyPg0KPGI+VG86PC9iPiB3YW5nLnFpbGVp QHp0ZS5jb20uY247IEdlcnQgR3JhbW1lbDxicj4NCjxiPkNjOjwvYj4gY2NhbXBAaWV0Zi5vcmc7 IGh1dWJhdHdvcmtAZ21haWwuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIE9E VTQgYW5kIE9EVUNuIGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIGFsbCw8YnI+DQo8 YnI+DQpJIHdvdWxkIHN1Ym1pdCB0aGF0IHdlIG5lZWQgYSBkb2N1bWVudCBzaW1pbGFyIHRvIDxz cGFuIGNsYXNzPSJncmV5Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzEzOSI+UkZDIDcxMzk8L2E+IChHTVBMUyBTaWduYWxpbmcgRXh0ZW5zaW9ucyBmb3IgQ29udHJv bCBvZiBFdm9sdmluZyBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydDwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0iZ3JleSI+TmV0d29ya3MpIGZvciB0aGUgbmV3IE9EVUNuIHNpZ25hbCB0eXBlcy4gPC9z cGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJncmV5Ij48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzEzOSI+UkZDIDcxMzk8L2E+PC9zcGFuPiBjb250YWlucyBzdWZm aWNpZW50IGluZm9ybWF0aW9uIGFuZCBkZXNjcmlwdGlvbnMgcmVnYXFyZGluZyB0aGUgbmV3IEcu NzA5IHNpZ25hbCB0eXBlcyBpbnRyb2R1Y2VkIGluIHRoZSBGZWIgMjAxMiByZXZpc2lvbiBvZiBH LjcwOS4NCjxicj4NCjxicj4NCkkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB0YWtlIGEgZGlmZmVy ZW50IGFwcHJvYWNoIGZvciB0aGUgbGF0ZXN0IDIwMTYgZXZvbHV0aW9uIG9mIEcuNzA5Ljxicj4N Cjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpEaWV0ZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMy4xMS4yMDE2IDE2OjM4LCA8YSBocmVmPSJtYWlsdG86 d2FuZy5xaWxlaUB6dGUuY29tLmNuIj4NCndhbmcucWlsZWlAenRlLmNvbS5jbjwvYT4gd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBHZXJ0LDwv c3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyBmb3Ig eW91ciBjb21tZW50cy4gRm9sbG93aW5nIGlzIG15IGFuc3dlciB0byB5b3VyIHByZXZpb3VzIG1h aWwgYW5kIHRoaXMgb25lLjwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPigxKSwgQWJvdXQgdGhlIHF1ZXN0aW9ucyBpbiB5b3VyIHByZXZpb3VzIG1haWwuIEkg dGhpbmsgeW91IGFscmVhZHkgaGF2ZSBtYW55IG9mIHRoZW0gc29sdmVkLiBPRFVDbiBoYXMgYWxt b3N0IHRoZSBzYW1lIG92ZXJoZWFkIGFzIHRoYXQgb2YgT0RVaywgc28gSSBkb24ndCB0aGluayBz b21lIG1lY2hhbmlzbXMgb2YgT0RVQ24gKGUuZy4sDQogT0FNIGV0YykgZGlmZmVyIGZyb20gdGhv c2Ugb2YgT0RVay4gSW4gdGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNob3VsZCBtYWlubHkg cGF5IGF0dGVudGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZmZXJlbmNlIHdpdGgg T0RVayBub3csIHN1Y2ggYXMgbGF5ZXIgbW9kZWwgb2YgT0RVQ24gYW5kIHNldHVwIG9mIE9EVUNu IGNvbm5lY3Rpb24uPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+KDIpLCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHRoZSBzZWNvbmQgaXRlbXMgb2YgdGhpcyB0 aHJlYWQuIEkgdGhpbmsgaXQncyBvdXQgb2YgdGhlIHNjb3BlIG9mIENDQU1QLiBJIGNhbid0IGdp dmUgYSBkZWZpbml0ZSBhbnN3ZXIgdG8gdGhlc2UgcXVlc3Rpb25zLg0KPC9zcGFuPjxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPigzKSwgQ29udHJvbCBvZiBvcHRpY2FsIG5l dHdvcmsgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBjdXJyZW50IE9EVUNuIGRvY3VtZW50LiBXZSB3 aWxsIG5vdCBpbnZvbHZlIHRoaXMgcGFydCBpbi4gQWxzbyBJIHN1Z2dlc3QgeW91IHRha2UgYSBs b29rIGF0IFJGQzc2OTgsIHdoaWNoIG1haW5seSBmb2N1cyBvbiB0aGUgY29udHJvbCBvZg0KIGZs ZXhpYmxlIGdyaWQgbmV0d29yay48L3NwYW4+IDxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlRoYW5rczwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ UWlsZWk8YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAw JSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjM2JSIg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDozNi4wJTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0 IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+R2VydCBHcmFtbWVsDQo8YSBocmVmPSJtYWlsdG86Z2dyYW1tZWxAanVuaXBlci5uZXQiPiZs dDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8L2E+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPg0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogJm5ic3A7 JnF1b3Q7Q0NBTVAmcXVvdDsNCjxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn Ij4mbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+PC9zcGFuPiA8bzpwPg0KPC9vOnA+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDE2LzExLzIzIDIxOjAxPC9zcGFu Pg0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyUiIHZhbGlnbj0idG9wIiBz dHlsZT0id2lkdGg6NjMuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7 Ij7mlLbku7bkuro8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhbmllbGUgQ2VjY2FyZWxsaQ0KPGEg aHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPiZsdDtkYW5pZWxl LmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzwvYT4sDQo8YSBocmVmPSJtYWlsdG86Y2NhbXBA aWV0Zi5vcmciPiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86 Y2NhbXBAaWV0Zi5vcmciPg0KJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvYT4sIDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5oqE6YCBPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPiZx dW90O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7PC9hPg0KPGEgaHJlZj0ibWFpbHRvOmh1dWJh dHdvcmtAZ21haWwuY29tIj4mbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PC9hPjwvc3Bhbj4g PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS4uzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBKaGVuZ0hlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7popg8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAu NzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L3NwYW4+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0 Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGFuaWVsZSwgQXV0aG9ycyw8L3NwYW4+DQo8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZnRlciBvdXIgaW5pdGlhbCBlbWFpbCBleGNoYW5nZSBJIHRv b2sgYSBtb3JlIGRldGFpbGVkIGxvb2sgaW4gdGhlIDIwMTYgdmVyc2lvbiBvZiBHLjcwOS4gSW4g ZXNzZW5jZSwgdGhlIDIwMTYgdmVyc2lvbiBvZiBHLjcwOSB3b3VsZCBpbXBhY3QgY29udHJvbCBw bGFuZSB3b3JrIGZvciBHLjcwOSAoUkZDNzEzOSkgYXMgd2VsbCBhcw0KIGZvciBXU09OIChSRkM2 MTYzKS4gVGhlIGNvbXBsZXggbmF0dXJlIG9mIHRob3NlIGRlZmluaXRpb25zIHdpbGwgY2VydGFp bmx5IG5vdCBiZSBhbiBlYXN5LWdvaW5nIGV4dGVuc2lvbiBhcyBpdCBoYWQgYmVlbiBlbnZpc2Fn ZWQgc28gZmFyLiBXcml0aW5nIGEg4oCcbGl0dGxlIHBpZWNlIG9mIHRleHTigJ0gbG9va3MgdG8g bWUgbGlrZSBhIOKAnGxpdHRsZSBiaXQgb2YgdW5kZXJzdGF0ZW1lbnTigJ0uIElmIHRoZSBXRyBp bnRlbmRzIHRvIHdvcmsgb24gdGhlDQogc3ViamVjdCwgbXkgcGxlZGdlIHdvdWxkIGJlIHRvIHN0 YXJ0IGZyb20gYSBmcmFtZXdvcmsgZG9jdW1lbnQgdG8gY2FwdHVyZSB0aGUgbmV3IGNvbmNlcHRz IGJlZm9yZSBkZWZpbmluZyBwcm90b2NvbCBleHRlbnNpb25zLjwvc3Bhbj4NCjxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkJlc3Q8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkdl cnQ8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZWxvdyBhIGxpc3Qgb2Ygb2JzZXJ2YXRpb25z IHRoYXQgaW5mbHVlbmNlZCB0aGlzIHZpZXc6PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4xLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPUFVDbiwgT0RVQ24gYW5kIE9U VUNuIGFyZSBuZXcgYW5kIHRoZSBsYXllcmluZyByZWxhdGlvbnNoaXAgdG8gdGhlIGZvcm1lciBz dHJ1Y3R1cmUgaXMgYSBiaXQgc3VycHJpc2luZywgYXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxp c3QgKHNlZSBiZWxvdykgc2hvd2VkLiBCZXR0ZXIgdG8gZ2V0IHRoaXMgcmlnaHQgZWFybHkNCiBv bjwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yLiAmbmJzcDsgJm5i c3A7ICZuYnNwOyBGaWd1cmUgNy0xIHNob3dzIHRoZSBPVE4gbXVsdGlwbGV4aW5nIGFuZCBtYXBw aW5nIHN0cnVjdHVyZXMgYnV0IGRvZXMgbm90IGluZGljYXRlIGhvdyBlLmcuIGEgNDAwR0Ugd291 bGQgYmUgbWFwcGVkIGludG8gdGhpcyBzdHJ1Y3R1cmUuIEl0IGlzIG5vdCBzdXJwcmlzaW5nIGFz IDQwMEdFIGlzIHN0aWxsIGluIHRoZQ0KIG1ha2luZ3MsIGJ1dCByYWlzZXMgYSBmZXcgcXVlc3Rp b25zIGFib3V0IGhvdyBpdCBpcyBwbGFubmVkIHRvIGJlIG1hcHBlZC4gSG93ZXZlciBndWlkYW5j ZSBmcm9tIFNHMTUgd291bGQgaGVscCB0byBnZXQgdGhlIHByb3RvY29sIGFyY2hpdGVjdHVyZSBm dXR1cmUgcHJvb2YuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5h LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEb2VzIGV2ZXJ5IGNsaWVudCBzaWduYWwgbmVlZCB0byBi ZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0ZWQg dmlhIGFuIE9QVUNuL09EVUNuPw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O2luaGVyaXQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKGkjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0aGlzIHdvdWxkIG1lYW4gdG8gZXh0 ZW5kIHRoZSBPRFUgc3RydWN0dXJlIGJ5IGFuIE9EVTUsNiw3IGV0Yy4gZm9yIGNsaWVudHMgJmd0 OyAxMDBHPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5iLiAmbmJz cDsgJm5ic3A7ICZuYnNwOyBXaWxsIG9ubHkgY2xpZW50IHNpZ25hbHMgJmx0Oz0gMTAwRyBuZWVk IHRvIGJlIHdyYXBwZWQgaW4gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0 ZWQgdmlhIGFuIE9QVUNuL09EVUNuPw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O2luaGVyaXQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKG kjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0aGlzIHdvdWxkIG1lYW4gdGhh dCB0aGVyZSB3aWxsIGJlIGEgYnJlYWsgaW4gdGhlIG1hcHBpbmdzIGF0IGFib3V0IDEwMEcgc2ln bmFscyBhbmQgbm8gT0RVNSw2LDcgd291bGQgbmVlZCB0byBiZQ0KIGRlZmluZWQ8L3NwYW4+IDxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Yy4gJm5ic3A7ICZuYnNwOyAmbmJzcDsg V2lsbCBmdXR1cmUgY2xpZW50cyBiZSBtYXBwZWQgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiBh bmQgdGhlIHNwZWNpYWwgY2FzZSBvZiAxMDBHRTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtpbmhlcml0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij7ihpI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PUFVrL09EVWs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7aW5oZXJpdCZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oaSPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+T1BVQ24vT0RVQ24NCiB3aWxsIGJlY29tZSBqdXN0IGFub3RoZXIgb3B0aW9uPyAoTm90 ZTogdGhlIGZpZ3VyZSBleHBsaWNpdGx5IGFsbG93cyBmb3IgcHJvcHJpZXRhcnkgbWFwcGluZ3Mg ZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBsaWtlIGEgcHJhY3RpY2FsIHVz ZSBjYXNlLCBidXQgaXQgbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlucyBwcm9yaWV0YXJ5KTwvc3Bh bj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+My4gJm5ic3A7ICZuYnNwOyAm bmJzcDsgVGhlIHNlY3Rpb24g4oCcNy4xIE1hcHBpbmfigJ0gYW5kIOKAnDcuMiBXYXZlbGVuZ3Ro IERpdmlzaW9uIE11bHRpcGxleOKAnSBjaGFuZ2VkIGEgYml0IGZyb20gdGhlIDIwMTIgdmVyc2lv bi4gQXMgYWNyb255bXMgaGF2ZSBjaGFuZ2VkIHRvbywgYSAxOjEgY29tcGFyaXNvbiBpcyBub3Qg dG9vIHNpbXBsZS4gVGhlIHRha2Vhd2F5DQogaXMgdGhhdCBhbiBPVFUgY2FuIGJlIG1hcHBlZCBp bnRvIGEgc2luZ2xlIHdhdmVsZW5ndGggb3Igc3ByZWFkIGFjcm9zcyBzb21lIChPVExrLm4gYW5k IE9UTEMubikgd2hpY2ggbWVhbnMgaW52ZXJzZSBtdWx0aXBsZXhpbmcuIFNvIGZhciB0aGlzIGNh c2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvciBSRkM2MTYzLjwvc3Bhbj4N Cjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NC4gJm5ic3A7ICZuYnNwOyAmbmJz cDsgSW4gU2VjdGlvbiDigJw2LjEuMSBPVE4gZGlnaXRhbCBzdHJ1Y3R1cmXigJ0gaXQgaXMgZXhw bGFpbmVkIHRoYXQgYW4gT1RVayBjb250YWlucyBhIEZFQywgYnV0IE9UVUNuIGRvZXMgbm90LCBs ZWF2aW5nIGl0IHRvIHRoZSBpbnRlcmZhY2UgdG8gYXBwbHkgc29tZS4gVGhpcyBiYXNpY2FsbHkg Y3JlYXRlcyBhIEZFQyBsYXllcg0KIGJlbG93IHRoZSBPVFVDbiB0aGF0IHdpbGwgbm90IGJlIGRl ZmluZWQgaW4gRy43MDkuIEEgY29udHJvbCBwbGFuZSB3b3VsZCBuZWVkIHRvIGNoZWNrIGNvbXBh dGliaWxpdHkgb2Ygd2F2ZWxlbmd0aCwgbW9kdWxhdGlvbiwgaW50ZXJmYWNlcyAoaS5lLiBob3cg bWFueSBsYW5lcykgYW5kIGNvbXBhdGliaWxpdHkgb2YgRkVDLCBhcyB3ZWxsIGFzIHVzYWdlIG9m IE9UVWsgdnMgT1RVQ24uIEFsc28gdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkDQog aW4gUkZDNzEzOSBvciBSRkM2MTYzLjwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij41LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSBpcyBhbHNvIGEgbmV3IE9NUyBN U0kgKHNlY3QgMTUuNCkgb3ZlcmhlYWQgZGVmaW5lZCwgd2hpY2ggcHJvdmlkZXMgYSBsaXN0IG9m IE9DaCBhbmQgT1RTaUEgZnJlcXVlbmN5IHNsb3QscG9ydCBudW1iZXJzIGFuZCBhIGxpc3Qgb2Yg bWVkaWEgY2hhbm5lbHMgKGZyZXF1ZW5jeSBzbG90LCBtZWRpYSBjaGFubmVsDQogcG9ydCBudW1i ZXJzKSB0byBkZWNvZGUgdGhlIGxhbmVzIGNvcnJlY3RseS4gVGhpcyBtYXkgYWZmZWN0IFJGQzYx NjM8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ni4gJm5ic3A7ICZu YnNwOyAmbmJzcDsgVGhlIHRlcm0g4oCcV2F2ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXjigJ0g aW4gdGhlIHNlY3Rpb25zIGFib3ZlIGRvZXNu4oCZdCBpbXBseSBhIHdhdmVsZW5ndGggY2FuIGJl IHJvdXRlZCB0aHJvdWdoIGEgRFdETSBuZXR3b3JrIHNpbmNlIHdlIGtub3cgdGhhdCBlLmcuIDEw MEcgaW50ZXJmYWNlcyBhcmUgbm90IHlldCBkZWZpbmVkDQogYnkgU0cxNSBmb3IgYW1wbGlmaWVk IERXRE0gYXBwbGljYXRpb25zLiBXaXRob3V0IGFtcGxpZmllcnMsIHRoZSBkaXN0YW5jZSBzdXBw b3J0ZWQgYnkgc3VjaCBEV0RNIGlzIGxpa2VseSBsaW1pdGVkIHRvIGJlbG93IDgwLTEwMGttLiBJ dCBpcyBub3QgeWV0IGNsZWFyIGJ5IHdoZW4gdGhpcyBsaW1pdGF0aW9uIHdpbGwgYmUgbGlmdGVk IGJ5IFNHMTUgKHNlZSBkcmFmdC1tYW55LWNvaGVyZW50LWR3ZG0taWYtY29udHJvbC0wMCkuIEFm dGVyIGFsbCwNCiBPVFU0IGJhc2VkIDEwMEcgaW50ZXJmYWNlcyBmb3IgYW1wbGlmaWVkIERXRE0g YXBwbGljYXRpb25zIGFyZSBhdmFpbGFibGUgYW5kIGhhdmUgZXZlbiBiZWVuIHByb3ZlbiB0byBi ZSBpbnRlcm9wZXJhYmxlIGFtb25nIG11bHRpcGxlIHZlbmRvcnMgY292ZXJpbmcgZGlzdGFuY2Vz ICZndDsxMDAwa20uICZuYnNwO0hvd2V2ZXIsIHRvIHN0YXkgaW4gdGhlIHN0YW5kYXJkcyBmcmFt ZXdvcmsgZm9yIG5vdywgUkZDNjE2MyB3b3VsZCBuZWVkIHRvIGNvbnNpZGVyOjwvc3Bhbj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsg V2hpbGUgYSBPVFVDbiBjYW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQgaW50 byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QgYmUgcm91dGVkIGluIFdTT04NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtpbmhlcml0 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7ihpI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gbm8gMTAwRyBpbnRlcmZhY2VzIGluIGFtcGxpZmllZCBEV0RNIG5ldHdvcmtzIGRl ZmluZWQgaW4gRy42OTguMjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Yi4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgQW4gT1RVQ24gbWF5IGJlIGJyb2tlbiBkb3duIGlu dG8gNCBsYW5lcyBhdCAyNUcgKE9UTDQuNCkgYnV0IHN0aWxsIGNhbuKAmXQgYmUgcm91dGVkIGlu IFdTT04NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtpbmhlcml0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7ihpI8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbm8gMjVHIGludGVyZmFjZXMgaW4gYW1wbGlmaWVkIERXRE0g bmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5OC4yPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5jLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbiBPVFUzICg9NDBHKSBjYW4g YmUgYnJva2VuIGRvd24gaW4gT1RMMy40IHByb3ZpZGluZyA0IGxhbmVzIGF0IDEwRyBlYWNoDQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7aW5o ZXJpdCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oaSPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IDEwRyBpbnRlcmZhY2VzIGFyZSBhbGxvd2VkIGluIGFtcGxpZmllZCBEV0RN IG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q0NBTVANCjxhIGhyZWY9Im1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj4mbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZn dDs8L2E+IG9uIGJlaGFsZiBvZiBEYW5pZWxlIENlY2NhcmVsbGkNCjxhIGhyZWY9Im1haWx0bzpk YW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIj4mbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVy aWNzc29uLmNvbSZndDs8L2E+PGI+PGJyPg0KRGF0ZTogPC9iPkZyaWRheSAxOCBOb3ZlbWJlciAy MDE2IGF0IDIwOjAyPGI+PGJyPg0KVG86IDwvYj48YSBocmVmPSJtYWlsdG86aHV1YmF0d29ya0Bn bWFpbC5jb20iPiZxdW90O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7PC9hPiA8YSBocmVmPSJt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPg0KJmx0O2h1dWJhdHdvcmtAZ21haWwuY29tJmd0 OzwvYT4sIENDQU1QIDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Jmx0O2NjYW1wQGll dGYub3JnJmd0OzwvYT48Yj48YnI+DQpTdWJqZWN0OiA8L2I+UmU6IFtDQ0FNUF0gT0RVNCBhbmQg T0RVQ24gZGlzY3Vzc2lvbjwvc3Bhbj4gPGJyPg0KJm5ic3A7IDxicj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VGhhbmsgSHV1Yiw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5BdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBwaWVjZSBvZiB0ZXh0IGRl c2NyaWJpbmcgdGhpcyBjb25zaWRlcmF0aW9uIGluIHRoZSBmcmFtZXdvcmsgb3IgaW4gb25lIG9m IHRoZSBzb2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGluZyB3aGF0IGFyZSB0aGUgcGxhbnMgZm9y IHRoZSBtZXJnZSkgdGhhdCB3b3VsZCBiZQ0KIGdyZWF0Ljwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+VGhhbmtzPC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkRhbmllbGUgJm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEh1dWIgdmFuIEhl bHZvb3J0IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbTwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj48YnI+DQpTZW50OjwvYj4g dmVuZXJkw6wgMTggbm92ZW1icmUgMjAxNiAxOTozMTxiPjxicj4NClRvOjwvYj4gRGFuaWVsZSBD ZWNjYXJlbGxpIDxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t Ij4mbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZndDs8L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT48Yj48YnI+DQpTdWJqZWN0 OjwvYj4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvc3Bhbj4gPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYW5pZWxlLDxicj4N Cjxicj4NCllvdSB3cml0ZTo8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VGhhbmtzIGZvciB0aGUgY2xlYXIgZXhwbGFuYXRpb24gSHV1Yi48L3NwYW4+DQo8YnI+DQo8 YnI+DQpZb3UncmUgd2VsY29tZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90aCBt YWtlIHNlbnNlLg0KPC9zcGFuPjxicj4NCjxicj4NCkkgaGF2ZSB0byBkaXNhZ3JlZSAoYWdhaW4p Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhl IG9uZSBwcm9wb3NlZCBieSBHZXJ0IGlzIHN0aXRjaGluZyBvZiBhbiBPRFU0IGFuZCBPRFVDMSw8 L3NwYW4+DQo8YnI+DQo8YnI+DQpUaGlzIHVzZSBjYXNlIGlzIGltcG9zc2libGUuIEFzIHlvdSBj YW4gc2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1cmUgNy0xIDxicj4NCmEgbG93ZXIgb3JkZXIgT0RV NCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFVDMSwgYW5kIHRoaXMgPGJyPg0KbWVh bnMgdGhhdCB0aGV5IGNvbnN0aXR1dGUgZGlmZmVyZW50IGxheWVycyBpbiB0aGUgT1ROLiA8YnI+ DQpBbmQgYXJlIGltcG9zc2libGUgdG8gc3RpdGNoLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+d2hpbGUgdGhlIG9uZSB5b3UgYXJlIGRlc2NyaWJp bmcgaXMgdHVubmVsaW5nIG9mIE9EVTQgb3ZlciBhbiBPRFVDMSB0cmFpbC48L3NwYW4+DQo8YnI+ DQo8YnI+DQpDb3JyZWN0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+VGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUgc3Rp dGNoaW5nIGlzIG5vdCBmZWFzaWJsZT88L3NwYW4+DQo8YnI+DQo8YnI+DQpJIHRyaWVkIHRvIGV4 cGxhaW4gYWJvdmUuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLCBIdXViLjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzDQogICAgICAgIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g Q0NBTVAgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDgyQkYiPm1haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SHV1YiB2YW4gSGVsdm9vcnQ8Yj48YnI+DQpTZW50OjwvYj4gZ2lv dmVkw6wgMTcgbm92ZW1icmUgMjAxNiAxNzowNjxiPjxicj4NClRvOjwvYj4gPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDgyQkYiPmNjYW1wQGlldGYub3JnPC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxicj4NClN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9zcGFuPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IZWxsbyBH ZXJ0LDxicj4NCjxicj4NCllvdXIgdXNlIGNhc2UgaXMgbm90IGNvbXBsZXRlbHkgY29ycmVjdC48 YnI+DQo8YnI+DQpJbnN0ZWFkIG9mOjwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MS4gJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BIHVzZSBj YXNlIHRvIGNvbnNpZGVyIGlzOjwvc3Bhbj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PC9iPiA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48L2I+DQo8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+MTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQt R01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC18LS0xMDBHRTwvc3Bhbj48L2I+ DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0t LS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0 MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOyAmbmJzcDsNCjwvc3Bhbj48L2I+ PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO05FMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtORTIgKD1HVy1ORSkgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBORTM8L3NwYW4+PC9iPg0KPGJyPg0KPGJyPg0KSXQgc2hvdWxkIGJlOiA8YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0tLS0tJiM0MzsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0t LS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48L2I+DQo8YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+MTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwt T1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0LUdNUC18LS0xMDBHRTwvc3Bhbj48L2I+DQo8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0t LS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0Mzst LS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOyAmbmJzcDsNCjwvc3Bh bj48L2I+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO05FMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtORTIgKD1HVy1ORSkgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBORTM8L3NwYW4+PC9iPjxicj4NCjxicj4NClRoZSBPRFVDMSBmcm9tIE5FMiB0byBO RTMgdHVubmVscyB0aGUgT0RVNC4gPG86cD48L286cD48L3A+DQo8cD5SZWdhcmRzLCBIdXViLiA8 bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyA8YnI+DQombmJzcDsgPG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyA8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0g PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFs d2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVzdCBsaWtlIGV2ZXJ5b25lIGVs c2UuLi48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3R0Pjxicj4NCjx0dD5DQ0FNUCBtYWlsaW5nIGxpc3Q8L3R0Pjxicj4NCjx0dD48YSBocmVmPSJt YWlsdG86Q0NBTVBAaWV0Zi5vcmciPkNDQU1QQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAiPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcDwvc3Bhbj48L3R0PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Q0NBTVAgbWFpbGluZyBsaXN0PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOkNDQU1QQGlldGYub3JnIj5DQ0FN UEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_4dfbb368423649d88f9bcf6a07af062esvex13prd1infineracom_-- From nobody Wed Nov 23 21:57:09 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9823B129453 for ; Wed, 23 Nov 2016 21:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 JVZyZKGkBnoE for ; Wed, 23 Nov 2016 21:57:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D361294AE for ; Wed, 23 Nov 2016 21:57:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVW01992; Thu, 24 Nov 2016 05:56:57 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Nov 2016 05:55:11 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.137]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 24 Nov 2016 13:55:06 +0800 From: "Zhangxian (Xian)" To: Gert Grammel , Daniele Ceccarelli , "ccamp@ietf.org" Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDc0ZUAgAGsY4CAAA5gAIAACPKAgAd2igCAAaANEA== Date: Thu, 24 Nov 2016 05:55:06 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> In-Reply-To: <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.139.68] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF7259FSZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58368129.01CE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.137, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e8ad78ee9974430d678884170e4a5fb8 Archived-At: Cc: "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 05:57:05 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF7259FSZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEdlcnQsDQoNCiAgICAgWWVzOyAgc3RhcnRpbmcgd2l0aCB1bmRlcnN0YW5kaW5nIHRoZSBu ZXcgZmVhdHVyZXMgb2YgdGhlIG5ldyBPVE4gYmVmb3JlIGRpdmluZyBpbnRvIHRoZSBwcm90b2Nv bCBleHRlbnNpb25zIGlzIGRlZmluaXRlbHkgdGhlIHVzdWFsIENDQU1QIHN0eWxlLCDimLouICAg U28sIHdlIHNob3VsZCBub3QgbG9vayBhdCBSRkM3MTM5IHdoaWNoIGlzIHByb3RvY29sIGV4dGVu c2lvbiBSRkMsIGJ1dCByYXRoZXIgUkZDNzA2Mi4NCg0KUmVnYXJkcywNClhpYW4NCg0K5Y+R5Lu2 5Lq6OiBDQ0FNUCBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBHZXJ0IEdy YW1tZWwNCuWPkemAgeaXtumXtDogMjAxNuW5tDEx5pyIMjPml6UgMjE6MDENCuaUtuS7tuS6ujog RGFuaWVsZSBDZWNjYXJlbGxpOyBjY2FtcEBpZXRmLm9yZw0K5oqE6YCBOiBodXViYXR3b3JrQGdt YWlsLmNvbQ0K5Li76aKYOiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoN CkRhbmllbGUsIEF1dGhvcnMsDQoNCkFmdGVyIG91ciBpbml0aWFsIGVtYWlsIGV4Y2hhbmdlIEkg dG9vayBhIG1vcmUgZGV0YWlsZWQgbG9vayBpbiB0aGUgMjAxNiB2ZXJzaW9uIG9mIEcuNzA5LiBJ biBlc3NlbmNlLCB0aGUgMjAxNiB2ZXJzaW9uIG9mIEcuNzA5IHdvdWxkIGltcGFjdCBjb250cm9s IHBsYW5lIHdvcmsgZm9yIEcuNzA5IChSRkM3MTM5KSBhcyB3ZWxsIGFzIGZvciBXU09OIChSRkM2 MTYzKS4gVGhlIGNvbXBsZXggbmF0dXJlIG9mIHRob3NlIGRlZmluaXRpb25zIHdpbGwgY2VydGFp bmx5IG5vdCBiZSBhbiBlYXN5LWdvaW5nIGV4dGVuc2lvbiBhcyBpdCBoYWQgYmVlbiBlbnZpc2Fn ZWQgc28gZmFyLiBXcml0aW5nIGEg4oCcbGl0dGxlIHBpZWNlIG9mIHRleHTigJ0gbG9va3MgdG8g bWUgbGlrZSBhIOKAnGxpdHRsZSBiaXQgb2YgdW5kZXJzdGF0ZW1lbnTigJ0uIElmIHRoZSBXRyBp bnRlbmRzIHRvIHdvcmsgb24gdGhlIHN1YmplY3QsIG15IHBsZWRnZSB3b3VsZCBiZSB0byBzdGFy dCBmcm9tIGEgZnJhbWV3b3JrIGRvY3VtZW50IHRvIGNhcHR1cmUgdGhlIG5ldyBjb25jZXB0cyBi ZWZvcmUgZGVmaW5pbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCg0KQmVzdA0KDQpHZXJ0DQoNCg0K QmVsb3cgYSBsaXN0IG9mIG9ic2VydmF0aW9ucyB0aGF0IGluZmx1ZW5jZWQgdGhpcyB2aWV3Og0K DQoxLiAgICAgICBPUFVDbiwgT0RVQ24gYW5kIE9UVUNuIGFyZSBuZXcgYW5kIHRoZSBsYXllcmlu ZyByZWxhdGlvbnNoaXAgdG8gdGhlIGZvcm1lciBzdHJ1Y3R1cmUgaXMgYSBiaXQgc3VycHJpc2lu ZywgYXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgKHNlZSBiZWxvdykgc2hvd2VkLiBCZXR0 ZXIgdG8gZ2V0IHRoaXMgcmlnaHQgZWFybHkgb24NCg0KMi4gICAgICAgRmlndXJlIDctMSBzaG93 cyB0aGUgT1ROIG11bHRpcGxleGluZyBhbmQgbWFwcGluZyBzdHJ1Y3R1cmVzIGJ1dCBkb2VzIG5v dCBpbmRpY2F0ZSBob3cgZS5nLiBhIDQwMEdFIHdvdWxkIGJlIG1hcHBlZCBpbnRvIHRoaXMgc3Ry dWN0dXJlLiBJdCBpcyBub3Qgc3VycHJpc2luZyBhcyA0MDBHRSBpcyBzdGlsbCBpbiB0aGUgbWFr aW5ncywgYnV0IHJhaXNlcyBhIGZldyBxdWVzdGlvbnMgYWJvdXQgaG93IGl0IGlzIHBsYW5uZWQg dG8gYmUgbWFwcGVkLiBIb3dldmVyIGd1aWRhbmNlIGZyb20gU0cxNSB3b3VsZCBoZWxwIHRvIGdl dCB0aGUgcHJvdG9jb2wgYXJjaGl0ZWN0dXJlIGZ1dHVyZSBwcm9vZi4NCg0KYS4gICAgICAgRG9l cyBldmVyeSBjbGllbnQgc2lnbmFsIG5lZWQgdG8gYmUgd3JhcHBlZCBpbnRvIGFuIE9QVWsvT0RV ayBiZWZvcmUgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8gLS0+IHRo aXMgd291bGQgbWVhbiB0byBleHRlbmQgdGhlIE9EVSBzdHJ1Y3R1cmUgYnkgYW4gT0RVNSw2LDcg ZXRjLiBmb3IgY2xpZW50cyA+IDEwMEcNCg0KYi4gICAgICAgV2lsbCBvbmx5IGNsaWVudCBzaWdu YWxzIDw9IDEwMEcgbmVlZCB0byBiZSB3cmFwcGVkIGluIGFuIE9QVWsvT0RVayBiZWZvcmUgaXQg Y2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8gLS0+IHRoaXMgd291bGQgbWVh biB0aGF0IHRoZXJlIHdpbGwgYmUgYSBicmVhayBpbiB0aGUgbWFwcGluZ3MgYXQgYWJvdXQgMTAw RyBzaWduYWxzIGFuZCBubyBPRFU1LDYsNyB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQNCg0KYy4g ICAgICAgV2lsbCBmdXR1cmUgY2xpZW50cyBiZSBtYXBwZWQgZGlyZWN0bHkgaW50byBPUFVDbi9P RFVDbiBhbmQgdGhlIHNwZWNpYWwgY2FzZSBvZiAxMDBHRS0tPk9QVWsvT0RVay0tPk9QVUNuL09E VUNuIHdpbGwgYmVjb21lIGp1c3QgYW5vdGhlciBvcHRpb24/IChOb3RlOiB0aGUgZmlndXJlIGV4 cGxpY2l0bHkgYWxsb3dzIGZvciBwcm9wcmlldGFyeSBtYXBwaW5ncyBkaXJlY3RseSBpbnRvIE9Q VUNuL09EVUNuIHdoaWNoIGxvb2tzIGxpa2UgYSBwcmFjdGljYWwgdXNlIGNhc2UsIGJ1dCBpdCBs b29rcyBvZGQgdGhhdCBpdCByZW1haW5zIHByb3JpZXRhcnkpDQoNCjMuICAgICAgIFRoZSBzZWN0 aW9uIOKAnDcuMSBNYXBwaW5n4oCdIGFuZCDigJw3LjIgV2F2ZWxlbmd0aCBEaXZpc2lvbiBNdWx0 aXBsZXjigJ0gY2hhbmdlZCBhIGJpdCBmcm9tIHRoZSAyMDEyIHZlcnNpb24uIEFzIGFjcm9ueW1z IGhhdmUgY2hhbmdlZCB0b28sIGEgMToxIGNvbXBhcmlzb24gaXMgbm90IHRvbyBzaW1wbGUuIFRo ZSB0YWtlYXdheSBpcyB0aGF0IGFuIE9UVSBjYW4gYmUgbWFwcGVkIGludG8gYSBzaW5nbGUgd2F2 ZWxlbmd0aCBvciBzcHJlYWQgYWNyb3NzIHNvbWUgKE9UTGsubiBhbmQgT1RMQy5uKSB3aGljaCBt ZWFucyBpbnZlcnNlIG11bHRpcGxleGluZy4gU28gZmFyIHRoaXMgY2FzZSBoYXMgbm90IGJlZW4g Y29uc2lkZXJlZCBpbiBSRkM3MTM5IG9yIFJGQzYxNjMuDQoNCjQuICAgICAgIEluIFNlY3Rpb24g 4oCcNi4xLjEgT1ROIGRpZ2l0YWwgc3RydWN0dXJl4oCdIGl0IGlzIGV4cGxhaW5lZCB0aGF0IGFu IE9UVWsgY29udGFpbnMgYSBGRUMsIGJ1dCBPVFVDbiBkb2VzIG5vdCwgbGVhdmluZyBpdCB0byB0 aGUgaW50ZXJmYWNlIHRvIGFwcGx5IHNvbWUuIFRoaXMgYmFzaWNhbGx5IGNyZWF0ZXMgYSBGRUMg bGF5ZXIgYmVsb3cgdGhlIE9UVUNuIHRoYXQgd2lsbCBub3QgYmUgZGVmaW5lZCBpbiBHLjcwOS4g QSBjb250cm9sIHBsYW5lIHdvdWxkIG5lZWQgdG8gY2hlY2sgY29tcGF0aWJpbGl0eSBvZiB3YXZl bGVuZ3RoLCBtb2R1bGF0aW9uLCBpbnRlcmZhY2VzIChpLmUuIGhvdyBtYW55IGxhbmVzKSBhbmQg Y29tcGF0aWJpbGl0eSBvZiBGRUMsIGFzIHdlbGwgYXMgdXNhZ2Ugb2YgT1RVayB2cyBPVFVDbi4g QWxzbyB0aGlzIGNhc2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvciBSRkM2 MTYzLg0KDQo1LiAgICAgICBUaGVyZSBpcyBhbHNvIGEgbmV3IE9NUyBNU0kgKHNlY3QgMTUuNCkg b3ZlcmhlYWQgZGVmaW5lZCwgd2hpY2ggcHJvdmlkZXMgYSBsaXN0IG9mIE9DaCBhbmQgT1RTaUEg ZnJlcXVlbmN5IHNsb3QscG9ydCBudW1iZXJzIGFuZCBhIGxpc3Qgb2YgbWVkaWEgY2hhbm5lbHMg KGZyZXF1ZW5jeSBzbG90LCBtZWRpYSBjaGFubmVsIHBvcnQgbnVtYmVycykgdG8gZGVjb2RlIHRo ZSBsYW5lcyBjb3JyZWN0bHkuIFRoaXMgbWF5IGFmZmVjdCBSRkM2MTYzDQoNCjYuICAgICAgIFRo ZSB0ZXJtIOKAnFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV44oCdIGluIHRoZSBzZWN0aW9u cyBhYm92ZSBkb2VzbuKAmXQgaW1wbHkgYSB3YXZlbGVuZ3RoIGNhbiBiZSByb3V0ZWQgdGhyb3Vn aCBhIERXRE0gbmV0d29yayBzaW5jZSB3ZSBrbm93IHRoYXQgZS5nLiAxMDBHIGludGVyZmFjZXMg YXJlIG5vdCB5ZXQgZGVmaW5lZCBieSBTRzE1IGZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlv bnMuIFdpdGhvdXQgYW1wbGlmaWVycywgdGhlIGRpc3RhbmNlIHN1cHBvcnRlZCBieSBzdWNoIERX RE0gaXMgbGlrZWx5IGxpbWl0ZWQgdG8gYmVsb3cgODAtMTAwa20uIEl0IGlzIG5vdCB5ZXQgY2xl YXIgYnkgd2hlbiB0aGlzIGxpbWl0YXRpb24gd2lsbCBiZSBsaWZ0ZWQgYnkgU0cxNSAoc2VlIGRy YWZ0LW1hbnktY29oZXJlbnQtZHdkbS1pZi1jb250cm9sLTAwKS4gQWZ0ZXIgYWxsLCBPVFU0IGJh c2VkIDEwMEcgaW50ZXJmYWNlcyBmb3IgYW1wbGlmaWVkIERXRE0gYXBwbGljYXRpb25zIGFyZSBh dmFpbGFibGUgYW5kIGhhdmUgZXZlbiBiZWVuIHByb3ZlbiB0byBiZSBpbnRlcm9wZXJhYmxlIGFt b25nIG11bHRpcGxlIHZlbmRvcnMgY292ZXJpbmcgZGlzdGFuY2VzID4xMDAwa20uICBIb3dldmVy LCB0byBzdGF5IGluIHRoZSBzdGFuZGFyZHMgZnJhbWV3b3JrIGZvciBub3csIFJGQzYxNjMgd291 bGQgbmVlZCB0byBjb25zaWRlcjoNCg0KYS4gICAgICAgV2hpbGUgYSBPVFVDbiBjYW4gYmUgZGln aXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBp dCBjYW5ub3QgYmUgcm91dGVkIGluIFdTT04gLS0+IG5vIDEwMEcgaW50ZXJmYWNlcyBpbiBhbXBs aWZpZWQgRFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjINCg0KYi4gICAgICAgQW4gT1RV Q24gbWF5IGJlIGJyb2tlbiBkb3duIGludG8gNCBsYW5lcyBhdCAyNUcgKE9UTDQuNCkgYnV0IHN0 aWxsIGNhbuKAmXQgYmUgcm91dGVkIGluIFdTT04gLS0+IG5vIDI1RyBpbnRlcmZhY2VzIGluIGFt cGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMg0KDQpjLiAgICAgICBBbiBP VFUzICg9NDBHKSBjYW4gYmUgYnJva2VuIGRvd24gaW4gT1RMMy40IHByb3ZpZGluZyA0IGxhbmVz IGF0IDEwRyBlYWNoIC0tPiAxMEcgaW50ZXJmYWNlcyBhcmUgYWxsb3dlZCBpbiBhbXBsaWZpZWQg RFdETSBuZXR3b3JrcyBkZWZpbmVkIGluIEcuNjk4LjINCg0KDQoNCg0KDQoNCkZyb206IENDQU1Q IDxjY2FtcC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4+DQpEYXRlOiBG cmlkYXkgMTggTm92ZW1iZXIgMjAxNiBhdCAyMDowMg0KVG86ICJodXViYXR3b3JrQGdtYWlsLmNv bTxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+IiA8aHV1YmF0d29ya0BnbWFpbC5jb208bWFp bHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPj4sIENDQU1QIDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86 Y2NhbXBAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlz Y3Vzc2lvbg0KDQpUaGFuayBIdXViLA0KDQpBdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxp dHRsZSBwaWVjZSBvZiB0ZXh0IGRlc2NyaWJpbmcgdGhpcyBjb25zaWRlcmF0aW9uIGluIHRoZSBm cmFtZXdvcmsgb3IgaW4gb25lIG9mIHRoZSBzb2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGluZyB3 aGF0IGFyZSB0aGUgcGxhbnMgZm9yIHRoZSBtZXJnZSkgdGhhdCB3b3VsZCBiZSBncmVhdC4NCg0K VGhhbmtzDQpEYW5pZWxlDQoNCkZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86aHV1YmF0 d29ya0BnbWFpbC5jb21dDQpTZW50OiB2ZW5lcmTDrCAxOCBub3ZlbWJyZSAyMDE2IDE5OjMxDQpU bzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPG1h aWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPj47IGNjYW1wQGlldGYub3JnPG1h aWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNu IGRpc2N1c3Npb24NCg0KRGFuaWVsZSwNCg0KWW91IHdyaXRlOg0KVGhhbmtzIGZvciB0aGUgY2xl YXIgZXhwbGFuYXRpb24gSHV1Yi4NCg0KWW91J3JlIHdlbGNvbWUuDQoNCg0KSSBzZWUgdHdvIGRp ZmZlcmVudCB1c2UgY2FzZXMgdGhhdCBib3RoIG1ha2Ugc2Vuc2UuDQoNCkkgaGF2ZSB0byBkaXNh Z3JlZSAoYWdhaW4pLg0KDQoNClRoZSBvbmUgcHJvcG9zZWQgYnkgR2VydCBpcyBzdGl0Y2hpbmcg b2YgYW4gT0RVNCBhbmQgT0RVQzEsDQoNClRoaXMgdXNlIGNhc2UgaXMgaW1wb3NzaWJsZS4gQXMg eW91IGNhbiBzZWUgaW4gRy43MDkgKDIwMTYpIGZpZ3VyZSA3LTENCmEgbG93ZXIgb3JkZXIgT0RV NCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFVDMSwgYW5kIHRoaXMNCm1lYW5zIHRo YXQgdGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBsYXllcnMgaW4gdGhlIE9UTi4NCkFuZCBhcmUg aW1wb3NzaWJsZSB0byBzdGl0Y2guDQoNCg0Kd2hpbGUgdGhlIG9uZSB5b3UgYXJlIGRlc2NyaWJp bmcgaXMgdHVubmVsaW5nIG9mIE9EVTQgb3ZlciBhbiBPRFVDMSB0cmFpbC4NCg0KQ29ycmVjdC4N Cg0KDQpUaGV5IGJvdGggc2VlbXMgcmVhc29uYWJsZSB0byBtZSwgd2h5IHRoZSBzdGl0Y2hpbmcg aXMgbm90IGZlYXNpYmxlPw0KDQpJIHRyaWVkIHRvIGV4cGxhaW4gYWJvdmUuDQoNCkJlc3QgcmVn YXJkcywgSHV1Yi4NCg0KDQoNCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEh1dWIgdmFuIEhlbHZvb3J0DQpTZW50OiBnaW92ZWTDrCAxNyBu b3ZlbWJyZSAyMDE2IDE3OjA2DQpUbzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpI ZWxsbyBHZXJ0LA0KDQpZb3VyIHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3QuDQoN Ckluc3RlYWQgb2Y6DQoNCjEuICAgICAgQSB1c2UgY2FzZSB0byBjb25zaWRlciBpczoNCg0KICAg ICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0rDQoxMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwtT0RV NC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLXwtLTEwMEdFDQogICAgICAg Ky0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICBORTEgICAgICAgICAgICAgICAgICAgIE5FMiAo PUdXLU5FKSAgICAgICAgICAgICAgICAgICAgICAgTkUzDQoNCkl0IHNob3VsZCBiZToNCiAgICAg ICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KMTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RV NC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEtLS1PVFVDMS18LU9EVUMxLUdNUC1PRFU0LUdNUC18 LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgTkUx ICAgICAgICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAgICAgICAgICAgIE5F Mw0KDQpUaGUgT0RVQzEgZnJvbSBORTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9EVTQuDQoNClJlZ2Fy ZHMsIEh1dWIuDQoNCg0KDQoNCg0KDQotLQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkFsd2F5cyByZW1lbWJlciB0 aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVzdCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF7259FSZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXcgXCxzZXJpZiI7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmg0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLmoIfpopggNCBDaGFyIjsN CgltYXJnaW4tdG9wOjIuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglwYWdlLWJy ZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkgTGlnaHQiOw0KCWNvbG9yOiMyRjU0OTY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6aXRhbGljO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iuag h+mimCA0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLm oIfpopggNCI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7 DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQpwLkhlYWRpbmc0LCBsaS5IZWFkaW5nNCwgZGl2LkhlYWRpbmc0DQoJe21z by1zdHlsZS1uYW1lOiJIZWFkaW5nIDQiOw0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSGVhZGluZzRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCI7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0KCWNvbG9yOiMyRjU0OTY7DQoJZm9udC1zdHls ZTppdGFsaWM7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYu SFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdp bjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJaSC1DTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5IaSwgR2VydCwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1ll czsmbmJzcDsgc3RhcnRpbmcgd2l0aCB1bmRlcnN0YW5kaW5nIHRoZSBuZXcgZmVhdHVyZXMgb2Yg dGhlIG5ldyBPVE4gYmVmb3JlIGRpdmluZyBpbnRvIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGlz IGRlZmluaXRlbHkgdGhlIHVzdWFsIENDQU1QIHN0eWxlLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6 IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+LiAmbmJzcDsmbmJzcDtTbywgd2Ugc2hvdWxkIG5vdCBsb29rIGF0 IFJGQzcxMzkgd2hpY2ggaXMgcHJvdG9jb2wgZXh0ZW5zaW9uIFJGQywgYnV0IHJhdGhlciBSRkM3 MDYyLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPGJyPg0KWGlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij4g Q0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0 Ij7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+R2VydCBHcmFtbWVs PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+IDIwMTY8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRv d3RleHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1V UyI+MjM8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDIxOjAxPGJyPg0KPC9zcGFuPjxi PuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IERhbmllbGUgQ2VjY2FyZWxsaTsgY2NhbXBAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5oqE 6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gaHV1 YmF0d29ya0BnbWFpbC5jb208YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RV Q24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5EYW5pZWxlLCBBdXRob3Jz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+QWZ0ZXIgb3Vy IGluaXRpYWwgZW1haWwgZXhjaGFuZ2UgSSB0b29rIGEgbW9yZSBkZXRhaWxlZCBsb29rIGluIHRo ZSAyMDE2IHZlcnNpb24gb2YgRy43MDkuIEluIGVzc2VuY2UsIHRoZSAyMDE2IHZlcnNpb24gb2Yg Ry43MDkgd291bGQgaW1wYWN0IGNvbnRyb2wgcGxhbmUgd29yayBmb3IgRy43MDkgKFJGQzcxMzkp DQogYXMgd2VsbCBhcyBmb3IgV1NPTiAoUkZDNjE2MykuIFRoZSBjb21wbGV4IG5hdHVyZSBvZiB0 aG9zZSBkZWZpbml0aW9ucyB3aWxsIGNlcnRhaW5seSBub3QgYmUgYW4gZWFzeS1nb2luZyBleHRl bnNpb24gYXMgaXQgaGFkIGJlZW4gZW52aXNhZ2VkIHNvIGZhci4gV3JpdGluZyBhIOKAnDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93 dGV4dCI+bGl0dGxlIHBpZWNlIG9mIHRleHTigJ0gbG9va3MNCiB0byBtZSBsaWtlIGEg4oCcbGl0 dGxlIGJpdCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5JZiB0aGUgV0cgaW50ZW5k cyB0byB3b3JrIG9uIHRoZSBzdWJqZWN0LCBteSBwbGVkZ2Ugd291bGQgYmUgdG8gc3RhcnQgZnJv bSBhIGZyYW1ld29yayBkb2N1bWVudCB0byBjYXB0dXJlIHRoZSBuZXcgY29uY2VwdHMgYmVmb3Jl IGRlZmluaW5nIHByb3RvY29sDQogZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOndpbmRvd3RleHQiPkJlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOndpbmRvd3RleHQiPkdlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndp bmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5k b3d0ZXh0Ij5CZWxvdyBhIGxpc3Qgb2Ygb2JzZXJ2YXRpb25zIHRoYXQgaW5mbHVlbmNlZCB0aGlz IHZpZXc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+MS48L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5PUFVDbiwgT0RVQ24gYW5kIE9U VUNuIGFyZSBuZXcgYW5kIHRoZSBsYXllcmluZyByZWxhdGlvbnNoaXAgdG8gdGhlIGZvcm1lciBz dHJ1Y3R1cmUgaXMgYSBiaXQgc3VycHJpc2luZywgYXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxp c3QgKHNlZSBiZWxvdykgc2hvd2VkLiBCZXR0ZXIgdG8gZ2V0IHRoaXMgcmlnaHQgZWFybHkgb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZpZ3VyZSA3LTEgc2hvd3MgdGhlIE9UTiBt dWx0aXBsZXhpbmcgYW5kIG1hcHBpbmcgc3RydWN0dXJlcyBidXQgZG9lcyBub3QgaW5kaWNhdGUg aG93IGUuZy4gYSA0MDBHRSB3b3VsZCBiZSBtYXBwZWQgaW50byB0aGlzIHN0cnVjdHVyZS4gSXQg aXMgbm90IHN1cnByaXNpbmcgYXMgNDAwR0UgaXMgc3RpbGwgaW4gdGhlIG1ha2luZ3MsDQogYnV0 IHJhaXNlcyBhIGZldyBxdWVzdGlvbnMgYWJvdXQgaG93IGl0IGlzIHBsYW5uZWQgdG8gYmUgbWFw cGVkLiBIb3dldmVyIGd1aWRhbmNlIGZyb20gU0cxNSB3b3VsZCBoZWxwIHRvIGdldCB0aGUgcHJv dG9jb2wgYXJjaGl0ZWN0dXJlIGZ1dHVyZSBwcm9vZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0 LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6d2luZG93dGV4dCI+YS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5Eb2VzIGV2ZXJ5IGNsaWVudCBzaWduYWwgbmVlZCB0 byBiZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBpdCBjYW4gYmUgdHJhbnNwb3J0 ZWQgdmlhIGFuIE9QVUNuL09EVUNuPw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+ w6A8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OndpbmRvd3RleHQiPiB0aGlzIHdvdWxkIG1lYW4gdG8gZXh0ZW5kIHRoZSBPRFUgc3RydWN0dXJl IGJ5IGFuIE9EVTUsNiw3IGV0Yy4gZm9yIGNsaWVudHMgJmd0OyAxMDBHPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPmIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+V2lsbCBvbmx5IGNsaWVudCBzaWdu YWxzICZsdDs9IDEwMEcgbmVlZCB0byBiZSB3cmFwcGVkIGluIGFuIE9QVWsvT0RVayBiZWZvcmUg aXQgY2FuIGJlIHRyYW5zcG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8NCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz O2NvbG9yOndpbmRvd3RleHQiPsOgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gdGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhl cmUgd2lsbCBiZSBhIGJyZWFrIGluIHRoZSBtYXBwaW5ncyBhdCBhYm91dCAxMDBHIHNpZ25hbHMg YW5kIG5vIE9EVTUsNiw3DQogd291bGQgbmVlZCB0byBiZSBkZWZpbmVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPmMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+V2lsbCBmdXR1cmUgY2xpZW50cyBi ZSBtYXBwZWQgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiBhbmQgdGhlIHNwZWNpYWwgY2FzZSBv ZiAxMDBHRTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQiPsOgPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5PUFVr L09EVWs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7DoDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+T1BVQ24v T0RVQ24NCiB3aWxsIGJlY29tZSBqdXN0IGFub3RoZXIgb3B0aW9uPyAoTm90ZTogdGhlIGZpZ3Vy ZSBleHBsaWNpdGx5IGFsbG93cyBmb3IgcHJvcHJpZXRhcnkgbWFwcGluZ3MgZGlyZWN0bHkgaW50 byBPUFVDbi9PRFVDbiB3aGljaCBsb29rcyBsaWtlIGEgcHJhY3RpY2FsIHVzZSBjYXNlLCBidXQg aXQgbG9va3Mgb2RkIHRoYXQgaXQgcmVtYWlucyBwcm9yaWV0YXJ5KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndp bmRvd3RleHQiPjMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6d2luZG93dGV4dCI+VGhlIHNlY3Rpb24g4oCcNy4xIE1hcHBpbmfigJ0gYW5kIOKAnDcuMiBX YXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleOKAnSBjaGFuZ2VkIGEgYml0IGZyb20gdGhlIDIw MTIgdmVyc2lvbi4gQXMgYWNyb255bXMgaGF2ZSBjaGFuZ2VkIHRvbywgYSAxOjEgY29tcGFyaXNv biBpcyBub3QgdG9vIHNpbXBsZS4gVGhlIHRha2Vhd2F5IGlzIHRoYXQNCiBhbiBPVFUgY2FuIGJl IG1hcHBlZCBpbnRvIGEgc2luZ2xlIHdhdmVsZW5ndGggb3Igc3ByZWFkIGFjcm9zcyBzb21lIChP VExrLm4gYW5kIE9UTEMubikgd2hpY2ggbWVhbnMgaW52ZXJzZSBtdWx0aXBsZXhpbmcuIFNvIGZh ciB0aGlzIGNhc2UgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvciBSRkM2MTYz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPjQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+SW4gU2VjdGlvbiDigJw2LjEuMSBPVE4g ZGlnaXRhbCBzdHJ1Y3R1cmXigJ0gaXQgaXMgZXhwbGFpbmVkIHRoYXQgYW4gT1RVayBjb250YWlu cyBhIEZFQywgYnV0IE9UVUNuIGRvZXMgbm90LCBsZWF2aW5nIGl0IHRvIHRoZSBpbnRlcmZhY2Ug dG8gYXBwbHkgc29tZS4gVGhpcyBiYXNpY2FsbHkgY3JlYXRlcyBhIEZFQyBsYXllciBiZWxvdw0K IHRoZSBPVFVDbiB0aGF0IHdpbGwgbm90IGJlIGRlZmluZWQgaW4gRy43MDkuIEEgY29udHJvbCBw bGFuZSB3b3VsZCBuZWVkIHRvIGNoZWNrIGNvbXBhdGliaWxpdHkgb2Ygd2F2ZWxlbmd0aCwgbW9k dWxhdGlvbiwgaW50ZXJmYWNlcyAoaS5lLiBob3cgbWFueSBsYW5lcykgYW5kIGNvbXBhdGliaWxp dHkgb2YgRkVDLCBhcyB3ZWxsIGFzIHVzYWdlIG9mIE9UVWsgdnMgT1RVQ24uIEFsc28gdGhpcyBj YXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluDQogUkZDNzEzOSBvciBSRkM2MTYzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOndpbmRvd3RleHQiPjUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+VGhlcmUgaXMgYWxzbyBhIG5ldyBPTVMgTVNJIChz ZWN0IDE1LjQpIG92ZXJoZWFkIGRlZmluZWQsIHdoaWNoIHByb3ZpZGVzIGEgbGlzdCBvZiBPQ2gg YW5kIE9UU2lBIGZyZXF1ZW5jeSBzbG90LHBvcnQgbnVtYmVycyBhbmQgYSBsaXN0IG9mIG1lZGlh IGNoYW5uZWxzIChmcmVxdWVuY3kgc2xvdCwgbWVkaWEgY2hhbm5lbCBwb3J0DQogbnVtYmVycykg dG8gZGVjb2RlIHRoZSBsYW5lcyBjb3JyZWN0bHkuIFRoaXMgbWF5IGFmZmVjdCBSRkM2MTYzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+Ni48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGUgdGVybSDigJxXYXZlbGVuZ3RoIERpdmlz aW9uIE11bHRpcGxleOKAnSBpbiB0aGUgc2VjdGlvbnMgYWJvdmUgZG9lc27igJl0IGltcGx5IGEg d2F2ZWxlbmd0aCBjYW4gYmUgcm91dGVkIHRocm91Z2ggYSBEV0RNIG5ldHdvcmsgc2luY2Ugd2Ug a25vdyB0aGF0IGUuZy4gMTAwRyBpbnRlcmZhY2VzIGFyZSBub3QgeWV0IGRlZmluZWQgYnkNCiBT RzE1IGZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMuIFdpdGhvdXQgYW1wbGlmaWVycywg dGhlIGRpc3RhbmNlIHN1cHBvcnRlZCBieSBzdWNoIERXRE0gaXMgbGlrZWx5IGxpbWl0ZWQgdG8g YmVsb3cgODAtMTAwa20uIEl0IGlzIG5vdCB5ZXQgY2xlYXIgYnkgd2hlbiB0aGlzIGxpbWl0YXRp b24gd2lsbCBiZSBsaWZ0ZWQgYnkgU0cxNSAoc2VlIGRyYWZ0LW1hbnktY29oZXJlbnQtZHdkbS1p Zi1jb250cm9sLTAwKS4gQWZ0ZXIgYWxsLCBPVFU0DQogYmFzZWQgMTAwRyBpbnRlcmZhY2VzIGZv ciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhbmQgaGF2ZSBldmVu IGJlZW4gcHJvdmVuIHRvIGJlIGludGVyb3BlcmFibGUgYW1vbmcgbXVsdGlwbGUgdmVuZG9ycyBj b3ZlcmluZyBkaXN0YW5jZXMgJmd0OzEwMDBrbS4gJm5ic3A7SG93ZXZlciwgdG8gc3RheSBpbiB0 aGUgc3RhbmRhcmRzIGZyYW1ld29yayBmb3Igbm93LCBSRkM2MTYzIHdvdWxkIG5lZWQgdG8gY29u c2lkZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPmEuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+ V2hpbGUgYSBPVFVDbiBjYW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQgaW50 byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QgYmUgcm91dGVkIGluIFdTT04NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQiPsOgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gbm8gMTAwRyBpbnRlcmZh Y2VzIGluIGFtcGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5iLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkFuIE9UVUNuIG1heSBi ZSBicm9rZW4gZG93biBpbnRvIDQgbGFuZXMgYXQgMjVHIChPVEw0LjQpIGJ1dCBzdGlsbCBjYW7i gJl0IGJlIHJvdXRlZCBpbiBXU09ODQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7D oDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 d2luZG93dGV4dCI+IG5vIDI1RyBpbnRlcmZhY2VzIGluIGFtcGxpZmllZCBEV0RNIG5ldHdvcmtz IGRlZmluZWQgaW4gRy42OTguMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5k b3d0ZXh0Ij5jLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OndpbmRvd3RleHQiPkFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93biBpbiBPVEwzLjQg cHJvdmlkaW5nIDQgbGFuZXMgYXQgMTBHIGVhY2gNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRv d3RleHQiPsOgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjp3aW5kb3d0ZXh0Ij4gMTBHIGludGVyZmFjZXMgYXJlIGFsbG93ZWQgaW4gYW1wbGlm aWVkIERXRE0gbmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5OC4yPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t R0IiPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiPkNDQU1QICZsdDs8YSBocmVm PSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyI+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBEYW5pZWxlIENlY2NhcmVsbGkgJmx0OzxhIGhyZWY9Im1haWx0 bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIj5kYW5pZWxlLmNlY2NhcmVsbGlAZXJp Y3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5IDE4IE5vdmVtYmVyIDIw MTYgYXQgMjA6MDI8YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpodXViYXR3 b3JrQGdtYWlsLmNvbSI+aHV1YmF0d29ya0BnbWFpbC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPiZn dDssIENDQU1QICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RV Q24gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndp bmRvd3RleHQiPlRoYW5rIEh1dWIsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93 dGV4dCI+QXV0aG9ycywgaWYgeW91IGNvdWxkIGhhdmUgYSBsaXR0bGUgcGllY2Ugb2YgdGV4dCBk ZXNjcmliaW5nIHRoaXMgY29uc2lkZXJhdGlvbiBpbiB0aGUgZnJhbWV3b3JrIG9yIGluIG9uZSBv ZiB0aGUgc29sdXRpb24gZG9jdW1lbnRzIChkZXBlbmRpbmcgd2hhdCBhcmUgdGhlIHBsYW5zIGZv ciB0aGUgbWVyZ2UpDQogdGhhdCB3b3VsZCBiZSBncmVhdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGFua3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5EYW5pZWxlJm5ic3A7 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 d2luZG93dGV4dCI+IEh1dWIgdmFuIEhlbHZvb3J0IFs8YSBocmVmPSJtYWlsdG86aHV1YmF0d29y a0BnbWFpbC5jb20iPm1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gdmVuZXJkw6wgMTggbm92ZW1icmUgMjAxNiAxOTozMTxicj4NCjxiPlRvOjwvYj4g RGFuaWVsZSBDZWNjYXJlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxp QGVyaWNzc29uLmNvbSI+ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTwvYT4mZ3Q7Ow0K PGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+RGFuaWVsZSw8YnI+DQo8YnI+DQpZ b3Ugd3JpdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij5UaGFua3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KWW91J3JlIHdlbGNvbWUuPGJyPg0KPGJyPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5JIHNlZSB0d28gZGlmZmVyZW50IHVzZSBjYXNlcyB0aGF0 IGJvdGggbWFrZSBzZW5zZS4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KSSBo YXZlIHRvIGRpc2FncmVlIChhZ2FpbikuPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0 ZXh0Ij5UaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFuIE9EVTQgYW5k IE9EVUMxLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KVGhpcyB1c2UgY2FzZSBp cyBpbXBvc3NpYmxlLiBBcyB5b3UgY2FuIHNlZSBpbiBHLjcwOSAoMjAxNikgZmlndXJlIDctMSA8 YnI+DQphIGxvd2VyIG9yZGVyIE9EVTQgaXMgbWFwcGVkIGludG8gYSBoaWdoZXIgb3JkZXIgT0RV QzEsIGFuZCB0aGlzIDxicj4NCm1lYW5zIHRoYXQgdGhleSBjb25zdGl0dXRlIGRpZmZlcmVudCBs YXllcnMgaW4gdGhlIE9UTi4gPGJyPg0KQW5kIGFyZSBpbXBvc3NpYmxlIHRvIHN0aXRjaC48YnI+ DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPndoaWxlIHRoZSBvbmUgeW91IGFyZSBk ZXNjcmliaW5nIGlzIHR1bm5lbGluZyBvZiBPRFU0IG92ZXIgYW4gT0RVQzEgdHJhaWwuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpDb3JyZWN0Ljxicj4NCjxicj4NCjxicj4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6d2luZG93dGV4dCI+VGhleSBib3RoIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0 aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi Pjxicj4NCkkgdHJpZWQgdG8gZXhwbGFpbiBhYm92ZS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMs IEh1dWIuPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjp3aW5kb3d0ZXh0Ij4gQ0NBTVAgWzxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkh1dWIgdmFuIEhlbHZvb3J0PGJyPg0KPGI+U2VudDo8L2I+IGdpb3ZlZMOsIDE3IG5v dmVtYnJlIDIwMTYgMTc6MDY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBp ZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NB TVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tR0IiPkhlbGxvIEdlcnQsPGJyPg0KPGJyPg0KWW91ciB1c2UgY2FzZSBpcyBub3Qg Y29tcGxldGVseSBjb3JyZWN0Ljxicj4NCjxicj4NCkluc3RlYWQgb2Y6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPjEuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5BIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3IFwsc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyBcLHNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0t JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPjEwMEdFLS18 LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEt fC1PRFVDMS1HTVAtfC0tMTAwR0U8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg XCxzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBORTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTkUyICg9R1ctTkUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMzwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCkl0IHNob3VsZCBiZTogPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4xMDBHRS0tfC1HTVAtT0RVNC18LU9UVTQtLS1PVFU0LXwt T0RVNC1HTVAtT0RVQzEtfC1PVFVDMS0tLU9UVUMxLXwtT0RVQzEtR01QLU9EVTQtR01QLXwtLTEw MEdFPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTkUxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE5FMiAoPUdXLU5FKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORTM8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpUaGUgT0RVQzEgZnJvbSBO RTIgdG8gTkUzIHR1bm5lbHMgdGhlIE9EVTQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcywgSHV1Yi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+LS0gPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5BbHdheXMgcmVt ZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF7259FSZXEMA512MBSchi_-- From nobody Thu Nov 24 00:07:37 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD94129699 for ; Thu, 24 Nov 2016 00:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LP1ittoKjx0t for ; Thu, 24 Nov 2016 00:07:33 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2863129568 for ; Thu, 24 Nov 2016 00:07:32 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id t79so50754810wmt.0 for ; Thu, 24 Nov 2016 00:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=f7Q2mL1dCvkGE2KbcYb3b6hDug+sYO/utcTioHSUeCM=; b=yuQIQNPxMWGw8V2O1V156+ya0fa2B/xOZYLQtJfe1q3pOETlX/75SMnO/MrxJ2rWFw Xh762dswdXh4MTWRz2xF35yDlSe953wIV02LuGVmBVrp5IrzyM3HOhF2LkWdacmJsa34 w9HTy5F/WZn1zTxBwJ7b7OnbvemN3yHqbE2Jt5AZnNggWn/ejHNFtRYyK6syWNoTfqMs pxDNIOAevtmt6e/ufnEfi1y0PmQW9sPTMwxRgEfKYUS/uG9YpuQT41qp6fRnUT4Qzm8a b2lUJFEpaYphb2hK5l/oHg0/CYYtJgH4jpOqmjFp3rvhCAz1P5I7mzZtzTyXz1FOo7GW 5fYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=f7Q2mL1dCvkGE2KbcYb3b6hDug+sYO/utcTioHSUeCM=; b=jJcn+mABGi3JoWOlxBoCGrZkoegqGC3XFy/nPV1RWKC8oI3As/v0cUqEVBhdTjRkaR 0HAjbyIouBgEwXdYoYsMBEBwN/PX5oI3MxNbdFSf9tp/8ug0ZtPhk2c4S7gT6onK7uNg /YS+g9bz4kYTkZ+kNSrlBvo5/kGV7oHnJL1ONKfJ10ODzhX3NG49SL3ZT5848Sz1Br+D nluq6UF92ArywuO7mr6STRkwZLvi001pAXx60ey/TtiZgEQUJ9AuOO4nHFAOCap84nj/ BHSC1XS4YW59zw45GKKbs6rCXGltZ+Hw2ojlUhB3IUS4wlgk4n76CB8gawYPxGepDEiB 5u6g== X-Gm-Message-State: AKaTC012L29Mvyx5PmneyKoeaSiMtlrifoUd/pZm5VV+TMnUpJo9+uiFoycdTIiXkvvY1A== X-Received: by 10.194.111.102 with SMTP id ih6mr978915wjb.214.1479974851256; Thu, 24 Nov 2016 00:07:31 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id 138sm6815159wms.20.2016.11.24.00.07.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 00:07:30 -0800 (PST) References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> To: Dieter Beller , wang.qilei@zte.com.cn, Gert Grammel From: Huub van Helvoort Message-ID: <31db5bbc-faa3-7856-02e7-cf7c34d428e5@gmail.com> Date: Thu, 24 Nov 2016 09:07:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 08:07:35 -0000
+1

Regards, Huub.

------
On 23/11/2016 17:50, Dieter Beller wrote:
Hi all,

I would submit that we need a document similar to RFC 7139 (GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport
Networks) for the new ODUCn signal types.

RFC 7139 contains sufficient information and descriptions regaqrding the new G.709 signal types introduced in the Feb 2012 revision of G.709.

I don't think we need to take a different approach for the latest 2016 evolution of G.709.


Thanks,
Dieter

On 23.11.2016 16:38, wang.qilei@zte.com.cn wrote:
Hi Gert,

Thanks for your comments. Following is my answer to your previous mail and this one.

(1), About the questions in your previous mail. I think you already have many of them solved. ODUCn has almost the same overhead as that of ODUk, so I don't think some mechanisms of ODUCn (e.g., OAM etc) differ from those of ODUk. In the ODUCn draft, I think we should mainly pay attention to ODUCn's feature and its difference with ODUk now, such as layer model of ODUCn and setup of ODUCn connection.

(2), About the questions in the second items of this thread. I think it's out of the scope of CCAMP. I can't give a definite answer to these questions.

(3), Control of optical network is out of the scope of current ODUCn document. We will not involve this part in. Also I suggest you take a look at RFC7698, which mainly focus on the control of flexible grid network.

Thanks
Qilei


Gert Grammel <ggrammel@juniper.net>
发件人:  "CCAMP" <ccamp-bounces@ietf.org>

2016/11/23 21:01

收件人
 Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "ccamp@ietf.org" <ccamp@ietf.org>,
抄送
 "huubatwork@gmail.com" <huubatwork@gmail.com>
主题
 Re: [CCAMP] ODU4 and ODUCn discussion







Daniele, Authors,
 
After our initial email exchange I took a more detailed look in the 2016 version of G.709. In essence, the 2016 version of G.709 would impact control plane work for G.709 (RFC7139) as well as for WSON (RFC6163). The complex nature of those definitions will certainly not be an easy-going extension as it had been envisaged so far. Writing a “little piece of text” looks to me like a “little bit of understatement”. If the WG intends to work on the subject, my pledge would be to start from a framework document to capture the new concepts before defining protocol extensions.
 
Best
 
Gert
 
 
Below a list of observations that influenced this view:
1.       OPUCn, ODUCn and OTUCn are new and the layering relationship to the former structure is a bit surprising, as the discussion on the list (see below) showed. Better to get this right early on
2.       Figure 7-1 shows the OTN multiplexing and mapping structures but does not indicate how e.g. a 400GE would be mapped into this structure. It is not surprising as 400GE is still in the makings, but raises a few questions about how it is planned to be mapped. However guidance from SG15 would help to get the protocol architecture future proof.
a.       Does every client signal need to be wrapped into an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? → this would mean to extend the ODU structure by an ODU5,6,7 etc. for clients > 100G
b.       Will only client signals <= 100G need to be wrapped in an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? → this would mean that there will be a break in the mappings at about 100G signals and no ODU5,6,7 would need to be defined
c.       Will future clients be mapped directly into OPUCn/ODUCn and the special case of 100GE→OPUk/ODUk→OPUCn/ODUCn will become just another option? (Note: the figure explicitly allows for proprietary mappings directly into OPUCn/ODUCn which looks like a practical use case, but it looks odd that it remains prorietary)
3.       The section “7.1 Mapping” and “7.2 Wavelength Division Multiplex” changed a bit from the 2012 version. As acronyms have changed too, a 1:1 comparison is not too simple. The takeaway is that an OTU can be mapped into a single wavelength or spread across some (OTLk.n and OTLC.n) which means inverse multiplexing. So far this case has not been considered in RFC7139 or RFC6163.
4.       In Section “6.1.1 OTN digital structure” it is explained that an OTUk contains a FEC, but OTUCn does not, leaving it to the interface to apply some. This basically creates a FEC layer below the OTUCn that will not be defined in G.709. A control plane would need to check compatibility of wavelength, modulation, interfaces (i.e. how many lanes) and compatibility of FEC, as well as usage of OTUk vs OTUCn. Also this case has not been considered in RFC7139 or RFC6163.
5.       There is also a new OMS MSI (sect 15.4) overhead defined, which provides a list of OCh and OTSiA frequency slot,port numbers and a list of media channels (frequency slot, media channel port numbers) to decode the lanes correctly. This may affect RFC6163
6.       The term “Wavelength Division Multiplex” in the sections above doesn’t imply a wavelength can be routed through a DWDM network since we know that e.g. 100G interfaces are not yet defined by SG15 for amplified DWDM applications. Without amplifiers, the distance supported by such DWDM is likely limited to below 80-100km. It is not yet clear by when this limitation will be lifted by SG15 (see draft-many-coherent-dwdm-if-control-00). After all, OTU4 based 100G interfaces for amplified DWDM applications are available and have even been proven to be interoperable among multiple vendors covering distances >1000km.  However, to stay in the standards framework for now, RFC6163 would need to consider:
a.       While a OTUCn can be digitally constructed and mapped into a single wavelength, it cannot be routed in WSON → no 100G interfaces in amplified DWDM networks defined in G.698.2
b.       An OTUCn may be broken down into 4 lanes at 25G (OTL4.4) but still can’t be routed in WSON → no 25G interfaces in amplified DWDM networks defined in G.698.2
c.       An OTU3 (=40G) can be broken down in OTL3.4 providing 4 lanes at 10G each → 10G interfaces are allowed in amplified DWDM networks defined in G.698.2
 
 
 
 
 
 
From: CCAMP <ccamp-bounces@ietf.org> on behalf of Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Date: Friday 18 November 2016 at 20:02
To: "huubatwork@gmail.com" <huubatwork@gmail.com>, CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Thank Huub,
 
Authors, if you could have a little piece of text describing this consideration in the framework or in one of the solution documents (depending what are the plans for the merge) that would be great.
 
Thanks
Daniele  
 
From: Huub van Helvoort [mailto:huubatwork@gmail.com]
Sent: venerdì 18 novembre 2016 19:31
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; ccamp@ietf.org
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Daniele,

You write:
Thanks for the clear explanation Huub.

You're welcome.
I see two different use cases that both make sense.

I have to disagree (again).
The one proposed by Gert is stitching of an ODU4 and ODUC1,

This use case is impossible. As you can see in G.709 (2016) figure 7-1
a lower order ODU4 is mapped into a higher order ODUC1, and this
means that they constitute different layers in the OTN.
And are impossible to stitch.
while the one you are describing is tunneling of ODU4 over an ODUC1 trail.

Correct.
They both seems reasonable to me, why the stitching is not feasible?

I tried to explain above.

Best regards, Huub.
 
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Huub van Helvoort
Sent: giovedì 17 novembre 2016 17:06
To: ccamp@ietf.org
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Hello Gert,

Your use case is not completely correct.

Instead of:
1.      A use case to consider is:
 
       +----------+             +----------------+               +-----------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-|--100GE
       +----------+             +----------------+               +-----------+  
             NE1                    NE2 (=GW-NE)                       NE3

It should be:
       +----------+             +----------------+               +--------------------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE
       +----------+             +----------------+               +--------------------+  
             NE1                    NE2 (=GW-NE)                       NE3

The ODUC1 from NE2 to NE3 tunnels the ODU4.

Regards, Huub.

 
 

 
--
================================================================
Always remember that you are unique...just like everyone else..._______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
 


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp




-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Thu Nov 24 07:51:13 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E94129961 for ; Thu, 24 Nov 2016 07:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 lmNfAw1T_6nb for ; Thu, 24 Nov 2016 07:51:08 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BBD12989C for ; Thu, 24 Nov 2016 07:51:07 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-e8-58370c69fb02 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id DA.06.06466.96C07385; Thu, 24 Nov 2016 16:51:05 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 24 Nov 2016 16:50:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9pws5Z+lgqsCP7XFyx7SKcNc/KPdva57xwI7rF5iyiM=; b=co4jkr6msHU2rKkZLuYiQXsVPOJ1sghxr3ebY1AEQktPwkiBSG7V8AvxT6g+n/xiE0IZXoERzAYJaax96ir6TioNPeM3S2WV+IILzvIAmMwvGQknGQiMHRS2VRc8o+uO1vq6e7lMDE3txBTLK4yTsNKxvodjV0rvY4Du7Iykf4g= Received: from AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) by AM3PR07MB0535.eurprd07.prod.outlook.com (10.141.47.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Thu, 24 Nov 2016 15:50:44 +0000 Received: from AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::f5f7:a983:e7e2:6701]) by AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::f5f7:a983:e7e2:6701%14]) with mapi id 15.01.0747.010; Thu, 24 Nov 2016 15:50:44 +0000 From: Jonas Ahlberg To: 'LUIS MIGUEL CONTRERAS MURILLO' , "'Yemin (Amy'" , "'Marko.Vaupotic@Aviatnet.com'" , "'jefftant.ietf@gmail.com'" , 'Koji Kawada' , "'Ippei Akiyoshi (i-akiyoshi@ah.jp.nec.com) (i-akiyoshi@ah.jp.nec.com)'" , 'Xi Li' , "'Martin Skorupski (External'" , "cjbc@it.uc3m.es" , "Rahman, Akbar" Thread-Topic: MDT meeting - YANG Data Model - December 1, 9:00-10:00 (CET) Thread-Index: AdJGaSzQP8ZBLChuQAKJWMHJPE+rYQ== Date: Thu, 24 Nov 2016 15:50:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jonas.ahlberg@ericsson.com; x-originating-ip: [87.241.98.47] x-ms-office365-filtering-correlation-id: 8e193966-86b2-4cd4-ae83-08d41481a6c9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB0535; x-microsoft-exchange-diagnostics: 1; AM3PR07MB0535; 7:s/xqI0iFGBgLrJBpAaLsc5xvuJi/UKsvIhlCynRHkNd4Yd1bFmcEWu6GoX/SeRYrZUCVgpzAJaBmuYoAib+BgVktXUukrEZ0iBK6KmxZ/DjMa4ZhgkOi8jgc7EN7VSC8uvDOpEXYEE5NHbE922bUAW5uOMloFfEqlXRGsSGUjeR9xGw5+oJ9/ZtbB8gssKpGFJyuckuR0G3h7NGaE38vgnuwxZSxvbW1sAy/lP/0T6d62HCnKqi39O2Cd013FJ7Bb6ykP240rSePNZOaIA78FNibdKoyMdVRqNEdBLNdiJapVWjyAvnzQst9hUnAv2ZRiX/tIt63RxZxuk6YrXm45CTxe/FgTunF+uSW6wqaxqZpR/BQzRK6PxiNIMkeHvoiXWvmvkonEC0MFRoTAQWbaOj6CxGchesiEA/qbnC2RH5h8OxLD5HEhxKH934XxYfIDOl02gjL+deUKO2dUYN4mQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(209352067349851)(176712945974257)(77634252153581)(120264001924599)(189100400724070)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040361)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324)(20161123555025)(20161123564025)(20161123560025)(20161123562025); SRVR:AM3PR07MB0535; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0535; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(497574002)(199003)(3905003)(53754006)(189002)(39380400001)(39410400001)(8936002)(2900100001)(101416001)(39060400001)(81156014)(81166006)(189998001)(19609705001)(68736007)(66066001)(74316002)(92566002)(2501003)(5001770100001)(5250100002)(50986999)(76576001)(97736004)(6506003)(606004)(7416002)(38730400001)(6116002)(790700001)(102836003)(105586002)(86362001)(3846002)(54356999)(3660700001)(9686002)(3280700002)(8676002)(7696004)(7066003)(5660300001)(7906003)(7736002)(33656002)(2906002)(106356001)(7846002)(4326007)(39400400001)(921003)(1121003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0535; H:AM3PR07MB0536.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB05360722551AA65DA4CE7B3F89B60AM3PR07MB0536eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2016 15:50:44.5302 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0535 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHO/dlu84Gt6n5oAaxCqVMTUrvhwgFw1skBEEtM2rZxVa+sWuW +kUzNU1TyGIOLUWz8i1TK0dK08I3SiuyqWyFuvAlDVNSVJC2HQW//Xh+/3M4/4fDkIpl2oPR xCcJ2nh1rFIio0pUb7z3a7YGqwIy0v25laJbBNd8p1HCWUuHKC6rtYngKr5m0tz0nWWC033t Jrn+CZ2E0z0rlnJzRh3JWeb7iBBnfrKiheTf59Yh3qC3SPnbH2ZpvqpqmeCfmLJpftH0kuZ1 XVNSPneVPOkUKTt8WYjVJAta/yMXZVeaXyxJE/sSb5a1N5LpKEvIQ04MsAdhorKNzkMyRsE2 IHj5OAPZhYLtQfDDkGwXFFtAwqfMVxRO3SegSb9xZBxB4bMW2n5EwgbAzPQjiV24sl0U1Nw1 E3ZBsnsg29TnCLmwR6E2xyC1syt7HHor10jMfvDXZKbsTNnyOSUPHe+Qs1GwNjjryCB2Oyz1 1a3f6Q4j1scELsFCVdsAidkNpsbXaJw/D7OT0xSe74SOwlFbnrFxBOgM+/E4AhYKph3NgM2n oLZaJ8XiGljy6hDmRwjMReE4VGqrX22msfCCnIVWGosZGip7ymm8PQGe1mch3NgDLN9y19kL Js3tNG6QABP3+uki5K3fVEi/SekdC9gGvSVWCs99ofztvATzPqiu+E1u8EfjOLF5Xo6kNchN FMRLcTGBgX6CVhMtignxfvFCUhOyfciOltWAVjQ1EdqJWAYpt8rnGg6pFLQ6WUyJ60TAkEpX +WlZsEohv6xOSRW0CRe012MFsRN5MpTSXR70/OcZBRujThKuCUKioN2wBOPkkY48uXqleMP5 acTQoHE5BtLGzrqUDfc27ghQhf1ZdAqLzDy2pVMVuTr6Tvqh9FRg9C+zV2746+5inxafjx1B uwwDSScivjxgww6QA1dTGgijWFvfFmtpP+U24tMwbPU7F2SNSvvO+IZ+TjamygZ2a3rz/13o MS2sNEcFK/xDxnrGlJR4RX1gL6kV1f8B6qnMbowDAAA= Archived-At: Cc: "ccamp@ietf.org" Subject: [CCAMP] MDT meeting - YANG Data Model - December 1, 9:00-10:00 (CET) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 15:51:11 -0000 --_000_AM3PR07MB05360722551AA65DA4CE7B3F89B60AM3PR07MB0536eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This is the invite for the MDT meeting next week. We've today gone through the work done so far on the open topics, but there= are many topics still to be completed. The focus until next week is therefore to continue the investigations and r= ecommend conclusions for all remaining topics. I suggest that responsible persons mail out proposals on conclusion in adva= nce of the next meeting. The proposed agenda: * Discussion & agreement on conclusions for all remaining open topi= cs * AOB Working material can be shared with others than the design team on request. Regards /JonasA ...........................................................................= .............................................................. --> Join Skype Meeting This is an online meeting for Skype for Business, the professional meetings= and communications app formerly known as Lync. Join by phone +46107140000 (Sweden) Engli= sh (United States) 89925 (Sweden) English (United St= ates) Find a local number Conference ID: 81068273 Forgot your dial-in PIN? |Help To join a Lync / Skype for Business meeting from an Ericsson standard video= room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the= conference ID). To join from a video room outside of Ericsson add one o= f the domains after 77 and Conference ID (e.g. 771234567@ xxxx.ericsson.net= , where xxxx=3Demea/apac/amcs). For assistance contact the IT Service Desk= . [!OC([1033])!] ...........................................................................= .............................................................. --_000_AM3PR07MB05360722551AA65DA4CE7B3F89B60AM3PR07MB0536eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This is the invite for the MDT meeting next week.

 

We’ve today gone through the work done so far = on the open topics, but there are many topics still to be completed.

The focus until next week is therefore to continue t= he investigations and recommend conclusions for all remaining topics.<= /o:p>

I suggest that responsible persons mail out proposal= s on conclusion in advance of the next meeting.

 

 

The proposed agenda:

·         Discussion & agreement on conclusions fo= r all remaining open topics

·         AOB

 

 

Working material can be shared with others than the = design team on request.

 

Regards

/JonasA

 

 

 <= /o:p>

...................................................= ...........................................................................= ...........

&agr= ave; = Join Skype Meeting      

This is an online meeting= for Skype for Business, the professional meetings and communications app f= ormerly known as Lync.

Join by phone

 

+46107140000 (Swe= den)            &nbs= p;      English (United States)

89925 (Sweden)   =             &nb= sp;   English (United States)  =

 

Find a= local number

 

Conference ID: 81068273

Forgot your dial-in PIN?<= span lang=3D"EN" style=3D"font-size:3.0pt"> |Help  

 

 

To j= oin a Lync / Skype for Business meeting from an Ericsson standard video roo= m, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the con= ference ID).    To join from a video room outside of Ericsson add one of the domains after 77 and Conference ID (e.g= . 771234567@ xxxx.ericsson.net, where xxxx=3Demea/apac/amcs).  For ass= istance contact the IT Service Desk.

[!OC([1033])!]

= ...........................................................................= ..............................................................<= /p>

 

 

--_000_AM3PR07MB05360722551AA65DA4CE7B3F89B60AM3PR07MB0536eurp_-- From nobody Mon Nov 28 05:53:01 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1441294C5; Mon, 28 Nov 2016 05:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 N956OlIyWVVX; Mon, 28 Nov 2016 05:52:46 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E15129405; Mon, 28 Nov 2016 05:52:45 -0800 (PST) X-AuditID: c1b4fb2d-073ff70000001117-49-583c36a9531f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 98.41.04375.9A63C385; Mon, 28 Nov 2016 14:52:44 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 28 Nov 2016 14:52:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ASxys1eGoazxs9wd3lOUAVLx5uGbkrAYeaFb9TDcXls=; b=i2g91L+zxMjPu9W/9opagst7HgxSem4s/cB8iwY9AAsp89lxUoEsb6IGorAGFzr/VaMUXepFk4ovz45Upp0fX7ggjxJ8Y5sHe/a7Ueh4rwhqlNTbZv4QB5Bfr/BBwIsorxv1pkz2nclIxdOn2gQhXHQKIZoVSmFbUiIbiP10SqU= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Mon, 28 Nov 2016 13:52:39 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0761.009; Mon, 28 Nov 2016 13:52:39 +0000 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: IETF 97 - Minutes Thread-Index: AdJJfGqW1nHLu05NTzaalyUbP88StQ== Date: Mon, 28 Nov 2016 13:52:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 70cafa35-e867-4e16-bd35-08d41795d13b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0994; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0994; 7:3lSjB6OCUUjtRZG2ADnkKIc1KirZG+VNqyIgtCPsvvIpiST4itoObrK+3AHfcPboNxL8Q0ogj9OIsdiUTcHlf0+vb8Gwd1tLBdeh9dpR8+MQldkB/KtpJQ8B3kZNMo0jdrVKIc+B8B4bhwK6EBKjtm+DWUf2c7MEhH5+8CzuX20dVizn2o3Q1TfhTbwnWM2yCOBZN3PWP+mm29PzRr8kD6t5OsqO/CfRLcdC5P9tqpEDoLga4UWwqTRRCXjkTYXfdhUY3keZ532aKnqUwSHZ38PjKATi1A9rYapsIihCrzvtejofooelkaI0+x7ZHYbxpmAdX35zYC2UhdaPujNiKJEsfbxHo5m+by3gBgsrIKhWLc8bpkcJfC5Ra8NhJTWOSrR6eUFw1yTbPH/5ukVTT4LBJzShJKIeT5E7Ovu1EBo8CoTE8wTYLtELJxqGjciOgX+dL90ZEkPmarb+5UbwMA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040361)(6045199)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(20161123560025)(20161123555025)(20161123564025)(20161123562025); SRVR:AM2PR07MB0994; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0994; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(53754006)(122556002)(7696004)(5660300001)(101416001)(39410400001)(39400400001)(8936002)(4326007)(2906002)(33656002)(54356999)(6506003)(606004)(76576001)(8676002)(77096006)(38730400001)(97736004)(39380400001)(39450400002)(50986999)(189998001)(81156014)(6916009)(110136003)(105586002)(106356001)(9686002)(92566002)(81166006)(66066001)(2900100001)(3846002)(7906003)(3660700001)(558084003)(790700001)(102836003)(6116002)(7736002)(7846002)(74316002)(3280700002)(450100001)(86362001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0994; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994FDE385670F4780B20CA0F08A0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 13:52:39.2000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0994 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTcRTG+e/eO6+j0XX5clyCNTDB8i3DxpDKT71gIJI1w16mXlR0U3ZV skDENNyaoOYEl5jFzGZTS1Jny6yBM01oRJpNw2IjFbFWZLXUqHm38NvvOc/DgedwSEzQTQjJ fEUJrVTICkVcHt4iHYyMNiYmSeOufwkQO1tncLG9w0CIq+Zn/MQ1v0z4EfyYXu/mpKKzvKQc ujC/jFbGHrrIy7PfCy22h15SXQupRF+D1cifBOoANA4Y/NSIRwqoHgTNVWaMFS8QjGkeEx6B U3UYvO5oIlhHywF1VZtXWBGMj/Rz1IgkuZQEnJYUz95AKhqGH77FPIxRRaD6bCc8vIMSgr3e jbGZcBgctfqxHAMTDY7NDE5FQPXaEPIwn8oEW20t7mFEBcPPCSOH3RkCductDtuBAv2TVxjL QbDk+EOw+SzorTF5M7vB1qXz8kl4N2j+zwMjqs3+QGlw6Gm/4V1UAK71SoJlCdQ2jBFsqJUD bbOtXiMMZo3zXsNMwJK2h+sxBBQNnd01yFf5/RuVl8NgcW6Y8J2lc2qFW48idVsa6bZYus0L BMB4ixNn5/ug3fyNy/JeuHt7GfPx5DMHZ+u8Hfl1oSCGZhh57v6EGFqZn80wRYoYBV3Sh/49 0fNHa9EmdH852YIoEom28V3fJVIBIStjyuUWBCQmCuS745OkAn6OrPwyrSy6oCwtpBkL2kni ohB+omH+jIDKlZXQBTRdTCt9Lof0F1YiydMoW5//wMvYju0Zlae1em35g1Hr6mSms2H66i7X h9+S9KjzmrTmjY8HceHhuqnUxcRVdb8jRa4J3zAMWXS2E+Hr8qwK80qTxGFLqA6U3+xNmzKN dsUtlGafC85Onl64MpdxXBMhch/dcKVNVnxKT03T/5A06kKMp6x7FtV3RDiTJ4uPwpSM7C+x 9YO+QAMAAA== Archived-At: Cc: "mpls@ietf.org" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [CCAMP] IETF 97 - Minutes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:52:48 -0000 --_000_AM2PR07MB0994FDE385670F4780B20CA0F08A0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, the first draft of the CCAMP and joint YANG session minutes is now availabl= e at the following link: https://www.ietf.org/proceedings/97/minutes/minute= s-97-ccamp-00.htm Thanks a lot to Italo, Haomian and Yoji for the help with notes taking. Thanks Daniele, Fatai, Oscar --_000_AM2PR07MB0994FDE385670F4780B20CA0F08A0AM2PR07MB0994eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

the first draft of the CCAMP an= d joint YANG session minutes is now available at the following link: https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-00.htm 

 

Thanks a lot to Italo, Haomian = and Yoji for the help with notes taking.

 

Thanks

Daniele, Fatai, Oscar

--_000_AM2PR07MB0994FDE385670F4780B20CA0F08A0AM2PR07MB0994eurp_-- From nobody Mon Nov 28 06:51:21 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5B71294F4 for ; Mon, 28 Nov 2016 06:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 220tlHwGmVIz for ; Mon, 28 Nov 2016 06:51:16 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB9E129600 for ; Mon, 28 Nov 2016 06:51:14 -0800 (PST) X-AuditID: c1b4fb30-c294498000000c18-34-583c4461c864 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 35.31.03096.0644C385; Mon, 28 Nov 2016 15:51:13 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 28 Nov 2016 15:51:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mbQWC/fSMQ+/pj6YICHfcvUk8GJf3L+3necYfI8DlVQ=; b=lHpGuvbkUIfzIU4OPLiBPgsOF9dCZucxt6u5JHIm4bc19Y8JiAFh1axFXGV8LLEqIuCX4+5aLsGtlqRg+KfUNZXoV7GZH02r5BVCpRVInRgFWlmvfW4GqptWwnl0MIcjdtfehN/CfzpEDTtF7udMoF0qHq7Z7R3pvI793tb2MXg= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0993.eurprd07.prod.outlook.com (10.162.37.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Mon, 28 Nov 2016 14:51:10 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0761.009; Mon, 28 Nov 2016 14:51:10 +0000 From: Daniele Ceccarelli To: Iftekhar Hussain , Dieter Beller , "wang.qilei@zte.com.cn" , Gert Grammel Thread-Topic: [CCAMP] ODU4 and ODUCn discussion Thread-Index: AQHSQKss6FRgyVlKfkipo+ArBheQVaDdV7EAgAGrtCCAAA8PAIAACKjwgAeHm4CAABtbAIAAE+UAgABV84CAB2MFgA== Date: Mon, 28 Nov 2016 14:51:10 +0000 Message-ID: References: <4be4d801-addf-cddd-b6f7-7f4d9cfa9afa@gmail.com> <36984a49-c29d-1f61-3e6d-da270fd778a7@gmail.com> <78E76D32-93DC-4F9E-B6EB-3B25437EB356@juniper.net> <9de0f3cf-1411-61d5-8be9-495a44be6255@nokia.com> <4dfbb368423649d88f9bcf6a07af062e@sv-ex13-prd1.infinera.com> In-Reply-To: <4dfbb368423649d88f9bcf6a07af062e@sv-ex13-prd1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 437851fe-7690-48a2-bf13-08d4179dfdda x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0993; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0993; 7:T3h/L6KTHobx/crff//PDnOg6MkolWnvP1WaZTU8wNeCw9prI7nfDjTFWc9xrIzI2O9T/oybTJMJGY33AbHgfeQ+yXRNfYny2tPs0DpAKpZsjkGmoM6y5e5+6ICImv8OrxT00UDOj8Zbe7boZtd4+SPbIzwJ8btPNo1k3BzizWhR28wzKevW6+G1rJ9Rm0F7Uc9o9GTeAiaGSo5fIeNW/CByDnUi35KoNVkQKeZj2/TgQ+pLjMC3wAj/sl+0TatmNjckJomyWt93cH9smfGaK8GDVAugMEnEPOjWziw2veuFHdiismUh07pGtbGH0MWJZG8NeKJ/kT4I5cWmOQXq3WPlh54bo1D4+PUlYuCN7qakGnXWCYMx3Vva4+aAnlyexh96kbje7JxEnAVvCQ48aA2ZP47e0wJOdp72Qta7gjpgzBxun/mMiV2Icm/FToUSPR3WayHIVkKSfP5ZsSHR+Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(138986009662008)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040361)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025); SRVR:AM2PR07MB0993; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0993; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(51914003)(377454003)(53754006)(24454002)(189002)(199003)(790700001)(9686002)(39380400001)(39450400002)(2906002)(102836003)(189998001)(97736004)(8676002)(3660700001)(3280700002)(39400400001)(8666005)(7846002)(7696004)(3846002)(8936002)(68736007)(4326007)(2501003)(2950100002)(5660300001)(38730400001)(6116002)(39410400001)(39060400001)(7736002)(74316002)(66066001)(86362001)(106116001)(5001770100001)(54356999)(7906003)(93886004)(606004)(106356001)(6506003)(81156014)(1941001)(122556002)(92566002)(76576001)(229853002)(33656002)(2900100001)(76176999)(50986999)(101416001)(105586002)(81166006)(77096006)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0993; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09947BEA72A75F0DF6F57B3DF08A0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 14:51:10.1027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0993 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0iTYRjl/W77nE3eluaDXbCh5IWcitiyURb9mJQRBSUh1NQP71P2LdGK EsEkS5DIyHkpaKmZaaa4eUFrlWQJmmmZOsUcNS1DQVKLRtu+Bf4773nOczmHlyWl72k/Nl2j 47QadZaMEVOVCcaAPeojyoRw+5qXwlo9TimaDVOUwtBVRynuVn2gFVMPGkUKe8cqHcuoOvUW kcpgWCdUIzYzo/pUNCZSWSZGCFVT7xp1gjkrVqZwWel5nFZ+4Lw4zWRMz71lI/NnahqZQtQz SZYiDxZwFEyM/mJKkZiV4mYEA61NImdBit8gqFs+4CxQuIyE4a42t6qCgNGSBVJ49COYHW92 tLAsg2PAaj7m5L1xC4I7a6+RcxSJT4NxRO8auwWHwbWaMcaJvbEc+m/8RgLOgNWJaRdP4UAY rDESTizBiVBc3ScSlnVRcLOw09XggePgXdtdlwmEt8Lq2yZCWOYLE9Z7hGAOg6FnyG3UB+bn 7LSgT4KWYpNbswuGG/WE0wDgeFg2RQt0PCya7rj2Ar5JQe+ymRIKmfB9ZcU98zIsjvxw89UE FLUeFvB2mGyaoYXmOgZKHw8hIVQO6p8UIyEJP7CMXkflKFi/4W4B50CFrZbWuwLYDAOVVkrv uI/EwdDSJRcku+D2jVmRgIMcGdWINvL3kagR+fAcn5SdGhkZxmnTk3k+RxOm4XTPkOOjvWj/ E25C898OmRFmkWyTZGklJkFKq/P4gmwzApaUeUu2xyoTpJIUdcFFTptzTnshi+PNaBtLyXwl 0Y9mzkhxqlrHZXJcLqf9XyVYD79ClIiutFTuXQqtH+uo6k68tLv8qe3oV8+DNLH/6NhcxNWD O48H/6Q+BvFeYZayIbsnTfibIroDtlmGfZ63L9BlD2t11zJfRWR8DokiGuQ7/BUrmvzYuOk/ YvmX0KJxZX8fZcoPtB63p9lO4X1k+8P1spcn1/2Wkyt0JYkNysnBvzKKT1NHhJBaXv0PPKxq 9GQDAAA= Archived-At: Cc: "ccamp@ietf.org" , "huubatwork@gmail.com" Subject: Re: [CCAMP] ODU4 and ODUCn discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:51:19 -0000 --_000_AM2PR07MB09947BEA72A75F0DF6F57B3DF08A0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpJdOKAmXMgZ3JlYXQgdG8gc2VlIHN1Y2ggYW4gZW50aHVzaWFzbSBpbiB0aGlzIG5l dyB0b3BpYy4NCg0KV2XigJlyZSBjb250cmlidXRpb24gZHJpdmVuLCBpZiB5b3UgZmVlbCB0aGUg bmVlZCB0byBzdWJtaXQgc2VwYXJhdGUgZnJhbWV3b3JrIGFuZCBlbmNvZGluZyBkcmFmdHMgcGxl YXNlIGRvIHNvLCBvbiB0aGUgb3RoZXIgaGFuZCBpZiB5b3UgdGhpbmsgdGhhdCBhbiBlbmNvZGlu ZyBkb2N1bWVudCB3aXRoIGFuIGV4cGxhaW5pbmcgaW50cm8gaXMgb2ssIHRoYXTigJlzIGZpbmUg dG9vLg0KTGV04oCZcyBzZWUgd2hhdCBjb21lcyBvdXQgYW5kIHRoZW4gd2XigJlsbCBkZWNpZGUg d2hhdCBhbmQgaG93IHRvIGFkb3B0IGluIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpPbmNlIGFnYWlu IEkgd291bGQgbGlrZSB0byByZW1pbmQgdGhhdCB0aGUgbmV3IElFU0cgc3RhdGVtZW50IGRvZXNu 4oCZdCBtZWFuIHRoYXQgd2Ugbm8gbG9uZ2VyIG5lZWQgc3VwcG9ydCBkb2N1bWVudGF0aW9uLCBp dOKAmXMganVzdCB0aGF0IEkgbWlnaHQgYmUgbWFuYWdlZCBkaWZmZXJlbnRseS4NCg0KVGhhbmtz DQpEYW5pZWxlDQoNCg0KRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSWZ0ZWtoYXIgSHVzc2Fpbg0KU2VudDogbWVyY29sZWTDrCAyMyBub3Zl bWJyZSAyMDE2IDIyOjU4DQpUbzogRGlldGVyIEJlbGxlciA8RGlldGVyLkJlbGxlckBub2tpYS5j b20+OyB3YW5nLnFpbGVpQHp0ZS5jb20uY247IEdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVuaXBl ci5uZXQ+DQpDYzogY2NhbXBAaWV0Zi5vcmc7IGh1dWJhdHdvcmtAZ21haWwuY29tDQpTdWJqZWN0 OiBSZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNClllcywgYWdyZWUgaXQg c2hvdWxkIGxldmVyYWdlIFJGQyA3MTM5IGFzIG11Y2ggYXMgcG9zc2libGUgYW5kIGZvbGxvdyBz aW1pbGFyIGFwcHJvYWNoLiAgVG8gYmVnaW4gd2l0aCBzaG91bGQgc3RhcnQgd2l0aCB1c2UgY2Fz ZXMsIHJlcXVpcmVtZW50cywgYW5kIG5lY2Vzc2FyeSBzb2x1dGlvbnMgKEdNUExTIHNpZ25hbGlu ZyBhbmQgcmVxdWlyZWQgZXh0ZW5zaW9uKS4NCg0KSWZ0ZWtoYXINCkZyb206IERpZXRlciBCZWxs ZXIgW21haWx0bzpEaWV0ZXIuQmVsbGVyQG5va2lhLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMjMsIDIwMTYgODo1MCBBTQ0KVG86IHdhbmcucWlsZWlAenRlLmNvbS5jbjxtYWlsdG86 d2FuZy5xaWxlaUB6dGUuY29tLmNuPjsgR2VydCBHcmFtbWVsDQpDYzogY2NhbXBAaWV0Zi5vcmc8 bWFpbHRvOmNjYW1wQGlldGYub3JnPjsgaHV1YmF0d29ya0BnbWFpbC5jb208bWFpbHRvOmh1dWJh dHdvcmtAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlz Y3Vzc2lvbg0KDQpIaSBhbGwsDQoNCkkgd291bGQgc3VibWl0IHRoYXQgd2UgbmVlZCBhIGRvY3Vt ZW50IHNpbWlsYXIgdG8gUkZDIDcxMzk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcx Mzk+IChHTVBMUyBTaWduYWxpbmcgRXh0ZW5zaW9ucyBmb3IgQ29udHJvbCBvZiBFdm9sdmluZyBH LjcwOSBPcHRpY2FsIFRyYW5zcG9ydA0KTmV0d29ya3MpIGZvciB0aGUgbmV3IE9EVUNuIHNpZ25h bCB0eXBlcy4NCg0KUkZDIDcxMzk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxMzk+ IGNvbnRhaW5zIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gYW5kIGRlc2NyaXB0aW9ucyByZWdhcXJk aW5nIHRoZSBuZXcgRy43MDkgc2lnbmFsIHR5cGVzIGludHJvZHVjZWQgaW4gdGhlIEZlYiAyMDEy IHJldmlzaW9uIG9mIEcuNzA5Lg0KDQpJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gdGFrZSBhIGRp ZmZlcmVudCBhcHByb2FjaCBmb3IgdGhlIGxhdGVzdCAyMDE2IGV2b2x1dGlvbiBvZiBHLjcwOS4N Cg0KDQpUaGFua3MsDQpEaWV0ZXINCk9uIDIzLjExLjIwMTYgMTY6MzgsIHdhbmcucWlsZWlAenRl LmNvbS5jbjxtYWlsdG86d2FuZy5xaWxlaUB6dGUuY29tLmNuPiB3cm90ZToNCkhpIEdlcnQsDQoN ClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gRm9sbG93aW5nIGlzIG15IGFuc3dlciB0byB5b3Vy IHByZXZpb3VzIG1haWwgYW5kIHRoaXMgb25lLg0KDQooMSksIEFib3V0IHRoZSBxdWVzdGlvbnMg aW4geW91ciBwcmV2aW91cyBtYWlsLiBJIHRoaW5rIHlvdSBhbHJlYWR5IGhhdmUgbWFueSBvZiB0 aGVtIHNvbHZlZC4gT0RVQ24gaGFzIGFsbW9zdCB0aGUgc2FtZSBvdmVyaGVhZCBhcyB0aGF0IG9m IE9EVWssIHNvIEkgZG9uJ3QgdGhpbmsgc29tZSBtZWNoYW5pc21zIG9mIE9EVUNuIChlLmcuLCBP QU0gZXRjKSBkaWZmZXIgZnJvbSB0aG9zZSBvZiBPRFVrLiBJbiB0aGUgT0RVQ24gZHJhZnQsIEkg dGhpbmsgd2Ugc2hvdWxkIG1haW5seSBwYXkgYXR0ZW50aW9uIHRvIE9EVUNuJ3MgZmVhdHVyZSBh bmQgaXRzIGRpZmZlcmVuY2Ugd2l0aCBPRFVrIG5vdywgc3VjaCBhcyBsYXllciBtb2RlbCBvZiBP RFVDbiBhbmQgc2V0dXAgb2YgT0RVQ24gY29ubmVjdGlvbi4NCg0KKDIpLCBBYm91dCB0aGUgcXVl c3Rpb25zIGluIHRoZSBzZWNvbmQgaXRlbXMgb2YgdGhpcyB0aHJlYWQuIEkgdGhpbmsgaXQncyBv dXQgb2YgdGhlIHNjb3BlIG9mIENDQU1QLiBJIGNhbid0IGdpdmUgYSBkZWZpbml0ZSBhbnN3ZXIg dG8gdGhlc2UgcXVlc3Rpb25zLg0KDQooMyksIENvbnRyb2wgb2Ygb3B0aWNhbCBuZXR3b3JrIGlz IG91dCBvZiB0aGUgc2NvcGUgb2YgY3VycmVudCBPRFVDbiBkb2N1bWVudC4gV2Ugd2lsbCBub3Qg aW52b2x2ZSB0aGlzIHBhcnQgaW4uIEFsc28gSSBzdWdnZXN0IHlvdSB0YWtlIGEgbG9vayBhdCBS RkM3Njk4LCB3aGljaCBtYWlubHkgZm9jdXMgb24gdGhlIGNvbnRyb2wgb2YgZmxleGlibGUgZ3Jp ZCBuZXR3b3JrLg0KDQpUaGFua3MNClFpbGVpDQoNCkdlcnQgR3JhbW1lbCA8Z2dyYW1tZWxAanVu aXBlci5uZXQ+PG1haWx0bzpnZ3JhbW1lbEBqdW5pcGVyLm5ldD4NCuWPkeS7tuS6ujogICJDQ0FN UCIgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn Pg0KDQoyMDE2LzExLzIzIDIxOjAxDQoNCuaUtuS7tuS6ug0KDQpEYW5pZWxlIENlY2NhcmVsbGkg PGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+PG1haWx0bzpkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tPiwgImNjYW1wQGlldGYub3JnIjxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ IDxjY2FtcEBpZXRmLm9yZz48bWFpbHRvOmNjYW1wQGlldGYub3JnPiwNCg0K5oqE6YCBDQoNCiJo dXViYXR3b3JrQGdtYWlsLmNvbSI8bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiA8aHV1YmF0 d29ya0BnbWFpbC5jb20+PG1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4NCg0K5Li76aKYDQoN ClJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KRGFu aWVsZSwgQXV0aG9ycywNCg0KQWZ0ZXIgb3VyIGluaXRpYWwgZW1haWwgZXhjaGFuZ2UgSSB0b29r IGEgbW9yZSBkZXRhaWxlZCBsb29rIGluIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkuIEluIGVz c2VuY2UsIHRoZSAyMDE2IHZlcnNpb24gb2YgRy43MDkgd291bGQgaW1wYWN0IGNvbnRyb2wgcGxh bmUgd29yayBmb3IgRy43MDkgKFJGQzcxMzkpIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYxNjMp LiBUaGUgY29tcGxleCBuYXR1cmUgb2YgdGhvc2UgZGVmaW5pdGlvbnMgd2lsbCBjZXJ0YWlubHkg bm90IGJlIGFuIGVhc3ktZ29pbmcgZXh0ZW5zaW9uIGFzIGl0IGhhZCBiZWVuIGVudmlzYWdlZCBz byBmYXIuIFdyaXRpbmcgYSDigJxsaXR0bGUgcGllY2Ugb2YgdGV4dOKAnSBsb29rcyB0byBtZSBs aWtlIGEg4oCcbGl0dGxlIGJpdCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gSWYgdGhlIFdHIGludGVu ZHMgdG8gd29yayBvbiB0aGUgc3ViamVjdCwgbXkgcGxlZGdlIHdvdWxkIGJlIHRvIHN0YXJ0IGZy b20gYSBmcmFtZXdvcmsgZG9jdW1lbnQgdG8gY2FwdHVyZSB0aGUgbmV3IGNvbmNlcHRzIGJlZm9y ZSBkZWZpbmluZyBwcm90b2NvbCBleHRlbnNpb25zLg0KDQpCZXN0DQoNCkdlcnQNCg0KDQpCZWxv dyBhIGxpc3Qgb2Ygb2JzZXJ2YXRpb25zIHRoYXQgaW5mbHVlbmNlZCB0aGlzIHZpZXc6DQoxLiAg ICAgICBPUFVDbiwgT0RVQ24gYW5kIE9UVUNuIGFyZSBuZXcgYW5kIHRoZSBsYXllcmluZyByZWxh dGlvbnNoaXAgdG8gdGhlIGZvcm1lciBzdHJ1Y3R1cmUgaXMgYSBiaXQgc3VycHJpc2luZywgYXMg dGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgKHNlZSBiZWxvdykgc2hvd2VkLiBCZXR0ZXIgdG8g Z2V0IHRoaXMgcmlnaHQgZWFybHkgb24NCjIuICAgICAgIEZpZ3VyZSA3LTEgc2hvd3MgdGhlIE9U TiBtdWx0aXBsZXhpbmcgYW5kIG1hcHBpbmcgc3RydWN0dXJlcyBidXQgZG9lcyBub3QgaW5kaWNh dGUgaG93IGUuZy4gYSA0MDBHRSB3b3VsZCBiZSBtYXBwZWQgaW50byB0aGlzIHN0cnVjdHVyZS4g SXQgaXMgbm90IHN1cnByaXNpbmcgYXMgNDAwR0UgaXMgc3RpbGwgaW4gdGhlIG1ha2luZ3MsIGJ1 dCByYWlzZXMgYSBmZXcgcXVlc3Rpb25zIGFib3V0IGhvdyBpdCBpcyBwbGFubmVkIHRvIGJlIG1h cHBlZC4gSG93ZXZlciBndWlkYW5jZSBmcm9tIFNHMTUgd291bGQgaGVscCB0byBnZXQgdGhlIHBy b3RvY29sIGFyY2hpdGVjdHVyZSBmdXR1cmUgcHJvb2YuDQphLiAgICAgICBEb2VzIGV2ZXJ5IGNs aWVudCBzaWduYWwgbmVlZCB0byBiZSB3cmFwcGVkIGludG8gYW4gT1BVay9PRFVrIGJlZm9yZSBp dCBjYW4gYmUgdHJhbnNwb3J0ZWQgdmlhIGFuIE9QVUNuL09EVUNuPyDihpIgdGhpcyB3b3VsZCBt ZWFuIHRvIGV4dGVuZCB0aGUgT0RVIHN0cnVjdHVyZSBieSBhbiBPRFU1LDYsNyBldGMuIGZvciBj bGllbnRzID4gMTAwRw0KYi4gICAgICAgV2lsbCBvbmx5IGNsaWVudCBzaWduYWxzIDw9IDEwMEcg bmVlZCB0byBiZSB3cmFwcGVkIGluIGFuIE9QVWsvT0RVayBiZWZvcmUgaXQgY2FuIGJlIHRyYW5z cG9ydGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8g4oaSIHRoaXMgd291bGQgbWVhbiB0aGF0IHRoZXJl IHdpbGwgYmUgYSBicmVhayBpbiB0aGUgbWFwcGluZ3MgYXQgYWJvdXQgMTAwRyBzaWduYWxzIGFu ZCBubyBPRFU1LDYsNyB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQNCmMuICAgICAgIFdpbGwgZnV0 dXJlIGNsaWVudHMgYmUgbWFwcGVkIGRpcmVjdGx5IGludG8gT1BVQ24vT0RVQ24gYW5kIHRoZSBz cGVjaWFsIGNhc2Ugb2YgMTAwR0XihpJPUFVrL09EVWvihpJPUFVDbi9PRFVDbiB3aWxsIGJlY29t ZSBqdXN0IGFub3RoZXIgb3B0aW9uPyAoTm90ZTogdGhlIGZpZ3VyZSBleHBsaWNpdGx5IGFsbG93 cyBmb3IgcHJvcHJpZXRhcnkgbWFwcGluZ3MgZGlyZWN0bHkgaW50byBPUFVDbi9PRFVDbiB3aGlj aCBsb29rcyBsaWtlIGEgcHJhY3RpY2FsIHVzZSBjYXNlLCBidXQgaXQgbG9va3Mgb2RkIHRoYXQg aXQgcmVtYWlucyBwcm9yaWV0YXJ5KQ0KMy4gICAgICAgVGhlIHNlY3Rpb24g4oCcNy4xIE1hcHBp bmfigJ0gYW5kIOKAnDcuMiBXYXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleOKAnSBjaGFuZ2Vk IGEgYml0IGZyb20gdGhlIDIwMTIgdmVyc2lvbi4gQXMgYWNyb255bXMgaGF2ZSBjaGFuZ2VkIHRv bywgYSAxOjEgY29tcGFyaXNvbiBpcyBub3QgdG9vIHNpbXBsZS4gVGhlIHRha2Vhd2F5IGlzIHRo YXQgYW4gT1RVIGNhbiBiZSBtYXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoIG9yIHNwcmVh ZCBhY3Jvc3Mgc29tZSAoT1RMay5uIGFuZCBPVExDLm4pIHdoaWNoIG1lYW5zIGludmVyc2UgbXVs dGlwbGV4aW5nLiBTbyBmYXIgdGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJG QzcxMzkgb3IgUkZDNjE2My4NCjQuICAgICAgIEluIFNlY3Rpb24g4oCcNi4xLjEgT1ROIGRpZ2l0 YWwgc3RydWN0dXJl4oCdIGl0IGlzIGV4cGxhaW5lZCB0aGF0IGFuIE9UVWsgY29udGFpbnMgYSBG RUMsIGJ1dCBPVFVDbiBkb2VzIG5vdCwgbGVhdmluZyBpdCB0byB0aGUgaW50ZXJmYWNlIHRvIGFw cGx5IHNvbWUuIFRoaXMgYmFzaWNhbGx5IGNyZWF0ZXMgYSBGRUMgbGF5ZXIgYmVsb3cgdGhlIE9U VUNuIHRoYXQgd2lsbCBub3QgYmUgZGVmaW5lZCBpbiBHLjcwOS4gQSBjb250cm9sIHBsYW5lIHdv dWxkIG5lZWQgdG8gY2hlY2sgY29tcGF0aWJpbGl0eSBvZiB3YXZlbGVuZ3RoLCBtb2R1bGF0aW9u LCBpbnRlcmZhY2VzIChpLmUuIGhvdyBtYW55IGxhbmVzKSBhbmQgY29tcGF0aWJpbGl0eSBvZiBG RUMsIGFzIHdlbGwgYXMgdXNhZ2Ugb2YgT1RVayB2cyBPVFVDbi4gQWxzbyB0aGlzIGNhc2UgaGFz IG5vdCBiZWVuIGNvbnNpZGVyZWQgaW4gUkZDNzEzOSBvciBSRkM2MTYzLg0KNS4gICAgICAgVGhl cmUgaXMgYWxzbyBhIG5ldyBPTVMgTVNJIChzZWN0IDE1LjQpIG92ZXJoZWFkIGRlZmluZWQsIHdo aWNoIHByb3ZpZGVzIGEgbGlzdCBvZiBPQ2ggYW5kIE9UU2lBIGZyZXF1ZW5jeSBzbG90LHBvcnQg bnVtYmVycyBhbmQgYSBsaXN0IG9mIG1lZGlhIGNoYW5uZWxzIChmcmVxdWVuY3kgc2xvdCwgbWVk aWEgY2hhbm5lbCBwb3J0IG51bWJlcnMpIHRvIGRlY29kZSB0aGUgbGFuZXMgY29ycmVjdGx5LiBU aGlzIG1heSBhZmZlY3QgUkZDNjE2Mw0KNi4gICAgICAgVGhlIHRlcm0g4oCcV2F2ZWxlbmd0aCBE aXZpc2lvbiBNdWx0aXBsZXjigJ0gaW4gdGhlIHNlY3Rpb25zIGFib3ZlIGRvZXNu4oCZdCBpbXBs eSBhIHdhdmVsZW5ndGggY2FuIGJlIHJvdXRlZCB0aHJvdWdoIGEgRFdETSBuZXR3b3JrIHNpbmNl IHdlIGtub3cgdGhhdCBlLmcuIDEwMEcgaW50ZXJmYWNlcyBhcmUgbm90IHlldCBkZWZpbmVkIGJ5 IFNHMTUgZm9yIGFtcGxpZmllZCBEV0RNIGFwcGxpY2F0aW9ucy4gV2l0aG91dCBhbXBsaWZpZXJz LCB0aGUgZGlzdGFuY2Ugc3VwcG9ydGVkIGJ5IHN1Y2ggRFdETSBpcyBsaWtlbHkgbGltaXRlZCB0 byBiZWxvdyA4MC0xMDBrbS4gSXQgaXMgbm90IHlldCBjbGVhciBieSB3aGVuIHRoaXMgbGltaXRh dGlvbiB3aWxsIGJlIGxpZnRlZCBieSBTRzE1IChzZWUgZHJhZnQtbWFueS1jb2hlcmVudC1kd2Rt LWlmLWNvbnRyb2wtMDApLiBBZnRlciBhbGwsIE9UVTQgYmFzZWQgMTAwRyBpbnRlcmZhY2VzIGZv ciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhbmQgaGF2ZSBldmVu IGJlZW4gcHJvdmVuIHRvIGJlIGludGVyb3BlcmFibGUgYW1vbmcgbXVsdGlwbGUgdmVuZG9ycyBj b3ZlcmluZyBkaXN0YW5jZXMgPjEwMDBrbS4gIEhvd2V2ZXIsIHRvIHN0YXkgaW4gdGhlIHN0YW5k YXJkcyBmcmFtZXdvcmsgZm9yIG5vdywgUkZDNjE2MyB3b3VsZCBuZWVkIHRvIGNvbnNpZGVyOg0K YS4gICAgICAgV2hpbGUgYSBPVFVDbiBjYW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBt YXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QgYmUgcm91dGVkIGluIFdT T04g4oaSIG5vIDEwMEcgaW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZp bmVkIGluIEcuNjk4LjINCmIuICAgICAgIEFuIE9UVUNuIG1heSBiZSBicm9rZW4gZG93biBpbnRv IDQgbGFuZXMgYXQgMjVHIChPVEw0LjQpIGJ1dCBzdGlsbCBjYW7igJl0IGJlIHJvdXRlZCBpbiBX U09OIOKGkiBubyAyNUcgaW50ZXJmYWNlcyBpbiBhbXBsaWZpZWQgRFdETSBuZXR3b3JrcyBkZWZp bmVkIGluIEcuNjk4LjINCmMuICAgICAgIEFuIE9UVTMgKD00MEcpIGNhbiBiZSBicm9rZW4gZG93 biBpbiBPVEwzLjQgcHJvdmlkaW5nIDQgbGFuZXMgYXQgMTBHIGVhY2gg4oaSIDEwRyBpbnRlcmZh Y2VzIGFyZSBhbGxvd2VkIGluIGFtcGxpZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42 OTguMg0KDQoNCg0KDQoNCg0KRnJvbTogQ0NBTVAgPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+PG1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGFuaWVsZSBDZWNjYXJl bGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjxtYWlsdG86ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbT4NCkRhdGU6IEZyaWRheSAxOCBOb3ZlbWJlciAyMDE2IGF0IDIw OjAyDQpUbzogImh1dWJhdHdvcmtAZ21haWwuY29tIjxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5j b20+IDxodXViYXR3b3JrQGdtYWlsLmNvbT48bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiwg Q0NBTVAgPGNjYW1wQGlldGYub3JnPjxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uDQoNClRoYW5rIEh1dWIsDQoNCkF1 dGhvcnMsIGlmIHlvdSBjb3VsZCBoYXZlIGEgbGl0dGxlIHBpZWNlIG9mIHRleHQgZGVzY3JpYmlu ZyB0aGlzIGNvbnNpZGVyYXRpb24gaW4gdGhlIGZyYW1ld29yayBvciBpbiBvbmUgb2YgdGhlIHNv bHV0aW9uIGRvY3VtZW50cyAoZGVwZW5kaW5nIHdoYXQgYXJlIHRoZSBwbGFucyBmb3IgdGhlIG1l cmdlKSB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0KDQpUaGFua3MNCkRhbmllbGUNCg0KRnJvbTogSHV1 YiB2YW4gSGVsdm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NClNlbnQ6IHZlbmVy ZMOsIDE4IG5vdmVtYnJlIDIwMTYgMTk6MzENClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+PG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJp Y3Nzb24uY29tPjsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpEYW5pZWxlLA0KDQpZ b3Ugd3JpdGU6DQpUaGFua3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLg0KDQpZb3Un cmUgd2VsY29tZS4NCg0KDQoNCkkgc2VlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHRoYXQgYm90 aCBtYWtlIHNlbnNlLg0KDQpJIGhhdmUgdG8gZGlzYWdyZWUgKGFnYWluKS4NCg0KDQoNClRoZSBv bmUgcHJvcG9zZWQgYnkgR2VydCBpcyBzdGl0Y2hpbmcgb2YgYW4gT0RVNCBhbmQgT0RVQzEsDQoN ClRoaXMgdXNlIGNhc2UgaXMgaW1wb3NzaWJsZS4gQXMgeW91IGNhbiBzZWUgaW4gRy43MDkgKDIw MTYpIGZpZ3VyZSA3LTENCmEgbG93ZXIgb3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hl ciBvcmRlciBPRFVDMSwgYW5kIHRoaXMNCm1lYW5zIHRoYXQgdGhleSBjb25zdGl0dXRlIGRpZmZl cmVudCBsYXllcnMgaW4gdGhlIE9UTi4NCkFuZCBhcmUgaW1wb3NzaWJsZSB0byBzdGl0Y2guDQoN Cg0KDQp3aGlsZSB0aGUgb25lIHlvdSBhcmUgZGVzY3JpYmluZyBpcyB0dW5uZWxpbmcgb2YgT0RV NCBvdmVyIGFuIE9EVUMxIHRyYWlsLg0KDQpDb3JyZWN0Lg0KDQoNCg0KVGhleSBib3RoIHNlZW1z IHJlYXNvbmFibGUgdG8gbWUsIHdoeSB0aGUgc3RpdGNoaW5nIGlzIG5vdCBmZWFzaWJsZT8NCg0K SSB0cmllZCB0byBleHBsYWluIGFib3ZlLg0KDQpCZXN0IHJlZ2FyZHMsIEh1dWIuDQoNCg0KDQoN CkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEh1dWIgdmFuIEhlbHZvb3J0DQpTZW50OiBnaW92ZWTDrCAxNyBub3ZlbWJyZSAyMDE2IDE3OjA2 DQpUbzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbg0KDQpIZWxsbyBHZXJ0LA0KDQpZb3Vy IHVzZSBjYXNlIGlzIG5vdCBjb21wbGV0ZWx5IGNvcnJlY3QuDQoNCkluc3RlYWQgb2Y6DQoxLiAg ICAgIEEgdXNlIGNhc2UgdG8gY29uc2lkZXIgaXM6DQoNCiAgICAgICArLS0tLS0tLS0tLSsgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0K MTAwR0UtLXwtR01QLU9EVTQtfC1PVFU0LS0tT1RVNC18LU9EVTQtR01QLU9EVUMxLXwtT1RVQzEt LS1PVFVDMS18LU9EVUMxLUdNUC18LS0xMDBHRQ0KICAgICAgICstLS0tLS0tLS0tKyAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgTkUxICAgICAgICAgICAgICAgICAgICBORTIgKD1HVy1ORSkgICAgICAgICAgICAg ICAgICAgICAgIE5FMw0KDQpJdCBzaG91bGQgYmU6DQogICAgICAgKy0tLS0tLS0tLS0rICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLSsNCjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18 LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0UNCiAgICAgICArLS0t LS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgIE5FMSAgICAgICAgICAgICAgICAgICAg TkUyICg9R1ctTkUpICAgICAgICAgICAgICAgICAgICAgICBORTMNCg0KVGhlIE9EVUMxIGZyb20g TkUyIHRvIE5FMyB0dW5uZWxzIHRoZSBPRFU0Lg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0KDQoN Ci0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1c3Qg bGlrZSBldmVyeW9uZSBlbHNlLi4uX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkND QU1QQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkNDQU1QIG1haWxpbmcgbGlzdA0KDQpDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NBTVBAaWV0Zi5v cmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0K --_000_AM2PR07MB09947BEA72A75F0DF6F57B3DF08A0AM2PR07MB0994eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6aW5oZXJp dDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1pY3Jvc29mdCBKaGVuZ0hlaSI7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIFwsIHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5ncmV5DQoJe21zby1zdHlsZS1uYW1lOmdyZXk7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iSVQiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdOKA mXMgZ3JlYXQgdG8gc2VlIHN1Y2ggYW4gZW50aHVzaWFzbSBpbiB0aGlzIG5ldyB0b3BpYy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+V2XigJlyZSBjb250cmlidXRpb24gZHJpdmVuLCBpZiB5b3UgZmVlbCB0aGUg bmVlZCB0byBzdWJtaXQgc2VwYXJhdGUgZnJhbWV3b3JrIGFuZCBlbmNvZGluZyBkcmFmdHMgcGxl YXNlIGRvIHNvLCBvbiB0aGUNCiBvdGhlciBoYW5kIGlmIHlvdSB0aGluayB0aGF0IGFuIGVuY29k aW5nIGRvY3VtZW50IHdpdGggYW4gZXhwbGFpbmluZyBpbnRybyBpcyBvaywgdGhhdOKAmXMgZmlu ZSB0b28uDQo8YnI+DQpMZXTigJlzIHNlZSB3aGF0IGNvbWVzIG91dCBhbmQgdGhlbiB3ZeKAmWxs IGRlY2lkZSB3aGF0IGFuZCBob3cgdG8gYWRvcHQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+T25jZSBhZ2FpbiBJIHdvdWxkIGxpa2UgdG8gcmVtaW5kIHRoYXQgdGhlIG5l dyBJRVNHIHN0YXRlbWVudCBkb2VzbuKAmXQgbWVhbiB0aGF0IHdlIG5vIGxvbmdlciBuZWVkIHN1 cHBvcnQgZG9jdW1lbnRhdGlvbiwNCiBpdOKAmXMganVzdCB0aGF0IEkgbWlnaHQgYmUgbWFuYWdl ZCBkaWZmZXJlbnRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EYW5pZWxlJm5ic3A7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPiBDQ0FNUCBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPklmdGVraGFyIEh1c3NhaW48YnI+DQo8Yj5TZW50OjwvYj4gbWVyY29sZWTD rCAyMyBub3ZlbWJyZSAyMDE2IDIyOjU4PGJyPg0KPGI+VG86PC9iPiBEaWV0ZXIgQmVsbGVyICZs dDtEaWV0ZXIuQmVsbGVyQG5va2lhLmNvbSZndDs7IHdhbmcucWlsZWlAenRlLmNvbS5jbjsgR2Vy dCBHcmFtbWVsICZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IGNj YW1wQGlldGYub3JnOyBodXViYXR3b3JrQGdtYWlsLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgYWdyZWUgaXQgc2hv dWxkIGxldmVyYWdlIFJGQyA3MTM5IGFzIG11Y2ggYXMgcG9zc2libGUgYW5kIGZvbGxvdyBzaW1p bGFyIGFwcHJvYWNoLiZuYnNwOyBUbyBiZWdpbiB3aXRoIHNob3VsZCBzdGFydCB3aXRoIHVzZSBj YXNlcywgcmVxdWlyZW1lbnRzLA0KIGFuZCBuZWNlc3Nhcnkgc29sdXRpb25zIChHTVBMUyBzaWdu YWxpbmcgYW5kIHJlcXVpcmVkIGV4dGVuc2lvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmdGVraGFyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+IERpZXRlciBCZWxsZXIgWzxhIGhyZWY9Im1haWx0bzpEaWV0ZXIuQmVs bGVyQG5va2lhLmNvbSI+bWFpbHRvOkRpZXRlci5CZWxsZXJAbm9raWEuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDIzLCAyMDE2IDg6NTAgQU08YnI+DQo8 Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp3YW5nLnFpbGVpQHp0ZS5jb20uY24iPndhbmcucWls ZWlAenRlLmNvbS5jbjwvYT47IEdlcnQgR3JhbW1lbDxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzpodXViYXR3b3JrQGdtYWlsLmNvbSI+DQpodXViYXR3b3JrQGdtYWlsLmNvbTwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+SGkgYWxsLDxicj4NCjxicj4NCkkgd291bGQgc3VibWl0IHRoYXQgd2UgbmVlZCBhIGRvY3Vt ZW50IHNpbWlsYXIgdG8gPHNwYW4gY2xhc3M9ImdyZXkiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MTM5Ij5SRkMgNzEzOTwvYT4gKEdNUExTIFNpZ25hbGluZyBFeHRl bnNpb25zIGZvciBDb250cm9sIG9mIEV2b2x2aW5nIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0PC9z cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJncmV5Ij5OZXR3b3JrcykgZm9yIHRoZSBuZXcgT0RVQ24g c2lnbmFsIHR5cGVzLiA8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImdyZXkiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTM5Ij5SRkMgNzEzOTwvYT48L3Nw YW4+IGNvbnRhaW5zIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gYW5kIGRlc2NyaXB0aW9ucyByZWdh cXJkaW5nIHRoZSBuZXcgRy43MDkgc2lnbmFsIHR5cGVzIGludHJvZHVjZWQgaW4gdGhlIEZlYiAy MDEyIHJldmlzaW9uIG9mIEcuNzA5Lg0KPGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayB3ZSBuZWVk IHRvIHRha2UgYSBkaWZmZXJlbnQgYXBwcm9hY2ggZm9yIHRoZSBsYXRlc3QgMjAxNiBldm9sdXRp b24gb2YgRy43MDkuPGJyPg0KPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkRpZXRlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gMjMuMTEuMjAxNiAxNjozOCwgPGEgaHJlZj0ibWFpbHRvOndhbmcucWlsZWlAenRl LmNvbS5jbiI+DQp3YW5nLnFpbGVpQHp0ZS5jb20uY248L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSBHZXJ0LDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gRm9sbG93aW5nIGlzIG15IGFuc3dl ciB0byB5b3VyIHByZXZpb3VzIG1haWwgYW5kIHRoaXMgb25lLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPigx KSwgQWJvdXQgdGhlIHF1ZXN0aW9ucyBpbiB5b3VyIHByZXZpb3VzIG1haWwuIEkgdGhpbmsgeW91 IGFscmVhZHkgaGF2ZSBtYW55IG9mIHRoZW0gc29sdmVkLiBPRFVDbiBoYXMgYWxtb3N0IHRoZSBz YW1lIG92ZXJoZWFkIGFzIHRoYXQgb2YgT0RVaywgc28gSSBkb24ndCB0aGluayBzb21lIG1lY2hh bmlzbXMNCiBvZiBPRFVDbiAoZS5nLiwgT0FNIGV0YykgZGlmZmVyIGZyb20gdGhvc2Ugb2YgT0RV ay4gSW4gdGhlIE9EVUNuIGRyYWZ0LCBJIHRoaW5rIHdlIHNob3VsZCBtYWlubHkgcGF5IGF0dGVu dGlvbiB0byBPRFVDbidzIGZlYXR1cmUgYW5kIGl0cyBkaWZmZXJlbmNlIHdpdGggT0RVayBub3cs IHN1Y2ggYXMgbGF5ZXIgbW9kZWwgb2YgT0RVQ24gYW5kIHNldHVwIG9mIE9EVUNuIGNvbm5lY3Rp b24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+KDIpLCBBYm91dCB0aGUgcXVlc3Rpb25zIGluIHRoZSBzZWNv bmQgaXRlbXMgb2YgdGhpcyB0aHJlYWQuIEkgdGhpbmsgaXQncyBvdXQgb2YgdGhlIHNjb3BlIG9m IENDQU1QLiBJIGNhbid0IGdpdmUgYSBkZWZpbml0ZSBhbnN3ZXIgdG8gdGhlc2UgcXVlc3Rpb25z Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPigzKSwgQ29udHJvbCBvZiBvcHRpY2FsIG5ldHdvcmsgaXMgb3V0 IG9mIHRoZSBzY29wZSBvZiBjdXJyZW50IE9EVUNuIGRvY3VtZW50LiBXZSB3aWxsIG5vdCBpbnZv bHZlIHRoaXMgcGFydCBpbi4gQWxzbyBJIHN1Z2dlc3QgeW91IHRha2UgYSBsb29rIGF0IFJGQzc2 OTgsIHdoaWNoIG1haW5seSBmb2N1cw0KIG9uIHRoZSBjb250cm9sIG9mIGZsZXhpYmxlIGdyaWQg bmV0d29yay48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YnI+DQo8YnI+DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlFpbGVpPGJyPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9 IjM2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDozNi4wJTtwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+R2Vy dCBHcmFtbWVsDQo8YSBocmVmPSJtYWlsdG86Z2dyYW1tZWxAanVuaXBlci5uZXQiPiZsdDtnZ3Jh bW1lbEBqdW5pcGVyLm5ldCZndDs8L2E+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPC9zcGFu Pjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjogJm5ic3A7JnF1b3Q7Q0NBTVAmcXVvdDsNCjxhIGhyZWY9Im1haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnIj4mbHQ7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+PC9zcGFu PiA8bzpwPg0KPC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4yMDE2LzExLzIzIDIxOjAxPC9z cGFuPg0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyUiIHZhbGlnbj0idG9w IiBzdHlsZT0id2lkdGg6NjMuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7Ij7mlLbku7bkuro8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRhbmllbGUgQ2VjY2FyZWxsaQ0KPGEgaHJlZj0ibWFp bHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPiZsdDtkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tJmd0OzwvYT4sDQo8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmci PiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0 Zi5vcmciPg0KJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvYT4sIDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmln aHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5oqE6YCBPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBo cmVmPSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPiZxdW90O2h1dWJhdHdvcmtAZ21haWwu Y29tJnF1b3Q7PC9hPg0KPGEgaHJlZj0ibWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tIj4mbHQ7 aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PC9hPjwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHls ZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS4uzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSZxdW90OyxzYW5z LXNlcmlmIj7popg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlOiBbQ0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Np b248L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhbmllbGUsIEF1dGhvcnMsPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkFmdGVyIG91ciBpbml0aWFsIGVtYWlsIGV4Y2hhbmdlIEkgdG9v ayBhIG1vcmUgZGV0YWlsZWQgbG9vayBpbiB0aGUgMjAxNiB2ZXJzaW9uIG9mIEcuNzA5LiBJbiBl c3NlbmNlLCB0aGUgMjAxNiB2ZXJzaW9uIG9mIEcuNzA5IHdvdWxkIGltcGFjdCBjb250cm9sIHBs YW5lIHdvcmsgZm9yIEcuNzA5IChSRkM3MTM5KQ0KIGFzIHdlbGwgYXMgZm9yIFdTT04gKFJGQzYx NjMpLiBUaGUgY29tcGxleCBuYXR1cmUgb2YgdGhvc2UgZGVmaW5pdGlvbnMgd2lsbCBjZXJ0YWlu bHkgbm90IGJlIGFuIGVhc3ktZ29pbmcgZXh0ZW5zaW9uIGFzIGl0IGhhZCBiZWVuIGVudmlzYWdl ZCBzbyBmYXIuIFdyaXRpbmcgYSDigJxsaXR0bGUgcGllY2Ugb2YgdGV4dOKAnSBsb29rcyB0byBt ZSBsaWtlIGEg4oCcbGl0dGxlIGJpdCBvZiB1bmRlcnN0YXRlbWVudOKAnS4gSWYgdGhlIFdHIGlu dGVuZHMgdG8gd29yaw0KIG9uIHRoZSBzdWJqZWN0LCBteSBwbGVkZ2Ugd291bGQgYmUgdG8gc3Rh cnQgZnJvbSBhIGZyYW1ld29yayBkb2N1bWVudCB0byBjYXB0dXJlIHRoZSBuZXcgY29uY2VwdHMg YmVmb3JlIGRlZmluaW5nIHByb3RvY29sIGV4dGVuc2lvbnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkJlc3Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+R2VydDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJlbG93 IGEgbGlzdCBvZiBvYnNlcnZhdGlvbnMgdGhhdCBpbmZsdWVuY2VkIHRoaXMgdmlldzo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjEuICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9QVUNuLCBPRFVDbiBhbmQgT1RVQ24gYXJl IG5ldyBhbmQgdGhlIGxheWVyaW5nIHJlbGF0aW9uc2hpcCB0byB0aGUgZm9ybWVyIHN0cnVjdHVy ZSBpcyBhIGJpdCBzdXJwcmlzaW5nLCBhcyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCAoc2Vl IGJlbG93KSBzaG93ZWQuIEJldHRlciB0bw0KIGdldCB0aGlzIHJpZ2h0IGVhcmx5IG9uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpZ3VyZSA3LTEgc2hvd3MgdGhlIE9UTiBt dWx0aXBsZXhpbmcgYW5kIG1hcHBpbmcgc3RydWN0dXJlcyBidXQgZG9lcyBub3QgaW5kaWNhdGUg aG93IGUuZy4gYSA0MDBHRSB3b3VsZCBiZSBtYXBwZWQgaW50byB0aGlzIHN0cnVjdHVyZS4gSXQg aXMgbm90IHN1cnByaXNpbmcgYXMgNDAwR0UNCiBpcyBzdGlsbCBpbiB0aGUgbWFraW5ncywgYnV0 IHJhaXNlcyBhIGZldyBxdWVzdGlvbnMgYWJvdXQgaG93IGl0IGlzIHBsYW5uZWQgdG8gYmUgbWFw cGVkLiBIb3dldmVyIGd1aWRhbmNlIGZyb20gU0cxNSB3b3VsZCBoZWxwIHRvIGdldCB0aGUgcHJv dG9jb2wgYXJjaGl0ZWN0dXJlIGZ1dHVyZSBwcm9vZi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmEuICZuYnNwOyAm bmJzcDsgJm5ic3A7IERvZXMgZXZlcnkgY2xpZW50IHNpZ25hbCBuZWVkIHRvIGJlIHdyYXBwZWQg aW50byBhbiBPUFVrL09EVWsgYmVmb3JlIGl0IGNhbiBiZSB0cmFuc3BvcnRlZCB2aWEgYW4gT1BV Q24vT0RVQ24/DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OmluaGVyaXQiPuKGkjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gdGhpcyB3b3VsZCBtZWFuIHRvIGV4dGVuZCB0aGUgT0RVIHN0cnVjdHVyZSBieSBh biBPRFU1LDYsNyBldGMuIGZvciBjbGllbnRzICZndDsgMTAwRzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Yi4gJm5i c3A7ICZuYnNwOyAmbmJzcDsgV2lsbCBvbmx5IGNsaWVudCBzaWduYWxzICZsdDs9IDEwMEcgbmVl ZCB0byBiZSB3cmFwcGVkIGluIGFuIE9QVWsvT0RVayBiZWZvcmUgaXQgY2FuIGJlIHRyYW5zcG9y dGVkIHZpYSBhbiBPUFVDbi9PRFVDbj8NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6aW5oZXJpdCI+4oaSPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB0aGlzIHdvdWxkIG1lYW4gdGhhdCB0aGVyZSB3aWxsIGJl IGEgYnJlYWsgaW4gdGhlIG1hcHBpbmdzIGF0IGFib3V0IDEwMEcgc2lnbmFscyBhbmQgbm8gT0RV NSw2LDcgd291bGQNCiBuZWVkIHRvIGJlIGRlZmluZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PiA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Yy4gJm5ic3A7ICZu YnNwOyAmbmJzcDsgV2lsbCBmdXR1cmUgY2xpZW50cyBiZSBtYXBwZWQgZGlyZWN0bHkgaW50byBP UFVDbi9PRFVDbiBhbmQgdGhlIHNwZWNpYWwgY2FzZSBvZiAxMDBHRTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6aW5oZXJpdCI+4oaS PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9QVWsvT0RVazwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6aW5oZXJp dCI+4oaSPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9QVUNuL09EVUNuDQog d2lsbCBiZWNvbWUganVzdCBhbm90aGVyIG9wdGlvbj8gKE5vdGU6IHRoZSBmaWd1cmUgZXhwbGlj aXRseSBhbGxvd3MgZm9yIHByb3ByaWV0YXJ5IG1hcHBpbmdzIGRpcmVjdGx5IGludG8gT1BVQ24v T0RVQ24gd2hpY2ggbG9va3MgbGlrZSBhIHByYWN0aWNhbCB1c2UgY2FzZSwgYnV0IGl0IGxvb2tz IG9kZCB0aGF0IGl0IHJlbWFpbnMgcHJvcmlldGFyeSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjMuICZuYnNwOyAm bmJzcDsgJm5ic3A7IFRoZSBzZWN0aW9uIOKAnDcuMSBNYXBwaW5n4oCdIGFuZCDigJw3LjIgV2F2 ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXjigJ0gY2hhbmdlZCBhIGJpdCBmcm9tIHRoZSAyMDEy IHZlcnNpb24uIEFzIGFjcm9ueW1zIGhhdmUgY2hhbmdlZCB0b28sIGEgMToxIGNvbXBhcmlzb24g aXMgbm90IHRvbyBzaW1wbGUuDQogVGhlIHRha2Vhd2F5IGlzIHRoYXQgYW4gT1RVIGNhbiBiZSBt YXBwZWQgaW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoIG9yIHNwcmVhZCBhY3Jvc3Mgc29tZSAoT1RM ay5uIGFuZCBPVExDLm4pIHdoaWNoIG1lYW5zIGludmVyc2UgbXVsdGlwbGV4aW5nLiBTbyBmYXIg dGhpcyBjYXNlIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2My48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjQuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluIFNlY3Rpb24g4oCcNi4xLjEg T1ROIGRpZ2l0YWwgc3RydWN0dXJl4oCdIGl0IGlzIGV4cGxhaW5lZCB0aGF0IGFuIE9UVWsgY29u dGFpbnMgYSBGRUMsIGJ1dCBPVFVDbiBkb2VzIG5vdCwgbGVhdmluZyBpdCB0byB0aGUgaW50ZXJm YWNlIHRvIGFwcGx5IHNvbWUuIFRoaXMgYmFzaWNhbGx5DQogY3JlYXRlcyBhIEZFQyBsYXllciBi ZWxvdyB0aGUgT1RVQ24gdGhhdCB3aWxsIG5vdCBiZSBkZWZpbmVkIGluIEcuNzA5LiBBIGNvbnRy b2wgcGxhbmUgd291bGQgbmVlZCB0byBjaGVjayBjb21wYXRpYmlsaXR5IG9mIHdhdmVsZW5ndGgs IG1vZHVsYXRpb24sIGludGVyZmFjZXMgKGkuZS4gaG93IG1hbnkgbGFuZXMpIGFuZCBjb21wYXRp YmlsaXR5IG9mIEZFQywgYXMgd2VsbCBhcyB1c2FnZSBvZiBPVFVrIHZzIE9UVUNuLiBBbHNvIHRo aXMgY2FzZQ0KIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGluIFJGQzcxMzkgb3IgUkZDNjE2My48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+NS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlcmUgaXMgYWxzbyBhIG5ldyBP TVMgTVNJIChzZWN0IDE1LjQpIG92ZXJoZWFkIGRlZmluZWQsIHdoaWNoIHByb3ZpZGVzIGEgbGlz dCBvZiBPQ2ggYW5kIE9UU2lBIGZyZXF1ZW5jeSBzbG90LHBvcnQgbnVtYmVycyBhbmQgYSBsaXN0 IG9mIG1lZGlhIGNoYW5uZWxzIChmcmVxdWVuY3kNCiBzbG90LCBtZWRpYSBjaGFubmVsIHBvcnQg bnVtYmVycykgdG8gZGVjb2RlIHRoZSBsYW5lcyBjb3JyZWN0bHkuIFRoaXMgbWF5IGFmZmVjdCBS RkM2MTYzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj42LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgdGVybSDigJxX YXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleOKAnSBpbiB0aGUgc2VjdGlvbnMgYWJvdmUgZG9l c27igJl0IGltcGx5IGEgd2F2ZWxlbmd0aCBjYW4gYmUgcm91dGVkIHRocm91Z2ggYSBEV0RNIG5l dHdvcmsgc2luY2Ugd2Uga25vdyB0aGF0IGUuZy4gMTAwRyBpbnRlcmZhY2VzDQogYXJlIG5vdCB5 ZXQgZGVmaW5lZCBieSBTRzE1IGZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMuIFdpdGhv dXQgYW1wbGlmaWVycywgdGhlIGRpc3RhbmNlIHN1cHBvcnRlZCBieSBzdWNoIERXRE0gaXMgbGlr ZWx5IGxpbWl0ZWQgdG8gYmVsb3cgODAtMTAwa20uIEl0IGlzIG5vdCB5ZXQgY2xlYXIgYnkgd2hl biB0aGlzIGxpbWl0YXRpb24gd2lsbCBiZSBsaWZ0ZWQgYnkgU0cxNSAoc2VlIGRyYWZ0LW1hbnkt Y29oZXJlbnQtZHdkbS1pZi1jb250cm9sLTAwKS4NCiBBZnRlciBhbGwsIE9UVTQgYmFzZWQgMTAw RyBpbnRlcmZhY2VzIGZvciBhbXBsaWZpZWQgRFdETSBhcHBsaWNhdGlvbnMgYXJlIGF2YWlsYWJs ZSBhbmQgaGF2ZSBldmVuIGJlZW4gcHJvdmVuIHRvIGJlIGludGVyb3BlcmFibGUgYW1vbmcgbXVs dGlwbGUgdmVuZG9ycyBjb3ZlcmluZyBkaXN0YW5jZXMgJmd0OzEwMDBrbS4gJm5ic3A7SG93ZXZl ciwgdG8gc3RheSBpbiB0aGUgc3RhbmRhcmRzIGZyYW1ld29yayBmb3Igbm93LCBSRkM2MTYzIHdv dWxkIG5lZWQgdG8NCiBjb25zaWRlcjo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YnI+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YS4gJm5ic3A7ICZuYnNwOyAmbmJz cDsgV2hpbGUgYSBPVFVDbiBjYW4gYmUgZGlnaXRhbGx5IGNvbnN0cnVjdGVkIGFuZCBtYXBwZWQg aW50byBhIHNpbmdsZSB3YXZlbGVuZ3RoLCBpdCBjYW5ub3QgYmUgcm91dGVkIGluIFdTT04NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6aW5oZXJpdCI+4oaSPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBubyAx MDBHIGludGVyZmFjZXMgaW4gYW1wbGlmaWVkIERXRE0gbmV0d29ya3MgZGVmaW5lZCBpbiBHLjY5 OC4yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5iLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbiBPVFVDbiBtYXkgYmUg YnJva2VuIGRvd24gaW50byA0IGxhbmVzIGF0IDI1RyAoT1RMNC40KSBidXQgc3RpbGwgY2Fu4oCZ dCBiZSByb3V0ZWQgaW4gV1NPTg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTppbmhlcml0Ij7ihpI8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IG5vIDI1RyBpbnRlcmZhY2VzIGluIGFtcGxpZmllZCBEV0RNIG5l dHdvcmtzIGRlZmluZWQgaW4gRy42OTguMjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Yy4gJm5ic3A7ICZuYnNwOyAm bmJzcDsgQW4gT1RVMyAoPTQwRykgY2FuIGJlIGJyb2tlbiBkb3duIGluIE9UTDMuNCBwcm92aWRp bmcgNCBsYW5lcyBhdCAxMEcgZWFjaA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTppbmhlcml0Ij7ihpI8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IDEwRyBpbnRlcmZhY2VzIGFyZSBhbGxvd2VkIGluIGFtcGxp ZmllZCBEV0RNIG5ldHdvcmtzIGRlZmluZWQgaW4gRy42OTguMjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206IDwvc3Bhbj4N CjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Q0NBTVAgPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0 Zi5vcmciPg0KJmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9hPiBvbiBiZWhhbGYgb2Yg RGFuaWVsZSBDZWNjYXJlbGxpIDxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJp Y3Nzb24uY29tIj4NCiZsdDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzwvYT48 Yj48YnI+DQpEYXRlOiA8L2I+RnJpZGF5IDE4IE5vdmVtYmVyIDIwMTYgYXQgMjA6MDI8Yj48YnI+ DQpUbzogPC9iPjxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbSI+JnF1b3Q7aHV1 YmF0d29ya0BnbWFpbC5jb20mcXVvdDs8L2E+IDxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdt YWlsLmNvbSI+DQombHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PC9hPiwgQ0NBTVAgPGEgaHJl Zj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj4mbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7PC9hPjxiPjxi cj4NClN1YmplY3Q6IDwvYj5SZTogW0NDQU1QXSBPRFU0IGFuZCBPRFVDbiBkaXNjdXNzaW9uPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJyPg0KJm5ic3A7IDxicj4NCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFuayBIdXViLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5BdXRob3JzLCBpZiB5b3UgY291bGQgaGF2ZSBhIGxpdHRsZSBwaWVjZSBvZiB0 ZXh0IGRlc2NyaWJpbmcgdGhpcyBjb25zaWRlcmF0aW9uIGluIHRoZSBmcmFtZXdvcmsgb3IgaW4g b25lIG9mIHRoZSBzb2x1dGlvbiBkb2N1bWVudHMgKGRlcGVuZGluZyB3aGF0IGFyZSB0aGUgcGxh bnMgZm9yIHRoZSBtZXJnZSkNCiB0aGF0IHdvdWxkIGJlIGdyZWF0Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+IDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoYW5rczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGFuaWVsZSAmbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBIdXViIHZhbiBIZWx2b29ydCBbPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IHZlbmVyZMOsIDE4 IG5vdmVtYnJlIDIwMTYgMTk6MzE8Yj48YnI+DQpUbzo8L2I+IERhbmllbGUgQ2VjY2FyZWxsaSA8 YSBocmVmPSJtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSI+Jmx0O2Rhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20mZ3Q7PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpjY2Ft cEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBb Q0NBTVBdIE9EVTQgYW5kIE9EVUNuIGRpc2N1c3Npb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PiA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhbmllbGUsPGJyPg0KPGJyPg0KWW91IHdy aXRlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSBjbGVhciBleHBsYW5hdGlvbiBIdXViLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8YnI+DQpZb3UncmUgd2VsY29tZS48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SSBzZWUgdHdvIGRpZmZlcmVudCB1c2UgY2FzZXMgdGhhdCBib3RoIG1ha2Ugc2Vuc2UuDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCkkgaGF2ZSB0byBkaXNhZ3JlZSAoYWdh aW4pLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgb25lIHByb3Bvc2VkIGJ5IEdlcnQgaXMgc3RpdGNoaW5nIG9mIGFuIE9EVTQg YW5kIE9EVUMxLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8YnI+DQpUaGlzIHVz ZSBjYXNlIGlzIGltcG9zc2libGUuIEFzIHlvdSBjYW4gc2VlIGluIEcuNzA5ICgyMDE2KSBmaWd1 cmUgNy0xIDxicj4NCmEgbG93ZXIgb3JkZXIgT0RVNCBpcyBtYXBwZWQgaW50byBhIGhpZ2hlciBv cmRlciBPRFVDMSwgYW5kIHRoaXMgPGJyPg0KbWVhbnMgdGhhdCB0aGV5IGNvbnN0aXR1dGUgZGlm ZmVyZW50IGxheWVycyBpbiB0aGUgT1ROLiA8YnI+DQpBbmQgYXJlIGltcG9zc2libGUgdG8gc3Rp dGNoLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj53aGlsZSB0aGUgb25lIHlvdSBhcmUgZGVzY3JpYmluZyBpcyB0dW5uZWxpbmcgb2Yg T0RVNCBvdmVyIGFuIE9EVUMxIHRyYWlsLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+ DQo8YnI+DQpDb3JyZWN0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaGV5IGJvdGggc2VlbXMgcmVhc29uYWJsZSB0byBtZSwgd2h5 IHRoZSBzdGl0Y2hpbmcgaXMgbm90IGZlYXNpYmxlPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ DQo8YnI+DQo8YnI+DQpJIHRyaWVkIHRvIGV4cGxhaW4gYWJvdmUuPGJyPg0KPGJyPg0KQmVzdCBy ZWdhcmRzLCBIdXViLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiAsIHNlcmlmJnF1 b3Q7LHNlcmlmIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gQ0NBTVAgWzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDA4MkJGIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHV1YiB2 YW4gSGVsdm9vcnQ8Yj48YnI+DQpTZW50OjwvYj4gZ2lvdmVkw6wgMTcgbm92ZW1icmUgMjAxNiAx NzowNjxiPjxicj4NClRvOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJt YWlsdG86Y2NhbXBAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA4MkJGIj5jY2Ft cEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxicj4NClN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gUmU6IFtDQ0FNUF0gT0RVNCBhbmQgT0RVQ24gZGlzY3Vzc2lvbjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhlbGxvIEdlcnQsPGJyPg0K PGJyPg0KWW91ciB1c2UgY2FzZSBpcyBub3QgY29tcGxldGVseSBjb3JyZWN0Ljxicj4NCjxicj4N Ckluc3RlYWQgb2Y6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4xLiAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5BIHVzZSBjYXNlIHRvIGNvbnNpZGVyIGlzOjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+DQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0t LS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4N Cjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEwMEdFLS18LUdNUC1PRFU0 LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1PRFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1H TVAtfC0tMTAwR0U8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7 LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7DQo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtORTEg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8YnI+DQpJdCBzaG91bGQgYmU6IDxicj4NCjwv c3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjEwMEdFLS18LUdNUC1PRFU0LXwtT1RVNC0tLU9UVTQtfC1PRFU0LUdNUC1P RFVDMS18LU9UVUMxLS0tT1RVQzEtfC1PRFVDMS1HTVAtT0RVNC1HTVAtfC0tMTAwR0U8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0t LS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsgJm5ic3A7DQo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtORTEgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7TkUyICg9R1ctTkUpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTkUzPC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KVGhlIE9EVUMxIGZyb20gTkUyIHRvIE5FMyB0dW5uZWxz IHRoZSBPRFU0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ UmVnYXJkcywgSHV1Yi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyA8YnI+DQombmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7IDxicj4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tIDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsd2F5 cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVzdCBsaWtlIGV2ZXJ5b25lIGVsc2Uu Li48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0 Pjxicj4NCjx0dD5DQ0FNUCBtYWlsaW5nIGxpc3Q8L3R0Pjxicj4NCjx0dD48YSBocmVmPSJtYWls dG86Q0NBTVBAaWV0Zi5vcmciPkNDQU1QQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L3NwYW4+PC90dD48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPkNDQU1QIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOkNDQU1QQGlldGYub3JnIj5DQ0FN UEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXAiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L2E+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM2PR07MB09947BEA72A75F0DF6F57B3DF08A0AM2PR07MB0994eurp_-- From nobody Tue Nov 29 13:56:39 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0260F129546; Tue, 29 Nov 2016 13:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 akkvsYovXBpF; Tue, 29 Nov 2016 13:56:30 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620D9127077; Tue, 29 Nov 2016 13:56:30 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id v84so207341571oie.3; Tue, 29 Nov 2016 13:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=IlFO93p6gOWuzZ2THHt4Htj/KpnFWSkqGZiOnYB6V6g=; b=dAX+5OSuUJ56iJF9JhP5Vs+9GKULn7zGj1e0HT5JXgrAcTgUbrGvnkXDLsh8X8/daP EgrKBjCa9qqKprIOFhs4rHMjD9Vn+Tc8O/uA7Nbx1EMNRyHIdqhd51z6YYrNqyDLb28k EDMXBn1pX79zkwRhZkkSPS2RjV3aWgXRc+50zGeSeNejLZvL+RTsbM9UoKl3GfLwoU5S lWYNIMyMpoo8luwREQ95O5a9t3NzEbBGwtorUrR/Lnr971xeQNdlZzQmBRMlCjOZMCDx vzNnyUP0oKEe0lef9hbESoRqYFreMn7SupPfHhsPl/4WvxryQwWKtbP4B7Bw2gYeLAJ/ DlHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=IlFO93p6gOWuzZ2THHt4Htj/KpnFWSkqGZiOnYB6V6g=; b=KVlAQAGD3/0HvHhMUITV6NG8XPNy6yj8Mr8PTk4lb+AFyQz+wlTW5+laRAaOaHQrjV +pQOfc3TaQ4XfV9LdW64UHhwy8u7KaQ8JY/pq2Ajq92pRRWcEKSLT7IRoy+NXy3TOQjk 3RHQLv4b3A6gBfm/S94dqn9ma3tHZuBPXSvpbI3K4O6Nk5auPjS/YVjq7yCXJ494WQAf UnS/h5FK387AMs9j5zvCWjQMTFEgIrEoiKpvF3xCVKgoKUlJPDW+K6bFwmp0bAGtPmOo cJlGbyXKoxXX55wYRyH+T5ygHfLNzArnMmYVJUZqamXltlht4IPZJYgafMbTR2QYCFZx d7kQ== X-Gm-Message-State: AKaTC01mexgg/8mwaPbRx7HIF9arrHjhmIspLV/CWff2ukyj1RxH7HduUyBTq1hh/fIQ6g== X-Received: by 10.157.49.119 with SMTP id v52mr15485142otd.134.1480456589680; Tue, 29 Nov 2016 13:56:29 -0800 (PST) Received: from xliuus (ip72-209-195-86.dc.dc.cox.net. [72.209.195.86]) by smtp.gmail.com with ESMTPSA id 90sm19303066otw.15.2016.11.29.13.56.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 13:56:29 -0800 (PST) From: "Xufeng Liu" To: "'Daniele Ceccarelli'" , "'CCAMP'" References: In-Reply-To: Date: Tue, 29 Nov 2016 16:56:29 -0500 Message-ID: <00d901d24a8b$71953880$54bfa980$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01D24A61.88BFF3D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIFU9WuS/Ts/YWjbwCL+T5Lg2kf/6CKbCDw Content-Language: en-us Archived-At: Cc: mpls@ietf.org, pce@ietf.org, 'TEAS WG' Subject: Re: [CCAMP] [mpls] IETF 97 - Minutes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 21:56:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DA_01D24A61.88BFF3D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Daniele, Fatiai and Oscar, For item 4, It will be good to add a record saying that we planned to split draft-ietf-mpls-ldp-mldp-yang-00 into two documents: draft-ietf-mpls-ldp-yang and draft-ietf-mpls-mldp-yang, as presented during the session. This is not obvious when looking at the linked presentation draft. The split documents were submitted right after the presentation. Thanks, - Xufeng From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Monday, November 28, 2016 8:53 AM To: CCAMP (ccamp@ietf.org) Cc: mpls@ietf.org; pce@ietf.org; TEAS WG (teas@ietf.org) Subject: [mpls] IETF 97 - Minutes Hi all, the first draft of the CCAMP and joint YANG session minutes is now available at the following link: https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-00.htm Thanks a lot to Italo, Haomian and Yoji for the help with notes taking. Thanks Daniele, Fatai, Oscar ------=_NextPart_000_00DA_01D24A61.88BFF3D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daniele, Fatiai and = Oscar,

 

For item 4, = It will be good to add a record saying that we planned to split = draft-ietf-mpls-ldp-mldp-yang-00 into two documents: = draft-ietf-mpls-ldp-yang and draft-ietf-mpls-mldp-yang, as = presented during the session. This is not obvious when looking at the = linked presentation draft. The split documents were submitted right = after the presentation.

 

Thanks,

 

- = Xufeng

 

------=_NextPart_000_00DA_01D24A61.88BFF3D0-- From nobody Tue Nov 29 17:50:22 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB70129D30 for ; Tue, 29 Nov 2016 17:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ebYuPBhpqNKN for ; Tue, 29 Nov 2016 17:49:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B831129D1A for ; Tue, 29 Nov 2016 17:49:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBQ20503; Wed, 30 Nov 2016 01:49:09 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Nov 2016 01:49:08 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.105]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Wed, 30 Nov 2016 09:48:56 +0800 From: Fatai Zhang To: "jonas.ahlberg@ericsson.com" , "LUIS MIGUEL CONTRERAS MURILLO" , "Yemin (Amy)" , Marko Vaupotic , "jefftant.ietf@gmail.com" , "k-kawada@ah.jp.nec.com" , "Xi.Li@neclab.eu" , "i-akiyoshi@ah.jp.nec.com" , "cjbc@it.uc3m.es" , "'CCAMP'" Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvig== Date: Wed, 30 Nov 2016 01:48:55 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.211.7] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8AAB1CFD6SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.583E3016.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b91d741b2b18035ae1eb985f5584b710 Archived-At: Subject: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 01:50:19 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF8AAB1CFD6SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_F82A4B6D50F9464B8EBA55651F541CF8AAB1CFD6SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors, Contributors, CCAMP

 

As part of the preparation for= polling for WG adoption:

 

Are you aware of any IPR that = applies to draft identified above?

 

Please state either:

"No, I'm not aware of any= IPR that applies to this draft"

or

"Yes, I'm aware of IPR th= at applies to this draft"

 

If so, has this IPR been discl= osed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details)?

If yes to the above, please st= ate either:

 

"Yes, the IPR has been di= sclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been= disclosed"

 

If you answer no, please provi= de any additional details you think appropriate. If you are listed as a doc= ument author or contributor please answer the above by responding to this e= mail regardless of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF Y= OU LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG ema= il list but are not listed as an author or contributor, we remind you of yo= ur obligations under the IETF IPR rules which encourages you to notify the = IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/tra= c/wiki/IntellectualProperty.

 

 

Thank you

 

Fatai & Daniele=

 

 

 

--_000_F82A4B6D50F9464B8EBA55651F541CF8AAB1CFD6SZXEMA504MBSchi_-- From nobody Tue Nov 29 18:07:47 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3C0129407 for ; Tue, 29 Nov 2016 18:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wiE-Vyj8y34Z for ; Tue, 29 Nov 2016 18:07:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F2A1293EC for ; Tue, 29 Nov 2016 18:07:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWG72692; Wed, 30 Nov 2016 02:07:36 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Nov 2016 02:07:34 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.67]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Wed, 30 Nov 2016 10:07:24 +0800 From: "Yemin (Amy)" To: Fatai Zhang , "jonas.ahlberg@ericsson.com" , LUIS MIGUEL CONTRERAS MURILLO , Marko Vaupotic , "jefftant.ietf@gmail.com" , "k-kawada@ah.jp.nec.com" , "Xi.Li@neclab.eu" , "i-akiyoshi@ah.jp.nec.com" , "cjbc@it.uc3m.es" , "'CCAMP'" Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvigAAm3yw Date: Wed, 30 Nov 2016 02:07:24 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FC619112C@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FC619112Cszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.583E3469.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.67, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7ef4fe1573f4ec3b7a16062631021ec6 Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 02:07:45 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461FC619112Cszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Amy From: Fatai Zhang Sent: Wednesday, November 30, 2016 9:49 AM To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO ; Yemin (Amy) ; Marko = Vaupotic ; jefftant.ietf@gmail.com; k-kawada@a= h.jp.nec.com; Xi.Li@neclab.eu; i-akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es; '= CCAMP' Cc: Daniele Ceccarelli ; Fatai Zhang Subject: Regarding IPR on draft-mwdt-ccamp-fmwk Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_9C5FD3EFA72E1740A3D41BADDE0B461FC619112Cszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of a= ny IPR that applies to this draft.

 

Amy

=  

From: = Fatai Zhang
Sent: Wednesday, November 30, 2016 9:49 AM
To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO <lu= ismiguel.contrerasmurillo@telefonica.com>; Yemin (Amy) <amy.yemin@hua= wei.com>; Marko Vaupotic <Marko.Vaupotic@Aviatnet.com>; jefftant.i= etf@gmail.com; k-kawada@ah.jp.nec.com; Xi.Li@neclab.eu; i-akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es; 'CCAMP' <ccamp@ietf.org><= br> Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Fata= i Zhang <zhangfatai@huawei.com>
Subject: Regarding IPR on draft-mwdt-ccamp-fmwk

 =

Authors, Contributors, CCAMP

 

As part of the preparation for polling for WG= adoption:

 

Are you aware of any IPR that applies to draf= t identified above?

 

Please state either:

"No, I'm not aware of any IPR that appli= es to this draft"

or

"Yes, I'm aware of IPR that applies to t= his draft"

 

If so, has this IPR been disclosed in complia= nce with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more detail= s)?

If yes to the above, please state either:

 

"Yes, the IPR has been disclosed in comp= liance with IETF IPR rules"

or

"No, the IPR has not been disclosed"= ;

 

If you answer no, please provide any addition= al details you think appropriate. If you are listed as a document author or= contributor please answer the above by responding to this email regardless= of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN TH= IS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list but are= not listed as an author or contributor, we remind you of your obligations = under the IETF IPR rules which encourages you to notify the IETF if you are= aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or disc= ussion related to your undisclosed IPR. For more information, please see th= e RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/Inte= llectualProperty.

 

 

Thank you

 

Fatai & Daniele

 

 

 

--_000_9C5FD3EFA72E1740A3D41BADDE0B461FC619112Cszxema506mbschi_-- From nobody Tue Nov 29 20:39:59 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788411294B7 for ; Tue, 29 Nov 2016 20:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y05M9sAAGcvZ for ; Tue, 29 Nov 2016 20:39:55 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C865129463 for ; Tue, 29 Nov 2016 20:39:55 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id c4so9431063pfb.3 for ; Tue, 29 Nov 2016 20:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Czr3ALeq0dZSMP1Y8UudONq/2nDaZP4dxjIbmA45jhU=; b=aQdZES62xqz9kWXFtUFaZ9YweLMniJh3X8mtSgKqjV1ZdGTiiXBn2XuBf41Xv0+b9/ a1nG587rF+r6QyXGLtWN1y7/lBw5o/sHf7PHx7Zxcg356sawa/4gWMkRjFfmQgzXN40z eSRJKotbzE5a+tmtBkFdzwDBp+CUA8Ex0bv4SC6EncZZ58ESOIjS6UbShs6Vxq9vLmdx +nziQ6ZK5tLjtLIqhkq22mXSMKIxBOo2L6Rt4pyoMUt4+Bj9K6+0mrgVb/9KlXWu/3Jx ihmX2oIB+h7Gpw6DGm9YhrALh0tPYw5sufplefRVMHskOKFteyyVJlO9KzjuuKG37IjJ 57Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Czr3ALeq0dZSMP1Y8UudONq/2nDaZP4dxjIbmA45jhU=; b=Ljp+ITa9JoSbWIqe2wWEOCxr0Zuwtj2dmDZL4gj0sHsmHKYFFnXSHxZqNwY+ehqI1J 6hYYMDUS3KfClbsfDQBCyWBNKPBif3iJq8ZfJkviWpocZlUmxs/N5AA7QmMrsxd+saOf 11F9+0vYULtpuRF+I0+2zhVd+gRPJLEmxNIMbMy4D3dd7jjdL7UQAEUiwehaYn8vwIsE fvd2CZtU2udybPEhQ+4o3Lk+Jp10Tw4AOir5r6XHbJaW78hxAVKiiFEnFU5hGFn0p6qK mlyzwlyBT1YKB4EwBUhYB8k+nICx42Kjgiss2OY3lQsv2HkbfPvWIJ0zOP1WP7A88slX zz+g== X-Gm-Message-State: AKaTC02kwbm1PIB/9sR6MU9VKFhykAfWdFSwJeAIAaVHtnldG+fQIIWWqNH8KjorR4VwaA== X-Received: by 10.84.162.204 with SMTP id o12mr70038336plg.17.1480480794926; Tue, 29 Nov 2016 20:39:54 -0800 (PST) Received: from [10.102.1.198] ([8.28.121.4]) by smtp.gmail.com with ESMTPSA id b71sm98502400pfj.62.2016.11.29.20.39.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 20:39:53 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1D279ECD-5273-4EDA-9B37-2112E274571A Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Tue, 29 Nov 2016 20:39:52 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Fatai Zhang Archived-At: Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 04:39:57 -0000 --Apple-Mail-1D279ECD-5273-4EDA-9B37-2112E274571A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Fatai, I'm not aware of any IPR that applies to this draft. Regards, Jeff > On Nov 29, 2016, at 17:48, Fatai Zhang wrote: >=20 > Authors, Contributors, CCAMP >=20 > =20 >=20 > As part of the preparation for polling for WG adoption: >=20 > =20 >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > =20 >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" >=20 > or >=20 > "Yes, I'm aware of IPR that applies to this draft" >=20 > =20 >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > =20 >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >=20 > or >=20 > "No, the IPR has not been disclosed" >=20 > =20 >=20 > If you answer no, please provide any additional details you think appropri= ate. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awar= e of any relevant IPR. >=20 > =20 >=20 > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > =20 >=20 > If you are on the CCAMP WG email list but are not listed as an author or c= ontributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an I= ETF contribution, or to refrain from participating in any contribution or di= scussion related to your undisclosed IPR. For more information, please see t= he RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/Inte= llectualProperty. >=20 > =20 >=20 > =20 >=20 > Thank you >=20 > =20 >=20 > Fatai & Daniele >=20 > =20 > =20 > =20 --Apple-Mail-1D279ECD-5273-4EDA-9B37-2112E274571A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Fatai,

I'm not aware of any IPR that applies to this draft.

Regards,
Jeff

Authors, Contributors, CCAMP

 

As part of the preparation for polling for WG adoption:

 

Are you aware of any IPR that applies to draft identified above?

 

Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"

 

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

 

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"

 

If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

 

 

Thank you

 

Fatai & Daniele

 

 

 

--Apple-Mail-1D279ECD-5273-4EDA-9B37-2112E274571A-- From nobody Wed Nov 30 00:46:39 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F431295C1 for ; Wed, 30 Nov 2016 00:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 lAXvAC7e8iiO for ; Wed, 30 Nov 2016 00:46:33 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934051295DD for ; Wed, 30 Nov 2016 00:45:19 -0800 (PST) X-AuditID: c1b4fb30-c294498000000c18-d3-583e919da48e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id A7.33.03096.D919E385; Wed, 30 Nov 2016 09:45:17 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 30 Nov 2016 09:44:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xu+BaKtgecAgVoem5CVTZuGkebJABUGcJ1xjzuCw6LQ=; b=ELOUCVTiaWzXZmOPCEMJaxSeZ/1ADpfAwzT6obPxF948rRliW9TmFKDTqAkwD3gi9wqluzb1xf2zAWZppYbADcqgzsabcaMvrvmYb6/rqk9TddR2Uy9lj4UTqxf3BxPufPdCDo6KXIMjl/wI1pRiNcYWQImye2466HPEMSF8HI8= Received: from AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) by AM2PR07MB0993.eurprd07.prod.outlook.com (10.162.37.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Wed, 30 Nov 2016 08:44:57 +0000 Received: from AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::1d80:1498:b9ae:6a0b]) by AM3PR07MB0536.eurprd07.prod.outlook.com ([fe80::1d80:1498:b9ae:6a0b%17]) with mapi id 15.01.0761.009; Wed, 30 Nov 2016 08:44:57 +0000 From: Jonas Ahlberg To: Fatai Zhang , LUIS MIGUEL CONTRERAS MURILLO , "Yemin (Amy)" , Marko Vaupotic , "jefftant.ietf@gmail.com" , "k-kawada@ah.jp.nec.com" , "Xi.Li@neclab.eu" , "i-akiyoshi@ah.jp.nec.com" , "cjbc@it.uc3m.es" , 'CCAMP' Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvigAOgTiw Date: Wed, 30 Nov 2016 08:44:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jonas.ahlberg@ericsson.com; x-originating-ip: [192.176.1.86] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0993; 7:xuEetlYl2RqTlRp5Gz5GhPsSDrDbNCHKdn3ivG2y+QJgEubxSBi2jOEF8blCLg1vtSbEreirrwJfon8Jr8EmsKIWLnDxb3GwzvgHcRiI9lDqBfwP8tgD3gziUNGp+thGAoGFO6fko7gLEgj12Q5to94yYkVqyZAklzW0xFUgYatPVfSqASZCIElfF88u/TU33APCgSUg+FwYH3Je7Ekq9/BMlqlDb1VEks11ynpGcfa+6qBnGX0qB6KCAblZrL1Y3AFjxtuLz83rdLaVoRHrLNz4wro+15YMJ611BBALpLz2YKQXMJ1abuJ7qkFeRxZmundHAtwmE21wNeSw+CmthQtbcaGFVonZ2pvd+7KWio31kEAJ0QUDgfkZ47Jf7XhsKYTQVRx5JkHzj5fqfnhd/HJ1T3jITozULTGfytFqHw+lWo9Uxs6Ic91vTUId9oOnoOjb0IoC/EVc8jdPQpw68g== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(4001430100002)(39450400002)(81166006)(790700001)(2906002)(8676002)(3280700002)(3660700001)(189998001)(97736004)(2950100002)(9686002)(102836003)(7846002)(7696004)(8936002)(107886002)(68736007)(3846002)(5250100002)(6116002)(2501003)(38730400001)(39410400001)(39060400001)(7736002)(4326007)(74316002)(5660300001)(7416002)(50986999)(66066001)(86362001)(6506003)(54356999)(2201001)(81156014)(5001770100001)(33656002)(92566002)(230783001)(76176999)(2900100001)(105586002)(229853002)(76576001)(101416001)(106356001)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0993; H:AM3PR07MB0536.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 94e1f423-b60b-490f-ce96-08d418fd299f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0993; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:AM2PR07MB0993; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0993; x-forefront-prvs: 0142F22657 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB05363F8C43FEA686BBF678AB898C0AM3PR07MB0536eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2016 08:44:56.7591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0993 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH931+3D1u3fZ1kc8o6aJWSjqVp1amf+raVP5I2S2ri2cId3YP lf5SR6GYsJwrxagw/RKl1KZLyI/UFUXMiubIj7IW0qwez9n67/V+f96f7/fz/ezLkIpR2pWJ 1iVwBp02VimRUQWhj9zWF14KCPX9YVOxD9LuSdjBqx8pNrW2imCLrUaaHUmbIViTtYlkXw+Z JKypLE/K9k22EGyWsYMOlKltxdWk+kV6JVI/NvdJ1SkNY7S6tHSGUP/6cJ9WmxqHper0WTKY 0ci2R3Cx0Sc4w4aAo7KoZ5Y3KP6T/tT5Rk0ysoVnIAcG8CaY6JkmMpCMUeA7CIo/mmhRNCNo uWNEgqBwJglj6RP2WB4BX21tElEMIChKu0sLh0mwL4yOXJsvOOEuEibnbpAZiGFIzELnuLeQ WYz94FLzHCXYTsLleX4iqmDiPS8kKOwFnVVn5k+U48NgLPssESIKHAL3v4QJtgM+CG9z/hAC I7wEploq55nELtAzeJ0QX4ah9GkHKbIzDA/M0WI+DMZsI5Toe0D/71xSGBjwRQpKXpYTopim 4WxOib17L5yz5VALPFZ7WSpyDIy3WuyZ41DZ3mBvziCguuyuPbQUalszkcAKzMGt26lI3IMr 9L1PR9lojfm/yUXWQ7d1mjTPL8ARXhUMUqK/DorqJiUie8PN4m/kArfVDxD/+0VIWoGceY4/ FhepUvlwhuhwntfrfHRcQhX69wefV8/61qLhoZ0WhBmkXCT/nr8jVEFrT/BJcRYEDKl0kpuz A0IV8ght0mnOoD9iSIzleAtyYyili3xLef8hBY7UJnAxHBfPGRaqBOPgmowQMfFOtcjaXNGR Euxonl7ZUre//YomLrfIvclo3qWfehjoX7c8eNuItdOydVNQjbNm0PUJbRxf+7Pj5uaN++oT LxSW7mh65hTEPe7KD/YcD4ncXdi6eqp7Wat3W6ZXr3uJR3nsqjSNvyGePeloxJ6JUzq3G3vo AytqynuHrO1Zn5UUH6XduJY08Nq/IK8yrH8DAAA= Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 08:46:36 -0000 --_000_AM3PR07MB05363F8C43FEA686BBF678AB898C0AM3PR07MB0536eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Regards JonasA From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: den 30 november 2016 02:49 To: Jonas Ahlberg ; LUIS MIGUEL CONTRERAS MURIL= LO ; Yemin (Amy) ; Marko Vaupotic ; jefftant.ietf@gmail= .com; k-kawada@ah.jp.nec.com; Xi.Li@neclab.eu; i-akiyoshi@ah.jp.nec.com; cj= bc@it.uc3m.es; 'CCAMP' Cc: Daniele Ceccarelli ; Fatai Zhang Subject: Regarding IPR on draft-mwdt-ccamp-fmwk Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_AM3PR07MB05363F8C43FEA686BBF678AB898C0AM3PR07MB0536eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR that applies to this draft.

 

Regards

JonasA

=  

From: = Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: den 30 november 2016 02:49
To: Jonas Ahlberg <jonas.ahlberg@ericsson.com>; LUIS MIGUEL CO= NTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>; Yemin (= Amy) <amy.yemin@huawei.com>; Marko Vaupotic <Marko.Vaupotic@Aviatn= et.com>; jefftant.ietf@gmail.com; k-kawada@ah.jp.nec.com; Xi.Li@neclab.eu; i-akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es; 'CCAMP' <cc= amp@ietf.org>
Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Fata= i Zhang <zhangfatai@huawei.com>
Subject: Regarding IPR on draft-mwdt-ccamp-fmwk

 =

Authors, Contribut= ors, CCAMP

 <= /span>

As part of the pre= paration for polling for WG adoption:

 <= /span>

Are you aware of a= ny IPR that applies to draft identified above?

 <= /span>

Please state eithe= r:

"No, I'm not = aware of any IPR that applies to this draft"

or

"Yes, I'm awa= re of IPR that applies to this draft"

 <= /span>

If so, has this IP= R been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 36= 69 and 5378 for more details)?

If yes to the abov= e, please state either:

 <= /span>

"Yes, the IPR= has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR = has not been disclosed"

 <= /span>

If you answer no, = please provide any additional details you think appropriate. If you are lis= ted as a document author or contributor please answer the above by respondi= ng to this email regardless of whether or not you are aware of any relevant IPR.

 <= /span>

NOTE: THIS APPLIES= TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

 <= /span>

If you are on the = CCAMP WG email list but are not listed as an author or contributor, we remi= nd you of your obligations under the IETF IPR rules which encourages you to= notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating= in any contribution or discussion related to your undisclosed IPR. For mor= e information, please see the RFCs listed above andhttp://trac.tools.ietf.o= rg/group/iesg/trac/wiki/IntellectualProperty.

 <= /span>

 <= /span>

Thank you

 <= /span>

Fatai & Daniel= e

&nbs= p;

&nbs= p;

&nbs= p;

--_000_AM3PR07MB05363F8C43FEA686BBF678AB898C0AM3PR07MB0536eurp_-- From nobody Wed Nov 30 01:07:42 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87712961D for ; Wed, 30 Nov 2016 01:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UpoZhqBBLr7X for ; Wed, 30 Nov 2016 01:07:38 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1770D129D42 for ; Wed, 30 Nov 2016 01:06:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 47EA2101985; Wed, 30 Nov 2016 10:06:01 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5XV91xgZIDJ; Wed, 30 Nov 2016 10:06:01 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 2272E101AB5; Wed, 30 Nov 2016 10:05:39 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.175]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 10:05:39 +0100 From: Xi Li To: Fatai Zhang , "jonas.ahlberg@ericsson.com" , LUIS MIGUEL CONTRERAS MURILLO , "Yemin (Amy)" , Marko Vaupotic , "jefftant.ietf@gmail.com" , "k-kawada@ah.jp.nec.com" , "i-akiyoshi@ah.jp.nec.com" , "cjbc@it.uc3m.es" , 'CCAMP' Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvigAPN5/w Date: Wed, 30 Nov 2016 09:05:38 +0000 Message-ID: <139E9C21EC047B43BA40AD7031AC09BE1DD72D52@PALLENE.office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.124] Content-Type: multipart/alternative; boundary="_000_139E9C21EC047B43BA40AD7031AC09BE1DD72D52PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 09:07:41 -0000 --_000_139E9C21EC047B43BA40AD7031AC09BE1DD72D52PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai, No, I'm not aware of any IPR that applies to this draft. Best regards, Xi From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Mittwoch, 30. November 2016 02:49 To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO; Yemin (Amy);= Marko Vaupotic; jefftant.ietf@gmail.com; k-kawada@ah.jp.nec.com; Xi Li; i-= akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es; 'CCAMP' Cc: Daniele Ceccarelli; Fatai Zhang Subject: Regarding IPR on draft-mwdt-ccamp-fmwk Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_139E9C21EC047B43BA40AD7031AC09BE1DD72D52PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fatai,

 

No, I'm not aware of a= ny IPR that applies to this draft.

 

Best regards,

Xi

=  

=  

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Mittwoch, 30. November 2016 02:49
To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO; Yemin= (Amy); Marko Vaupotic; jefftant.ietf@gmail.com; k-kawada@ah.jp.nec.com; Xi= Li; i-akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es; 'CCAMP'
Cc: Daniele Ceccarelli; Fatai Zhang
Subject: Regarding IPR on draft-mwdt-ccamp-fmwk

 =

Authors, Contributors, CCAMP

 

As part of the preparation for polling for WG= adoption:

 

Are you aware of any IPR that applies to draf= t identified above?

 

Please state either:

"No, I'm not aware of any IPR that appli= es to this draft"

or

"Yes, I'm aware of IPR that applies to t= his draft"

 

If so, has this IPR been disclosed in complia= nce with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more detail= s)?

If yes to the above, please state either:

 

"Yes, the IPR has been disclosed in comp= liance with IETF IPR rules"

or

"No, the IPR has not been disclosed"= ;

 

If you answer no, please provide any addition= al details you think appropriate. If you are listed as a document author or= contributor please answer the above by responding to this email regardless= of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN TH= IS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list but are= not listed as an author or contributor, we remind you of your obligations = under the IETF IPR rules which encourages you to notify the IETF if you are= aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or disc= ussion related to your undisclosed IPR. For more information, please see th= e RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/Inte= llectualProperty.

 

 

Thank you

 

Fatai & Daniele

 

 

 

--_000_139E9C21EC047B43BA40AD7031AC09BE1DD72D52PALLENEofficehd_-- From nobody Wed Nov 30 01:10:01 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BDC129D40 for ; Wed, 30 Nov 2016 01:09:59 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 e88YGdHWtBRv for ; Wed, 30 Nov 2016 01:09:57 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A4E129D3E for ; Wed, 30 Nov 2016 01:09:45 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id uAU99VW1002295; Wed, 30 Nov 2016 18:09:31 +0900 (JST) Received: from mailsv4.nec.co.jp (imss61.nec.co.jp [10.7.69.156]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id uAU99V202045; Wed, 30 Nov 2016 18:09:31 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id uAU99UXj025070; Wed, 30 Nov 2016 18:09:31 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.146] [10.38.151.146]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-4037; Wed, 30 Nov 2016 18:07:13 +0900 Received: from BPXM17GP.gisp.nec.co.jp ([10.38.151.209]) by BPXC18GP.gisp.nec.co.jp ([10.38.151.146]) with mapi id 14.03.0224.002; Wed, 30 Nov 2016 18:07:12 +0900 From: Koji Kawada To: Fatai Zhang , "jonas.ahlberg@ericsson.com" , LUIS MIGUEL CONTRERAS MURILLO , "Yemin (Amy)" , Marko Vaupotic , "jefftant.ietf@gmail.com" , "Xi.Li@neclab.eu" , Ippei Akiyoshi , "cjbc@it.uc3m.es" , "'CCAMP'" Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvigAO6RpQ Date: Wed, 30 Nov 2016 09:07:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.38.32.55] Content-Type: multipart/alternative; boundary="_000_FA9BA58964F30648B6C92A510A0DBF85A2C876C1BPXM17GPgispnec_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 09:09:59 -0000 --_000_FA9BA58964F30648B6C92A510A0DBF85A2C876C1BPXM17GPgispnec_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Best Regards, Kawada _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ NEC Corporation Mobile Wireless Solutions Division Koji Kawada Tel: +81 44 455 8458 PHS: 8-22-76893 / ZIP: 22-82302(EMS) e-mail: k-kawada@ah.jp.nec.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, November 30, 2016 10:49 AM To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO ; Yemin (Amy) ; Marko = Vaupotic ; jefftant.ietf@gmail.com; Kawada Koj= i(=1B$B2OED=1B(B =1B$B9-; Xi.Li@neclab.eu;= Akiyoshi Ippei(=1B$B=3D)9%=1B(B =1B$B0lJ?=1B(B) = ; cjbc@it.uc3m.es; 'CCAMP' Cc: Daniele Ceccarelli ; Fatai Zhang Subject: Regarding IPR on draft-mwdt-ccamp-fmwk Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_FA9BA58964F30648B6C92A510A0DBF85A2C876C1BPXM17GPgispnec_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR that applies= to this draft.

 

Best Regards,

Kawada

 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

NEC Corporation

Mobile Wireless Solutions Division<= /o:p>

 

  Koji Kawada

  Tel: +81 44 455 8458

  PHS: 8-22-76893 / ZIP: 22-82302(E= MS)

  e-mail: k-kawada@ah.jp.nec.com

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

 =

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, November 30, 2016 10:49 AM
To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO <lu= ismiguel.contrerasmurillo@telefonica.com>; Yemin (Amy) <amy.yemin@hua= wei.com>; Marko Vaupotic <Marko.Vaupotic@Aviatnet.com>; jefftant.i= etf@gmail.com; Kawada Koji(=1B$B2OED=1B(B =1B$B9-) <k-kawada@ah.jp.nec.com>; Xi.Li@neclab.eu; Akiyo= shi Ippei(=1B$B=3D)9%=1B(B =1B$B0lJ?=1B(B) <i-akiyoshi@ah.jp.nec.com>; cjbc@it.uc3m.es; 'CC= AMP' <ccamp@ietf.org>
Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Fata= i Zhang <zhangfatai@huawei.com>
Subject: Regarding IPR on draft-mwdt-ccamp-fmwk

 

Authors, Contributors, CCAMP

 

As part of the preparation for= polling for WG adoption:

 

Are you aware of any IPR that = applies to draft identified above?

 

Please state either:

"No, I'm not aware of any= IPR that applies to this draft"

or

"Yes, I'm aware of IPR th= at applies to this draft"

 

If so, has this IPR been discl= osed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details)?

If yes to the above, please st= ate either:

 

"Yes, the IPR has been di= sclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been= disclosed"

 

If you answer no, please provi= de any additional details you think appropriate. If you are listed as a doc= ument author or contributor please answer the above by responding to this e= mail regardless of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF Y= OU LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG ema= il list but are not listed as an author or contributor, we remind you of yo= ur obligations under the IETF IPR rules which encourages you to notify the = IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/tra= c/wiki/IntellectualProperty.

 

 

Thank you

 

Fatai & Daniele=

 

 

 

--_000_FA9BA58964F30648B6C92A510A0DBF85A2C876C1BPXM17GPgispnec_-- From nobody Wed Nov 30 01:39:38 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3425129E2B; Wed, 30 Nov 2016 01:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 gdz_pwLMXmh2; Wed, 30 Nov 2016 01:39:29 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70416129E7B; Wed, 30 Nov 2016 01:35:03 -0800 (PST) X-AuditID: c1b4fb3a-98fff70000007918-35-583e9d44a03e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id DB.B4.31000.44D9E385; Wed, 30 Nov 2016 10:35:01 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 30 Nov 2016 10:35:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dYO6ucCXaeR4KGUdjTWHZOUwKvY+Bv50nSNPztcw7CQ=; b=MrhRnOTeEfpGtFkLuFWRSJA2gEPsbdldkCu3pEk0C16kJs1sLMapMjkk0b+FGLM889snOM75yaZ5s+o8SYDX7C5by1HJgOdkMq8uZ8qdZ9dn2gcMHMJfCPhEfL3dNqFoQy9Rruvj8BJG3Gj/XhseGT0+bG6aQVt1NrHz0WOhtRI= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0995.eurprd07.prod.outlook.com (10.162.37.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Wed, 30 Nov 2016 09:34:59 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0761.009; Wed, 30 Nov 2016 09:34:59 +0000 From: Daniele Ceccarelli To: Xufeng Liu , 'CCAMP' Thread-Topic: [Teas] [mpls] IETF 97 - Minutes Thread-Index: AdJJfGqW1nHLu05NTzaalyUbP88StQBDwWWAABhiSrA= Date: Wed, 30 Nov 2016 09:34:59 +0000 Message-ID: References: <00d901d24a8b$71953880$54bfa980$@gmail.com> In-Reply-To: <00d901d24a8b$71953880$54bfa980$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 9d08af51-d4de-4a5b-3f40-08d419042732 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0995; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 7:s0OjEWSh1VSk7mDIo0vVi3nMzVrJIZ/Y444kcreBgKPW8Yj65lrRyVDeRwTU3c2y2reyMLLH7EDZW66nA17MUy9IRW/UHC/V+el8jxgD1es1d3dS/FVxWQJwE9zctqdQlHZ3NgIzGyjU/+qNv8/7tqBYiYxr0KA/BlK64Fva7ncYJvl0dwFlW1x5kg4Nl6HA9M55RqSg+YUUvmHjOkjJiLP2Xy0mvals9PfXh43Z345uc+2KDpzisASyZMQ7hOlZinplv4jBow5rlQNzPqsYa97UdcKXqZ4BgcR5jANijnuOnCf7qXemujsFlvnQy7IWqL7uGVJvjzXT6HAADcvIamo/Tsuakb/Mb1OVWeScLgPcSBAKwTXhcYUgh4t+2vV7Ky98r6E+5DiiNBCU/HOW/GP3ZJk1jf5BjPJp/YAkUgOvJqaH+2QM1IPJwjnw9bUwI6yfLKlT5ItyRFoNSUuhQw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123558021)(20161123564025)(20161123560025)(6072148); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995; x-forefront-prvs: 0142F22657 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(51914003)(377454003)(53754006)(86362001)(189998001)(68736007)(5660300001)(76176999)(7846002)(8936002)(122556002)(3846002)(101416001)(7736002)(102836003)(229853002)(74316002)(81156014)(39450400002)(6116002)(7906003)(3660700001)(2906002)(3280700002)(606004)(77096006)(39410400001)(92566002)(54356999)(6506003)(2950100002)(50986999)(790700001)(81166006)(2900100001)(76576001)(38730400001)(4326007)(39060400001)(7696004)(8676002)(66066001)(5001770100001)(97736004)(105586002)(33656002)(106356001)(9686002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994CDE2EDC732C060AD1A24F08C0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2016 09:34:59.2829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe/7bnu1Bqd5ezCVXDfTvGRSw0oUiiSsBAlHCLryRU2dtldN 84sE++DSMtLSaeRlldq0NK9oHxyRN1IzL9MSMxdlIq7A0iytt2Pgt9/z/H+H85yHw9KyZpEz m6BO4zRqVZJcbMuUKFs9vU/cC1L6Lfx2U1jKzIxi8kGNSHFt2ixRaJfbGMVI9y8qWBTarp+S hBoMK1Q4dd72aCyXlJDBaXyDYmzjewYWUaohNDNvvoHOQW+CdciGBRwAYwNaiQ7ZsjJcj2Bm ZpAmRQ+CCm0zEgoG59NgnBjf0AopmB/VIuG8DL9E8Dz3ig6xrBgHgsUUJrTt8XHoNFtpgWkc DcbHLYzAdng/lFd9QIJuj73hs1FGMBBu5IQIBoN3g3WpjBJYiqNgor5/Yx4dgvbFdZHg22AF 1NU4Cg7CjvCjz0iRm5xg0nKfIg/DYOgcpAk7wNzsmoj4F+CJtm3DcYehWv0Gn4a+lTXmP3+/ Y5IQzmNgociPcCLUVzaICZ+CUvN7SpgNsJ6Cd61jiAQu0Nafj0jQK4K5bwMMWRUHj+rI2uyw M0yN5KICtE+/aXDCKfC1sprR/1vANugtsTCk7wPmokIxYS94WDFPE/aG4jUTs7lfjiS1yIHn eD45zt/fh9MkXOT5FLWPmktrRH8/U1fTamAb6voUYkKYRfKtUuvdY0qZSJXBZyWbELC03F66 oyxIKZPGqrKucpqUaE16Eseb0HaWkTtJD9VMR8pwnCqNS+S4VE7zP6VYG+ccdPbw9QA+W9La 6eU3uLOutKoq4q0U5n5mMvJi/fJqaceZ5u5LeyvDsxNu3poPLggrWjXEaGiLe19+tNXF46Pb ks8X9Svm2euOyaEXu3pWxiOG5XkjjdXrHlPDt32PlJSzJ6PSz3VFyl0HLjvlZoWLoxqtLa6Z Tw+O7okYbgpp3DIrZ/h41QFPWsOr/gAaS/UwSAMAAA== Archived-At: Cc: "mpls@ietf.org" , "pce@ietf.org" , 'TEAS WG' Subject: Re: [CCAMP] [Teas] [mpls] IETF 97 - Minutes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 09:39:32 -0000 --_000_AM2PR07MB0994CDE2EDC732C060AD1A24F08C0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xufeng, Thanks for the note. Minutes fixed. https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-01.htm BR Daniele From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: marted=EC 29 novembre 2016 22:56 To: Daniele Ceccarelli ; 'CCAMP' Cc: mpls@ietf.org; pce@ietf.org; 'TEAS WG' Subject: Re: [Teas] [mpls] IETF 97 - Minutes Hi Daniele, Fatiai and Oscar, For item 4, It will be good to add a record saying that we planned to split= draft-ietf-mpls-ldp-mldp-yang-00 into two documents: draft-ietf-mpls-ldp-y= ang and draft-ietf-mpls-mldp-yang, as presented during the session. This is= not obvious when looking at the linked presentation draft. The split docum= ents were submitted right after the presentation. Thanks, - Xufeng From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Monday, November 28, 2016 8:53 AM To: CCAMP (ccamp@ietf.org) > Cc: mpls@ietf.org; pce@ietf.org;= TEAS WG (teas@ietf.org) > Subject: [mpls] IETF 97 - Minutes Hi all, the first draft of the CCAMP and joint YANG session minutes is now availabl= e at the following link: https://www.ietf.org/proceedings/97/minutes/minute= s-97-ccamp-00.htm Thanks a lot to Italo, Haomian and Yoji for the help with notes taking. Thanks Daniele, Fatai, Oscar --_000_AM2PR07MB0994CDE2EDC732C060AD1A24F08C0AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Xufeng,

 

Thanks for the note. Minutes fi= xed.

 

https://www.ietf.org/proce= edings/97/minutes/minutes-97-ccamp-01.htm

 

BR
Daniele 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: marted=EC 29 novembre 2016 22:56
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; 'CCA= MP' <ccamp@ietf.org>
Cc: mpls@ietf.org; pce@ietf.org; 'TEAS WG' <teas@ietf.org>
Subject: Re: [Teas] [mpls] IETF 97 - Minutes

 

Hi Daniele, Fatiai and Oscar,

 

For item 4, It will be good to add a record saying that we planned to= split draft-ietf-mpls-ldp-mldp-yang-00 into two documents: draft-ietf-mpls-ldp-yang and draft-ietf-mpls-ml= dp-yang, as presented during the session. This is not obvious when looking = at the linked presentation draft. The split documents were submitted right = after the presentation.

 

Thanks,

 

- Xufeng

 

From: mpls [mailto:mpls-bounces= @ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Monday, November 28, 2016 8:53 AM
To: CCAMP (ccamp@ietf.org) <= ;ccamp@ietf.org>
Cc: mpls@ietf.org; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: [mpls] IETF 97 - Minutes

 

Hi all,

 

the first draft of the CCAMP an= d joint YANG session minutes is now available at the following link: https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-00.htm 

 

Thanks a lot to Italo, Haomian = and Yoji for the help with notes taking.

 

Thanks

Daniele, Fatai, Oscar

--_000_AM2PR07MB0994CDE2EDC732C060AD1A24F08C0AM2PR07MB0994eurp_-- From nobody Wed Nov 30 02:45:53 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01C3129F6A for ; Wed, 30 Nov 2016 02:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aV6SA1JQg6G0 for ; Wed, 30 Nov 2016 02:45:48 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0136.outbound.protection.outlook.com [104.47.1.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7682C129F61 for ; Wed, 30 Nov 2016 02:45:46 -0800 (PST) Received: from DB5PR06MB1381.eurprd06.prod.outlook.com (10.163.103.11) by DB5PR06MB1382.eurprd06.prod.outlook.com (10.163.103.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Wed, 30 Nov 2016 10:45:43 +0000 Received: from DB5PR06MB1381.eurprd06.prod.outlook.com ([10.163.103.11]) by DB5PR06MB1381.eurprd06.prod.outlook.com ([10.163.103.11]) with mapi id 15.01.0747.015; Wed, 30 Nov 2016 10:45:43 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: Fatai Zhang , "jonas.ahlberg@ericsson.com" , "Yemin (Amy)" , "Marko Vaupotic" , "jefftant.ietf@gmail.com" , "k-kawada@ah.jp.nec.com" , "Xi.Li@neclab.eu" , "i-akiyoshi@ah.jp.nec.com" , "cjbc@it.uc3m.es" , 'CCAMP' Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvigASvGlA Date: Wed, 30 Nov 2016 10:45:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=luismiguel.contrerasmurillo@telefonica.com; x-originating-ip: [195.235.92.36] x-ms-office365-filtering-correlation-id: aac3a9b3-c8bf-4d6f-29c4-08d4190e08bd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR06MB1382; x-microsoft-exchange-diagnostics: 1; DB5PR06MB1382; 7:cw/SUQjTSEkfISQf5qVBPYrfawGOBa6GGR5Ss+fHo3vOWUbYhB1ezi4quiLlIXu6O3tmcao+dWTYsmr/BmqXFqVYIorNDMq5grDgzXlIixqMLAHFi911cfd11ZX/ZiGsLt63BL2noUOwWAhx0QRGIUvhfSP8OeKKTVSat8iGSG2mS97E3+jmyNtCAkIrriwLJHzs+AX1CGq7nNLmKxqddmvqD3XruV7armJBwDldda+r9Z8nZw0pr0WZzWuAFHuXY/bMd/2EkOctxSSLIUorO/WawPuX0aRgbDMsFrQYN8QSqufrfm1RCtB48Cdv/WmUaKZGqVlBsIJEgqraWTv1tQLLrt019fpxg1y1sjoF4NFMVpjEcpuOJMqVwfeAtc9XN6PqQk2UB5r65J+wN+iVjlxLCvM0mCWv+KGQyoyqQx7RYHZUf6M3vjRBgjsjaeXvec3nTEAkoBtIDcRnfhvvLg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DB5PR06MB1382; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB1382; x-forefront-prvs: 0142F22657 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(39060400001)(54356999)(2900100001)(77096006)(2201001)(3280700002)(39410400001)(97736004)(105586002)(229853002)(101416001)(5001770100001)(106356001)(66066001)(6116002)(3660700001)(9686002)(189998001)(86362001)(68736007)(790700001)(6506003)(102836003)(230783001)(38730400001)(3846002)(2906002)(50986999)(7416002)(4326007)(33656002)(5660300001)(2950100002)(81166006)(76176999)(7736002)(7846002)(39450400002)(8936002)(8676002)(81156014)(74316002)(76576001)(92566002)(122556002)(2501003)(7696004)(921003)(9010500006)(1121003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR06MB1382; H:DB5PR06MB1381.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR06MB1381E4085638EB5673BEDAF49E8C0DB5PR06MB1381eurp_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2016 10:45:43.0962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB1382 Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 10:45:51 -0000 --_000_DB5PR06MB1381E4085638EB5673BEDAF49E8C0DB5PR06MB1381eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Fatai, No, I'm not aware of any IPR that applies to this draft Best regards Luis De: Fatai Zhang [mailto:zhangfatai@huawei.com] Enviado el: mi=E9rcoles, 30 de noviembre de 2016 2:49 Para: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO ; Yemin (Amy) ; Mark= o Vaupotic ; jefftant.ietf@gmail.com; k-kawada= @ah.jp.nec.com; Xi.Li@neclab.eu; i-akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es;= 'CCAMP' CC: Daniele Ceccarelli ; Fatai Zhang Asunto: Regarding IPR on draft-mwdt-ccamp-fmwk Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_DB5PR06MB1381E4085638EB5673BEDAF49E8C0DB5PR06MB1381eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Fatai,

 

No, I'm not aware of any IPR that applies to this draft=

 

Best regards

 

Luis

 

 

De: Fa= tai Zhang [mailto:zhangfatai@huawei.com]
Enviado el: mi=E9rcoles, 30 de noviembre de 2016 2:49
Para: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO <= luismiguel.contrerasmurillo@telefonica.com>; Yemin (Amy) <amy.yemin@h= uawei.com>; Marko Vaupotic <Marko.Vaupotic@Aviatnet.com>; jefftant= .ietf@gmail.com; k-kawada@ah.jp.nec.com; Xi.Li@neclab.eu; i-akiyoshi@ah.jp.nec.com; cjbc@it.uc3m.es; 'CCAMP' <ccamp@ietf.org><= br> CC: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Fata= i Zhang <zhangfatai@huawei.com>
Asunto: Regarding IPR on draft-mwdt-ccamp-fmwk

 =

Aut= hors, Contributors, CCAMP

 

As = part of the preparation for polling for WG adoption:

 

Are= you aware of any IPR that applies to draft identified above?

 

Ple= ase state either:

&qu= ot;No, I'm not aware of any IPR that applies to this draft"=

or<= o:p>

&qu= ot;Yes, I'm aware of IPR that applies to this draft"=

 

If = so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs= 3979, 4879, 3669 and 5378 for more details)?

If = yes to the above, please state either:

 

&qu= ot;Yes, the IPR has been disclosed in compliance with IETF IPR rules"<= o:p>

or<= o:p>

&qu= ot;No, the IPR has not been disclosed"

 

If = you answer no, please provide any additional details you think appropriate.= If you are listed as a document author or contributor please answer the ab= ove by responding to this email regardless of whether or not you are aware of any relevant IPR.

 

NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.=

 

If = you are on the CCAMP WG email list but are not listed as an author or contr= ibutor, we remind you of your obligations under the IETF IPR rules which en= courages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from par= ticipating in any contribution or discussion related to your undisclosed IP= R. For more information, please see the RFCs listed above andhttp://trac.to= ols.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

 

 

Tha= nk you

 

Fat= ai & Daniele

 

 

 

--_000_DB5PR06MB1381E4085638EB5673BEDAF49E8C0DB5PR06MB1381eurp_-- From nobody Wed Nov 30 03:03:55 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268C8129FA6 for ; Wed, 30 Nov 2016 03:03:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 kZD6hp_eP8Sp for ; Wed, 30 Nov 2016 03:03:51 -0800 (PST) Received: from mail-wj0-x22b.google.com (mail-wj0-x22b.google.com [IPv6:2a00:1450:400c:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15ACB129F7B for ; Wed, 30 Nov 2016 03:03:33 -0800 (PST) Received: by mail-wj0-x22b.google.com with SMTP id xy5so170352507wjc.0 for ; Wed, 30 Nov 2016 03:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=ciDhxUryBP2kqWPZOJUw1LAyjFC23ad7+nzQNjjnKlE=; b=mW2NUulN6SYnICGdfJGRoaCkAi48Y0Hy9G5Le0CyNHMc7JIpVAm5QcUdmvM8Gcd0b3 vDtepf6CkmPXar2AoMnuzgBgR6Dj7JeRBFaJ6epm0XiFoNOE1JE6ieLmUdndBT8zkALc oA+qL0VEx4ULtne2MMqkSYTCttEdD4DTJhIm8rAHGUicE9jq0dQpi0+vp/62xjaPD0VA H7M+6fFVSlGKM6OiQCiqEzQ1Qkd5SuRCjctpaFdpTu8NGH9Rh3NCU+2zaayWV3WQyUhJ mzUcCudn8gCWCGDoguCT3ZkwFEfA7GROiNNIb4PAwCEnn4T1r113FrVeXumJ5pfGb8Bk nRvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=ciDhxUryBP2kqWPZOJUw1LAyjFC23ad7+nzQNjjnKlE=; b=LRDvtQoWG1SciMBVbbygHPuH3bqtyvTDbXNSiIhpJPDe88gkJGFOyrXvRf5+obzsTo KRCBDkRzkcVVFFcN8XF8AUJUEdXrNuAO1kKdG4g74VQL63Ekz28MLB/EraTkn7XojU06 DDVPCm+3/PGTc745PF0BrQdU0oRNoHcDJGX+pEra7ZiErby9kwnvMvCguDb5mfBCHXHS tEowCqt8jXlpgGLIQSFyKglGK9+A2MtnIgnJ+g2OZ/EnlSaANadxrDrQEjgRYPAy5+Xl WgFNBdJdNTGtrk2/L05Jg4gA/ASYm2hELV/1bJzQCAlsrD2BgitKD7/w8F3DCz1hnSmX bBSw== X-Gm-Message-State: AKaTC03+ew3N4lUunhEkCtAdN5wmCTMnjli7epQnbhdlylFJ/peehWZl56JW0/RyFgM//uWR X-Received: by 10.194.39.7 with SMTP id l7mr27349759wjk.182.1480503811366; Wed, 30 Nov 2016 03:03:31 -0800 (PST) Received: from ?IPv6:2001:720:410:1010:36e6:d7ff:fe6a:7354? ([2001:720:410:1010:36e6:d7ff:fe6a:7354]) by smtp.gmail.com with ESMTPSA id pd2sm72312913wjb.31.2016.11.30.03.03.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 30 Nov 2016 03:03:30 -0800 (PST) Message-ID: <1480503809.15365.0.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Fatai Zhang , "jonas.ahlberg@ericsson.com" , LUIS MIGUEL CONTRERAS MURILLO , "Yemin (Amy)" , Marko Vaupotic , "jefftant.ietf@gmail.com" , "k-kawada@ah.jp.nec.com" , "Xi.Li@neclab.eu" , "i-akiyoshi@ah.jp.nec.com" , 'CCAMP' Date: Wed, 30 Nov 2016 12:03:29 +0100 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 11:03:54 -0000 Dear Fatai, Daniele, No, I'm not aware of any IPR that applies to this draft. Thanks, Carlos On Wed, 2016-11-30 at 01:48 +0000, Fatai Zhang wrote: > Authors, Contributors, CCAMP > >   > > As part of the preparation for polling for WG adoption: > >   > > Are you aware of any IPR that applies to draft identified above? > >   > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > > or > > "Yes, I'm aware of IPR that applies to this draft" > >   > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > >   > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > > or > > "No, the IPR has not been disclosed" > >   > > If you answer no, please provide any additional details you think > appropriate. If you are listed as a document author or contributor > please answer the above by responding to this email regardless of > whether or not you are aware of any relevant IPR. > >   > > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. > >   > > If you are on the CCAMP WG email list but are not listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which encourages you to notify the IETF if you are aware of IPR > of others on an IETF contribution, or to refrain from participating > in any contribution or discussion related to your undisclosed IPR. > For more information, please see the RFCs listed above andhttp://trac > .tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >   > >   > > Thank you > >   > > Fatai & Daniele > >   >   >   From nobody Wed Nov 30 16:08:16 2016 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510C6129BC4 for ; Wed, 30 Nov 2016 16:08:14 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UwzhTbhH8QCl for ; Wed, 30 Nov 2016 16:08:11 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263E11298C6 for ; Wed, 30 Nov 2016 16:08:11 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id uB107vKu005947; Thu, 1 Dec 2016 09:07:57 +0900 (JST) Received: from mailsv.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id uB107vV24359; Thu, 1 Dec 2016 09:07:57 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id uB107uYI028809; Thu, 1 Dec 2016 09:07:56 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.129] [10.38.151.129]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-9588; Thu, 1 Dec 2016 01:08:37 +0900 Received: from BPXM05GP.gisp.nec.co.jp ([10.38.151.197]) by BPXC01GP.gisp.nec.co.jp ([10.38.151.129]) with mapi id 14.03.0224.002; Thu, 1 Dec 2016 01:08:36 +0900 From: Ippei Akiyoshi To: Fatai Zhang , "jonas.ahlberg@ericsson.com" , LUIS MIGUEL CONTRERAS MURILLO , "Yemin (Amy)" , Marko Vaupotic , "jefftant.ietf@gmail.com" , Koji Kawada , "Xi.Li@neclab.eu" , "cjbc@it.uc3m.es" , "'CCAMP'" Thread-Topic: Regarding IPR on draft-mwdt-ccamp-fmwk Thread-Index: AdJKq+20kM15vVq5TgSinF3UgzFvigAd/ipw Date: Wed, 30 Nov 2016 16:08:35 +0000 Message-ID: <4BE55FCA27C3564D9C99F3F9F80BD68A812C6191@BPXM05GP.gisp.nec.co.jp> References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.8.178] Content-Type: multipart/alternative; boundary="_000_4BE55FCA27C3564D9C99F3F9F80BD68A812C6191BPXM05GPgispnec_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] Regarding IPR on draft-mwdt-ccamp-fmwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 00:08:14 -0000 --_000_4BE55FCA27C3564D9C99F3F9F80BD68A812C6191BPXM05GPgispnec_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Dear Fatai and Daniele, No, I'm not aware of any IPR that applies to this draft BR, Ippei From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, November 30, 2016 10:49 AM To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO ; Yemin (Amy) ; Marko = Vaupotic ; jefftant.ietf@gmail.com; Kawada Koj= i(=1B$B2OED=1B(B =1B$B9-; Xi.Li@neclab.eu;= Akiyoshi Ippei(=1B$B=3D)9%=1B(B =1B$B0lJ?=1B(B) = ; cjbc@it.uc3m.es; 'CCAMP' Cc: Daniele Ceccarelli ; Fatai Zhang Subject: Regarding IPR on draft-mwdt-ccamp-fmwk Authors, Contributors, CCAMP As part of the preparation for polling for WG adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty. Thank you Fatai & Daniele --_000_4BE55FCA27C3564D9C99F3F9F80BD68A812C6191BPXM05GPgispnec_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Dear Fatai and Daniele,<= o:p>

 =

No, I'm not aware of any= IPR that applies to this draft

 =

BR,

Ippei<= /p>

 =

 =

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, November 30, 2016 10:49 AM
To: jonas.ahlberg@ericsson.com; LUIS MIGUEL CONTRERAS MURILLO <lu= ismiguel.contrerasmurillo@telefonica.com>; Yemin (Amy) <amy.yemin@hua= wei.com>; Marko Vaupotic <Marko.Vaupotic@Aviatnet.com>; jefftant.i= etf@gmail.com; Kawada Koji(=1B$B2OED=1B(B =1B$B9-) <k-kawada@ah.jp.nec.com>; Xi.Li@neclab.eu; Akiyo= shi Ippei(=1B$B=3D)9%=1B(B =1B$B0lJ?=1B(B) <i-akiyoshi@ah.jp.nec.com>; cjbc@it.uc3m.es; 'CC= AMP' <ccamp@ietf.org>
Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Fata= i Zhang <zhangfatai@huawei.com>
Subject: Regarding IPR on draft-mwdt-ccamp-fmwk

 

Authors, Contributors, CCAMP

 

As part of the preparation for= polling for WG adoption:

 

Are you aware of any IPR that = applies to draft identified above?

 

Please state either:

"No, I'm not aware of any= IPR that applies to this draft"

or

"Yes, I'm aware of IPR th= at applies to this draft"

 

If so, has this IPR been discl= osed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details)?

If yes to the above, please st= ate either:

 

"Yes, the IPR has been di= sclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been= disclosed"

 

If you answer no, please provi= de any additional details you think appropriate. If you are listed as a doc= ument author or contributor please answer the above by responding to this e= mail regardless of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF Y= OU LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG ema= il list but are not listed as an author or contributor, we remind you of yo= ur obligations under the IETF IPR rules which encourages you to notify the = IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above andhttp://trac.tools.ietf.org/group/iesg/tra= c/wiki/IntellectualProperty.

 

 

Thank you

 

Fatai & Daniele=

 

 

 

--_000_4BE55FCA27C3564D9C99F3F9F80BD68A812C6191BPXM05GPgispnec_--