From nobody Tue Nov 1 06:53:37 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27C1296F0; Tue, 1 Nov 2016 06:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=metaswitch.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 5AQTlb9EVjnF; Tue, 1 Nov 2016 06:53:32 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D7C12944B; Tue, 1 Nov 2016 06:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E4R5KOHrxLZtuxy96dUJfcjWMvynHXV/NEs73tkTVfg=; b=HEQRNU5V2b41OVMM/ssIRSj/rmYokc86xgTEAWXdaHM7lDlVufQfTERpwCjKvMKC5wofzLFiiivpV29K4fAa3TMBfXB4tvC3jwHwO4NVVcT/pl8Qq45fyZco1dLExO4CgqJMHUcZxxEfS0bzfoDxb1xyPghts9LwKo80OZXwFaA= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 1 Nov 2016 13:53:30 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0693.009; Tue, 1 Nov 2016 13:53:30 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: PCE meeting draft agenda Thread-Index: AdI0RqAp4nvyT1jQSCCpXErQ2eOX3A== Date: Tue, 1 Nov 2016 13:53:29 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.84.242] x-ms-office365-filtering-correlation-id: 10da486a-4b5b-4603-95fd-08d4025e764a x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1910; 7:X6cYqvW0yPNzKfJ8o/+gaC0nk/ndlfO+MKw9idhQkhr91QlIO0LXH2dApcvpioBL69OqysKVwSoAuvkQ4OEScNVnTqix2UI2hW6ERZV1uyZ0hGTotn+Vn0ICt0HsM9iYAg9cYc/gC5ArGyGRfGTnv31jJQHI3JERFqf2PHgiMfR4xOXX76LBmc74RCGgmaLmGliYJ2HhAPL/SrdLiMHXDEUnzyjCoEQYdNB61iKCQfp3NBRp7W4MR49ed57oLoxEbvxrmpn4ZjZSkI4CyTm/6nGHg22z2ONWqA+m1ExpSgMYKEclshMg3L4u25Lsqdw7ym2tJilxmX/gfSgM7o/+NYn9Io9CpGhEHl951vKb2tM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1910; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1910; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1910; x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(66654002)(199003)(189002)(66066001)(81166006)(4326007)(33656002)(122556002)(2900100001)(3660700001)(19617315012)(97736004)(92566002)(8936002)(7696004)(3480700004)(7736002)(10400500002)(7906003)(5002640100001)(7846002)(74316002)(5660300001)(2501003)(110136003)(87936001)(2906002)(450100001)(77096005)(15975445007)(76576001)(86362001)(6916009)(54356999)(50986999)(2351001)(106356001)(19580395003)(9686002)(229853001)(16236675004)(586003)(99286002)(19625215002)(81156014)(5640700001)(6116002)(8676002)(790700001)(101416001)(68736007)(1730700003)(11100500001)(189998001)(5630700001)(3846002)(105586002)(19300405004)(102836003)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1910; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19106C5483EF532A7FE7C2C684A10BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 13:53:29.7050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1910 Archived-At: Cc: "pce-chairs@ietf.org" Subject: [Pce] PCE meeting draft agenda X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 13:53:36 -0000 --_000_BY2PR0201MB19106C5483EF532A7FE7C2C684A10BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have published the draft agenda for the upcoming PCE working group meeti= ng in Seoul. https://datatracker.ietf.org/meeting/97/agenda/pce/ This time, we had lots of requests for meeting time - many thanks for being= such an active working group! Unfortunately, we only have 90 minutes for = the meeting, so we were not able to accommodate every request, and in some = cases have had to allocate a smaller timeslot than requested. Please let us know if you have any comments. Jon, Julien and JP. --_000_BY2PR0201MB19106C5483EF532A7FE7C2C684A10BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have published the draft agenda for the upcoming = PCE working group meeting in Seoul.

https://datatracker.ietf.org/meeting/97/agenda/pce/

 

This time, we had lots of requests for meeting time = – many thanks for being such an active working group!  Unfortuna= tely, we only have 90 minutes for the meeting, so we were not able to accom= modate every request, and in some cases have had to allocate a smaller timeslot than requested.

 

Please let us know if you have any comments.

 

Jon, Julien and JP.

 

--_000_BY2PR0201MB19106C5483EF532A7FE7C2C684A10BY2PR0201MB1910_-- From nobody Thu Nov 3 02:13:32 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] CCAMP and JOINT YANG session agenda @IETF97 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 02:58:27 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9B5129586 for ; Thu, 3 Nov 2016 02:58:25 -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 WpDmjFtiVpqs for ; Thu, 3 Nov 2016 02:58:23 -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 82E56129428 for ; Thu, 3 Nov 2016 02:58:22 -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 CUK98742; Thu, 03 Nov 2016 09:58:18 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 09:58:12 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 15:28:01 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: RFC6006bis Thread-Index: AdI1senDznHi90ZNSxO4IKCBtMFEPg== Date: Thu, 3 Nov 2016 09:58:01 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C9C143C@blreml501-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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.581B0A3A.01C4, 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: 02c5a4303595e96b474ec6fe5667c59a Archived-At: Subject: [Pce] RFC6006bis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:58:25 -0000 Hi PCE WG,=20 We have uploaded a bis document for RFC6006 (P2MP) - https://datatracker.ie= tf.org/doc/draft-palleti-pce-rfc6006bis/.=20 The changes made to RFC6006 can be seen at -=20 https://tools.ietf.org//rfcdiff?url1=3DRFC6006&url2=3Ddraft-palleti-pce-rfc= 6006bis-00 Summary:=20 This document obsoletes RFC 6006 making following changes to that document: o Incorporate all outstanding Errata. * Erratum with IDs: 3819, 3830, and 3836.=20 o Update the Routing Backus-Naur Form (RBNF) [RFC5511] for Request message format:=20 * Update the request message to allows for the bundling of multiple path computation requests within a single Path Computation Request (PCReq) message. * Add in PCReq message. This object was missed in [RFC6006]. * Add BNC object in PCReq message. This object is required to support P2MP. It shares the same format as Include Route Object (IRO) but it is a different object.=20 * Update the format to also allow Secondary Record Route object (SRRO). This object was missed in [RFC6006]. * Removed the BANDWIDTH Object followed by Record Route Object (RRO) from . As BANDWIDTH object doesn't need to follow for each RRO in the , there already exist BANDWIDTH object follow and is backward compatible with [RFC5440]. * Update the to allow optional BANDWIDTH object only if is included.=20 o Update the RBNF for Reply message format: * Update PCEP allows for the bundling of multiple path computation responses within a single Path Computation Reply (PCRep) message. * Update UNREACH-DESTINATION in PCRep message. This object was=20 missed in [RFC6006]. We request WG to have a look and provide comments.=20 Stateful P2MP draft is also updated to accommodate these changes - =20 https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-pce-stateful-pce-p2mp-00&url= 2=3Ddraft-ietf-pce-stateful-pce-p2mp-01 Regards, Dhruv=20 From nobody Thu Nov 3 06:15:27 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:18 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:57 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:37:35 -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:32 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:50:02 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:58:11 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:04:05 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:32 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:09 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:37 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:11 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:43:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 11:49:30 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:47 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:16:45 -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:13 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:21 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:03:09 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:12:40 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:47 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:20 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:16:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:34 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 Fri Nov 4 03:17:59 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 03:45:01 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F19129BF6; Fri, 4 Nov 2016 03:44:56 -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 JzsgDkDLVynx; Fri, 4 Nov 2016 03:44:50 -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 BCF28129BF2; Fri, 4 Nov 2016 03:44:49 -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 CZR38048; Fri, 04 Nov 2016 10:44:46 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 10:44:44 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 16:14:33 +0530 From: Dhruv Dhody To: Francesco Lazzeri , Leeyoung , "Beller, Dieter (Nokia - DE)" Thread-Topic: Path-key and Path Computation API (was RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00) Thread-Index: AdI2iGjPLAgKTtx+Suil5G4QyXxIsA== Date: Fri, 4 Nov 2016 10:44:33 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C9C3703@blreml501-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_23CE718903A838468A8B325B80962F9B8C9C3703blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.581C669F.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: 321b99776f2aded90bd4f66f79673d65 Archived-At: Cc: "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [Pce] Path-key and Path Computation API (was RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:44:56 -0000 --_000_23CE718903A838468A8B325B80962F9B8C9C3703blreml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Francesco, Interesting case. Starting a new thread and limiting to PCE and TEAS WG. IMHO I would shy away from storing path-key and its confidential path segme= nt (cps) as tunnels with "compute-only". In PCEP Yang, we do store path-keys in the operational data store of PCEP. = [https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/?include_text= =3D1] +--ro path-keys {path-key}? | +--ro path-keys* [path-key] | +--ro path-key uint16 | +--ro cps | | +--ro explicit-route-objects* [index] | | +--ro index uint8 | | +--ro explicit-route-usage? identityref | | +--ro (type)? | | +--:(ipv4-address) | | | +--ro v4-address? inet:ipv4-address | | | +--ro v4-prefix-length? uint8 | | | +--ro v4-loose? boolean | | +--:(ipv6-address) | | | +--ro v6-address? inet:ipv6-address | | | +--ro v6-prefix-length? uint8 | | | +--ro v6-loose? boolean | | +--:(as-number) | | | +--ro as-number? uint16 | | +--:(unnumbered-link) | | | +--ro router-id? inet:ip-address | | | +--ro interface-id? uint32 | | +--:(label) | | +--ro value? uint32 | +--ro pcc-original? -> /pcep-state/entity/peers/peer/addr | +--ro req-id? uint32 | +--ro retrieved? boolean | +--ro pcc-retrieved? -> /pcep-state/entity/peers/peer/addr | +--ro creation-time? yang:timestamp | +--ro discard-time? uint32 | +--ro reuse-time? uint32 Perhaps we need to decide if there is a need to make this generic? Regards, Dhruv From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com] Sent: 04 November 2016 15:37 To: Dhruv Dhody ; Leeyoung ; B= eller, 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: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 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, Die= ter (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_23CE718903A838468A8B325B80962F9B8C9C3703blreml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Francesco,

 

Interesting case. Starting a new thread and limiting t= o PCE and TEAS WG.

 

IMHO I would shy away from storing path-key and its co= nfidential path segment (cps) as tunnels with “compute-only”.

 

In PCEP Yang, we do store path-keys in the operational= data store of PCEP.  [https://datatracker.ietf.org/doc/draft-ietf-pce= -pcep-yang/?include_text=3D1]

+--ro path-keys {path-key}?

         |&nbs= p; +--ro path-keys* [path-key]

         |&nbs= p;    +--ro path-key      =    uint16

         |&nbs= p;    +--ro cps

         |&nbs= p;    |  +--ro explicit-route-objects* [index]=

         |&nbs= p;    |     +--ro index  &= nbsp;           &nbs= p;    uint8

         |&nbs= p;    |     +--ro explicit-route-usa= ge?   identityref

         |&nbs= p;    |     +--ro (type)?=

         |&nbs= p;    |        +--:(i= pv4-address)

         |&nbs= p;    |        |  &#= 43;--ro v4-address?         &n= bsp;   inet:ipv4-address

         |&nbs= p;    |        |  &#= 43;--ro v4-prefix-length?       uint8

         |&nbs= p;    |        |  &#= 43;--ro v4-loose?         &nbs= p;     boolean

         |&nbs= p;    |        +--:(i= pv6-address)

         |&nbs= p;    |        |  &#= 43;--ro v6-address?         &n= bsp;   inet:ipv6-address

         |&nbs= p;    |        |  &#= 43;--ro v6-prefix-length?       uint8

         |&nbs= p;    |        |  &#= 43;--ro v6-loose?         &nbs= p;     boolean

         |&nbs= p;    |        +--:(a= s-number)

         |&nbs= p;    |        |  &#= 43;--ro as-number?         &nb= sp;    uint16

         |&nbs= p;    |        +--:(u= nnumbered-link)

         |&nbs= p;    |        |  &#= 43;--ro router-id?         &nb= sp;    inet:ip-address

         |&nbs= p;    |        |  &#= 43;--ro interface-id?         =   uint32

         |&nbs= p;    |        +--:(l= abel)

         |&nbs= p;    |         = ;  +--ro value?        &nb= sp;         uint32

         |&nbs= p;    +--ro pcc-original?    -> /pcep-= state/entity/peers/peer/addr

         |&nbs= p;    +--ro req-id?      &= nbsp;   uint32

         |&nbs= p;    +--ro retrieved?     &nbs= p; boolean

         |&nbs= p;    +--ro pcc-retrieved?   -> /pcep-state= /entity/peers/peer/addr

         |&nbs= p;    +--ro creation-time?   yang:timestamp

         |&nbs= p;    +--ro discard-time?    uint32<= /o:p>

         |&nbs= p;    +--ro reuse-time?      ui= nt32

 

Perhaps we need to decide if there is a need to make t= his generic?

 

Regards,

Dhruv

 

From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: 04 November 2016 15:37
To: Dhruv Dhody <dhruv.dhody@huawei.com>; Leeyoung <leeyoun= g@huawei.com>; Beller, Dieter (Nokia - DE) <dieter.beller@nokia.com&g= t;
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: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

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

In that case the path key mecha= nism is foreseen; the controller returns a path key identifier which can be= used eventually to implement the requested path.

Here something must be stored i= nside the controller in order to understand the path key and translate it t= o the relevant route as needed. I would store the path and probably would k= eep also reserved the relevant resources, until eventual operation or expiration of the path key. This cannot be avo= ided.

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

Regards,

Francesco

 

From: CCAMP [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: 04 November, 2016 5:36 AM
To: Leeyoung <leeyoung@hua= wei.com>; Beller, Dieter (Nokia - DE) <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) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

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-boun= ces@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>

 

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_23CE718903A838468A8B325B80962F9B8C9C3703blreml501mbx_-- From nobody Fri Nov 4 06:07:21 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:48:48 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:27 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 Sun Nov 6 22:45:08 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C153129534 for ; Sun, 6 Nov 2016 22:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.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 nsRX7HduIuz2 for ; Sun, 6 Nov 2016 22:45:03 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 99ADC1294C0 for ; Sun, 6 Nov 2016 22:45:03 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id p190so162397255wmp.1 for ; Sun, 06 Nov 2016 22:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=HVx8O2CDz/Uc5aHbnzifakuK6I8UUedrVyjeklnoUSc=; b=G7B15SLYdM7MwASucF5wsVCcVxiMadLTI9Z/QpmTEMPVmn2RAnmdUSJ65uoX867cHf m1fiRd1jZWCKW6KMXQQqBUQAxI3MoATb8KF+Dtdkok3rlQ8NwEOzsPvSCAoVSYoZe2cW ew4d1kVYzxlviARTBblom3WxXmx2y6S3ft2XkMTaYVEnBNbxS3+lQJcVhW9+IM2IoMq4 S7Bn40oOvm7MkLT+Fu1bIkBESFSCZTD4XiI5urd/VbjA59UHcKLLlJqDEqBxakKQk4g3 O114TdoWQydFMIbDNiNYfIw1ly2EKWnii4rfbKv9tB4vas6r8coCmWhDxVnBulxEW5Qh jkJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=HVx8O2CDz/Uc5aHbnzifakuK6I8UUedrVyjeklnoUSc=; b=JYChzGJQz7lGooaflQ1antYc65lffJwOzGlDJ5M7gvYu0/BylL6YH9HwX4q/Tj+eVe uJ4i9Fc04U7hY710mNE+kFYG6lqCA0wBKAO1XV9m9434T7IoRRTPt3C+KD99rZrStT5m rwDpGUXIFcVdC42C13Z58WJxDpHYaG/vubizYCRFr/x7iPfYIU1IoP0heP23P7/cudU4 PM7jpxhMOTWFC2xAvg9lM3H0NEZ39t2Z58+n9jKEZAE7PwzReMSlcZhokTqfIg9UgCGm HG9BgDUv6tNPt6ZIO2B1h9CM4hcoj1VtZRT8QuL+0Z6fvnxfIXxXmzNWABSaAQiAkWpg dFMQ== X-Gm-Message-State: ABUngvcTVaWM8jjAjZ7KE77rlRTMDJtLL3v4G4IIgDmHoxto+kXUFhAAmKqM7Qiph3c1FA== X-Received: by 10.28.146.203 with SMTP id u194mr6858442wmd.79.1478501102097; Sun, 06 Nov 2016 22:45:02 -0800 (PST) Received: from CIPHER ([88.97.6.210]) by smtp.gmail.com with ESMTPSA id g10sm29055250wjw.18.2016.11.06.22.45.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Nov 2016 22:45:00 -0800 (PST) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: "'Jonathan Hardwick'" , , References: In-Reply-To: Date: Mon, 7 Nov 2016 06:44:57 -0000 Message-ID: <005e01d238c2$74fa3050$5eee90f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01D238C2.74FB41C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHBccve97ozcBj5XgHL4r0Hqpz4Y6DuoOHQ Content-Language: en-gb Archived-At: Cc: pce-chairs@ietf.org Subject: Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-area-as-applicability-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 06:45:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005F_01D238C2.74FB41C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Chairs, As an author, I am not aware of any IPR that applies to this I-D. BR, Dan. From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: 21 October 2016 11:27 To: pce@ietf.org; draft-ietf-pce-inter-area-as-applicability@ietf.org Cc: pce-chairs@ietf.org Subject: Working group last call (including final IPR check) for draft-ietf-pce-inter-area-as-applicability-06 Dear PCE working group, This email starts a working group last call for draft-ietf-pce-inter-area-as-applicability-06. https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/ Please read the document and reply to the PCE mailing list whether you believe this document is ready to be published, or not (including any comments on why not). The last call will end on Friday 4 November. We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-pce-inter-area-as-applicability-06, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are a document author, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The document won't progress without answers from all the authors. No IPR disclosures currently exist against this document. Many thanks Jon, JP and Julien ------=_NextPart_000_005F_01D238C2.74FB41C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chairs,

 

As an = author, I am not aware of any IPR that applies to this I-D. =

 

BR, Dan.

 

From: Jonathan Hardwick = [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: 21 October = 2016 11:27
To: pce@ietf.org; = draft-ietf-pce-inter-area-as-applicability@ietf.org
Cc: = pce-chairs@ietf.org
Subject: Working group last call = (including final IPR check) for = draft-ietf-pce-inter-area-as-applicability-06

=

 

Dear PCE working group,

 

This email = starts a working group last call for = draft-ietf-pce-inter-area-as-applicability-06.

https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-a= s-applicability/

 

Please read = the document and reply to the PCE mailing list whether you believe this = document is ready to be published, or not (including any comments on why = not).  The last call will end on Friday 4 = November.

 

We are also polling for knowledge of any undisclosed = IPR that applies to draft-ietf-pce-inter-area-as-applicability-06, to = ensure that IPR has been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving = forward.  If you are a document author, please respond to this = email and indicate whether or not you are aware of any relevant = undisclosed IPR. The document won't progress without answers from all = the authors.  No IPR disclosures currently exist against this = document.

 

Many thanks

Jon, JP = and Julien

 

------=_NextPart_000_005F_01D238C2.74FB41C0-- From nobody Sun Nov 6 22:47:31 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2AF129B57; Sun, 6 Nov 2016 22:47:29 -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 1jmJtinzkD8v; Sun, 6 Nov 2016 22:47: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 C49C412965C; Sun, 6 Nov 2016 22:47:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZV36297; Mon, 07 Nov 2016 06:47:24 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Nov 2016 06:47:14 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Mon, 7 Nov 2016 12:17:08 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "pce@ietf.org" , "draft-ietf-pce-inter-area-as-applicability@ietf.org" Thread-Topic: Working group last call (including final IPR check) for draft-ietf-pce-inter-area-as-applicability-06 Thread-Index: AdIrhQl7pBhcwBpBRqOqB/AjL2LbBwNPaQUA Date: Mon, 7 Nov 2016 06:47:07 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C9C690C@blreml501-mbx> References: In-Reply-To: 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_23CE718903A838468A8B325B80962F9B8C9C690Cblreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5820237D.0031, 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: c40986b49d0b63bad5ff0e447c9b0706 Archived-At: Cc: "pce-chairs@ietf.org" Subject: Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-area-as-applicability-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 06:47:30 -0000 --_000_23CE718903A838468A8B325B80962F9B8C9C690Cblreml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am also not aware of any IPR relevant to this document. Regards, Dhruv From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 21 October 2016 15:57 To: pce@ietf.org; draft-ietf-pce-inter-area-as-applicability@ietf.org Cc: pce-chairs@ietf.org Subject: [Pce] Working group last call (including final IPR check) for draf= t-ietf-pce-inter-area-as-applicability-06 Dear PCE working group, This email starts a working group last call for draft-ietf-pce-inter-area-a= s-applicability-06. https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability= / Please read the document and reply to the PCE mailing list whether you beli= eve this document is ready to be published, or not (including any comments = on why not). The last call will end on Friday 4 November. We are also polling for knowledge of any undisclosed IPR that applies to dr= aft-ietf-pce-inter-area-as-applicability-06, to ensure that IPR has been di= sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 53= 78 for more details) prior to moving forward. If you are a document author= , please respond to this email and indicate whether or not you are aware of= any relevant undisclosed IPR. The document won't progress without answers = from all the authors. No IPR disclosures currently exist against this docu= ment. Many thanks Jon, JP and Julien --_000_23CE718903A838468A8B325B80962F9B8C9C690Cblreml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am also not aware of any = IPR relevant to this document.

 

Regards,<= /p>

Dhruv

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 21 October 2016 15:57
To: pce@ietf.org; draft-ietf-pce-inter-area-as-applicability@ietf.or= g
Cc: pce-chairs@ietf.org
Subject: [Pce] Working group last call (including final IPR check) f= or draft-ietf-pce-inter-area-as-applicability-06

 

Dear PCE working group,

 

This email starts a working gro= up last call for draft-ietf-pce-inter-area-as-applicability-06.<= /span>

https://datatrack= er.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/<= /span>

 

Please read the document and re= ply to the PCE mailing list whether you believe this document is ready to b= e published, or not (including any comments on why not).  The last cal= l will end on Friday 4 November.

 

We are also polling for knowled= ge of any undisclosed IPR that applies to draft-ietf-pce-inter-area-as-appl= icability-06, to ensure that IPR has been disclosed in compliance with IETF= IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward.  If you are a doc= ument author, please respond to this email and indicate whether or not you = are aware of any relevant undisclosed IPR. The document won't progress with= out answers from all the authors.  No IPR disclosures currently exist against this document.

 

Many thanks

Jon, JP and Julien

 

--_000_23CE718903A838468A8B325B80962F9B8C9C690Cblreml501mbx_-- From nobody Mon Nov 7 00:50:23 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 Wed Nov 9 02:11:57 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [Pce] =?gb2312?b?tPC4tDogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o?= =?gb2312?b?dG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24t?= =?gb2312?b?MDA=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:49:10 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:26:10 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 14:25:49 -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:48:05 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:39 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:35 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:23 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:52 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:36 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [Pce] =?gb2312?b?tPC4tDogW21wbHNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o?= =?gb2312?b?dG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24t?= =?gb2312?b?MDA=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 Wed Nov 9 23:00:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B08129479 for ; Wed, 9 Nov 2016 23:00:55 -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 lHXpv_TXWC6t for ; Wed, 9 Nov 2016 23:00:52 -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 A4A47129416 for ; Wed, 9 Nov 2016 23:00:51 -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 DAB89327; Thu, 10 Nov 2016 07:00:49 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 07:00:48 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 12:30:45 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: ACTN related drafts in PCEP Thread-Index: AdI2ghyUMDVFYHHnRY6eYwq3GbQWdA== Date: Thu, 10 Nov 2016 07:00:44 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C9CF2F5@blreml501-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_23CE718903A838468A8B325B80962F9B8C9CF2F5blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58241B22.0007, 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: 881a6e5e9ba3d9fad5991b0c1dde4909 Archived-At: Subject: [Pce] ACTN related drafts in PCEP X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 07:00:55 -0000 --_000_23CE718903A838468A8B325B80962F9B8C9CF2F5blreml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi PCE WG, We have updated a few of the drafts related to ACTN. Here is a quick summar= y - (1) Applicability of PCE for ACTN [https://tools.ietf.org/html/draft-dho= dy-pce-applicability-actn-01] Updated to handle comments received on Mic and offline. See https://mailarc= hive.ietf.org/arch/msg/pce/Fst0XjIadPpDDSExpR-ikuxYfiA for details. (2) Stateful H-PCE [https://tools.ietf.org/html/draft-dhodylee-pce-statef= ul-hpce-02] - Added a statement on recursiveness - In case of per domain LSP, an additional optional step for also = initiating an E2E multi-domain lsp. - Scalability Consideration section - Oscar joined as co-author Diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-dhodylee-pce-stateful-hpce-= 01&url2=3Ddraft-dhodylee-pce-stateful-hpce-02 (3) VN Association [https://tools.ietf.org/html/draft-leedhody-pce-vn-as= sociation-01] - Added text on how this association could be useful. Diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-leedhody-pce-vn-association= -00&url2=3Ddraft-leedhody-pce-vn-association-01 Please provide comments. Also in case you are at IETF, do stop by at the hackathon on Saturday/Sunda= y where we continue to work on this. Regards, Dhruv (on behalf of all co-authors) --_000_23CE718903A838468A8B325B80962F9B8C9CF2F5blreml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi PCE WG,

 

We have updated a few of the drafts r= elated to ACTN. Here is a quick summary –

 

(1)    Applicability of PCE for ACTN= [https://tools.ietf.org/html/draft-dhody-pce-applicability-actn-01]

= Updated to handle comments received on Mic and offline. See https://mailarchive.ietf.org/arch/msg/pce/Fst0XjIadPpDDSExpR-ikuxYfi= A for details.

=  

(2)   Stateful H-PCE [https://tools= .ietf.org/html/draft-dhodylee-pce-stateful-hpce-02]

-    &n= bsp;     Added a statement on recursiv= eness

-    &n= bsp;     In case of per domain LSP, an= additional optional step for also initiating an E2E multi-domain lsp.=

-    &n= bsp;     Scalability Consideration sec= tion

-    &n= bsp;     Oscar joined as co-author

= Diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-dhodylee-pce-stateful-hpce-01&= ;url2=3Ddraft-dhodylee-pce-stateful-hpce-02

 

(3)    VN Association [https://tools= .ietf.org/html/draft-leedhody-pce-vn-association-01]

-    &n= bsp;     Added text on how this associ= ation could be useful.

= Diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-leedhody-pce-vn-association-00&am= p;url2=3Ddraft-leedhody-pce-vn-association-01

 

Please provide comments.

 

Also in case you are at IETF, do stop= by at the hackathon on Saturday/Sunday where we continue to work on this.<= o:p>

 

Regards,

Dhruv (on behalf of all co-authors)

 

--_000_23CE718903A838468A8B325B80962F9B8C9CF2F5blreml501mbx_-- From nobody Thu Nov 10 02:02:30 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:24 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:30 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:02 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:20 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:42 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:25 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:33 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 06:44:18 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:52 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:18 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:35 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:45:01 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:18 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:08 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:07 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:52:09 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] Slides for Joint YANG session X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 06:40:13 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5995C12955A for ; Mon, 14 Nov 2016 06:40:12 -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 O-0o-VobS2HN for ; Mon, 14 Nov 2016 06:40:11 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 21768129551 for ; Mon, 14 Nov 2016 06:40:11 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q130so97471580qke.1 for ; Mon, 14 Nov 2016 06:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XJHx7rOp98VkmjD1XV1cnphsTIlFLH8p9SCdx3v+iY8=; b=oofxawMvhPZC3WTV6V+xXr3J7UcfYAMLDEKC8IBPKibsJre9LY8swSXF8toc7pyRu8 5Pq8Sym0e6pABWaQyjX3xJH/dugs58vEL3DFh791FpQ42CYXPHJL1/OnY5XM7iEhw3/4 YUTZtCyXGVOJD8AW8TklEysz9rVN4Dz05jE2I2heI9NieB9NLr+0l9j2SERKg7/WCQu+ 6mhuFGQYuSOGuihGoE15cu8O65dlMH7VDc7AZ9sojlF/rWBRjW5gagNJAxo5Bg6pBFbw RQJcqeVWQH09iy/2+UobYG4FEn8hFk7v+iHPfdEZN908bk2P70NYO6rW+XcZN8p9Q8Jl iUHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XJHx7rOp98VkmjD1XV1cnphsTIlFLH8p9SCdx3v+iY8=; b=b/xOhQksWKS7xc8SeTUg3sNk/lJ+JON8VEuLL+PopDwxvI/D9K5kXgcXQ/Nf4lN9dy L1s0d9DhNSNCAqSgA9fDVEkHME2gwZd1asCdOzAOjpnryUQ5Gskh1RN1ksPWBuT58Al4 3dD2SMrsfoJE/cAHOlCjHQutipl3zCuDYVqYMICPs/0X/hVbcHm/BfYaK0t8Ug0urg3C RN8ifrHxTIGVZAYvrwJ3MtUIrZPRWydUtlnUHeo5bTS8GCikar6DTDCzE28JFIy5UO/X So22cV5sXDx/PPohPzn6MQ98VzppExmIGVfWJaAx4IQbBtbRVz3uctMut2BaX+rWLs+B A7LQ== X-Gm-Message-State: ABUngve4XGmLXconoBOA+KCPgOYv4MgUInzq3sl0rm84P8+kKQrCMzntd5hIksZM2l6Jewr6TgUUQnpAYkw6SQ== X-Received: by 10.55.135.69 with SMTP id j66mr17112039qkd.31.1479134410136; Mon, 14 Nov 2016 06:40:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.133.34 with HTTP; Mon, 14 Nov 2016 06:40:09 -0800 (PST) From: Cyril Margaria Date: Mon, 14 Nov 2016 09:40:09 -0500 Message-ID: To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c075f46176b65054143d1db Archived-At: Subject: [Pce] Comments on draft-ietf-pce-segment-routing-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 14:40:12 -0000 --94eb2c075f46176b65054143d1db Content-Type: text/plain; charset=UTF-8 Dear PCE'ers I reviewed the document and I have the following comments/questions: 1) The document implies that the PCC has to /MUST do IP address to SID conversion, I think that it would allow a more simpler PCC if that capability is optional and negotiated with additional error codes to indicate that the NAI SR-EROs are not supported. 2) One aspect of the SR-ERO processing is that, when building the label stack, the PCC should have enough information to decide on the outgoing link (this can be provided by the PCE). It will be good if the document state could spell out this part of the procedure and indicates any specific SR-ERO procedure. For instance one solution could be that the PCE may use IP address or Adjacency SID to indicate the outgoing link. 3) Taking the outgoing link selection into account, the Maximum Stack Depth (MSD) calculation may be not trivial: for instance if the first hop is a local Adjacency-SID, then the label will not be stacked, but it will if the first hop is a Prefix SID it may be counted (non-adjacent node or adjacent node without PHP) but it may not be counted (adjacent node, with PHP). I think the draft should clarify it. Thanks, Cyril --94eb2c075f46176b65054143d1db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear PCE'ers

<= p class=3D"gmail-p1">I reviewed the document and I= have the following comments/questions:=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = The document implies that the PCC has to /MUST do IP address to SID convers= ion, I =C2=A0think that it would allow a more simpler PCC if that capabilit= y is optional =C2=A0and negotiated with additional error codes to in= dicate that the NAI SR-EROs are not supported.

2)=C2=A0 =C2=A0 =C2=A0 =C2=A0One aspect of the SR-ERO processing is tha= t, =C2=A0when building the label stack, the= PCC should have enough information to decide on the outgoing link (this ca= n be provided by the PCE). It will be good if the document state could spel= l out this part of the procedure and indicates any specific SR-ERO procedur= e. For instance one solution could be =C2=A0that the PCE may use IP address= or Adjacency SID to indicate the outgoing link.

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Taking the outgoing link selection into account, the Maximum Stack Depth (M= SD) calculation may be not trivial: for instance if the first hop is a loca= l Adjacency-SID, then the label will not be stacked, but it will if the fir= st hop is a Prefix SID it may be counted (non-adjacent node or adjacent nod= e without PHP) but it may not be counted (adjacent node, with PHP). I think= the draft should clarify it.

Thanks,=C2=A0

Cyril=C2=A0



=C2=A0

--94eb2c075f46176b65054143d1db-- From nobody Mon Nov 14 07:45:23 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 Mon Nov 14 10:05:30 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85810129564 for ; Mon, 14 Nov 2016 10:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.096 X-Spam-Level: X-Spam-Status: No, score=-4.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 afvl2C5K9eVz for ; Mon, 14 Nov 2016 10:05:27 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2BB129424 for ; Mon, 14 Nov 2016 10:05:26 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id EBBC8203E4; Mon, 14 Nov 2016 19:05:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id C2B421A006D; Mon, 14 Nov 2016 19:05:24 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 19:05:24 +0100 From: To: Cyril Margaria , "pce@ietf.org" Thread-Topic: [Pce] Comments on draft-ietf-pce-segment-routing-08 Thread-Index: AQHSPoUGqKOABs9inkipMImcyolwlaDYvVew Date: Mon, 14 Nov 2016 18:05:23 +0000 Message-ID: <25467_1479146724_5829FCE4_25467_994_1_9E32478DFA9976438E7A22F69B08FF921DBA75F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DBA75F9OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Comments on draft-ietf-pce-segment-routing-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 18:05:28 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921DBA75F9OPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ3lyaWwsDQoNClBsZWFzZSBmaW5kIHNvbWUgaW5saW5lIGNvbW1lbnRzLg0KDQpCcmdkcywN Cg0KRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBD eXJpbCBNYXJnYXJpYQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAxNiAyMzo0MA0KVG86 IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogW1BjZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Ut c2VnbWVudC1yb3V0aW5nLTA4DQoNCg0KRGVhciBQQ0UnZXJzDQoNCkkgcmV2aWV3ZWQgdGhlIGRv Y3VtZW50IGFuZCBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cy9xdWVzdGlvbnM6DQoNCjEp ICAgICAgICAgICAgICBUaGUgZG9jdW1lbnQgaW1wbGllcyB0aGF0IHRoZSBQQ0MgaGFzIHRvIC9N VVNUIGRvIElQIGFkZHJlc3MgdG8gU0lEIGNvbnZlcnNpb24sIEkgIHRoaW5rIHRoYXQgaXQgd291 bGQgYWxsb3cgYSBtb3JlIHNpbXBsZXIgUENDIGlmIHRoYXQgY2FwYWJpbGl0eSBpcyBvcHRpb25h bCAgYW5kIG5lZ290aWF0ZWQgd2l0aCBhZGRpdGlvbmFsIGVycm9yIGNvZGVzIHRvIGluZGljYXRl IHRoYXQgdGhlIE5BSSBTUi1FUk9zIGFyZSBub3Qgc3VwcG9ydGVkLg0KDQpbU0xJXSBVc2FnZSBv ZiBOQUkgaW4gdGhlIFNSLUVSTyBpcyBhbHJlYWR5IG9wdGlvbmFsIHRvZGF5IGJ1dCBkcml2ZW4g YnkgUENFLiBEbyB5b3UgbWVhbiB0aGF0IHRoZSBQQ0Mgc2hvdWxkIGRyaXZlIHRoZSBQQ0UgY29t cHV0YXRpb24gcmVzdWx0IGJlaGF2aW9yID8gQSBuZXcgb2JqZWN0IG1heSBiZSBjcmVhdGVkIGZv ciB0aGlzIHB1cnBvc2UgYXMgYSBuZXcgcGF0aCBjb25zdHJhaW50LiBCdXQgeW91IGFsc28gbWF5 IGZhbGwgaW50byBzaXR1YXRpb25zIHdoZXJlIHRoZSBQQ0UgZG9lcyBub3Qgc3VwcG9ydCB0aGlz IG5ldyBjb25zdHJhaW50IHJlcXVlc3RlZCBieSBQQ0MuIFRoZW4sIGl0IHdvdWxkIGJlIGdvb2Qg dG8gaW1wb3NlIG9uZSBtZXRob2QgdG8gYmUgc3VwcG9ydGVkIGFuZCBvdGhlcnMgdG8gYmUgb3B0 aW9uYWwsIHRoaXMgd2lsbCBlbnN1cmUgYSByZWFsIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBh bGwgaW1wbGVtZW50YXRpb25zLiBJIHdvdWxkIGFsc28gcHJlZmVyIHRvIGxpbWl0IHRoZSBvcHRp b25z4oCmIChkb2VzIG1peGluZyBTSUQgYW5kIE5BSSBtYWtlIHNlbnNlID8gSSBkbyBub3Qgc2Vl IHRoZSB1c2UgY2FzZSBiZWhpbmQpDQoNCg0KDQoyKSAgICAgICAgICAgICAgT25lIGFzcGVjdCBv ZiB0aGUgU1ItRVJPIHByb2Nlc3NpbmcgaXMgdGhhdCwgIHdoZW4gYnVpbGRpbmcgdGhlIGxhYmVs IHN0YWNrLCB0aGUgUENDIHNob3VsZCBoYXZlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBkZWNpZGUg b24gdGhlIG91dGdvaW5nIGxpbmsgKHRoaXMgY2FuIGJlIHByb3ZpZGVkIGJ5IHRoZSBQQ0UpLiBJ dCB3aWxsIGJlIGdvb2QgaWYgdGhlIGRvY3VtZW50IHN0YXRlIGNvdWxkIHNwZWxsIG91dCB0aGlz IHBhcnQgb2YgdGhlIHByb2NlZHVyZSBhbmQgaW5kaWNhdGVzIGFueSBzcGVjaWZpYyBTUi1FUk8g cHJvY2VkdXJlLiBGb3IgaW5zdGFuY2Ugb25lIHNvbHV0aW9uIGNvdWxkIGJlICB0aGF0IHRoZSBQ Q0UgbWF5IHVzZSBJUCBhZGRyZXNzIG9yIEFkamFjZW5jeSBTSUQgdG8gaW5kaWNhdGUgdGhlIG91 dGdvaW5nIGxpbmsuDQoNCltTTEldIEFyZSB5b3UgaW4gdGhlIGNhc2Ugb2YgU0lEIG9ubHkgdXNl ZCBpbiBFUk8gPyBJZiBOQUkgaXMgdXNlZCwgb3V0Z29pbmcgaWYgY2FuIGJlIGRlZHVjZWQgZnJv bSB0aGUgZmlyc3QgaG9wIE5BSSwgaWYgTkFJIGlzIG5vdCB1c2VkLCB0aGVuIGl0IGJlY29tZXMg bm90IHRyaXZpYWwgYW5kIGhvbmVzdGx5IEkgZG8gbm90IHNlZSBob3cgdG8gZGVkdWNlIHRoZSBp bnRlcmZhY2UgKFBDQyBjYW5ub3QgY2hlY2sgaXRzIG91dGdvaW5nIGxhYmVsIGRhdGFiYXNlLCBh cyB0aGUgc2FtZSB2YWx1ZSBtYXkgYmUgdXNlZCBieSBtdWx0aXBsZSBuZWlnaGJvcnMpLiBOQUkg c2hvdWxkIGJlIGEgTVVTVCBmb3IgdGhlIGZpcnN0IGhvcCA/DQoNCjMpICAgICAgICAgICAgICBU YWtpbmcgdGhlIG91dGdvaW5nIGxpbmsgc2VsZWN0aW9uIGludG8gYWNjb3VudCwgdGhlIE1heGlt dW0gU3RhY2sgRGVwdGggKE1TRCkgY2FsY3VsYXRpb24gbWF5IGJlIG5vdCB0cml2aWFsOiBmb3Ig aW5zdGFuY2UgaWYgdGhlIGZpcnN0IGhvcCBpcyBhIGxvY2FsIEFkamFjZW5jeS1TSUQsIHRoZW4g dGhlIGxhYmVsIHdpbGwgbm90IGJlIHN0YWNrZWQsIGJ1dCBpdCB3aWxsIGlmIHRoZSBmaXJzdCBo b3AgaXMgYSBQcmVmaXggU0lEIGl0IG1heSBiZSBjb3VudGVkIChub24tYWRqYWNlbnQgbm9kZSBv ciBhZGphY2VudCBub2RlIHdpdGhvdXQgUEhQKSBidXQgaXQgbWF5IG5vdCBiZSBjb3VudGVkIChh ZGphY2VudCBub2RlLCB3aXRoIFBIUCkuIEkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBjbGFyaWZ5 IGl0Lg0KDQpbU0xJXSBJIGRvIG5vdCBzZWUgd2h5IHRoZSBmaXJzdCBob3AgY291bGQgYmUgYSBs b2NhbCBBZGotU0lE4oCmIGlmIHRoZSBFUk8gcmVwcmVzZW50cyB0aGUgc3RhY2sgdG8gYmUgdXNl ZCBmb3IgdGhlIHB1c2ggb3BlcmF0aW9uLCBhbmQgaWYgaXQgc3RhcnRzIHdpdGggYW4gQWRqLVNJ RCwgdGhlIEFkai1TSUQgc2hvdWxkIHJlcHJlc2VudCB0aGUgZmlyc3QgcmVhbCBmb3J3YXJkaW5n IG9wZXJhdGlvbi4gR29pbmcgYmFjayB0byBvaWYgcG9pbnQsIGlmIE5BSSBpc27igJl0IHVzZWQs IGhvdyBjYW4gYSBQQ0Mga25vdyB0aGF0IHRoZSBmaXJzdCBBZGotU0lEIGlzIGEgbG9jYWwgU0lE IG9yIGEgbmVpZ2hib3LigJlzIFNJRCA/IElmIFNJRCBvbmx5IGlzIHVzZWQgYW5kIHN0YXJ0cyB3 aXRoIGFuIEFkai1TSUQsIHRoZSBTUi1FUk8gbWF5IGJlIGVuY29kZWQgdXNpbmc6IE5BSSxBZGot U0lELFNJRCMxLFNJRCMyLFNJRCMzLOKAplNJRCNuLiBUaGUgZmlyc3QgaG9wIGRlZmluZXMgb25s eSB0aGUgb2lmLg0KDQpJbiBjYXNlIHRoZSBzdGFjayBzdGFydHMgd2l0aCBhIE5vZGUtU0lELCB3 ZSBtYXkgaGF2ZTpOb2RlLVNJRCtOQUksU0lEIzEsU0lEIzIsU0lEIzMg4oCmDQoNClVzaW5nIHRo aXMsIHdlIGFyZSBhbHdheXMgaW5saW5lIHdpdGggTVNEIGFzIHdlIG5ldmVyIHNlbmQgYW4gRVJP IHdpdGggbW9yZSBsYWJlbHMgdGhhbiBzdXBwb3J0ZWQuDQoNCg0KDQoNCg0KVGhhbmtzLA0KDQpD eXJpbA0KDQoNCg0KDQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF921DBA75F9OPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5nbWFpbC1wMSwgbGkuZ21haWwtcDEs IGRpdi5nbWFpbC1wMQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1wMTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5nbWFpbC1zMQ0KCXttc28tc3R5bGUt bmFtZTpnbWFpbC1zMTt9DQpzcGFuLmdtYWlsLXMyDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLXMy O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo4MDExOTQzODA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02NDYxODQxMzQgLTE2MTUwMzM5MzQgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6NDguNzVwdDsNCgl0ZXh0LWluZGVudDotMzAuNzVwdDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEN5 cmlsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGZpbmQgc29tZSBpbmxpbmUgY29tbWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Ccmdkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBjZSBb bWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DeXJpbCBN YXJnYXJpYTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDE0LCAyMDE2IDIzOjQw PGJyPg0KPGI+VG86PC9iPiBwY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1BjZV0g Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nLTA4PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLXAxIj48c3BhbiBjbGFzcz0iZ21haWwtczEiPkRlYXIgUENF J2Vyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1wMSI+PHNwYW4gY2xh c3M9ImdtYWlsLXMxIj5JIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgSSBoYXZlIHRoZSBmb2xs b3dpbmcgY29tbWVudHMvcXVlc3Rpb25zOjwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJnbWFpbC1wMSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQ4Ljc1cHQ7dGV4dC1pbmRlbnQ6 LTMwLjc1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gY2xhc3M9ImdtYWlsLXMxIj5UaGUgZG9jdW1lbnQgaW1w bGllcyB0aGF0IHRoZSBQQ0MgaGFzIHRvIC9NVVNUIGRvIElQIGFkZHJlc3MgdG8gU0lEIGNvbnZl cnNpb24sIEkgJm5ic3A7dGhpbmsgdGhhdCBpdCB3b3VsZCBhbGxvdyBhIG1vcmUgc2ltcGxlciBQ Q0MgaWYgdGhhdCBjYXBhYmlsaXR5IGlzIG9wdGlvbmFsICZuYnNwOzwvc3Bhbj5hbmQgbmVnb3Rp YXRlZCB3aXRoIGFkZGl0aW9uYWwgZXJyb3IgY29kZXMNCiB0byBpbmRpY2F0ZSB0aGF0IHRoZSBO QUkgU1ItRVJPcyBhcmUgbm90IHN1cHBvcnRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJn bWFpbC1wMSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltTTEldIFVzYWdlIG9mIE5BSSBp biB0aGUgU1ItRVJPIGlzIGFscmVhZHkgb3B0aW9uYWwgdG9kYXkgYnV0IGRyaXZlbiBieSBQQ0Uu IERvIHlvdSBtZWFuIHRoYXQgdGhlIFBDQyBzaG91bGQgZHJpdmUgdGhlIFBDRSBjb21wdXRhdGlv biByZXN1bHQgYmVoYXZpb3IgPyBBIG5ldyBvYmplY3QgbWF5IGJlIGNyZWF0ZWQgZm9yIHRoaXMg cHVycG9zZSBhcyBhIG5ldyBwYXRoDQogY29uc3RyYWludC4gQnV0IHlvdSBhbHNvIG1heSBmYWxs IGludG8gc2l0dWF0aW9ucyB3aGVyZSB0aGUgUENFIGRvZXMgbm90IHN1cHBvcnQgdGhpcyBuZXcg Y29uc3RyYWludCByZXF1ZXN0ZWQgYnkgUENDLiBUaGVuLCBpdCB3b3VsZCBiZSBnb29kIHRvIGlt cG9zZSBvbmUgbWV0aG9kIHRvIGJlIHN1cHBvcnRlZCBhbmQgb3RoZXJzIHRvIGJlIG9wdGlvbmFs LCB0aGlzIHdpbGwgZW5zdXJlIGEgcmVhbCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gYWxsDQog aW1wbGVtZW50YXRpb25zLiBJIHdvdWxkIGFsc28gcHJlZmVyIHRvIGxpbWl0IHRoZSBvcHRpb25z 4oCmIChkb2VzIG1peGluZyBTSUQgYW5kIE5BSSBtYWtlIHNlbnNlID8gSSBkbyBub3Qgc2VlIHRo ZSB1c2UgY2FzZSBiZWhpbmQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWls LXAxIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9ImdtYWlsLXAxIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDguNzVwdDt0ZXh0 LWluZGVudDotMzAuNzVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBjbGFzcz0iZ21haWwtczEiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBjbGFzcz0iZ21haWwtczIiPk9uZSBhc3BlY3Qgb2YgdGhlIFNSLUVSTyBwcm9jZXNzaW5n IGlzIHRoYXQsICZuYnNwO3c8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLXMxIj5oZW4gYnVpbGRp bmcgdGhlIGxhYmVsIHN0YWNrLCB0aGUgUENDIHNob3VsZCBoYXZlIGVub3VnaCBpbmZvcm1hdGlv biB0byBkZWNpZGUgb24gdGhlIG91dGdvaW5nIGxpbmsgKHRoaXMgY2FuIGJlIHByb3ZpZGVkIGJ5 IHRoZQ0KIFBDRSkuIEl0IHdpbGwgYmUgZ29vZCBpZiB0aGUgZG9jdW1lbnQgc3RhdGUgY291bGQg c3BlbGwgb3V0IHRoaXMgcGFydCBvZiB0aGUgcHJvY2VkdXJlIGFuZCBpbmRpY2F0ZXMgYW55IHNw ZWNpZmljIFNSLUVSTyBwcm9jZWR1cmUuIEZvciBpbnN0YW5jZSBvbmUgc29sdXRpb24gY291bGQg YmUgJm5ic3A7dGhhdCB0aGUgUENFIG1heSB1c2UgSVAgYWRkcmVzcyBvciBBZGphY2VuY3kgU0lE IHRvIGluZGljYXRlIHRoZSBvdXRnb2luZyBsaW5rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJnbWFpbC1wMSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltTTEldIEFyZSB5 b3UgaW4gdGhlIGNhc2Ugb2YgU0lEIG9ubHkgdXNlZCBpbiBFUk8gPyBJZiBOQUkgaXMgdXNlZCwg b3V0Z29pbmcgaWYgY2FuIGJlIGRlZHVjZWQgZnJvbSB0aGUgZmlyc3QgaG9wIE5BSSwgaWYgTkFJ IGlzIG5vdCB1c2VkLCB0aGVuIGl0IGJlY29tZXMgbm90IHRyaXZpYWwgYW5kIGhvbmVzdGx5IEkg ZG8gbm90IHNlZSBob3cgdG8gZGVkdWNlIHRoZQ0KIGludGVyZmFjZSAoUENDIGNhbm5vdCBjaGVj ayBpdHMgb3V0Z29pbmcgbGFiZWwgZGF0YWJhc2UsIGFzIHRoZSBzYW1lIHZhbHVlIG1heSBiZSB1 c2VkIGJ5IG11bHRpcGxlIG5laWdoYm9ycykuIE5BSSBzaG91bGQgYmUgYSBNVVNUIGZvciB0aGUg Zmlyc3QgaG9wID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtcDEiIHN0 eWxlPSJtYXJnaW4tbGVmdDo0OC43NXB0O3RleHQtaW5kZW50Oi0zMC43NXB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGNsYXNzPSJnbWFpbC1z MSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGNsYXNzPSJnbWFpbC1zMSI+VGFraW5n IHRoZSBvdXRnb2luZyBsaW5rIHNlbGVjdGlvbiBpbnRvIGFjY291bnQsIHRoZSBNYXhpbXVtIFN0 YWNrIERlcHRoIChNU0QpIGNhbGN1bGF0aW9uIG1heSBiZSBub3QgdHJpdmlhbDogZm9yIGluc3Rh bmNlIGlmIHRoZSBmaXJzdCBob3AgaXMgYSBsb2NhbCBBZGphY2VuY3ktU0lELCB0aGVuIHRoZSBs YWJlbCB3aWxsIG5vdCBiZSBzdGFja2VkLA0KIGJ1dCBpdCB3aWxsIGlmIHRoZSBmaXJzdCBob3Ag aXMgYSBQcmVmaXggU0lEIGl0IG1heSBiZSBjb3VudGVkIChub24tYWRqYWNlbnQgbm9kZSBvciBh ZGphY2VudCBub2RlIHdpdGhvdXQgUEhQKSBidXQgaXQgbWF5IG5vdCBiZSBjb3VudGVkIChhZGph Y2VudCBub2RlLCB3aXRoIFBIUCkuIEkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBjbGFyaWZ5IGl0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1wMSI+PHNwYW4gY2xhc3M9 ImdtYWlsLXMxIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1NMSV0gSSBkbyBub3Qgc2Vl IHdoeSB0aGUgZmlyc3QgaG9wIGNvdWxkIGJlIGEgbG9jYWwgQWRqLVNJROKApiBpZiB0aGUgRVJP IHJlcHJlc2VudHMgdGhlIHN0YWNrIHRvIGJlIHVzZWQgZm9yIHRoZSBwdXNoIG9wZXJhdGlvbiwg YW5kIGlmIGl0IHN0YXJ0cyB3aXRoIGFuIEFkai1TSUQsIHRoZSBBZGotU0lEIHNob3VsZCByZXBy ZXNlbnQNCiB0aGUgZmlyc3QgcmVhbCBmb3J3YXJkaW5nIG9wZXJhdGlvbi4gR29pbmcgYmFjayB0 byBvaWYgcG9pbnQsIGlmIE5BSSBpc27igJl0IHVzZWQsIGhvdyBjYW4gYSBQQ0Mga25vdyB0aGF0 IHRoZSBmaXJzdCBBZGotU0lEIGlzIGEgbG9jYWwgU0lEIG9yIGEgbmVpZ2hib3LigJlzIFNJRCA/ IElmIFNJRCBvbmx5IGlzIHVzZWQgYW5kIHN0YXJ0cyB3aXRoIGFuIEFkai1TSUQsIHRoZSBTUi1F Uk8gbWF5IGJlIGVuY29kZWQgdXNpbmc6IE5BSSxBZGotU0lELFNJRCMxLFNJRCMyLFNJRCMzLOKA plNJRCNuLg0KIFRoZSBmaXJzdCBob3AgZGVmaW5lcyBvbmx5IHRoZSBvaWYuPG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1wMSI+PHNwYW4gY2xhc3M9ImdtYWls LXMxIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gY2FzZSB0aGUgc3RhY2sgc3RhcnRz IHdpdGggYSBOb2RlLVNJRCwgd2UgbWF5IGhhdmU6Tm9kZS1TSUQmIzQzO05BSSxTSUQjMSxTSUQj MixTSUQjMyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWls LXAxIj48c3BhbiBjbGFzcz0iZ21haWwtczEiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5V c2luZyB0aGlzLCB3ZSBhcmUgYWx3YXlzIGlubGluZSB3aXRoIE1TRCBhcyB3ZSBuZXZlciBzZW5k IGFuIEVSTyB3aXRoIG1vcmUgbGFiZWxzIHRoYW4gc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtcDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1zMSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iZ21haWwtcDEiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtcDEiPjxzcGFuIGNs YXNzPSJnbWFpbC1zMSI+VGhhbmtzLCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1wMSI+Q3lyaWwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1wMSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtcDEiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLXAxIj48c3BhbiBjbGFzcz0iZ21haWwtczEi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF921DBA75F9OPEXCLILMA4corp_-- From nobody Tue Nov 15 02:41:57 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA10129477 for ; Tue, 15 Nov 2016 02:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 B1h4VGunMASc for ; Tue, 15 Nov 2016 02:41:52 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 C8801129A6F for ; Tue, 15 Nov 2016 02:41:51 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id q124so162979326itd.1 for ; Tue, 15 Nov 2016 02:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=VNr50IzHNrDM1D+txkARzk1JiX1J32QgtR2+xCUY/+o=; b=z1BysHNCtFwi9QCHot/bcXXH1Hr3o7/KWOypn1CyXS/KLpKFBLhNlSmoNNNKNdnT4l oMKmMynPw4L0ey4JoOkLkTEmePbopKRLZZ8XBI8EM3szqMb3sEafANV9oczErwcG5jBm 21jn9C7wpvDacdvADcdOoB58SyYsZDemo2W5xti1ofor/CRAg2ZNwmQRmy9Ocf8du0iH m2oyqH/fSpScY75aZYvYuYPZqGv2MpsjbBYzBXH9UjxCqA5n4zc8Hj/2W7Zz/a91faqc 0qwfw7o/49u9kv9dCK0I49SK84eP1fCQArVCLGMoOsT7zNQDIScMM38QRUH5tkS3APZw nF5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=VNr50IzHNrDM1D+txkARzk1JiX1J32QgtR2+xCUY/+o=; b=UkHcNl9hupe1na/m3cGDAUsVoLSd49DCwaoC3Uz8t5LhypBXsyUPhh6ZgIHRu8r6TQ k0ZJf2qVo7OlwAE80McImvQZ0pMWg9pAgZ5sYiEgQPL0xe0FwUbilsvFL27Hv6dvZW61 ztKbmgMRyRD7VrphNbRA5reaLdK/MOynYOK0pONU/c7rAbOjHpjVUdiPtlPDigO82Ve6 DyJcPl7EnEeRnoXTZBXLg3acnLW2QhgDsaoT/CEMLD1nwpexTsiQJuU7IEMVjO6oSsHb Fay1fJf/1cbWmRJ8G1vuZEboNWW6jZ5Uai5gZCs1Q2j5D9EkBQcnbXIkBto6a3STSjyy fyIA== X-Gm-Message-State: ABUngvfSrWHAhN1P9PVx0Iqy2K+ZYWHRHPMAmtTaAZ5Y+X62+sC8e8vgx0sQ0imI5MeWiOaZn8sojWaL8kmGLQ== X-Received: by 10.36.61.212 with SMTP id n203mr2068989itn.79.1479206511003; Tue, 15 Nov 2016 02:41:51 -0800 (PST) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.21.232 with HTTP; Tue, 15 Nov 2016 02:41:50 -0800 (PST) In-Reply-To: References: <23CE718903A838468A8B325B80962F9B8C421A83@BLREML509-MBX.china.huawei.com> <5628C89B.3000404@hq.sk> <99B428A7-A65F-49D2-AF58-95BA1023AAF1@ericsson.com> <23CE718903A838468A8B325B80962F9B8C505D19@BLREML509-MBX.china.huawei.com> From: Dhruv Dhody Date: Tue, 15 Nov 2016 19:41:50 +0900 X-Google-Sender-Auth: lO57ZkyTMA---t7EZimlqSFjwno Message-ID: To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=001a114448bca34b360541549a8b Archived-At: Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 10:41:56 -0000 --001a114448bca34b360541549a8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Recent discussion started by Cyril and Stephane on PCE-SR draft reminded me that this issue is also still open - https://mailarchive.ietf.org/arch/msg/pce/XLxa7lrHtabXukzvJUWZCCwUROE or see below... Thanks! Dhruv On Tue, May 17, 2016 at 11:15 PM, Dhruv Dhody wrote: > Hi WG, > > During the IETF-95, I discussed this open point in PCEP-SR draft with Jef= f > and Jon and also pointed out that the generic TE-Yang is using 5 tuple as= a > key in LSP-state information. > > https://tools.ietf.org/html/draft-ietf-teas-yang-te-03#section-3.4 > > module: ietf-te > +--rw te! > +--ro lsps-state > | +--ro lsp* > [source destination tunnel-id lsp-id extended-tunnel-id type] > | +--ro source inet:ip-address > | +--ro destination inet:ip-address > | +--ro tunnel-id uint16 > | +--ro lsp-id uint16 > | +--ro extended-tunnel-id inet:ip-address > | +--ro type identityref > > > =E2=80=8B=E2=80=8B > > =E2=80=8B =E2=80=8B > =E2=80=8B....t > he RSVP-TE [RFC3209 ] YANG model aug= mentation of the TE > model is covered in [I-D.ietf-teas-yang-rsvp ], and other sig= naling > > protocol model(s) (e.g. for Segment-Routing TE) are expected to also > augment the TE generic model. > > > =E2=80=8BI could see benefit in having this information for SR-TE LSP (an= d have an > LSP Identifier TLV) in PCEP messages. > > > What does the authors of the drafts (SR, Yang..) and the WG think about > it? > > Regards, > Dhruv > > On Fri, Feb 12, 2016 at 11:14 AM, Dhruv Dhody > wrote: > >> Hi Jeff, >> >> >> >> [PCEP-SR] did not change the format of the stateful PCE messages (i.e. >> RBNF of PCRpt/PCUpd); and [STATEFUL-PCE] does not have END-POINTS object= in >> those messages. >> >> Only PCInitiate message [PCE-INITIATE] has END-POINTS object. >> >> >> >> In the implementations I am aware of, LSP Identifiers TLV is carried in >> PCEP-SR. >> >> One way to find middle ground would be, to make LSP Identifiers TLV as >> optional for PCEP-SR, with a use-case during delegation of a PCC configu= red >> LSP via PCRpt message. >> >> >> >> Regards, >> >> Dhruv >> >> [PCEP-SR] https://www.ietf.org/archive/id/draft-ietf-pce-segment- >> routing-06.txt >> >> [STATEFUL-PCE] https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-1= 3 >> >> [PCE-INITIATE] https://tools.ietf.org/html/draft-ietf-pce-pce-initiated- >> lsp-05 >> >> >> >> >> >> >> >> *From:* Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >> *Sent:* 12 February 2016 06:42 >> *To:* Robert Varga; Dhruv Dhody; draft-ietf-pce-segment-routing@ietf.org= ; >> draft-ietf-pce-stateful-pce@tools.ietf.org >> *Cc:* pce@ietf.org; pce-chairs@tools.ietf.org >> >> *Subject:* Re: [Pce] Query on Usage of LSP Identifier TLV in SR >> >> >> >> Hi Robert, >> >> >> >> I disagree with you, I don=E2=80=99t think we need RSVP-TE semantics her= e, in the >> implementations I'm aware of LSP Identifiers TLV is not used. >> >> END-POINTS object is used to identify the tunnel endpoint addresses. >> >> >> >> I do agree that SR draft should be clear about this and we will update i= t. >> >> >> >> Cheers, >> >> Jeff >> >> >> >> *From: *Robert Varga >> *Date: *Thursday, October 22, 2015 at 04:29 >> *To: *Dhruv Dhody , "draft-ietf-pce-segment- >> routing@ietf.org" , " >> draft-ietf-pce-stateful-pce@tools.ietf.org" > tools.ietf.org> >> *Cc: *"pce@ietf.org" , "pce-chairs@tools.ietf.org" < >> pce-chairs@tools.ietf.org> >> *Subject: *Re: [Pce] Query on Usage of LSP Identifier TLV in SR >> >> >> >> On 10/12/2015 07:58 AM, Dhruv Dhody wrote: >> >> Hi Authors, >> >> >> >> In the stateful PCE draft [1], it says =E2=80=93 >> >> The LSP Identifiers TLV MUST be included in the LSP object in PCRpt >> >> messages for RSVP-signaled LSPs. >> >> >> >> The SR draft [2] did not mention anything about LSP Identifier TLV. >> >> And in implementations that I am aware of, SR-TE LSP still uses the >> LSP-Identifier TLV. Is that correct? (I personally think so!!) >> >> >> >> If yes, do you think there is a need to update =E2=80=93 >> >> - [1] to say all LSPs (and not just RSVP-signaled). >> >> - Or [2] to say that LSP-Identifier TLV are also applicable to SR >> and MUST be included. >> >> >> >> >> The wording in stateful draft is meant to proscribe behavior for RSVP (a= s >> that is what RFC5440 assumes), while allowing different setup mechanisms= ( >> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/) specify >> their own LSP identifier format. >> >> In this spirit I think the SR draft should be updated to explicitly stat= e >> that SR reuses the same identifier format as RSVP (or whatever is >> appropriate). >> >> Bye, >> Robert >> >> >> >> >> >> =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 >> >> =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD >> >> =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 >> >> This e-mail and its attachments contain confidential information from >> HUAWEI, which is intended only for the person or entity whose address is >> listed above. Any use of the information contained herein in any way >> (including, but not limited to, total or partial disclosure, reproductio= n, >> or dissemination) by persons other than the intended >> >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender by phone or email immediately and delete it! >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> > --001a114448bca34b360541549a8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Recent disc= ussion started by Cyril and Stephane on PCE-SR draft reminded me that this = issue is also still open -=C2=A0

http= s://mailarchive.ietf.org/arch/msg/pce/XLxa7lrHtabXukzvJUWZCCwUROE
=

o= r see below...=C2=A0

Thanks!=C2=A0
Dhruv=C2=A0

On Tue, May 17, 2016 at 11:15 PM, Dhruv Dhody <= dhruv.ietf@gmail.= com> wrote:
Hi WG,=C2=A0

= During the IETF-95, I=C2=A0discussed this open point in PCEP-SR draft with = Jeff and Jon and also pointed out that the generic TE-Yang is using 5 tuple= as a key in LSP-state information.=C2=A0

https://tools.ietf.org/html/draft-ietf-teas-= yang-te-03#section-3.4

   module: ietf-te
      +--rw te!
         +--ro lsps-state
         |  +--ro lsp*
         [source destination tunnel-id lsp-id extended-tunnel-id type]
         |     +--ro source                    inet:ip-address
         |     +--ro destination               inet:ip-address
         |     +--ro tunnel-id                 uint16
         |     +--ro lsp-id                    uint16
         |     +--ro extended-tunnel-id        inet:ip-address
         |     +--ro type                      identityref

= =E2=80=8B=E2=80=8B
=E2=80=8B  =
   =E2=80=8B
=E2=80=8B....t
he RSVP=
-TE [RFC3209] =
YANG model augmentation of the TE
   model is covered in [I-D.ietf-teas=
-yang-rsvp], and other signaling
   protocol model(s) (e=
.g. for Segment-Routing TE) are expected to also
   augment the TE generic model.

=
=E2=80=8BI could see= benefit in having this information for SR-TE LSP (and have an LSP Identifi= er TLV) in PCEP messages.=C2=A0


What does the authors of the drafts=C2=A0(SR, Yang= ..) and the WG think about it?=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:r= gb(76,17,48);display:inline">
Regards,
Dhruv

On Fri, Feb 12, 20= 16 at 11:14 AM, Dhruv Dhody <dhruv.dhody@huawei.com> wr= ote:

Hi Jeff,

=C2=A0

[PCEP-SR] did not change the format of the= stateful PCE messages (i.e. RBNF of PCRpt/PCUpd); and [STATEFUL-PCE] does = not have END-POINTS object in those messages.

Only PCInitiate message [PCE-INITIATE] has= END-POINTS object. =C2=A0

=C2=A0

In the implementations I am aware of, LSP = Identifiers TLV is carried in PCEP-SR.

One way to find middle ground would be, to= make LSP Identifiers TLV as optional for PCEP-SR, with a use-case during d= elegation of a PCC configured LSP via PCRpt message.

=C2=A0

Regards,

Dhruv

[PCEP-SR] https://www.ietf.org/archive/id/draft-ietf-pc= e-segment-routing-06.txt

[STATEFUL-PCE] https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-= 13

[PCE-INITIATE] https://tools.ietf.org/html/draft-ietf-pce-pce-init= iated-lsp-05

=C2=A0

=C2=A0

=C2=A0

From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]
Sent: 12 February 2016 06:42
To: Robert Varga; Dhruv Dhody; draft-ietf-pce-segment-routing= @ietf.org; draft-ietf-pce-stateful-pce@tools.ietf.org
Cc: pce@ietf.org; pce-chai= rs@tools.ietf.org


Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR=

=C2=A0

Hi Robe= rt,

= =C2=A0

I disag= ree with you, I don=E2=80=99t think we need RSVP-TE semantics here, in the = implementations I'm aware of LSP Identifiers TLV is not used.=

END-POI= NTS object is used to identify the tunnel endpoint addresses.=

= =C2=A0

I do ag= ree that SR draft should be clear about this and we will update it.<= u>

= =C2=A0

Cheers,=

Jeff=

= =C2=A0

From: Robert Varga <nite@hq.sk>
Date: Thursday, October 22, 2015 at 04:29
To: Dhruv Dhody <dhruv.dhody@huawei.com>, "draft-ietf-pce-segment-= routing@ietf.org" <draft-ietf-pce-segment-routing@i= etf.org>, "draft-ietf-pce-stateful-pce@tools.ietf.org" <<= a href=3D"mailto:draft-ietf-pce-stateful-pce@tools.ietf.org" target=3D"_bla= nk">draft-ietf-pce-stateful-pce@tools.ietf.org>
Cc: "pce@ietf= .org" <pce@ie= tf.org>, "pce-chairs@tools.ietf.org" <pce-chairs@tools.ietf.org> Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR=

= =C2=A0

On 10/1= 2/2015 07:58 AM, Dhruv Dhody wrote:

Hi Authors,

=C2=A0

In the stateful PCE draft [1], it says =E2= =80=93

The= LSP Identifiers TLV MUST be included in the LSP object in PCRpt

mes= sages for RSVP-signaled LSPs.<= /u>

=C2=A0

The SR draft [2] did not mention anything a= bout LSP Identifier TLV.

And in implementations that I am aware of, = SR-TE LSP still uses the LSP-Identifier TLV. Is that correct? (I personally= think so!!)

=C2=A0

If yes, do you think there is a need to upd= ate =E2=80=93

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [1] to say all LSPs (and not just RSVP= -signaled).

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Or [2] to say that LSP-Identifier TLV = are also applicable to SR and MUST be included.

=C2=A0


The wording in stateful draft is meant to proscribe behavior for RSVP (as t= hat is what RFC5440 assumes), while allowing different setup mechanisms (https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-s= etup-type/) specify their own LSP identifier format.

In this spirit I think the SR draft should be updated to explicitly state t= hat SR reuses the same identifier format as RSVP (or whatever is appropriat= e).

Bye,
Robert

=C2=A0

=C2=A0

=E6=9C=AC=E9=82= =AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=9C=89=E5=8D=8E= =E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6=81=AF=EF= =BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=E4=B8=8A= =E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4=B8=AA=E4= =BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81

=E6=AD=A2=E4=BB=BB=E4=BD=95= =E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4= =BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA= =8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2= =E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC= =89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD=

=E7=9A=84=E4=BF=A1=E6=81=AF= =E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9= =82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5= =E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4= =BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=81

This e-mail and its attachments conta= in confidential information from HUAWEI, which is intended only for the per= son or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited= to, total or partial disclosure, reproduction, or dissemination) by person= s other than the intended

recipient(s) is prohibited. If you re= ceive this e-mail in error, please notify the sender by phone or email imme= diately and delete it!

=C2=A0=


_____________________________________= __________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce



--001a114448bca34b360541549a8b-- From nobody Tue Nov 15 21:40:25 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A789312968F for ; Tue, 15 Nov 2016 21:40:22 -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 VLQT7aJSdnMi for ; Tue, 15 Nov 2016 21:40: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 A88C8129671 for ; Tue, 15 Nov 2016 21:40:11 -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 CVG20426; Wed, 16 Nov 2016 05:40:08 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Nov 2016 05:40:07 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.215]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Wed, 16 Nov 2016 13:40:03 +0800 From: Zhenghaomian To: "stephane.litkowski@orange.com" Thread-Topic: RSO Draft pointer - on response of the draft-litkowski-pce-association-diversity Thread-Index: AdI/y+AHxgUqrtFCSeWKwoUpZYDjxA== Date: Wed, 16 Nov 2016 05:40:03 +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.47.112.106] Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A43985F213SZXEMA504MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010201.582BF139.003F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ca4bab03158a97c049771a89c43dbd76 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] RSO Draft pointer - on response of the draft-litkowski-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 05:40:23 -0000 --_000_E0C26CAA2504C84093A49B2CAC3261A43985F213SZXEMA504MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephane, Great discussion in PCE. The Resource Sharing Object (RSO) draft I mentione= d in pce WG can be found at https://datatracker.ietf.org/doc/draft-zhang-pc= e-resource-sharing/. I think we are working on similar scenarios with diffe= rent flags, which are complimentary with each other. I am also wondering wh= ether such kind of association work need to differentiate IP PCE with Optic= al PCE or not, and what's your preference. Thank you. Best wishes, Haomian --_000_E0C26CAA2504C84093A49B2CAC3261A43985F213SZXEMA504MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephane, =

 

Great discussion in PCE. The Re= source Sharing Object (RSO) draft I mentioned in pce WG can be found at https://datatracker.ietf.org/doc/draft-zhang-pce-resource-sharing/.= I think we are working on similar scenarios with different flags, which ar= e complimentary with each other. I am also wondering whether such kind of association work need to differenti= ate IP PCE with Optical PCE or not, and what’s your preference. Thank= you.

 

Best wishes,<= /p>

Haomian

--_000_E0C26CAA2504C84093A49B2CAC3261A43985F213SZXEMA504MBXchi_-- From nobody Tue Nov 15 23:36:51 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2085D129645 for ; Tue, 15 Nov 2016 21:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, 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 9mkT-DNUBvhv for ; Tue, 15 Nov 2016 21:37:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BD01293EE for ; Tue, 15 Nov 2016 21:37:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C9072B80FA6; Tue, 15 Nov 2016 21:37:45 -0800 (PST) To: qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jonathan.hardwick@metaswitch.com, jpv@cisco.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161116053745.C9072B80FA6@rfc-editor.org> Date: Tue, 15 Nov 2016 21:37:45 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 15 Nov 2016 23:36:49 -0800 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC6006 (4867) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 05:37:47 -0000 The following errata report has been submitted for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=4867 -------------------------------------- Type: Technical Reported by: DHRUV DHODY Section: 3.4 Original Text ------------- ::= where: ::= [] [] [] [] [] [] where: ::= [][] [] ::=[][] ::=[] Corrected Text -------------- ::= [] where: ::= [] [] [] ::=[] ::= [] [] [] [] [|] [] where: ::= [[]] [] ::=(|)[] ::=[] Notes ----- o Update the Routing Backus-Naur Form (RBNF) [RFC5511] for Request message format: * Update the request message to allows for the bundling of multiple path computation requests within a single Path Computation Request (PCReq) message. * Add in PCReq message. This object was missed in [RFC6006]. * Add BNC object in PCReq message. This object is required to support P2MP. It shares the same format as Include Route Object (IRO) but it is a different object. * Update the format to also allow Secondary Record Route object (SRRO). This object was missed in [RFC6006]. * Removed the BANDWIDTH Object followed by Record Route Object (RRO) from . As BANDWIDTH object doesn't need to follow for each RRO in the , there already exist BANDWIDTH object follow and is backward compatible with [RFC5440]. * Update the to allow optional BANDWIDTH object only if is included. Refer https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 15 23:36:54 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4212968E for ; Tue, 15 Nov 2016 21:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, 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 LBZNNcEltpOv for ; Tue, 15 Nov 2016 21:40:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CCB129687 for ; Tue, 15 Nov 2016 21:40:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 444BEB80FB1; Tue, 15 Nov 2016 21:40:27 -0800 (PST) To: qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jonathan.hardwick@metaswitch.com, jpv@cisco.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161116054027.444BEB80FB1@rfc-editor.org> Date: Tue, 15 Nov 2016 21:40:27 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 15 Nov 2016 23:36:50 -0800 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC6006 (4868) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 05:40:48 -0000 The following errata report has been submitted for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=4868 -------------------------------------- Type: Technical Reported by: DHRUV DHODY Section: 3.5 Original Text ------------- ::= ::= [] [] [] where: ::= [][] ::= (|) [] ::=[] [] [] [] [] Corrected Text -------------- ::= where: ::=[] ::= [] [] [] [] ::= [][] ::= (|) [] where: ::=[] [] [] [] [] Notes ----- o Update the RBNF for Reply message format: * Update PCEP allows for the bundling of multiple path computation responses within a single Path Computation Reply (PCRep) message. * Update UNREACH-DESTINATION in PCRep message. This object was missed in [RFC6006]. Refer: https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 15 23:37:05 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD596129452; Tue, 15 Nov 2016 21:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, 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 1dEoUZYl7dEg; Tue, 15 Nov 2016 21:59:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CBD1293EE; Tue, 15 Nov 2016 21:59:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 70904B810A4; Tue, 15 Nov 2016 21:59:10 -0800 (PST) To: DHRUV.IETF@GMAIL.COM, qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161116055910.70904B810A4@rfc-editor.org> Date: Tue, 15 Nov 2016 21:59:10 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 15 Nov 2016 23:36:50 -0800 Cc: pce@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Errata Verified] RFC6006 (4868) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 05:59:12 -0000 The following errata report has been verified for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=4868 -------------------------------------- Status: Verified Type: Technical Reported by: DHRUV DHODY Date Reported: 2016-11-16 Verified by: Deborah Brungard (IESG) Section: 3.5 Original Text ------------- ::= ::= [] [] [] where: ::= [][] ::= (|) [] ::=[] [] [] [] [] Corrected Text -------------- ::= where: ::=[] ::= [] [] [] [] ::= [][] ::= (|) [] where: ::=[] [] [] [] [] Notes ----- o Update the RBNF for Reply message format: * Update PCEP allows for the bundling of multiple path computation responses within a single Path Computation Reply (PCRep) message. * Update UNREACH-DESTINATION in PCRep message. This object was missed in [RFC6006]. Refer: https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1 -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Nov 16 00:03:19 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED9E12954A; Wed, 16 Nov 2016 00:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 LILuN_HRUa13; Wed, 16 Nov 2016 00:03:16 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686A4129525; Wed, 16 Nov 2016 00:03:16 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAG83ETv024676; Wed, 16 Nov 2016 08:03:14 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAG834Pv024625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2016 08:03:12 GMT From: "Adrian Farrel" To: Date: Wed, 16 Nov 2016 08:03:01 -0000 Message-ID: <06f201d23fdf$e06bbe20$a1433a60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdI/32jJpkEbQoCSQDC76wO2vn5LoA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22702.005 X-TM-AS-Result: No--3.476-10.0-31-10 X-imss-scan-details: No--3.476-10.0-31-10 X-TMASE-MatchedRID: 5saoGwUzKRBs2M2McsO4c3BRIrj8R47F4+ZcrqvCDkFkljqvtoNIdmOS NUODX9wnK0FqxWGrDzR5OPD8XJFfpE1+zyfzlN7y/sToY2qzpx5q8/xv2Um1avoLR4+zsDTtiPb fA0kXryHxVh1IYzJ0hmPmejq9mk/xLhOYx1I5+LrxKJWn1/H2nOh6vUQky8b7LLR5nF3ltXgVUh luC41uNBWJz0qF3xvHJIWB1QP6/JM= Archived-At: Cc: pce@ietf.org Subject: [Pce] Thought on SRP flags X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:03:18 -0000 Hi, Just reading your I-D during the meeting (sorry, but better now than never :-) I think we need a registry for the flags in the SRP registry. Maybe that should be in draft-ietf-pce-stateful-pce? But it could also be in your document. And if we need evidence that this is needed, your figure 1 shows the 'R' flag, but there is no mention of it in the text, so I assume you have seen it in some other document. Cheers, Adrian From nobody Wed Nov 16 01:46:58 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D13129695 for ; Wed, 16 Nov 2016 01:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 EZXPJg0rFCKf for ; Wed, 16 Nov 2016 01:46:54 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392E21293DF for ; Wed, 16 Nov 2016 01:46:54 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAG9knSk032758; Wed, 16 Nov 2016 09:46:49 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAG9ke05032541 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2016 09:46:45 GMT From: "Adrian Farrel" To: References: <20161116055910.70904B810A4@rfc-editor.org> In-Reply-To: <20161116055910.70904B810A4@rfc-editor.org> Date: Wed, 16 Nov 2016 09:46:38 -0000 Message-ID: <073c01d23fee$578fbd90$06af38b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFYhNSPXeFFQUZtBkjlua9Q/I6ro6HO0WMw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22702.006 X-TM-AS-Result: No--9.151-10.0-31-10 X-imss-scan-details: No--9.151-10.0-31-10 X-TMASE-MatchedRID: vbSD0OnL8/ImMPeO88gK4OYAh37ZsBDC+q1Y+/eEArbagsZM0qVv15RW 6398OQ0I8kJKPvReuFWIbw7sIXTQE6H9LoIy5n1ulY5qr7f6fHJy4VFP6muDhkzECFBbaHiHwua niM9QXy36CSiGEewpx7FhteRj057JXElnxg+tc0F2IsPC9Z62GBmyTBaqiJvcInzOyTDR1uvIik GDABhxYvwmrTK52VgEVzBTuxSDWddw+rm6wZ9/Lu9VsdrlGzy3VYV8j2OAQmVb6PBUqmq+UmQcK yBERs/h7Z8Crj6H3NfagENdHMmYX1gYIP9YyXCky7TSWcbz49Z7jgCP1tYUdxHfiujuTbedA7sE L+X/NlitNc9EIw980JNCFJkTKtUh6c6GXyQATroQ9/tMNQ4aiguK1hIitSIH51ONI4UL++qjxYy RBa/qJX3mXSdV7KK4QiE5bJj38wALbigRnpKlKSPzRlrdFGDw3VP2relToc62VGmrgvKUcWMA7o iLlkgwDvvO5sISu7+s/agQAQFd+A== Archived-At: Subject: Re: [Pce] [Errata Verified] RFC6006 (4868) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 09:46:57 -0000 Good job getting this done quickly. Thanks. Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of RFC Errata System > Sent: 16 November 2016 05:59 > To: DHRUV.IETF@GMAIL.COM; qzhao@huawei.com; daniel@olddog.co.uk; > fabien.verhaeghe@GMAIL.COM; takeda.tomonori@lab.ntt.co.jp; > zali@cisco.com; julien.meuric@orange-ftgroup.com > Cc: pce@ietf.org; iesg@ietf.org; rfc-editor@rfc-editor.org > Subject: [Pce] [Errata Verified] RFC6006 (4868) > > The following errata report has been verified for RFC6006, > "Extensions to the Path Computation Element Communication Protocol (PCEP) > for Point-to-Multipoint Traffic Engineering Label Switched Paths". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=4868 > > -------------------------------------- > Status: Verified > Type: Technical > > Reported by: DHRUV DHODY > Date Reported: 2016-11-16 > Verified by: Deborah Brungard (IESG) > > Section: 3.5 > > Original Text > ------------- > ::= > > ::= > [] > [] > [] > > where: > > ::= > [][] > > ::= (|) [] > > ::=[] > [] > [] > [] > [] > > Corrected Text > -------------- > ::= > > > where: > > ::=[] > > ::= > [] > [] > [] > [] > > ::= > [][] > > ::= (|) [] > > where: > > ::=[] > [] > [] > [] > [] > > Notes > ----- > o Update the RBNF for Reply message format: > > * Update PCEP allows for the bundling of multiple path computation > responses within a single Path Computation Reply (PCRep) message. > > * Update UNREACH-DESTINATION in PCRep message. This object was > missed in [RFC6006]. > > Refer: https://datatracker.ietf.org/doc/draft-palleti-pce- > rfc6006bis/?include_text=1 > > -------------------------------------- > RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) > -------------------------------------- > Title : Extensions to the Path Computation Element Communication > Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths > Publication Date : September 2010 > Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. > Meuric > Category : PROPOSED STANDARD > Source : Path Computation Element > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Wed Nov 16 02:02:18 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27721296CA; Wed, 16 Nov 2016 02:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_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=metaswitch.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 NA06_Jx2VJ6K; Wed, 16 Nov 2016 02:02:14 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E305F1296BE; Wed, 16 Nov 2016 02:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=f84VmhLn6s3bYLKmZcb2ISLkVnMivoqkgxTMQ1GHp0w=; b=OYXT8UU3VWxXMQVM+qRp9udxvHnM6+uE39RbBRRKmm1rvrrDPMnePijn/g+JsRXO5R1qZF9L7Ol1dwkmdmoWzXDNkydEnyDkdbR/6UZsdQVo8egAkrlOdVGbwgww6WS9YM+khDEGZLyj42RC/1jrg7ASPbQyewBCYU2e8Ujjlvc= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 16 Nov 2016 10:02:09 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0734.007; Wed, 16 Nov 2016 10:02:09 +0000 From: Jonathan Hardwick To: "adrian@olddog.co.uk" , "draft-raghu-pce-lsp-control-request@ietf.org" Thread-Topic: [Pce] Thought on SRP flags Thread-Index: AdI/32jJpkEbQoCSQDC76wO2vn5LoAAEMsrQ Date: Wed, 16 Nov 2016 10:02:08 +0000 Message-ID: References: <06f201d23fdf$e06bbe20$a1433a60$@olddog.co.uk> In-Reply-To: <06f201d23fdf$e06bbe20$a1433a60$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [58.120.104.2] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:4LoICOpwOwa2HlYu2are/LQpR3oSocC9cyzZvwge5GhQLNxP4TK7Q/DJ46N1UgxNVOvWL1mc4uFi4FVmX2oaoLYmDVHAwK40VsXQR6Sx9T1cY5crAr/1PGAo4p148a6HK/kqiTSBYToQXyUvTxHSTbNGb1XeEigVpaB3MesOvcFhBxkIv9TNZAWRgXdzH61DdOLV4zkRhNiFTJ/IgtYOUoFmXNRRCFqJCk5+j6AFDgRtPmLm9/QPcryEHAWprOq6CExT8L3HTB2qAOekp/nHAmiMZTFRdV4vDIsv93bV9Z494IZ4Kiv6tVM1D8JPh1gmD6k3drp0DPlCpiwOnGzsXlkgSNj37nU4wTs385u7xKc= x-ms-office365-filtering-correlation-id: 2aa1be46-38be-4520-51c9-08d40e07a128 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0201MB1911; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041223)(6061324); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(5001770100001)(4326007)(2906002)(3280700002)(97736004)(305945005)(7736002)(3660700001)(2501003)(7846002)(81156014)(6116002)(87936001)(6506003)(66066001)(2900100001)(102836003)(92566002)(3846002)(229853002)(2950100002)(99286002)(8676002)(105586002)(68736007)(33656002)(76576001)(74316002)(8936002)(7696004)(86362001)(106356001)(122556002)(189998001)(50986999)(5660300001)(54356999)(81166006)(77096005)(101416001)(76176999)(9686002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 10:02:08.4585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Thought on SRP flags X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:02:16 -0000 Hi Adrian draft-ietf-pce-pce-initiated-lsp defines the R flag and requests IANA to cr= eate the registry in section 8.3. Registries cannot be created during IANA= early allocation, so we need to wait for this draft to be published. (As = an aside, I believe that IANA are considering changing that policy down the= line.) Cheers Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 16 November 2016 17:03 To: draft-raghu-pce-lsp-control-request@ietf.org Cc: pce@ietf.org Subject: [Pce] Thought on SRP flags Hi, Just reading your I-D during the meeting (sorry, but better now than never = :-) I think we need a registry for the flags in the SRP registry. Maybe that should be in draft-ietf-pce-stateful-pce? But it could also be i= n your document. And if we need evidence that this is needed, your figure 1 shows the 'R' fl= ag, but there is no mention of it in the text, so I assume you have seen it= in some other document. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Wed Nov 16 02:29:24 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CB6129501; Wed, 16 Nov 2016 02:29:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147929215879.7401.14282862513385405893.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2016 02:29:18 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:29:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering Authors : Eiji Oki Tomonori Takeda Adrian Farrel Fatai Zhang Filename : draft-ietf-pce-inter-layer-ext-11.txt Pages : 21 Date : 2016-11-16 Abstract: The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-inter-layer-ext-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-layer-ext-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 16 02:36:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BBB1296FC for ; Wed, 16 Nov 2016 02:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 vDfsvuBWcXdJ for ; Wed, 16 Nov 2016 02:36:53 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FA8129631 for ; Wed, 16 Nov 2016 02:36:52 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAGAaovL032467 for ; Wed, 16 Nov 2016 10:36:50 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAGAakjW032434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2016 10:36:49 GMT From: "Adrian Farrel" To: References: <147929215879.7401.14282862513385405893.idtracker@ietfa.amsl.com> In-Reply-To: <147929215879.7401.14282862513385405893.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2016 10:36:43 -0000 Message-ID: <076001d23ff5$55b1f8b0$0115ea10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ1Cer+miffFVT1pdrO/wCEJrcGsZ+V1egA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22702.006 X-TM-AS-Result: No--10.298-10.0-31-10 X-imss-scan-details: No--10.298-10.0-31-10 X-TMASE-MatchedRID: u7Yf2n7Ca/1jDV//SvkH3khwlOfYeSqxc4o5QwWHg/zadW4iYSMjUV2t vsxNXD/lC3dDPh8g5SEXEaT5uhkwzCWvhQBtQUwTLTHwnYOikQ01wgjXWX56uOOxOq7LQlGLyIp BgwAYcWIYvp5stj2gDHJ+dugnvMsGouyZccV4bBo5yvfl9TlCR1+PJNkR/r/XZYbwjLYbFhqVBo 0Fcim+v2wgtatx4aKGg8bVQHHB2QUItMWhbSshqkK9qlwiTElfIZm2INWXDp5k2J2ef3Nd3/TrP 5e8ec7BsBb3Q0HEUXwFnwbZRaSvqQzyMxeMEX6wOX/V8P8ail3InWAWA4yE6bazRqvlkBL0q7rF UcuGp/EgBwKKRHe+r0UGSvvU8K5WXo6ElYMX/0tvRgJ/Bf1+P7yp5X2lyjmdPRUyOR3vI3A= Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:36:55 -0000 Hi, I updated this once again; this time for Dhruv's comments. Dhruv could you please check I got it right. Chairs, ready to go after Dhruv's ack. Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 16 November 2016 10:29 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D Action: draft-ietf-pce-inter-layer-ext-11.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Path Computation Element of the IETF. > > Title : Extensions to the Path Computation Element communication > Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering > Authors : Eiji Oki > Tomonori Takeda > Adrian Farrel > Fatai Zhang > Filename : draft-ietf-pce-inter-layer-ext-11.txt > Pages : 21 > Date : 2016-11-16 > > Abstract: > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > MPLS and GMPLS networks may be constructed from layered service > networks. It is advantageous for overall network efficiency to > provide end-to-end traffic engineering across multiple network layers > through a process called inter-layer traffic engineering. PCE is a > candidate solution for such requirements. > > The PCE communication Protocol (PCEP) is designed as a communication > protocol between Path Computation Clients (PCCs) and PCEs. This > document presents PCEP extensions for inter-layer traffic > engineering. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-inter-layer-ext-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-layer-ext-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 16 05:56:45 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEDE1297CF; Wed, 16 Nov 2016 05:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 kQAJKh0FOR2K; Wed, 16 Nov 2016 05:56:42 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF25912953D; Wed, 16 Nov 2016 05:56:41 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAGDudPH031915; Wed, 16 Nov 2016 13:56:39 GMT Received: from 950129200 ([58.120.104.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAGDuY7d031879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2016 13:56:37 GMT From: "Adrian Farrel" To: "'Jonathan Hardwick'" , References: <06f201d23fdf$e06bbe20$a1433a60$@olddog.co.uk> In-Reply-To: Date: Wed, 16 Nov 2016 13:56:29 -0000 Message-ID: <076301d24011$4006b9d0$c0142d70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHkPeLtN8fGnZfi2ri3U098tzBuVQH/zyLdoKdxU4A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22702.007 X-TM-AS-Result: No--18.079-10.0-31-10 X-imss-scan-details: No--18.079-10.0-31-10 X-TMASE-MatchedRID: scwq2vQP8OHRhEyb9f1sjk0IfQOJvRLRwx0jRRxcQfOObf10apLcScLm p4jPUF8tRFsqph676uCU+xfB5OHYy/Ue3cF58v23StpI+4+KLgA+ooVNjt38kWtEzrC9eANp9Ae 1UPqORDrUr8pZ+ygb1b4bOTEqgJ/8eJ1d43FMKpRIRA38P/dwbgOocmryPTnw0mAM2eipqloONn COtDoJBZ6Ss6O2bihGHDnwvr6B+jQYB2fOueQzjzl/1fD/GopdyJ1gFgOMhOn6APa9i04WGCq2r l3dzGQ1A/3R8k/14e0= Archived-At: Cc: pce@ietf.org Subject: Re: [Pce] Thought on SRP flags X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 13:56:44 -0000 Aha, good. So just that draft-raghu... should ask for a new flag from the to-be-created registry. Thanks. Adrian > -----Original Message----- > From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > Sent: 16 November 2016 10:02 > To: adrian@olddog.co.uk; draft-raghu-pce-lsp-control-request@ietf.org > Cc: pce@ietf.org > Subject: RE: [Pce] Thought on SRP flags > > Hi Adrian > > draft-ietf-pce-pce-initiated-lsp defines the R flag and requests IANA to create the > registry in section 8.3. Registries cannot be created during IANA early allocation, > so we need to wait for this draft to be published. (As an aside, I believe that > IANA are considering changing that policy down the line.) > > Cheers > Jon > > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 16 November 2016 17:03 > To: draft-raghu-pce-lsp-control-request@ietf.org > Cc: pce@ietf.org > Subject: [Pce] Thought on SRP flags > > Hi, > > Just reading your I-D during the meeting (sorry, but better now than never :-) > > I think we need a registry for the flags in the SRP registry. > > Maybe that should be in draft-ietf-pce-stateful-pce? But it could also be in your > document. > > And if we need evidence that this is needed, your figure 1 shows the 'R' flag, but > there is no mention of it in the text, so I assume you have seen it in some other > document. > > Cheers, > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Wed Nov 16 05:58:01 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8919C1296DD for ; Wed, 16 Nov 2016 05:58:00 -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 TBewnpEVf89q for ; Wed, 16 Nov 2016 05:57:58 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 7DD60129465 for ; Wed, 16 Nov 2016 05:57:58 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id o1so53502090ito.1 for ; Wed, 16 Nov 2016 05:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dXEiG94nV7HoqySh0UX0ip+SmmAGdvmYnIhrNtgF7ys=; b=caW4wxzL+IBRC1UaaAiwCMDxyQtIed01Ixz9esDFH5yIFZ75usW2bGU7SLe05LnWjU nIRMR6YctdE8hd/ola+PanFixklr7C0PRs1XW8fRPHQbx0lhwaETJKgo/Dc88ZIBCd2n HmnRxDWjCAhYAa4Rd6CmRL/pXsJ3E+lIG9pQubIQ5Yy9jutGwNN6H4V+Bu04V9c/oADg /fBeEFWZ9emA0PxL0btG2DFKffcw6LtJ3u5ipt+1D1bhniDlD48lQ9hr3P1Z29RfeABm 5Fu1/WsL2cLhwDwH+vcwh32Z8YCBAuNuCF4x66wMWO3vmoQxAHZC4vinAbm0fW9faUVU MiFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dXEiG94nV7HoqySh0UX0ip+SmmAGdvmYnIhrNtgF7ys=; b=Z4OU6+lpjDP8GcImSafjGGQv9E5PNrgb6W/rAaNc5tAeVbwER06RTpU9PF6Z1EUxQB x20WroP/JsfVjvnkxYz3RYgCEI4BFSeUH64DRaR/vlcx8LAFLn1Fxyca0YRjNxkvlFx5 0RoWfJwaryUurrjrsCxlU1Q8fCC288dzMxVX5e+plXS1AgifmU30+qlgBDRI2bv4lO13 hFdIeV20LKHK5cQaYYZtUYJHwaYg7j4pIzKtM1RFYGNoVIXNQ3FH/Tku3m8Ynb3FGTja +xi3o4eaqw5k1kOH6D8xKigpBS1v+VYMpBpAqMU0rkWKMsz4znTUWiwObVIgrzAdcR5i ohBw== X-Gm-Message-State: ABUngved7DUB0Qx2gqL4tHrOR1WCRmHmsvvVTWd2x4OsxrJGrTe6UgB4iEXofYq0YAKN6Smza3/nIxpnwMqOvg== X-Received: by 10.107.25.11 with SMTP id 11mr2558111ioz.138.1479304677048; Wed, 16 Nov 2016 05:57:57 -0800 (PST) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.21.232 with HTTP; Wed, 16 Nov 2016 05:57:56 -0800 (PST) In-Reply-To: <076001d23ff5$55b1f8b0$0115ea10$@olddog.co.uk> References: <147929215879.7401.14282862513385405893.idtracker@ietfa.amsl.com> <076001d23ff5$55b1f8b0$0115ea10$@olddog.co.uk> From: Dhruv Dhody Date: Wed, 16 Nov 2016 22:57:56 +0900 X-Google-Sender-Auth: Wssd0FSmFAUd2eXvku5LZCsetdg Message-ID: To: Farrel Adrian Content-Type: multipart/alternative; boundary=001a114097aaca4ac405416b7555 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 13:58:00 -0000 --001a114097aaca4ac405416b7555 Content-Type: text/plain; charset=UTF-8 Ack. Thanks for taking my suggestions. Dhruv On Wed, Nov 16, 2016 at 7:36 PM, Adrian Farrel wrote: > Hi, > > I updated this once again; this time for Dhruv's comments. > > Dhruv could you please check I got it right. > > Chairs, ready to go after Dhruv's ack. > > Adrian > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 16 November 2016 10:29 > > To: i-d-announce@ietf.org > > Cc: pce@ietf.org > > Subject: I-D Action: draft-ietf-pce-inter-layer-ext-11.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Path Computation Element of the IETF. > > > > Title : Extensions to the Path Computation Element > communication > > Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering > > Authors : Eiji Oki > > Tomonori Takeda > > Adrian Farrel > > Fatai Zhang > > Filename : draft-ietf-pce-inter-layer-ext-11.txt > > Pages : 21 > > Date : 2016-11-16 > > > > Abstract: > > The Path Computation Element (PCE) provides path computation > > functions in support of traffic engineering in Multiprotocol Label > > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > > > MPLS and GMPLS networks may be constructed from layered service > > networks. It is advantageous for overall network efficiency to > > provide end-to-end traffic engineering across multiple network layers > > through a process called inter-layer traffic engineering. PCE is a > > candidate solution for such requirements. > > > > The PCE communication Protocol (PCEP) is designed as a communication > > protocol between Path Computation Clients (PCCs) and PCEs. This > > document presents PCEP extensions for inter-layer traffic > > engineering. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-pce-inter-layer-ext-11 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-layer-ext-11 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a114097aaca4ac405416b7555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ack.=C2=A0

Thanks for taking my suggestions.=C2=A0
Dhruv

On Wed, Nov 16, 2016 at 7:36 PM, Adrian Farrel <ad= rian@olddog.co.uk> wrote:
H= i,

I updated this once again; this time for Dhruv's comments.

Dhruv could you please check I got it right.

Chairs, ready to go after Dhruv's ack.

Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: 16 November 2016 10:29
> To: i-d-announce@ietf.org=
> Cc: pce@ietf.org
> Subject: I-D Action: draft-ietf-pce-inter-layer-ext-11.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Path Computation Element of the IETF.=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Extensions to the Path Computation Element
communication
> Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Eiji Oki
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Tomonori Takeda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Adrian Farrel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Fatai Zhang
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-pce-inter-layer-ext-11.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 21
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-11-16
>
> Abstract:
>=C2=A0 =C2=A0 The Path Computation Element (PCE) provides path computat= ion
>=C2=A0 =C2=A0 functions in support of traffic engineering in Multiproto= col Label
>=C2=A0 =C2=A0 Switching (MPLS) and Generalized MPLS (GMPLS) networks. >
>=C2=A0 =C2=A0 MPLS and GMPLS networks may be constructed from layered s= ervice
>=C2=A0 =C2=A0 networks.=C2=A0 It is advantageous for overall network ef= ficiency to
>=C2=A0 =C2=A0 provide end-to-end traffic engineering across multiple ne= twork layers
>=C2=A0 =C2=A0 through a process called inter-layer traffic engineering.= =C2=A0 PCE is a
>=C2=A0 =C2=A0 candidate solution for such requirements.
>
>=C2=A0 =C2=A0 The PCE communication Protocol (PCEP) is designed as a co= mmunication
>=C2=A0 =C2=A0 protocol between Path Computation Clients (PCCs) and PCEs= .=C2=A0 This
>=C2=A0 =C2=A0 document presents PCEP extensions for inter-layer traffic=
>=C2=A0 =C2=A0 engineering.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/d= raft-ietf-pce-inter-layer-ext-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-pce-inter-layer-ext-11
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-= d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html=
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= br>

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a114097aaca4ac405416b7555-- From nobody Wed Nov 16 06:07:35 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608C612959A; Wed, 16 Nov 2016 06:07:34 -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 v2O3dexAJ-iE; Wed, 16 Nov 2016 06:07:32 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 3E647129608; Wed, 16 Nov 2016 06:07:32 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id o1so53963308ito.1; Wed, 16 Nov 2016 06:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZsT6jnNBix+yrS0pEIVwa1EmT3C+6iaQJKOWX7KtRyg=; b=W/0sXbiI6KGyvEL6k2+Otqkc1M57uE+eZsnSYVMw9cpNnFDitihRJAZuyB64gFrqle p2SDtA7Y7YYeC3wO8XEYEHX3YX8BCCp2oCVpu8SE3NYmM+7X6HghIk3RtlYFLcU30f4m 4hsKH3QktCeeYt3zbaV9gd0Bplyk+X70+ww6DAiUwsd6wwT8vK9BGameVZ3eY/mWO7HM Qd3nNaBENKuhFroDkOLcMn+cZKSoUhaVRlpSsjY1rsX0prNdX+dvTgrdYoOdvudrZK7y nZvLzh8QioujDUHh+9jcddcFyj2IDTYznIma19YBPBuMkzx0Ztr1pP45czItAo4iAItM F/bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZsT6jnNBix+yrS0pEIVwa1EmT3C+6iaQJKOWX7KtRyg=; b=mHCEDIlmV/M3+ldSLx+MatOwKfmLAusrswg9FR+2Q+6ojbS9FKkWN51Sf2ChixbJ8G cn64NiTwEbE27QIkf+4wxij/9lefkwUhZ2DtDpfafwCeQYXv8QCpl/U6M2IIjfMktmdu ktLWZprdTWyGpfzD7Gr3kZRt9J96vRqt+YcD1PIyOptwiBs4bSadndSDxMyDuUlT6ENe rWRAqwbn4Ky5AiGr+zGiUsVce0wyug8ENMgRu68cG8zxTS/Cksu+wNF7tCeuzWJipdhX x8PM9C+CTqfcVf2mf5Wu/opKoZKiudRcyfEWXp1orazD9cZhGZrEhyPogEYoR4wA72Wh Dq7w== X-Gm-Message-State: ABUngvdeQCyMl7am33fTPUnLv652AveEGN7PnrkoMldYKgY3z5L8nRFbe6XLXwzkSRjb0mIh0ZLkD041Ije11w== X-Received: by 10.36.50.214 with SMTP id j205mr8264298ita.33.1479305251443; Wed, 16 Nov 2016 06:07:31 -0800 (PST) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.21.232 with HTTP; Wed, 16 Nov 2016 06:07:31 -0800 (PST) In-Reply-To: <076301d24011$4006b9d0$c0142d70$@olddog.co.uk> References: <06f201d23fdf$e06bbe20$a1433a60$@olddog.co.uk> <076301d24011$4006b9d0$c0142d70$@olddog.co.uk> From: Dhruv Dhody Date: Wed, 16 Nov 2016 23:07:31 +0900 X-Google-Sender-Auth: vVHgNDo60zRdXqmaH6fVIcLmv6I Message-ID: To: Farrel Adrian Content-Type: multipart/alternative; boundary=001a114aab8c06da4605416b98f1 Archived-At: Cc: "pce@ietf.org" , draft-raghu-pce-lsp-control-request@ietf.org Subject: Re: [Pce] Thought on SRP flags X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 14:07:34 -0000 --001a114aab8c06da4605416b98f1 Content-Type: text/plain; charset=UTF-8 Yes and I should add the IANA section in the next revision for draft-raghu... asking for a flag, and will also clarify where the "R" flag is defined. Thanks! Dhruv On Wed, Nov 16, 2016 at 10:56 PM, Adrian Farrel wrote: > Aha, good. > > So just that draft-raghu... should ask for a new flag from the > to-be-created > registry. > > Thanks. > Adrian > > > -----Original Message----- > > From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > > Sent: 16 November 2016 10:02 > > To: adrian@olddog.co.uk; draft-raghu-pce-lsp-control-request@ietf.org > > Cc: pce@ietf.org > > Subject: RE: [Pce] Thought on SRP flags > > > > Hi Adrian > > > > draft-ietf-pce-pce-initiated-lsp defines the R flag and requests IANA to > create the > > registry in section 8.3. Registries cannot be created during IANA early > allocation, > > so we need to wait for this draft to be published. (As an aside, I > believe > that > > IANA are considering changing that policy down the line.) > > > > Cheers > > Jon > > > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: 16 November 2016 17:03 > > To: draft-raghu-pce-lsp-control-request@ietf.org > > Cc: pce@ietf.org > > Subject: [Pce] Thought on SRP flags > > > > Hi, > > > > Just reading your I-D during the meeting (sorry, but better now than > never :-) > > > > I think we need a registry for the flags in the SRP registry. > > > > Maybe that should be in draft-ietf-pce-stateful-pce? But it could also > be in > your > > document. > > > > And if we need evidence that this is needed, your figure 1 shows the 'R' > flag, > but > > there is no mention of it in the text, so I assume you have seen it in > some > other > > document. > > > > Cheers, > > Adrian > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > --001a114aab8c06da4605416b98f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes and I should add the IANA section in the= next revision for draft-raghu... asking for a flag, and will also clarify = where the "R" flag is defined.=C2=A0

Thanks!=C2=A0
Dhruv=C2=A0



=
On Wed, Nov 16, 2016 at 10:56 PM, Adrian Farrel = <adrian@olddog.co.uk> wrote:
Aha, good.

So just that draft-raghu... should ask for a new flag from the to-be-create= d
registry.

Thanks.
Adrian

> -----Original Message-----
> From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
> Sent: 16 November 2016 10:02
> To: adrian@olddog.co.uk; draft-raghu-p= ce-lsp-control-request@ietf.org
> Cc: pce@ietf.org
> Subject: RE: [Pce] Thought on SRP flags
>
> Hi Adrian
>
> draft-ietf-pce-pce-initiated-lsp defines the R flag and requests = IANA to
create the
> registry in section 8.3.=C2=A0 Registries cannot be created during IAN= A early
allocation,
> so we need to wait for this draft to be published.=C2=A0 (As an aside,= I believe
that
> IANA are considering changing that policy down the line.)
>
> Cheers
> Jon
>
> -----Original Message-----
> From: Pce [mailto:pce-bounces@= ietf.org] On Behalf Of Adrian Farrel
> Sent: 16 November 2016 17:03
> To: dr= aft-raghu-pce-lsp-control-request@ietf.org
> Cc: pce@ietf.org
> Subject: [Pce] Thought on SRP flags
>
> Hi,
>
> Just reading your I-D during the meeting (sorry, but better now than n= ever :-)
>
> I think we need a registry for the flags in the SRP registry.
>
> Maybe that should be in draft-ietf-pce-stateful-pce? But it could also= be in
your
> document.
>
> And if we need evidence that this is needed, your figure 1 shows the &= #39;R' flag,
but
> there is no mention of it in the text, so I assume you have seen it in= some
other
> document.
>
> Cheers,
> Adrian
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


--001a114aab8c06da4605416b98f1-- From nobody Wed Nov 16 06:24:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37691295BF for ; Wed, 16 Nov 2016 06:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 TR_muQwnRbpG for ; Wed, 16 Nov 2016 06:24:53 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 03D1412949B for ; Wed, 16 Nov 2016 06:24:53 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id l8so66289610iti.1 for ; Wed, 16 Nov 2016 06:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=NCavWvSAJdChsW9JZSs8Cc3NxJ+AM7d2bIv8Jtl0K8I=; b=GpmVc0Tl1Y0PiaLl5uIow2pGlM1ISQgQSboIO8ceJBldkTOrWQk4Puun4k2+vSDsZf gsQ1PYkZKGaA3+mGkqdkaKbLOy8cJuYg1oTY26icsxHe7uhSjvK9Whqo92Qp9sEdJDjD yuo8B6YwxAtg9nfVEXTomxj5b3i2bt2Mj3KW74T7k4IMiVVzyU4L1A/P5f4bnHUQlyl6 0a4+Pl5XavOivo6cVL5HpHB8Psk5NSLVsVbwq6/nxgt4eBBY75ZUdCYKmrDDOnkFK50x wZ8wtcCgMDDETFqWV/ciphKRH78LzcHFb8o7Bt54ZuLJPpVdq8uR/DJNDE7fCPhowRZh j+8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=NCavWvSAJdChsW9JZSs8Cc3NxJ+AM7d2bIv8Jtl0K8I=; b=gg4RdpkXaT0KtcI+FZ0yV/apDrf9ZDlndJ+RH2LwqcHlgMmg0jUAVCUg6oph+3v1s3 b5AI/pWLiIrPSHhcOySnTTvh66K1aVTs7H4xBc/0Vw58Cdrw2XME+yf8gKpYCREv1hxd piSgT6o1VKZiK+9EnsrAFtkqRHQdQSItPa/aStCKkTdS+jbnUQ6Kheb/FTG7mYmkCIh6 E6qAFfb941Rhg8NsGbXj+17ZxCdbwtBIHEdAbhk/Jfe3tt83qbrvLQVeqg/3s6krE37p aVJCWbovOKOfC52n941zjjJ78zC2S718+OcLysJZkpseaWyt3OUa2BqktEkn1nl6lnRP R1jg== X-Gm-Message-State: ABUngvdiAflB5XN7YEsQpVPtYAIlUg4tehb5yC2ySNR4GF/om6mru+uKi7IqOZRtVqZ/h+WDMwUeKnLt8gdy+A== X-Received: by 10.36.1.67 with SMTP id 64mr1596159itk.121.1479306292088; Wed, 16 Nov 2016 06:24:52 -0800 (PST) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.21.232 with HTTP; Wed, 16 Nov 2016 06:24:51 -0800 (PST) From: Dhruv Dhody Date: Wed, 16 Nov 2016 23:24:51 +0900 X-Google-Sender-Auth: tBo2XZW08fNb_T0bProF5K_h7_8 Message-ID: To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=001a1143ed0c0e160a05416bd632 Archived-At: Subject: [Pce] Auto-BW draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 14:24:55 -0000 --001a1143ed0c0e160a05416bd632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B =E2=80=8BHi WG,=E2=80=8B =E2=80=8B You may recall that the Auto-Bandwidth draft defined 2 Models of operations. Model 1: PCC decides the adjusted BW Model 2: PCC reports the bandwidth-usage, PCE decides the adjusted BW =E2=80=8BModel 2 has been a bit controversial, in the spirit of moving thin= gs forward, we have decided to remove the model 2 from this draft and progress that along with a more generic P=E2=80=8Berformance Measurement (PM)=E2=80= =8B draft in another document. =E2=80=8BAuthors have up=E2=80=8Bdated a new version which only talks about= =E2=80=8Bmodel 1=E2=80=8B where PCC monitors the bandwidth and request for a new adjusted bandwidth for both PCC and PCE initiated LSPs. =E2=80=8BWith this update, we request the chairs for WG adoption. =E2=80=8B Regards, Dhruv (on behalf of my co-authors) Name: draft-dhody-pce-stateful-pce-auto-bandwidth Title: PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE URL: https://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce-auto-band= width-09.txt Status: https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidt= h/ Htmlized: https://tools.ietf.org/html/draft-dhody-pce-stateful-pce-auto-bandwidth-09 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-stateful-pce-auto-bandw= idth-09 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) using PCEP. This document describes PCEP extensions for automatic bandwidth adjustment when employing an Active Stateful PCE for both PCE- initiated and PCC-initiated LSPs. --001a1143ed0c0e160a05416bd632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B
=E2=80=8BHi WG,=E2=80=8B =E2=80=8B

You may recall that the Auto-= Bandwidth draft defined 2 Models of operations.=C2=A0

Model 1: PCC decides the adjus= ted BW=C2=A0
Model 2: PCC reports the bandwidth-usage, PCE decides the adjusted BW= =C2=A0

= =E2=80=8BModel 2 has been a bit controversial, in the spirit of moving thin= gs forward, we have decided to remove the model 2 from this draft and progr= ess that along with a more generic P=E2=80=8Berformance Measurement (PM)=E2= =80=8B draft in another document.=C2=A0

=E2=80=8BAuthors have up=E2=80=8Bdated a new= version which only talks about =E2=80=8Bmodel 1=E2=80=8B where PCC monitor= s the bandwidth and request for a new adjusted bandwidth for both PCC and P= CE initiated LSPs. =C2=A0

=E2=80=8BWith this update, we request the chairs for WG ad= option. =E2=80=8B

Regards,
Dhruv (on behalf of my co-authors)

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-dhody-pce-sta= teful-pce-auto-bandwidth
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PCEP Extensions for MPLS-TE LSP= Automatic Bandwidth Adjustment with Stateful PCE
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= a href=3D"https://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce= -auto-bandwidth-09.txt">https://www.ietf.org/internet-drafts/draft-dhody-pc= e-stateful-pce-auto-bandwidth-09.txt

Abstract:
<= div>=C2=A0 =C2=A0Label Switching (MPLS)= Traffic Engineering Label Switched Paths (TE
--001a1143ed0c0e160a05416bd632-- From nobody Wed Nov 16 06:37:20 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98353129614 for ; Wed, 16 Nov 2016 06:37:18 -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 MknQiZLs2Dw2 for ; Wed, 16 Nov 2016 06:37:16 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 4A54E129601 for ; Wed, 16 Nov 2016 06:37:15 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id p16so102662693qta.0 for ; Wed, 16 Nov 2016 06:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NBMn1m0F909YVxWmAY43E91TOozrrgXklMyazwXXZuw=; b=GQPVL6IqJGl+yy/5UcBz3fdfF7NthFP5qw6f6fQeHQ4Lh5tuQNi7I6lNyRoYH9/53Y cLqSZ9+Yh9WGr1XPtE+fExSkLwA1qWBiNiwDsy7WwsmdEEw3Hj9M0ozyqrpq4WoMxBdz TECnmFNeZi2WWU0/9ef56xawclBHsdt/vKGhWuYgOf5UXPKrWPHO/Y0R7Won/OOW/g15 1gwMw7J4GI0A1ijkv9dvz7KK3BBt7LZLsFxMaulsosiHrfpuAg0ywxSuEo/nKOxSxhi0 w56VepVcebNXEekYgMjNieO4+m4UZg4zoOhb8P+Mfjg9SXM6gpPDHBampJ7pvmocaOIE PofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NBMn1m0F909YVxWmAY43E91TOozrrgXklMyazwXXZuw=; b=aj4foP6EdCBXxmuLQStVTZ+tVzhZkIy87MPR6CELfJFnNgJm5N7lVKOtBvvpwRwN9V ENdhphMSfEZu+pCXwMjTH8SISiW8SszuCubFbIbunbRfaQV7sbT9yxqC54Xk5uVydTM6 4Nn4uZrfaAQ9PGaWOxiO6f7ztngC2cXfFX/1dPseXIZyj6J+p4H5TVHNpmkDpbUvHlA+ BQyTI/FRDVJ04L4heQ8hs2Y5iG1i6cethKwBthC4obBOoqjscoZ52wFa78Q4kjshQ3xU AB55AxWmxuUfxrxuU4sjR7WapkFS0wek28SgKyUMtOJnesCS+eGqQWCUsvAq+M8AnZAr ZS3A== X-Gm-Message-State: ABUngvfN+9vqXU0Ux5eYE9dJ0Ub7XquRhJPzBWlXLyqIsuL8ZtbCDm+Iu/FhEL0HabuI7DPQjQhNKtHi0K223g== X-Received: by 10.237.42.40 with SMTP id c37mr2255735qtd.92.1479307034243; Wed, 16 Nov 2016 06:37:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.133.34 with HTTP; Wed, 16 Nov 2016 06:37:13 -0800 (PST) In-Reply-To: <25467_1479146724_5829FCE4_25467_994_1_9E32478DFA9976438E7A22F69B08FF921DBA75F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <25467_1479146724_5829FCE4_25467_994_1_9E32478DFA9976438E7A22F69B08FF921DBA75F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Cyril Margaria Date: Wed, 16 Nov 2016 09:37:13 -0500 Message-ID: To: "LITKOWSKI Stephane DTF/DERX" Content-Type: multipart/alternative; boundary=001a1140e91a4a427f05416c0240 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-ietf-pce-segment-routing-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 14:37:18 -0000 --001a1140e91a4a427f05416c0240 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephane, please see inline On 14 November 2016 at 13:05, wrote: > > > *From:* Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Cyril Margaria > *Sent:* Monday, November 14, 2016 23:40 > Dear PCE'ers > > I reviewed the document and I have the following comments/questions: > > 1) The document implies that the PCC has to /MUST do IP > address to SID conversion, I think that it would allow a more simpler PC= C > if that capability is optional and negotiated with additional error > codes to indicate that the NAI SR-EROs are not supported. > > [SLI] Usage of NAI in the SR-ERO is already optional today but driven by > PCE. Do you mean that the PCC should drive the PCE computation result > behavior ? > I think the PCC should be able to indicate if it supports NAI->SID translation. I see the following point missing : - There is no capability negotiation or specific error code to indicate that the PCC does not support S flag set to 0. - if NAI->SID translation is supported, What is the procedure/error code if a PCC cannot resolve a NAI to a SID? From PCE perspective this is a change in the format of the ERO, this does not influence the path computation. A new object may be created for this purpose as a new path constraint. But > you also may fall into situations where the PCE does not support this new > constraint requested by PCC. Then, it would be good to impose one method = to > be supported and others to be optional, this will ensure a real > interoperability between all implementations. > I agree, the draft should mandate one method for SR support, but the other should be negotiated.. > I would also prefer to limit the options=E2=80=A6 (does mixing SID and NA= I make > sense ? I do not see the use case behind) > The ERO should (points below excluded) be consistent, mixing SID-Only and NAI-Only does not make much sense. Having both NAI and SID does make sense for troubleshooting though. > 2) One aspect of the SR-ERO processing is that, when > building the label stack, the PCC should have enough information to decid= e > on the outgoing link (this can be provided by the PCE). It will be good i= f > the document state could spell out this part of the procedure and indicat= es > any specific SR-ERO procedure. For instance one solution could be that t= he > PCE may use IP address or Adjacency SID to indicate the outgoing link. > > [SLI] Are you in the case of SID only used in ERO ? If NAI is used, > outgoing if can be deduced from the first hop NAI, if NAI is not used, th= en > it becomes not trivial and honestly I do not see how to deduce the > interface (PCC cannot check its outgoing label database, as the same valu= e > may be used by multiple neighbors). NAI should be a MUST for the first ho= p ? > I think NAI is a must for the first hop. 3) Taking the outgoing link selection into account, the > Maximum Stack Depth (MSD) calculation may be not trivial: for instance if > the first hop is a local Adjacency-SID, then the label will not be stacke= d, > but it will if the first hop is a Prefix SID it may be counted > (non-adjacent node or adjacent node without PHP) but it may not be counte= d > (adjacent node, with PHP). I think the draft should clarify it. > > [SLI] I do not see why the first hop could be a local Adj-SID=E2=80=A6 if= the ERO > represents the stack to be used for the push operation, and if it starts > with an Adj-SID, the Adj-SID should represent the first real forwarding > operation. Going back to oif point, if NAI isn=E2=80=99t used, how can a = PCC know > that the first Adj-SID is a local SID or a neighbor=E2=80=99s SID ? > I agree, if the PCC does not support NAI->SID, the first hop MUST include a NAI for out interface selection. If SID only is used and starts with an Adj-SID, the SR-ERO may be encoded > using: NAI,Adj-SID,SID#1,SID#2,SID#3,=E2=80=A6SID#n. The first hop define= s only > the oif. > In case the stack starts with a Node-SID, we may > have:Node-SID+NAI,SID#1,SID#2,SID#3 =E2=80=A6 > Using this, we are always inline with MSD as we never send an ERO with more > labels than supported. > > > This works if the first hop for outgoing link selection correspond to an ADj-SID, I am not sure on the Node SID, it believe it depends if its a neigbhor and PHP flag: Following that for SID PCC only this would give the following stacks: - NAI,Adj-SID,SID#1,SID#2,SID#3: stack is SID#1,SID#2,SID#3 (stack size: 3) - Node-SID+NAI,SID#1,SID#2,SID#3: - if the Node is adjacent with PHP: SID#1,SID#2,SID#3 (stack size: 3) - if the Node is adjacent without PHP: Node-SID,SID#1,SID#2,SID#3 (stack size: 4) - if the Node is not adjacent : Node-SID,SID#1,SID#2,SID#3 (stack size: 4) For PCC supporting NAI translation: - NAI#0+(SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3): stack is SID#1,SID#2,SID#3 (stack size: 3) - NAI#0+(Node-SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3): - if the Node is adjacent with PHP: SID#1,SID#2,SID#3 (stack size: 3) - if the Node is adjacent without PHP: Node-SID#0,SID#1,SID#2,SID#3 (stack size: 4) - if the Node is not adjacent : Node-SID#0,SID#1,SID#2,SID#3 (stack size: 4) Thanks, Cyril > > Thanks, > > Cyril > > > > > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --001a1140e91a4a427f05416c0240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephane,=C2=A0

please see inline

On 14 November 2= 016 at 13:05, <stephane.litkowski@orange.com> w= rote:

=C2=A0

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, November 14, 2016 23:40
Dear PCE'ers

<= u>

I reviewed the document and I have the following = comments/questions:=C2=A0

1)=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Th= e document implies that the PCC has to /MUST do IP address to SID conversio= n, I =C2=A0think that it would allow a more simpler PCC if that capability = is optional =C2=A0and negotiated with additional error codes to indicate that the NAI SR-EROs are not supported.

[SLI] Usage of NAI in the SR-ERO is already optional toda= y but driven by PCE. Do you mean that the PCC should drive the PCE computat= ion result behavior ?


I think the PCC should be able to indicate if it supports NAI->S= ID translation.=C2=A0
I see the following point missing :=C2=A0
=C2=A0 - There is no capability negotiation or specific error code= to indicate that the PCC does not support S flag set to 0.
=C2= =A0 - if NAI->SID translation is supported, What is the procedure/error = code if a PCC cannot =C2=A0resolve a NAI to a SID?

=C2=A0From PCE perspective this is a change in the format of the ERO, this= does not influence the path computation.=C2=A0
=C2=A0
=

A new object may be created for this purpose as a new path constraint. But you also may fall into situations where the PCE does not s= upport this new constraint requested by PCC. Then, it would be good to impo= se one method to be supported and others to be optional, this will ensure a= real interoperability between all implementations.

I agree, th= e draft should mandate one method for SR support, but the other should be n= egotiated..
=C2=A0

I would also prefer to limit the options=E2=80=A6 (d= oes mixing SID and NAI make sense ? I do not see the use case behind)


The ERO should (points be= low excluded) be consistent, mixing SID-Only and NAI-Only does not make muc= h sense. Having both NAI and SID does make sense for troubleshooting though= .
=C2=A0
<= div lang=3D"EN-US">
<= div>

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 One aspect of the SR-ERO processing is that, =C2=A0when building the label stack, the = PCC should have enough information to decide on the outgoing link (this can= be provided by the PCE). It will be good if the document state could spell out this part of t= he procedure and indicates any specific SR-ERO procedure. For instance one = solution could be =C2=A0that the PCE may use IP address or Adjacency SID to= indicate the outgoing link.

[SLI] Are you in the case of SID only used in ERO ? If NA= I is used, outgoing if can be deduced from the first hop NAI, if NAI is not= used, then it becomes not trivial and honestly I do not see how to deduce = the interface (PCC cannot check its outgoing label database, as the same value= may be used by multiple neighbors). NAI should be a MUST for the first hop= ?

I think NAI is a must for = the first hop.

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Taking the outgoing link selection into account, the Maximum Stack Dep= th (MSD) calculation may be not trivial: for instance if the first hop is a= local Adjacency-SID, then the label will not be stacked, but it will if the first hop is a Prefix SID it may be counted (non-adjace= nt node or adjacent node without PHP) but it may not be counted (adjacent n= ode, with PHP). I think the draft should clarify it.

[SLI]= I do not see why the first hop could be a local Adj-SID=E2=80=A6 if the ER= O represents the stack to be used for the push operation, and if it starts = with an Adj-SID, the Adj-SID should represent the first real forwarding operation. Going back to oif point, if NAI isn= =E2=80=99t used, how can a PCC know that the first Adj-SID is a local SID o= r a neighbor=E2=80=99s SID ?

=C2=A0I agree, if the PCC does not support NAI->SID, the first ho= p MUST include a NAI for out interface selection.=C2=A0

If SID only is used and starts= with an Adj-SID, the SR-ERO may be encoded using: NAI,Adj-SID,SID#1,SID#2,= SID#3,=E2=80=A6SID#n. The first hop defines only the oif.=C2=A0

In case the = stack starts with a Node-SID, we may have:Node-SID+NAI,SID#1,SID#2,SID= #3 =E2=80=A6=C2=A0

Using this, we are always inline with MS= D as we never send an ERO with more labels than supported.

=C2= =A0

This works if the = first hop for outgoing link selection correspond to an ADj-SID, I am not su= re on the Node SID, it believe it depends if its a neigbhor and PHP flag:
=C2=A0
Following that for SID PCC only this would g= ive the following stacks:
=C2=A0 - NAI,Adj-SID,SID#1,SID#2,SID#3:= stack is SID#1,SID#2,SID#3 (stack size: 3)=C2=A0
=C2=A0 - Node-S= ID+NAI,SID#1,SID#2,SID#3:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0if t= he Node is adjacent with PHP: =C2=A0 =C2=A0 =C2=A0SID#1,SID#2,SID#3 (stack = size: 3)=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0if the Node is = adjacent without PHP: Node-SID,SID#1,SID#2,SID#3 (stack size: 4)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0if the Node is =C2=A0not adjacent : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Node-SID,SID#1,SID#2,SID#3 (s= tack size: 4)

For PCC supporting NAI translation:<= /div>
=C2=A0 - NAI#0+(SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3):= stack is SID#1,SID#2,SID#3 (stack size: 3)=C2=A0
=C2=A0 - NAI#0+= (Node-SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3):
=C2=A0 = =C2=A0 =C2=A0 =C2=A0- =C2=A0if the Node is adjacent with PHP: =C2=A0 =C2=A0= =C2=A0SID#1,SID#2,SID#3 (stack size: 3)=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0- =C2=A0if the Node is adjacent without PHP: Node-SID#0,SID#1,SID= #2,SID#3 (stack size: 4)
=C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0if th= e Node is =C2=A0not adjacent : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Node-SID#0,SID#1,SID#2,SID#3 (stack size: 4)


Thanks,
Cyril=C2=A0




=C2=A0

Thanks,=C2=A0

Cyril=C2=A0<= /p>

=C2=A0

=C2=A0

=C2=A0

____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--001a1140e91a4a427f05416c0240-- From nobody Wed Nov 16 17:33:06 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA621293FD; Wed, 16 Nov 2016 17:33:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147934638095.14978.15669690631739795427.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2016 17:33:00 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-17.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:33:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : PCEP Extensions for Stateful PCE Authors : Edward Crabbe Ina Minei Jan Medved Robert Varga Filename : draft-ietf-pce-stateful-pce-17.txt Pages : 52 Date : 2016-11-16 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 16 17:36:21 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5748E1295C8 for ; Wed, 16 Nov 2016 17:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.937 X-Spam-Level: X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zIoK3bNryOTs for ; Wed, 16 Nov 2016 17:36:17 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 1FDF21295F3 for ; Wed, 16 Nov 2016 17:36:16 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x190so199844424qkb.0 for ; Wed, 16 Nov 2016 17:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6ls4IrHCh2G8/CUTJMik//2unEVJlPuZ6tBGsFh3ph0=; b=MsyuB/HrJbGlAhwvKenJ3vmCUKRvWYpkbzP+4n6M9i64VR7b3qk5aaNNzSGWMmgVJH /cecMeUx0Iiou8p1S5rnnwVjER6pbxAiswOy1utIF5LaZIN/aivepP5tEA2O1Cq6XfIY ZQ+tH/ItISAoB+BpVWf6iQ2K/Tyhm3ZShsNDHL5fGRJu3qFJxES3HqFTM/JOGYyYeBfK WZKAZ2BNN0tzGLOS5otdLrcYc226anRh+1gaIqnKTkIOdqYgXP9fJU5Gmf5dJgmxfrW1 qFCWLurz/hKEtXSySpWaM/sxhStbA639TAAEn1z0cg/GuBLmScOdrGQCD2cFl1D3P6KX 7c5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6ls4IrHCh2G8/CUTJMik//2unEVJlPuZ6tBGsFh3ph0=; b=HxQbB8HZ3RshKmRMpki4LAl1v9QMOv5dSi9XuZQW/98AaULcSyQqkD+GXe3eCVWgDL 7PZpV/MX5Xt8GICCc7ANW+zlV1JVAtdLzDQskjtfR+x6lUpP7bQcjfvS4fKbKL66hsbn mquMlw9Kd7HBmySUsS8X+AYji2vweGWec/oxXBxDk+cq5fZhjmdpB2pEEEPKKqit7q5Z PqA5MCM2itHVDas/+8LZM58Wf0UC58PutS/MMJwH3Wmhm7y43vlsQk7pfrQxrWAGr34l IuPVqGxZa+vWsOXTgu0tHScFmtVprgko2OuS/91B24RMy/G/f2zGXqa/s4N/xUOOj0gh 7amw== X-Gm-Message-State: AKaTC029jdM8fD+MPSRIMykuaM+oetMB1C6umYMr4ySi7Xezz2prv42uj3rkAx1v9fr2Y0HDU0ZxW1xaf6BSbd8P X-Received: by 10.55.69.68 with SMTP id s65mr619050qka.314.1479346575001; Wed, 16 Nov 2016 17:36:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.115.2 with HTTP; Wed, 16 Nov 2016 17:36:14 -0800 (PST) In-Reply-To: <147934638095.14978.15669690631739795427.idtracker@ietfa.amsl.com> References: <147934638095.14978.15669690631739795427.idtracker@ietfa.amsl.com> From: Ina Minei Date: Wed, 16 Nov 2016 17:36:14 -0800 Message-ID: To: pce Content-Type: multipart/alternative; boundary=001a1148aaf21accc9054175377e Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-17.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:36:19 -0000 --001a1148aaf21accc9054175377e Content-Type: text/plain; charset=UTF-8 This version addresses: 1) Clarification regarding the possibility of an empty ERO in PCUpd 2) Remove terminology that was moved to the applicability draft as part of its progression to RFC On Wed, Nov 16, 2016 at 5:33 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element of the IETF. > > Title : PCEP Extensions for Stateful PCE > Authors : Edward Crabbe > Ina Minei > Jan Medved > Robert Varga > Filename : draft-ietf-pce-stateful-pce-17.txt > Pages : 52 > Date : 2016-11-16 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > > Although PCEP explicitly makes no assumptions regarding the > information available to the PCE, it also makes no provisions for PCE > control of timing and sequence of path computations within and across > PCEP sessions. This document describes a set of extensions to PCEP > to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-17 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a1148aaf21accc9054175377e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This version addresses:
1) Clarification regarding the= possibility of an empty ERO in PCUpd
2) Remove terminology that = was moved to the applicability draft as part of its progression to RFC

On Wed, Nov 16, = 2016 at 5:33 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Path Computation Element of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= PCEP Extensions for Stateful PCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Edwa= rd Crabbe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ina Minei
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jan Medved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Robert Varga
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-pce-stateful-pce-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 52
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-11-16

Abstract:
=C2=A0 =C2=A0The Path Computation Element Communication Protocol (PCEP) pro= vides
=C2=A0 =C2=A0mechanisms for Path Computation Elements (PCEs) to perform pat= h
=C2=A0 =C2=A0computations in response to Path Computation Clients (PCCs) re= quests.

=C2=A0 =C2=A0Although PCEP explicitly makes no assumptions regarding the =C2=A0 =C2=A0information available to the PCE, it also makes no provisions = for PCE
=C2=A0 =C2=A0control of timing and sequence of path computations within and= across
=C2=A0 =C2=A0PCEP sessions.=C2=A0 This document describes a set of extensio= ns to PCEP
=C2=A0 =C2=A0to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-pce-stateful-pce/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-pce-stateful-pce-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-pce-17


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--001a1148aaf21accc9054175377e-- From nobody Wed Nov 16 18:51:01 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC8129462 for ; Wed, 16 Nov 2016 18:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.115 X-Spam-Level: X-Spam-Status: No, score=-4.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bNDFYfZ-4Kuq for ; Wed, 16 Nov 2016 18:50:58 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0349E12957B for ; Wed, 16 Nov 2016 18:50:58 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 24B9920575; Thu, 17 Nov 2016 03:50:56 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id CD59820067; Thu, 17 Nov 2016 03:50:55 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 03:50:55 +0100 From: To: Ina Minei , pce Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-pce-17.txt Thread-Index: AQHSQHKOVSd7EipMC0y2Bp/qHHFgS6DcVE4AgAAli1A= Date: Thu, 17 Nov 2016 02:50:54 +0000 Message-ID: <5293_1479351056_582D1B0F_5293_1215_1_9E32478DFA9976438E7A22F69B08FF921DBB1759@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <147934638095.14978.15669690631739795427.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DBB1759OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-17.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 02:50:59 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921DBB1759OPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90IEluYSBmb3IgdGhlIGRyYWZ0IHVwZGF0ZS4NCg0KDQpGcm9tOiBQY2UgW21h aWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEluYSBNaW5laQ0KU2VudDog VGh1cnNkYXksIE5vdmVtYmVyIDE3LCAyMDE2IDEwOjM2DQpUbzogcGNlDQpTdWJqZWN0OiBSZTog W1BjZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTE3LnR4dA0KDQpU aGlzIHZlcnNpb24gYWRkcmVzc2VzOg0KMSkgQ2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgdGhlIHBv c3NpYmlsaXR5IG9mIGFuIGVtcHR5IEVSTyBpbiBQQ1VwZA0KMikgUmVtb3ZlIHRlcm1pbm9sb2d5 IHRoYXQgd2FzIG1vdmVkIHRvIHRoZSBhcHBsaWNhYmlsaXR5IGRyYWZ0IGFzIHBhcnQgb2YgaXRz IHByb2dyZXNzaW9uIHRvIFJGQw0KDQpPbiBXZWQsIE5vdiAxNiwgMjAxNiBhdCA1OjMzIFBNLCA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ PiB3cm90ZToNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IG9mIHRoZSBJRVRGLg0KDQogICAg ICAgIFRpdGxlICAgICAgICAgICA6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgU3RhdGVmdWwgUENFDQog ICAgICAgIEF1dGhvcnMgICAgICAgICA6IEVkd2FyZCBDcmFiYmUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgSW5hIE1pbmVpDQogICAgICAgICAgICAgICAgICAgICAgICAgIEphbiBNZWR2ZWQN CiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFZhcmdhDQogICAgICAgIEZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0xNy50eHQNCiAgICAgICAgUGFn ZXMgICAgICAgICAgIDogNTINCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNi0xMS0xNg0K DQpBYnN0cmFjdDoNCiAgIFRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgQ29tbXVuaWNhdGlv biBQcm90b2NvbCAoUENFUCkgcHJvdmlkZXMNCiAgIG1lY2hhbmlzbXMgZm9yIFBhdGggQ29tcHV0 YXRpb24gRWxlbWVudHMgKFBDRXMpIHRvIHBlcmZvcm0gcGF0aA0KICAgY29tcHV0YXRpb25zIGlu IHJlc3BvbnNlIHRvIFBhdGggQ29tcHV0YXRpb24gQ2xpZW50cyAoUENDcykgcmVxdWVzdHMuDQoN CiAgIEFsdGhvdWdoIFBDRVAgZXhwbGljaXRseSBtYWtlcyBubyBhc3N1bXB0aW9ucyByZWdhcmRp bmcgdGhlDQogICBpbmZvcm1hdGlvbiBhdmFpbGFibGUgdG8gdGhlIFBDRSwgaXQgYWxzbyBtYWtl cyBubyBwcm92aXNpb25zIGZvciBQQ0UNCiAgIGNvbnRyb2wgb2YgdGltaW5nIGFuZCBzZXF1ZW5j ZSBvZiBwYXRoIGNvbXB1dGF0aW9ucyB3aXRoaW4gYW5kIGFjcm9zcw0KICAgUENFUCBzZXNzaW9u cy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIGV4dGVuc2lvbnMgdG8gUENFUA0K ICAgdG8gZW5hYmxlIHN0YXRlZnVsIGNvbnRyb2wgb2YgTVBMUy1URSBhbmQgR01QTFMgTFNQcyB2 aWEgUENFUC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBjZS8NCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY2Utc3RhdGVm dWwtcGNlLTE3DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXBjZS1z dGF0ZWZ1bC1wY2UtMTcNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6 Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2Ug bWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmc8bWFpbHRvOlBjZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== --_000_9E32478DFA9976438E7A22F69B08FF921DBB1759OPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGEgbG90IElu YSBmb3IgdGhlIGRyYWZ0IHVwZGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQY2UgW21haWx0 bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SW5hIE1pbmVpPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAxNywgMjAxNiAxMDozNjxicj4NCjxi PlRvOjwvYj4gcGNlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUGNlXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMTcudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhpcyB2ZXJzaW9uIGFkZHJlc3Nlczo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBDbGFyaWZpY2F0aW9uIHJlZ2FyZGluZyB0aGUg cG9zc2liaWxpdHkgb2YgYW4gZW1wdHkgRVJPIGluIFBDVXBkPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBSZW1vdmUgdGVybWlub2xvZ3kgdGhh dCB3YXMgbW92ZWQgdG8gdGhlIGFwcGxpY2FiaWxpdHkgZHJhZnQgYXMgcGFydCBvZiBpdHMgcHJv Z3Jlc3Npb24gdG8gUkZDPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBXZWQsIE5vdiAxNiwgMjAxNiBhdCA1OjMzIFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBvZiB0aGUgSUVURi48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogUENFUCBFeHRlbnNpb25zIGZvciBTdGF0ZWZ1bCBQ Q0U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IEVkd2FyZCBDcmFiYmU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSW5hIE1pbmVpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IEphbiBNZWR2ZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUm9iZXJ0IFZhcmdhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1l Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNl LTE3LnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA1Mjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg OiAyMDE2LTExLTE2PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBQ YXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgQ29tbXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgcHJv dmlkZXM8YnI+DQombmJzcDsgJm5ic3A7bWVjaGFuaXNtcyBmb3IgUGF0aCBDb21wdXRhdGlvbiBF bGVtZW50cyAoUENFcykgdG8gcGVyZm9ybSBwYXRoPGJyPg0KJm5ic3A7ICZuYnNwO2NvbXB1dGF0 aW9ucyBpbiByZXNwb25zZSB0byBQYXRoIENvbXB1dGF0aW9uIENsaWVudHMgKFBDQ3MpIHJlcXVl c3RzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtBbHRob3VnaCBQQ0VQIGV4cGxpY2l0bHkgbWFr ZXMgbm8gYXNzdW1wdGlvbnMgcmVnYXJkaW5nIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtpbmZvcm1h dGlvbiBhdmFpbGFibGUgdG8gdGhlIFBDRSwgaXQgYWxzbyBtYWtlcyBubyBwcm92aXNpb25zIGZv ciBQQ0U8YnI+DQombmJzcDsgJm5ic3A7Y29udHJvbCBvZiB0aW1pbmcgYW5kIHNlcXVlbmNlIG9m IHBhdGggY29tcHV0YXRpb25zIHdpdGhpbiBhbmQgYWNyb3NzPGJyPg0KJm5ic3A7ICZuYnNwO1BD RVAgc2Vzc2lvbnMuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIGV4dGVu c2lvbnMgdG8gUENFUDxicj4NCiZuYnNwOyAmbmJzcDt0byBlbmFibGUgc3RhdGVmdWwgY29udHJv bCBvZiBNUExTLVRFIGFuZCBHTVBMUyBMU1BzIHZpYSBQQ0VQLjxicj4NCjxicj4NCjxicj4NClRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGNlLXN0 YXRlZnVsLXBjZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UvPC9hPjxicj4NCjxicj4NClRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMTciIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlLTE3PC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTE3IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcGNlLXN0 YXRlZnVsLXBjZS0xNzwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJy Pg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmll dGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86UGNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UGNlQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K PC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF921DBB1759OPEXCLILMA4corp_-- From nobody Wed Nov 16 21:03:15 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3544D129889 for ; Wed, 16 Nov 2016 21:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Rj95d-nx_6xs for ; Wed, 16 Nov 2016 21:03:11 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE13C129866 for ; Wed, 16 Nov 2016 21:03:08 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 7EE4940573; Thu, 17 Nov 2016 06:03:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 5154C2006E; Thu, 17 Nov 2016 06:03:07 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 06:03:07 +0100 From: To: Cyril Margaria Thread-Topic: [Pce] Comments on draft-ietf-pce-segment-routing-08 Thread-Index: AQHSPoUGqKOABs9inkipMImcyolwlaDYvVewgALisoCAAP6ZwA== Date: Thu, 17 Nov 2016 05:03:06 +0000 Message-ID: <21967_1479358987_582D3A0B_21967_1067_1_9E32478DFA9976438E7A22F69B08FF921DBB1D13@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <25467_1479146724_5829FCE4_25467_994_1_9E32478DFA9976438E7A22F69B08FF921DBA75F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DBB1D13OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-ietf-pce-segment-routing-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 05:03:14 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921DBB1D13OPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KTW9yZSBpbmxpbmUgW1NMSTJdDQoNCkZyb206IEN5cmlsIE1hcmdhcmlhIFttYWlsdG86 Y3lyaWwubWFyZ2FyaWFAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwg MjAxNiAyMzozNw0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBPQlMvT0lOSVMNCkNjOiBwY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1zZWdt ZW50LXJvdXRpbmctMDgNCg0KSGkgU3RlcGhhbmUsDQoNCnBsZWFzZSBzZWUgaW5saW5lDQoNCk9u IDE0IE5vdmVtYmVyIDIwMTYgYXQgMTM6MDUsIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+PiB3cm90ZToNCg0KRnJvbTog UGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBjZS1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEN5cmlsIE1hcmdhcmlhDQpTZW50OiBNb25kYXksIE5vdmVtYmVy IDE0LCAyMDE2IDIzOjQwDQpEZWFyIFBDRSdlcnMNCg0KSSByZXZpZXdlZCB0aGUgZG9jdW1lbnQg YW5kIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzL3F1ZXN0aW9uczoNCg0KMSkgICAgICAg ICAgICAgIFRoZSBkb2N1bWVudCBpbXBsaWVzIHRoYXQgdGhlIFBDQyBoYXMgdG8gL01VU1QgZG8g SVAgYWRkcmVzcyB0byBTSUQgY29udmVyc2lvbiwgSSAgdGhpbmsgdGhhdCBpdCB3b3VsZCBhbGxv dyBhIG1vcmUgc2ltcGxlciBQQ0MgaWYgdGhhdCBjYXBhYmlsaXR5IGlzIG9wdGlvbmFsICBhbmQg bmVnb3RpYXRlZCB3aXRoIGFkZGl0aW9uYWwgZXJyb3IgY29kZXMgdG8gaW5kaWNhdGUgdGhhdCB0 aGUgTkFJIFNSLUVST3MgYXJlIG5vdCBzdXBwb3J0ZWQuDQoNCltTTEldIFVzYWdlIG9mIE5BSSBp biB0aGUgU1ItRVJPIGlzIGFscmVhZHkgb3B0aW9uYWwgdG9kYXkgYnV0IGRyaXZlbiBieSBQQ0Uu IERvIHlvdSBtZWFuIHRoYXQgdGhlIFBDQyBzaG91bGQgZHJpdmUgdGhlIFBDRSBjb21wdXRhdGlv biByZXN1bHQgYmVoYXZpb3IgPw0KDQpJIHRoaW5rIHRoZSBQQ0Mgc2hvdWxkIGJlIGFibGUgdG8g aW5kaWNhdGUgaWYgaXQgc3VwcG9ydHMgTkFJLT5TSUQgdHJhbnNsYXRpb24uDQpJIHNlZSB0aGUg Zm9sbG93aW5nIHBvaW50IG1pc3NpbmcgOg0KICAtIFRoZXJlIGlzIG5vIGNhcGFiaWxpdHkgbmVn b3RpYXRpb24gb3Igc3BlY2lmaWMgZXJyb3IgY29kZSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBQQ0Mg ZG9lcyBub3Qgc3VwcG9ydCBTIGZsYWcgc2V0IHRvIDAuDQpbU0xJMl0gWWVzIHRoaXMgY2FuIGJl IG5lZ290aWF0ZWQgYnV0IG11c3Qgbm90IHByZXZlbnQgdGhlIHNlc3Npb24gdG8gZ28gdXAgaWYg b25lIHNwZWFrZXIgZG9lcyBub3Qgc3VwcG9ydCBpdCwgaW4gdGhpcyBjYXNlLCB0aGV5IHdpbGwg anVzdCBub3QgdXNlIE5BSS0+U0lEIHRyYW5zbGF0aW9uLiBCdXQgd2UgY2FuIGFsc28gdGhpbmsg b2YgUENFIHRoYXQgYXJlIG5vdCBjYXBhYmxlIG9mIGNvbXB1dGluZyB0aGUgbGFiZWwgc3RhY2ss IHNvIHRoaXMgbWF5IGJlIG5lZ290aWF0ZWQgYWxzby4gQW5kIGluIGNhc2UgdGhlIHR3byBzcGVh a2VyIGRvZXMgbm90IGhhdmUgYW55IG1hdGNoIChOQUkgb3IgU0lEKSwgd2UgbWF5IGNvbnNpZGVy IHRoYXQgU1IgZXh0ZW5zaW9ucyBjYW5ub3QgYmUgdXNlZC4NCiAgLSBpZiBOQUktPlNJRCB0cmFu c2xhdGlvbiBpcyBzdXBwb3J0ZWQsIFdoYXQgaXMgdGhlIHByb2NlZHVyZS9lcnJvciBjb2RlIGlm IGEgUENDIGNhbm5vdCAgcmVzb2x2ZSBhIE5BSSB0byBhIFNJRD8NCltTTEkyXSBBdCBsZWFzdCB3 ZSBuZWVkIGEgd2F5IHRvIGluZm9ybSBQQ0Ugd2h5IHRoZSBwYXRoIGNhbm5vdCBnZXQgdXAuIEFu ZCBhcyBhIHJlYXNvbiBQQ0MgY2FuIGdpdmUg4oCcTm90IHBvc3NpYmxlIHRvIGVuY29kZSBwYXRo 4oCdDQoNCiBGcm9tIFBDRSBwZXJzcGVjdGl2ZSB0aGlzIGlzIGEgY2hhbmdlIGluIHRoZSBmb3Jt YXQgb2YgdGhlIEVSTywgdGhpcyBkb2VzIG5vdCBpbmZsdWVuY2UgdGhlIHBhdGggY29tcHV0YXRp b24uDQoNCg0KDQpBIG5ldyBvYmplY3QgbWF5IGJlIGNyZWF0ZWQgZm9yIHRoaXMgcHVycG9zZSBh cyBhIG5ldyBwYXRoIGNvbnN0cmFpbnQuIEJ1dCB5b3UgYWxzbyBtYXkgZmFsbCBpbnRvIHNpdHVh dGlvbnMgd2hlcmUgdGhlIFBDRSBkb2VzIG5vdCBzdXBwb3J0IHRoaXMgbmV3IGNvbnN0cmFpbnQg cmVxdWVzdGVkIGJ5IFBDQy4gVGhlbiwgaXQgd291bGQgYmUgZ29vZCB0byBpbXBvc2Ugb25lIG1l dGhvZCB0byBiZSBzdXBwb3J0ZWQgYW5kIG90aGVycyB0byBiZSBvcHRpb25hbCwgdGhpcyB3aWxs IGVuc3VyZSBhIHJlYWwgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGFsbCBpbXBsZW1lbnRhdGlv bnMuDQpJIGFncmVlLCB0aGUgZHJhZnQgc2hvdWxkIG1hbmRhdGUgb25lIG1ldGhvZCBmb3IgU1Ig c3VwcG9ydCwgYnV0IHRoZSBvdGhlciBzaG91bGQgYmUgbmVnb3RpYXRlZC4uDQpbU0xJMl0gT2sN Cg0KSSB3b3VsZCBhbHNvIHByZWZlciB0byBsaW1pdCB0aGUgb3B0aW9uc+KApiAoZG9lcyBtaXhp bmcgU0lEIGFuZCBOQUkgbWFrZSBzZW5zZSA/IEkgZG8gbm90IHNlZSB0aGUgdXNlIGNhc2UgYmVo aW5kKQ0KDQpUaGUgRVJPIHNob3VsZCAocG9pbnRzIGJlbG93IGV4Y2x1ZGVkKSBiZSBjb25zaXN0 ZW50LCBtaXhpbmcgU0lELU9ubHkgYW5kIE5BSS1Pbmx5IGRvZXMgbm90IG1ha2UgbXVjaCBzZW5z ZS4gSGF2aW5nIGJvdGggTkFJIGFuZCBTSUQgZG9lcyBtYWtlIHNlbnNlIGZvciB0cm91Ymxlc2hv b3RpbmcgdGhvdWdoLg0KDQpbU0xJMl0gVGhpcyBzaG91bGQgYmUgY3J5c3RhbCBjbGVhciBpbiB0 aGUgZHJhZnQuDQoNCjIpICAgICAgICAgICAgICBPbmUgYXNwZWN0IG9mIHRoZSBTUi1FUk8gcHJv Y2Vzc2luZyBpcyB0aGF0LCAgd2hlbiBidWlsZGluZyB0aGUgbGFiZWwgc3RhY2ssIHRoZSBQQ0Mg c2hvdWxkIGhhdmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRlY2lkZSBvbiB0aGUgb3V0Z29pbmcg bGluayAodGhpcyBjYW4gYmUgcHJvdmlkZWQgYnkgdGhlIFBDRSkuIEl0IHdpbGwgYmUgZ29vZCBp ZiB0aGUgZG9jdW1lbnQgc3RhdGUgY291bGQgc3BlbGwgb3V0IHRoaXMgcGFydCBvZiB0aGUgcHJv Y2VkdXJlIGFuZCBpbmRpY2F0ZXMgYW55IHNwZWNpZmljIFNSLUVSTyBwcm9jZWR1cmUuIEZvciBp bnN0YW5jZSBvbmUgc29sdXRpb24gY291bGQgYmUgIHRoYXQgdGhlIFBDRSBtYXkgdXNlIElQIGFk ZHJlc3Mgb3IgQWRqYWNlbmN5IFNJRCB0byBpbmRpY2F0ZSB0aGUgb3V0Z29pbmcgbGluay4NCg0K W1NMSV0gQXJlIHlvdSBpbiB0aGUgY2FzZSBvZiBTSUQgb25seSB1c2VkIGluIEVSTyA/IElmIE5B SSBpcyB1c2VkLCBvdXRnb2luZyBpZiBjYW4gYmUgZGVkdWNlZCBmcm9tIHRoZSBmaXJzdCBob3Ag TkFJLCBpZiBOQUkgaXMgbm90IHVzZWQsIHRoZW4gaXQgYmVjb21lcyBub3QgdHJpdmlhbCBhbmQg aG9uZXN0bHkgSSBkbyBub3Qgc2VlIGhvdyB0byBkZWR1Y2UgdGhlIGludGVyZmFjZSAoUENDIGNh bm5vdCBjaGVjayBpdHMgb3V0Z29pbmcgbGFiZWwgZGF0YWJhc2UsIGFzIHRoZSBzYW1lIHZhbHVl IG1heSBiZSB1c2VkIGJ5IG11bHRpcGxlIG5laWdoYm9ycykuIE5BSSBzaG91bGQgYmUgYSBNVVNU IGZvciB0aGUgZmlyc3QgaG9wID8NCkkgdGhpbmsgTkFJIGlzIGEgbXVzdCBmb3IgdGhlIGZpcnN0 IGhvcC4NCg0KW1NMSTJdIE9rLCBzbyB0aGlzIGlzIHNvbWV0aGluZyB0byBhZGQgaW4gdGhlIGRy YWZ0Lg0KDQozKSAgICAgICAgICAgICAgVGFraW5nIHRoZSBvdXRnb2luZyBsaW5rIHNlbGVjdGlv biBpbnRvIGFjY291bnQsIHRoZSBNYXhpbXVtIFN0YWNrIERlcHRoIChNU0QpIGNhbGN1bGF0aW9u IG1heSBiZSBub3QgdHJpdmlhbDogZm9yIGluc3RhbmNlIGlmIHRoZSBmaXJzdCBob3AgaXMgYSBs b2NhbCBBZGphY2VuY3ktU0lELCB0aGVuIHRoZSBsYWJlbCB3aWxsIG5vdCBiZSBzdGFja2VkLCBi dXQgaXQgd2lsbCBpZiB0aGUgZmlyc3QgaG9wIGlzIGEgUHJlZml4IFNJRCBpdCBtYXkgYmUgY291 bnRlZCAobm9uLWFkamFjZW50IG5vZGUgb3IgYWRqYWNlbnQgbm9kZSB3aXRob3V0IFBIUCkgYnV0 IGl0IG1heSBub3QgYmUgY291bnRlZCAoYWRqYWNlbnQgbm9kZSwgd2l0aCBQSFApLiBJIHRoaW5r IHRoZSBkcmFmdCBzaG91bGQgY2xhcmlmeSBpdC4NCg0KW1NMSV0gSSBkbyBub3Qgc2VlIHdoeSB0 aGUgZmlyc3QgaG9wIGNvdWxkIGJlIGEgbG9jYWwgQWRqLVNJROKApiBpZiB0aGUgRVJPIHJlcHJl c2VudHMgdGhlIHN0YWNrIHRvIGJlIHVzZWQgZm9yIHRoZSBwdXNoIG9wZXJhdGlvbiwgYW5kIGlm IGl0IHN0YXJ0cyB3aXRoIGFuIEFkai1TSUQsIHRoZSBBZGotU0lEIHNob3VsZCByZXByZXNlbnQg dGhlIGZpcnN0IHJlYWwgZm9yd2FyZGluZyBvcGVyYXRpb24uIEdvaW5nIGJhY2sgdG8gb2lmIHBv aW50LCBpZiBOQUkgaXNu4oCZdCB1c2VkLCBob3cgY2FuIGEgUENDIGtub3cgdGhhdCB0aGUgZmly c3QgQWRqLVNJRCBpcyBhIGxvY2FsIFNJRCBvciBhIG5laWdoYm9y4oCZcyBTSUQgPw0KIEkgYWdy ZWUsIGlmIHRoZSBQQ0MgZG9lcyBub3Qgc3VwcG9ydCBOQUktPlNJRCwgdGhlIGZpcnN0IGhvcCBN VVNUIGluY2x1ZGUgYSBOQUkgZm9yIG91dCBpbnRlcmZhY2Ugc2VsZWN0aW9uLg0KDQoNCklmIFNJ RCBvbmx5IGlzIHVzZWQgYW5kIHN0YXJ0cyB3aXRoIGFuIEFkai1TSUQsIHRoZSBTUi1FUk8gbWF5 IGJlIGVuY29kZWQgdXNpbmc6IE5BSSxBZGotU0lELFNJRCMxLFNJRCMyLFNJRCMzLOKAplNJRCNu LiBUaGUgZmlyc3QgaG9wIGRlZmluZXMgb25seSB0aGUgb2lmLg0KDQpJbiBjYXNlIHRoZSBzdGFj ayBzdGFydHMgd2l0aCBhIE5vZGUtU0lELCB3ZSBtYXkgaGF2ZTpOb2RlLVNJRCtOQUksU0lEIzEs U0lEIzIsU0lEIzMg4oCmDQoNClVzaW5nIHRoaXMsIHdlIGFyZSBhbHdheXMgaW5saW5lIHdpdGgg TVNEIGFzIHdlIG5ldmVyIHNlbmQgYW4gRVJPIHdpdGggbW9yZSBsYWJlbHMgdGhhbiBzdXBwb3J0 ZWQuDQoNCg0KVGhpcyB3b3JrcyBpZiB0aGUgZmlyc3QgaG9wIGZvciBvdXRnb2luZyBsaW5rIHNl bGVjdGlvbiBjb3JyZXNwb25kIHRvIGFuIEFEai1TSUQsIEkgYW0gbm90IHN1cmUgb24gdGhlIE5v ZGUgU0lELCBpdCBiZWxpZXZlIGl0IGRlcGVuZHMgaWYgaXRzIGEgbmVpZ2Job3IgYW5kIFBIUCBm bGFnOg0KDQoNCkZvbGxvd2luZyB0aGF0IGZvciBTSUQgUENDIG9ubHkgdGhpcyB3b3VsZCBnaXZl IHRoZSBmb2xsb3dpbmcgc3RhY2tzOg0KICAtIE5BSSxBZGotU0lELFNJRCMxLFNJRCMyLFNJRCMz OiBzdGFjayBpcyBTSUQjMSxTSUQjMixTSUQjMyAoc3RhY2sgc2l6ZTogMykNCltTTEkyXSBXaHkg YSBzaXplIG9mIDMsIHdoaWxlIEkgc2VlIDQgU0lEcyA/DQoNCiAgLSBOb2RlLVNJRCtOQUksU0lE IzEsU0lEIzIsU0lEIzM6DQogICAgICAgLSAgaWYgdGhlIE5vZGUgaXMgYWRqYWNlbnQgd2l0aCBQ SFA6ICAgICAgU0lEIzEsU0lEIzIsU0lEIzMgKHN0YWNrIHNpemU6IDMpDQogICAgICAgLSAgaWYg dGhlIE5vZGUgaXMgYWRqYWNlbnQgd2l0aG91dCBQSFA6IE5vZGUtU0lELFNJRCMxLFNJRCMyLFNJ RCMzIChzdGFjayBzaXplOiA0KQ0KICAgICAgIC0gIGlmIHRoZSBOb2RlIGlzICBub3QgYWRqYWNl bnQgOiAgICAgICAgICAgICAgIE5vZGUtU0lELFNJRCMxLFNJRCMyLFNJRCMzIChzdGFjayBzaXpl OiA0KQ0KW1NMSTJdIEkgZG8gbm90IHNlZSB3aHkgUEhQIG1hdHRlcnMgaGVyZS4NCklmIEnigJlt IGNvbm5lY3RlZCB0byB0aGUgbm9kZSB0aGF0IEkgbmVlZCB0byBmb3J3YXJkIHRvLCBJIGRvIG5v dCBuZWVkIGFueSBTSUQsIEkgY2FuIGp1c3QgZm9yd2FyZCBteSB0cmFmZmljIG9uIHRoZSBsaW5r IHdpdGggdGhlIG5leHQgbGFiZWxzIGluIHRoZSBzdGFjayBidXQgSSBkbyBub3QgbmVlZCB0byBj YXJlIGFib3V0IFBIUCBhcyBJ4oCZbSBub3QgdXNpbmcgYW4gSUxNLT5OSExGRSBhY3Rpb24gaGVy ZSB0aGF04oCZcyBqdXN0IGEgcHVzaC4NCg0KRm9yIFBDQyBzdXBwb3J0aW5nIE5BSSB0cmFuc2xh dGlvbjoNCiAgLSBOQUkjMCsoU0lEIzApLE5BSSMxKyhTSUQjMSksTkFJIzIrKFNJRCMyKSxOQUkj MygrU0lEIzMpOiBzdGFjayBpcyBTSUQjMSxTSUQjMixTSUQjMyAoc3RhY2sgc2l6ZTogMykNCiAg LSBOQUkjMCsoTm9kZS1TSUQjMCksTkFJIzErKFNJRCMxKSxOQUkjMisoU0lEIzIpLE5BSSMzKCtT SUQjMyk6DQogICAgICAgLSAgaWYgdGhlIE5vZGUgaXMgYWRqYWNlbnQgd2l0aCBQSFA6ICAgICAg U0lEIzEsU0lEIzIsU0lEIzMgKHN0YWNrIHNpemU6IDMpDQogICAgICAgLSAgaWYgdGhlIE5vZGUg aXMgYWRqYWNlbnQgd2l0aG91dCBQSFA6IE5vZGUtU0lEIzAsU0lEIzEsU0lEIzIsU0lEIzMgKHN0 YWNrIHNpemU6IDQpDQogICAgICAgLSAgaWYgdGhlIE5vZGUgaXMgIG5vdCBhZGphY2VudCA6ICAg ICAgICAgICAgICBOb2RlLVNJRCMwLFNJRCMxLFNJRCMyLFNJRCMzIChzdGFjayBzaXplOiA0KQ0K DQoNClRoYW5rcywNCkN5cmlsDQoNCg0KDQoNCg0KDQoNClRoYW5rcywNCg0KQ3lyaWwNCg0KDQoN Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_9E32478DFA9976438E7A22F69B08FF921DBB1D13OPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpw LmdtYWlsLW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtcDEsIGxpLmdtYWlsLW01NTExMDc1NTMx MjA5OTA1MjM4Z21haWwtcDEsIGRpdi5nbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAx DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAxOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmdtYWlsLW01 NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtczENCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV81NTEx MDc1NTMxMjA5OTA1MjM4Z21haWwtczE7fQ0Kc3Bhbi5nbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIz OGdtYWlsLXMyDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNTUxMTA3NTUzMTIwOTkwNTIzOGdt YWlsLXMyO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy NQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TW9yZSBpbmxpbmUgW1NMSTJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBDeXJpbCBNYXJnYXJpYSBbbWFpbHRvOmN5cmlsLm1hcmdhcmlhQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDE2LCAyMDE2IDIzOjM3 PGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgT0JTL09JTklTPGJyPg0KPGI+Q2M6 PC9iPiBwY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtQY2VdIENvbW1lbnRz IG9uIGRyYWZ0LWlldGYtcGNlLXNlZ21lbnQtcm91dGluZy0wODxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIFN0ZXBoYW5lLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGxlYXNlIHNlZSBpbmxpbmU8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNCBOb3ZlbWJlciAyMDE2IGF0IDEzOjA1LCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGNlIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cGNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DeXJpbCBN YXJnYXJpYTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDE0LCAyMDE2IDIzOjQw PGJyPg0KPC9zcGFuPkRlYXIgUENFJ2VyczxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJnbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAxIj48c3BhbiBjbGFzcz0iZ21haWwt bTU1MTEwNzU1MzEyMDk5MDUyMzhnbWFpbC1zMSI+SSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5k IEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzL3F1ZXN0aW9uczo8L3NwYW4+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTU1MTEwNzU1MzEyMDk5MDUyMzhnbWFpbC1w MSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQ4Ljc1cHQiPjEpPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW01 NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtczEiPlRoZSBkb2N1bWVudCBpbXBsaWVzIHRoYXQgdGhl IFBDQyBoYXMgdG8gL01VU1QgZG8gSVAgYWRkcmVzcyB0byBTSUQgY29udmVyc2lvbiwgSSAmbmJz cDt0aGluayB0aGF0IGl0IHdvdWxkIGFsbG93IGEgbW9yZSBzaW1wbGVyIFBDQyBpZiB0aGF0IGNh cGFiaWxpdHkgaXMgb3B0aW9uYWwgJm5ic3A7PC9zcGFuPmFuZCBuZWdvdGlhdGVkIHdpdGggYWRk aXRpb25hbCBlcnJvcg0KIGNvZGVzIHRvIGluZGljYXRlIHRoYXQgdGhlIE5BSSBTUi1FUk9zIGFy ZSBub3Qgc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW01NTExMDc1 NTMxMjA5OTA1MjM4Z21haWwtcDEiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU0xJXSBV c2FnZSBvZiBOQUkgaW4gdGhlIFNSLUVSTyBpcyBhbHJlYWR5IG9wdGlvbmFsIHRvZGF5IGJ1dCBk cml2ZW4gYnkgUENFLiBEbyB5b3UgbWVhbiB0aGF0IHRoZSBQQ0Mgc2hvdWxkIGRyaXZlIHRoZSBQ Q0UgY29tcHV0YXRpb24gcmVzdWx0IGJlaGF2aW9yID88L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIHRoZSBQQ0Mgc2hvdWxkIGJlIGFibGUgdG8gaW5kaWNhdGUgaWYgaXQgc3VwcG9ydHMgTkFJ LSZndDtTSUQgdHJhbnNsYXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSB0aGUgZm9sbG93aW5nIHBvaW50IG1pc3Npbmcg OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7IC0gVGhlcmUgaXMgbm8gY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBvciBzcGVjaWZp YyBlcnJvciBjb2RlIHRvIGluZGljYXRlIHRoYXQgdGhlIFBDQyBkb2VzIG5vdCBzdXBwb3J0IFMg ZmxhZyBzZXQgdG8gMC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0xJMl0gWWVzIHRoaXMgY2Fu IGJlIG5lZ290aWF0ZWQgYnV0IG11c3Qgbm90IHByZXZlbnQgdGhlIHNlc3Npb24gdG8gZ28gdXAg aWYgb25lIHNwZWFrZXIgZG9lcyBub3Qgc3VwcG9ydCBpdCwgaW4gdGhpcyBjYXNlLCB0aGV5IHdp bGwganVzdCBub3QgdXNlIE5BSS0mZ3Q7U0lEDQogdHJhbnNsYXRpb24uIEJ1dCB3ZSBjYW4gYWxz byB0aGluayBvZiBQQ0UgdGhhdCBhcmUgbm90IGNhcGFibGUgb2YgY29tcHV0aW5nIHRoZSBsYWJl bCBzdGFjaywgc28gdGhpcyBtYXkgYmUgbmVnb3RpYXRlZCBhbHNvLiBBbmQgaW4gY2FzZSB0aGUg dHdvIHNwZWFrZXIgZG9lcyBub3QgaGF2ZSBhbnkgbWF0Y2ggKE5BSSBvciBTSUQpLCB3ZSBtYXkg Y29uc2lkZXIgdGhhdCBTUiBleHRlbnNpb25zIGNhbm5vdCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIGlm IE5BSS0mZ3Q7U0lEIHRyYW5zbGF0aW9uIGlzIHN1cHBvcnRlZCwgV2hhdCBpcyB0aGUgcHJvY2Vk dXJlL2Vycm9yIGNvZGUgaWYgYSBQQ0MgY2Fubm90ICZuYnNwO3Jlc29sdmUgYSBOQUkgdG8gYSBT SUQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1NMSTJdIEF0IGxlYXN0IHdlIG5lZWQgYSB3YXkg dG8gaW5mb3JtIFBDRSB3aHkgdGhlIHBhdGggY2Fubm90IGdldCB1cC4gQW5kIGFzIGEgcmVhc29u IFBDQyBjYW4gZ2l2ZSDigJxOb3QgcG9zc2libGUgdG8gZW5jb2RlIHBhdGjigJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7RnJvbSBQQ0UgcGVyc3BlY3RpdmUg dGhpcyBpcyBhIGNoYW5nZSBpbiB0aGUgZm9ybWF0IG9mIHRoZSBFUk8sIHRoaXMgZG9lcyBub3Qg aW5mbHVlbmNlIHRoZSBwYXRoIGNvbXB1dGF0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFp bC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAxIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+QSBuZXcgb2JqZWN0IG1heSBiZSBjcmVhdGVkIGZvciB0aGlzIHB1cnBvc2UgYXMgYSBuZXcg cGF0aCBjb25zdHJhaW50LiBCdXQgeW91IGFsc28gbWF5IGZhbGwgaW50byBzaXR1YXRpb25zIHdo ZXJlIHRoZSBQQ0UgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIG5ldyBjb25zdHJhaW50IHJlcXVlc3Rl ZCBieSBQQ0MuIFRoZW4sDQogaXQgd291bGQgYmUgZ29vZCB0byBpbXBvc2Ugb25lIG1ldGhvZCB0 byBiZSBzdXBwb3J0ZWQgYW5kIG90aGVycyB0byBiZSBvcHRpb25hbCwgdGhpcyB3aWxsIGVuc3Vy ZSBhIHJlYWwgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGFsbCBpbXBsZW1lbnRhdGlvbnMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUsIHRoZSBkcmFmdCBzaG91bGQg bWFuZGF0ZSBvbmUgbWV0aG9kIGZvciBTUiBzdXBwb3J0LCBidXQgdGhlIG90aGVyIHNob3VsZCBi ZSBuZWdvdGlhdGVkLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU0xJMl0gT2s8L3NwYW4+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJnbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAxIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBhbHNvIHByZWZlciB0byBsaW1pdCB0aGUgb3B0aW9uc+KA piAoZG9lcyBtaXhpbmcgU0lEIGFuZCBOQUkgbWFrZSBzZW5zZSA/IEkgZG8gbm90IHNlZSB0aGUg dXNlIGNhc2UgYmVoaW5kKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgRVJPIHNob3Vs ZCAocG9pbnRzIGJlbG93IGV4Y2x1ZGVkKSBiZSBjb25zaXN0ZW50LCBtaXhpbmcgU0lELU9ubHkg YW5kIE5BSS1Pbmx5IGRvZXMgbm90IG1ha2UgbXVjaCBzZW5zZS4gSGF2aW5nIGJvdGggTkFJIGFu ZCBTSUQgZG9lcyBtYWtlIHNlbnNlIGZvciB0cm91Ymxlc2hvb3RpbmcgdGhvdWdoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W1NMSTJdIFRoaXMgc2hvdWxkIGJlIGNyeXN0YWwgY2xlYXIgaW4g dGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdt YWlsLXAxIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDguNzVwdCI+PHNwYW4gY2xhc3M9ImdtYWlsLW01 NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtczEiPjIpPC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbC1t NTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXMxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWls LW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtczIiPk9uZSBhc3BlY3Qgb2YgdGhlIFNSLUVSTyBw cm9jZXNzaW5nIGlzIHRoYXQsICZuYnNwO3c8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW01NTEx MDc1NTMxMjA5OTA1MjM4Z21haWwtczEiPmhlbiBidWlsZGluZyB0aGUgbGFiZWwgc3RhY2ssIHRo ZSBQQ0Mgc2hvdWxkIGhhdmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRlY2lkZSBvbiB0aGUgb3V0 Z29pbmcNCiBsaW5rICh0aGlzIGNhbiBiZSBwcm92aWRlZCBieSB0aGUgUENFKS4gSXQgd2lsbCBi ZSBnb29kIGlmIHRoZSBkb2N1bWVudCBzdGF0ZSBjb3VsZCBzcGVsbCBvdXQgdGhpcyBwYXJ0IG9m IHRoZSBwcm9jZWR1cmUgYW5kIGluZGljYXRlcyBhbnkgc3BlY2lmaWMgU1ItRVJPIHByb2NlZHVy ZS4gRm9yIGluc3RhbmNlIG9uZSBzb2x1dGlvbiBjb3VsZCBiZSAmbmJzcDt0aGF0IHRoZSBQQ0Ug bWF5IHVzZSBJUCBhZGRyZXNzIG9yIEFkamFjZW5jeSBTSUQgdG8gaW5kaWNhdGUNCiB0aGUgb3V0 Z29pbmcgbGluay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTU1MTEw NzU1MzEyMDk5MDUyMzhnbWFpbC1wMSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltTTEld IEFyZSB5b3UgaW4gdGhlIGNhc2Ugb2YgU0lEIG9ubHkgdXNlZCBpbiBFUk8gPyBJZiBOQUkgaXMg dXNlZCwgb3V0Z29pbmcgaWYgY2FuIGJlIGRlZHVjZWQgZnJvbSB0aGUgZmlyc3QgaG9wIE5BSSwg aWYgTkFJIGlzIG5vdCB1c2VkLCB0aGVuIGl0IGJlY29tZXMgbm90IHRyaXZpYWwgYW5kIGhvbmVz dGx5IEkgZG8NCiBub3Qgc2VlIGhvdyB0byBkZWR1Y2UgdGhlIGludGVyZmFjZSAoUENDIGNhbm5v dCBjaGVjayBpdHMgb3V0Z29pbmcgbGFiZWwgZGF0YWJhc2UsIGFzIHRoZSBzYW1lIHZhbHVlIG1h eSBiZSB1c2VkIGJ5IG11bHRpcGxlIG5laWdoYm9ycykuIE5BSSBzaG91bGQgYmUgYSBNVVNUIGZv ciB0aGUgZmlyc3QgaG9wID88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayBOQUkgaXMgYSBtdXN0IGZvciB0aGUgZmlyc3QgaG9wLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0xJMl0gT2ssIHNvIHRoaXMg aXMgc29tZXRoaW5nIHRvIGFkZCBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWls LW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtcDEiIHN0eWxlPSJtYXJnaW4tbGVmdDo0OC43NXB0 Ij48c3BhbiBjbGFzcz0iZ21haWwtbTU1MTEwNzU1MzEyMDk5MDUyMzhnbWFpbC1zMSI+Myk8L3Nw YW4+PHNwYW4gY2xhc3M9ImdtYWlsLW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtczEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlRh a2luZyB0aGUgb3V0Z29pbmcgbGluayBzZWxlY3Rpb24gaW50byBhY2NvdW50LCB0aGUgTWF4aW11 bSBTdGFjayBEZXB0aCAoTVNEKSBjYWxjdWxhdGlvbiBtYXkgYmUgbm90IHRyaXZpYWw6IGZvciBp bnN0YW5jZSBpZiB0aGUgZmlyc3QgaG9wIGlzIGEgbG9jYWwgQWRqYWNlbmN5LVNJRCwgdGhlbiB0 aGUgbGFiZWwgd2lsbCBub3QgYmUgc3RhY2tlZCwgYnV0IGl0IHdpbGwgaWYgdGhlIGZpcnN0IGhv cCBpcyBhIFByZWZpeCBTSUQgaXQNCiBtYXkgYmUgY291bnRlZCAobm9uLWFkamFjZW50IG5vZGUg b3IgYWRqYWNlbnQgbm9kZSB3aXRob3V0IFBIUCkgYnV0IGl0IG1heSBub3QgYmUgY291bnRlZCAo YWRqYWNlbnQgbm9kZSwgd2l0aCBQSFApLiBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgY2xhcmlm eSBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTU1MTEwNzU1MzEy MDk5MDUyMzhnbWFpbC1wMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW01NTExMDc1NTMxMjA5OTA1MjM4 Z21haWwtczEiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU0xJXSBJIGRvIG5vdCBzZWUg d2h5IHRoZSBmaXJzdCBob3AgY291bGQgYmUgYSBsb2NhbCBBZGotU0lE4oCmIGlmIHRoZSBFUk8g cmVwcmVzZW50cyB0aGUgc3RhY2sgdG8gYmUgdXNlZCBmb3IgdGhlIHB1c2ggb3BlcmF0aW9uLCBh bmQNCiBpZiBpdCBzdGFydHMgd2l0aCBhbiBBZGotU0lELCB0aGUgQWRqLVNJRCBzaG91bGQgcmVw cmVzZW50IHRoZSBmaXJzdCByZWFsIGZvcndhcmRpbmcgb3BlcmF0aW9uLiBHb2luZyBiYWNrIHRv IG9pZiBwb2ludCwgaWYgTkFJIGlzbuKAmXQgdXNlZCwgaG93IGNhbiBhIFBDQyBrbm93IHRoYXQg dGhlIGZpcnN0IEFkai1TSUQgaXMgYSBsb2NhbCBTSUQgb3IgYSBuZWlnaGJvcuKAmXMgU0lEID88 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0kgYWdyZWUsIGlm IHRoZSBQQ0MgZG9lcyBub3Qgc3VwcG9ydCBOQUktJmd0O1NJRCwgdGhlIGZpcnN0IGhvcCBNVVNU IGluY2x1ZGUgYSBOQUkgZm9yIG91dCBpbnRlcmZhY2Ugc2VsZWN0aW9uLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iZ21haWwtbTU1MTEwNzU1MzEyMDk5MDUyMzhnbWFpbC1wMSI+PHNwYW4gY2xhc3M9Imdt YWlsLW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtczEiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JZiBTSUQgb25seSBpcyB1c2VkIGFuZCBzdGFydHMgd2l0aCBhbiBBZGotU0lELCB0aGUg U1ItRVJPIG1heSBiZSBlbmNvZGVkIHVzaW5nOiBOQUksQWRqLVNJRCxTSUQjMSxTSUQjMixTSUQj MyzigKZTSUQjbi4gVGhlIGZpcnN0IGhvcCBkZWZpbmVzDQogb25seSB0aGUgb2lmLjwvc3Bhbj48 L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Imdt YWlsLW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtcDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1tNTUx MTA3NTUzMTIwOTkwNTIzOGdtYWlsLXMxIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4g Y2FzZSB0aGUgc3RhY2sgc3RhcnRzIHdpdGggYSBOb2RlLVNJRCwgd2UgbWF5IGhhdmU6Tm9kZS1T SUQmIzQzO05BSSxTSUQjMSxTSUQjMixTSUQjMyDigKY8L3NwYW4+PC9zcGFuPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tNTUxMTA3NTUzMTIw OTkwNTIzOGdtYWlsLXAxIj48c3BhbiBjbGFzcz0iZ21haWwtbTU1MTEwNzU1MzEyMDk5MDUyMzhn bWFpbC1zMSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlVzaW5nIHRoaXMsIHdlIGFyZSBh bHdheXMgaW5saW5lIHdpdGggTVNEIGFzIHdlIG5ldmVyIHNlbmQgYW4gRVJPIHdpdGggbW9yZSBs YWJlbHMgdGhhbiBzdXBwb3J0ZWQuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAxIj48c3BhbiBjbGFzcz0iZ21h aWwtbTU1MTEwNzU1MzEyMDk5MDUyMzhnbWFpbC1zMSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3 b3JrcyBpZiB0aGUgZmlyc3QgaG9wIGZvciBvdXRnb2luZyBsaW5rIHNlbGVjdGlvbiBjb3JyZXNw b25kIHRvIGFuIEFEai1TSUQsIEkgYW0gbm90IHN1cmUgb24gdGhlIE5vZGUgU0lELCBpdCBiZWxp ZXZlIGl0IGRlcGVuZHMgaWYgaXRzIGEgbmVpZ2Job3IgYW5kIFBIUCBmbGFnOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvbGxvd2luZyB0aGF0IGZvciBTSUQgUEND IG9ubHkgdGhpcyB3b3VsZCBnaXZlIHRoZSBmb2xsb3dpbmcgc3RhY2tzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gTkFJLEFkai1T SUQsU0lEIzEsU0lEIzIsU0lEIzM6IHN0YWNrIGlzIFNJRCMxLFNJRCMyLFNJRCMzIChzdGFjayBz aXplOiAzKTxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1NMSTJdIFdoeSBhIHNpemUgb2YgMywgd2hpbGUgSSBzZWUgNCBTSURzID88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIE5vZGUt U0lEJiM0MztOQUksU0lEIzEsU0lEIzIsU0lEIzM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstICZu YnNwO2lmIHRoZSBOb2RlIGlzIGFkamFjZW50IHdpdGggUEhQOiAmbmJzcDsgJm5ic3A7ICZuYnNw O1NJRCMxLFNJRCMyLFNJRCMzIChzdGFjayBzaXplOiAzKSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7LSAmbmJzcDtpZiB0aGUgTm9kZSBpcyBhZGphY2VudCB3aXRob3V0IFBIUDogTm9kZS1T SUQsU0lEIzEsU0lEIzIsU0lEIzMgKHN0YWNrIHNpemU6IDQpPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDstICZuYnNwO2lmIHRoZSBOb2RlIGlzICZuYnNwO25vdCBhZGphY2VudCA6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOb2RlLVNJRCxTSUQjMSxTSUQj MixTSUQjMyAoc3RhY2sgc2l6ZTogNCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU0xJMl0gSSBk byBub3Qgc2VlIHdoeSBQSFAgbWF0dGVycyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiBJ4oCZbSBj b25uZWN0ZWQgdG8gdGhlIG5vZGUgdGhhdCBJIG5lZWQgdG8gZm9yd2FyZCB0bywgSSBkbyBub3Qg bmVlZCBhbnkgU0lELCBJIGNhbiBqdXN0IGZvcndhcmQgbXkgdHJhZmZpYyBvbiB0aGUgbGluayB3 aXRoIHRoZSBuZXh0IGxhYmVscyBpbiB0aGUgc3RhY2sgYnV0IEkgZG8gbm90IG5lZWQgdG8gY2Fy ZSBhYm91dCBQSFAgYXMgSeKAmW0gbm90IHVzaW5nDQogYW4gSUxNLSZndDtOSExGRSBhY3Rpb24g aGVyZSB0aGF04oCZcyBqdXN0IGEgcHVzaC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Gb3IgUENDIHN1cHBvcnRpbmcgTkFJIHRyYW5zbGF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gTkFJIzAmIzQzOyhTSUQj MCksTkFJIzEmIzQzOyhTSUQjMSksTkFJIzImIzQzOyhTSUQjMiksTkFJIzMoJiM0MztTSUQjMyk6 IHN0YWNrIGlzIFNJRCMxLFNJRCMyLFNJRCMzIChzdGFjayBzaXplOiAzKSZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gTkFJ IzAmIzQzOyhOb2RlLVNJRCMwKSxOQUkjMSYjNDM7KFNJRCMxKSxOQUkjMiYjNDM7KFNJRCMyKSxO QUkjMygmIzQzO1NJRCMzKTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gJm5ic3A7aWYgdGhlIE5v ZGUgaXMgYWRqYWNlbnQgd2l0aCBQSFA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7U0lEIzEsU0lEIzIs U0lEIzMgKHN0YWNrIHNpemU6IDMpJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstICZuYnNw O2lmIHRoZSBOb2RlIGlzIGFkamFjZW50IHdpdGhvdXQgUEhQOiBOb2RlLVNJRCMwLFNJRCMxLFNJ RCMyLFNJRCMzIChzdGFjayBzaXplOiA0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSAmbmJzcDtp ZiB0aGUgTm9kZSBpcyAmbmJzcDtub3QgYWRqYWNlbnQgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOb2RlLVNJRCMwLFNJRCMxLFNJRCMyLFNJRCMzIChz dGFjayBzaXplOiA0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkN5cmlsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Imdt YWlsLW01NTExMDc1NTMxMjA5OTA1MjM4Z21haWwtcDEiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTU1MTEw NzU1MzEyMDk5MDUyMzhnbWFpbC1wMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW01NTExMDc1NTMxMjA5 OTA1MjM4Z21haWwtczEiPlRoYW5rcywmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iZ21haWwtbTU1MTEwNzU1MzEyMDk5MDUyMzhnbWFpbC1wMSI+Q3lyaWwmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNTUxMTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAx Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNTUxMTA3NTUzMTIwOTkw NTIzOGdtYWlsLXAxIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNTUx MTA3NTUzMTIwOTkwNTIzOGdtYWlsLXAxIj48c3BhbiBjbGFzcz0iZ21haWwtbTU1MTEwNzU1MzEy MDk5MDUyMzhnbWFpbC1zMSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286 cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+ VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_9E32478DFA9976438E7A22F69B08FF921DBB1D13OPEXCLILMA4corp_-- From nobody Fri Nov 18 06:35:12 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0E012945D; Fri, 18 Nov 2016 06:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.031 X-Spam-Level: X-Spam-Status: No, score=-5.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 SboAfgM2nlh1; Fri, 18 Nov 2016 06:35:09 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 83CB3129449; Fri, 18 Nov 2016 06:35:06 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60AB8A441AE; Fri, 18 Nov 2016 15:35:05 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 5A490A440C6; Fri, 18 Nov 2016 15:35:05 +0100 (CET) Received: from [10.193.71.173] (10.193.71.173) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Fri, 18 Nov 2016 15:35:04 +0100 From: Julien Meuric To: Organization: Orange Message-ID: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> Date: Fri, 18 Nov 2016 15:35:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 14:35:11 -0000 Dear authors of the aforementioned I-D, Could you please share with the mailing list whether you are aware of any IPR that applies to draft-ietf-pce-stateful-pce and, if so, if it has been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.) If you are not aware of any IPR that applies, please reply saying “I am not aware of any IPR that applies to this draft”. A feedback from each of you is required to move the document to the IESG. Best regards, Jon, JP & Julien From nobody Fri Nov 18 06:37:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB091295BA; Fri, 18 Nov 2016 06:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 pHoOn6PNnK8H; Fri, 18 Nov 2016 06:36:58 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 13010129576; Fri, 18 Nov 2016 06:36:55 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 22143E30079; Fri, 18 Nov 2016 15:36:54 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 1863BE30077; Fri, 18 Nov 2016 15:36:54 +0100 (CET) Received: from [10.193.71.173] (10.193.71.173) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Fri, 18 Nov 2016 15:36:53 +0100 From: Julien Meuric To: Organization: Orange Message-ID: <13d1bd3c-5abc-136c-87e1-5fd9c3b4bffb@orange.com> Date: Fri, 18 Nov 2016 15:36:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Last IPR Check for draft-ietf-pce-pce-initiated-lsp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 14:36:59 -0000 Dear authors of the aforementioned I-D, Could you please share with the mailing list whether you are aware of any IPR that applies to draft-ietf-pce-pce-initiated-lsp and, if so, if it has been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.) If you are not aware of any IPR that applies, please reply saying “I am not aware of any IPR that applies to this draftâ€. A feedback from each of you is required to move the document to the IESG. Best regards, Jon, JP & Julien From nobody Fri Nov 18 07:01:08 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E837E129590 for ; Fri, 18 Nov 2016 07:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.518 X-Spam-Level: X-Spam-Status: No, score=-15.518 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, RCVD_IN_SORBS_SPAM=0.5, 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 orgaOt_1tcv6 for ; Fri, 18 Nov 2016 07:01:05 -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 6B7D112958F for ; Fri, 18 Nov 2016 07:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1318; q=dns/txt; s=iport; t=1479481265; x=1480690865; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hqoFqoEtsTFiOB+uP6Fa2BgpdVOmA8o/GMceTWAea5I=; b=X99EDKTZZrseeO9fcliXY5rLbwcSLpsxzLeIaTKLsz7JUUEiIffEoFR6 e2ZPnzk1GrWQ6viLZnl6q/DfbA1yRdXW5E6L1QqIIJT+9fMkVvfiAAqvM sKOV4BIOpijPmrnoo94uzCI12wvWrgOVglb591HDCshs9FTZ3OnATk8Sz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQCEFy9Y/5xdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR9YgQAHjTirdYIHHQuFeQIagXA/FAECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQQBAQEgETobAgEIGgImAgICJQsVEAIEARKIbA6sAoIpi08BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYEJhTOBfYJdhEkXgm0tgjABBJpLAZBxgXCEd4lAkWUBHje?= =?us-ascii?q?BCx2FIXKHPoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,510,1473120000"; d="scan'208";a="172868054" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 15:01:00 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uAIF100c009221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 15:01:00 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 10:00:59 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 18 Nov 2016 10:00:59 -0500 From: "Jan Medved (jmedved)" To: Julien Meuric , "Pce@ietf.org" Thread-Topic: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce Thread-Index: AQHSQaj8gzun7DU20kStcMI8bdr6ZKDeo4eA Date: Fri, 18 Nov 2016 15:00:59 +0000 Message-ID: References: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> In-Reply-To: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.18.169] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 15:01:08 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0K DQovSmFuDQoNCg0KT24gMTEvMTgvMTYsIDY6MzUgQU0sICJQY2Ugb24gYmVoYWxmIG9mIEp1bGll biBNZXVyaWMiIDxwY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YganVsaWVuLm1ldXJp Y0BvcmFuZ2UuY29tPiB3cm90ZToNCg0KICAgIERlYXIgYXV0aG9ycyBvZiB0aGUgYWZvcmVtZW50 aW9uZWQgSS1ELA0KICAgIA0KICAgIENvdWxkIHlvdSBwbGVhc2Ugc2hhcmUgd2l0aCB0aGUgbWFp bGluZyBsaXN0IHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiANCiAgICBhbnkgSVBSIHRoYXQgYXBw bGllcyB0byBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UgYW5kLCBpZiBzbywgaWYgaXQgDQog ICAgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcz8g KFNlZSBSRkNzIDM5NzksIA0KICAgIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cy4pICBJZiB5b3UgYXJlIG5vdCBhd2FyZSBvZiBhbnkgSVBSIA0KICAgIHRoYXQgYXBwbGllcywg cGxlYXNlIHJlcGx5IHNheWluZyDigJxJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgDQog ICAgYXBwbGllcyB0byB0aGlzIGRyYWZ04oCdLg0KICAgIA0KICAgIA0KICAgIEEgZmVlZGJhY2sg ZnJvbSBlYWNoIG9mIHlvdSBpcyByZXF1aXJlZCB0byBtb3ZlIHRoZSBkb2N1bWVudCB0byB0aGUg SUVTRy4NCiAgICANCiAgICBCZXN0IHJlZ2FyZHMsDQogICAgDQogICAgSm9uLCBKUCAmIEp1bGll bg0KICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgUGNlIG1haWxpbmcgbGlzdA0KICAgIFBjZUBpZXRmLm9yZw0KICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQogICAgDQoNCg== From nobody Fri Nov 18 07:01:33 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF6212958F; Fri, 18 Nov 2016 07:01:32 -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 bX0P4NYpygJr; Fri, 18 Nov 2016 07:01:30 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B24A1295C6; Fri, 18 Nov 2016 07:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1318; q=dns/txt; s=iport; t=1479481290; x=1480690890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hqoFqoEtsTFiOB+uP6Fa2BgpdVOmA8o/GMceTWAea5I=; b=YINC35QqW8n/lp0S9d1BaDmUGCkzaX5aq4FYZqRnqiKKb69IkySXIMiZ pBaoallxVl7APIfIX+dC/sasREhyH8Xsk7FgCwC4GvfGIcEw9RaGHlPlq NjjpfDYCGcX+1vynkWr+5L/qXEd6iI7UJEz81OWPRWQRRAfwUgIzmDvel 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQCeFi9Y/4MNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR9YgQAHjTirdYIHHQuFeQIagXA/FAECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQQBAQEgEToLEAIBCBoCJgICAiULFRACBAENBYhsDqt/gimLTwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFgQmFM4F9gl2ESReCbS2CMAEEmksBkHGBcIR3iUCRZQE?= =?us-ascii?q?eN4ELHYUhcoc+gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,510,1473120000"; d="scan'208";a="175064099" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2016 15:01:29 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAIF1TLl013434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 15:01:29 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 10:01:28 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 18 Nov 2016 10:01:28 -0500 From: "Jan Medved (jmedved)" To: Julien Meuric , "draft-ietf-pce-stateful-pce@ietf.org" Thread-Topic: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce Thread-Index: AQHSQaj8gzun7DU20kStcMI8bdr6ZKDeo6oA Date: Fri, 18 Nov 2016 15:01:28 +0000 Message-ID: <3868916A-D236-44C0-BE20-F1532F4CBE45@cisco.com> References: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> In-Reply-To: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.18.169] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 15:01:32 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0K DQovSmFuDQoNCg0KT24gMTEvMTgvMTYsIDY6MzUgQU0sICJQY2Ugb24gYmVoYWxmIG9mIEp1bGll biBNZXVyaWMiIDxwY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YganVsaWVuLm1ldXJp Y0BvcmFuZ2UuY29tPiB3cm90ZToNCg0KICAgIERlYXIgYXV0aG9ycyBvZiB0aGUgYWZvcmVtZW50 aW9uZWQgSS1ELA0KICAgIA0KICAgIENvdWxkIHlvdSBwbGVhc2Ugc2hhcmUgd2l0aCB0aGUgbWFp bGluZyBsaXN0IHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiANCiAgICBhbnkgSVBSIHRoYXQgYXBw bGllcyB0byBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UgYW5kLCBpZiBzbywgaWYgaXQgDQog ICAgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcz8g KFNlZSBSRkNzIDM5NzksIA0KICAgIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cy4pICBJZiB5b3UgYXJlIG5vdCBhd2FyZSBvZiBhbnkgSVBSIA0KICAgIHRoYXQgYXBwbGllcywg cGxlYXNlIHJlcGx5IHNheWluZyDigJxJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgDQog ICAgYXBwbGllcyB0byB0aGlzIGRyYWZ04oCdLg0KICAgIA0KICAgIA0KICAgIEEgZmVlZGJhY2sg ZnJvbSBlYWNoIG9mIHlvdSBpcyByZXF1aXJlZCB0byBtb3ZlIHRoZSBkb2N1bWVudCB0byB0aGUg SUVTRy4NCiAgICANCiAgICBCZXN0IHJlZ2FyZHMsDQogICAgDQogICAgSm9uLCBKUCAmIEp1bGll bg0KICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgUGNlIG1haWxpbmcgbGlzdA0KICAgIFBjZUBpZXRmLm9yZw0KICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQogICAgDQoNCg== From nobody Tue Nov 22 01:03:01 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E079129500; Tue, 22 Nov 2016 01:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=metaswitch.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 iVQiER5irhB6; Tue, 22 Nov 2016 01:02:57 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0122.outbound.protection.outlook.com [104.47.32.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4758C129A89; Tue, 22 Nov 2016 01:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9wLxcVYv8QXZDRlVX7AaeU7rH0O9msJrWMUI4e4fBe4=; b=Xp6i9Zh8wwbMhfyZaneIaecpsbkbC9EQedazcG3INs5HQPB7lTNWAJKmrnH10iXj+FxboZ/ehGWd2HaBIX1Ho5JYRerm5+FArAnXCmG389w20LY/EDFH7uYVNCoCWsXpQM9JdExRZUQWDzBh+m9U0FC2I3kNGZXafBdZ6r4EBTs= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 09:02:54 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 09:02:54 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: PCE WG meeting minutes available Thread-Index: AdJEnuqdeEZA0wo9QgWnjwHc7SNA9w== Date: Tue, 22 Nov 2016 09:02:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.164.131.250] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1910; 7:xz/4hspox97QSljceEVMcsADaZRxuhIqAMAbjvM5KpZ6AAuZev0CvnFeSWHgfeh0djQ3Soq+MkLN+6ISrUMkpsPmAswmzTnWfbbTN4R9VWg/0je/VLJb9D4nrONNnjsLSjb2AwIORTV9bWgfOQrDNDZGbBjoc6ka5klifhfMUpgWBhncJp9ndCW3Q00DZyy1+H0ZyPHASm5MpVh4DUMVhnNvZsE2+cFazGNxI9N90E+aBwo7n9G1b+kFZywVs49JlkvwZ+F+/QvouJUg1pOtY6n9uu5OXxiIkQS0yQrNjxC1GNjA6d6yDN4vCXIs08Ww1I/aROmI4AdSMD0a5JPjYFHaamhMYjM6TDTfQHFqvZg= x-ms-office365-filtering-correlation-id: 73d45efc-3b25-44d5-ba8c-08d412b6585d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0201MB1910; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(97927398514766)(100405760836317)(95692535739014)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324)(6072148); SRVR:BY2PR0201MB1910; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1910; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(54164003)(43544003)(37854004)(189002)(199003)(3846002)(102836003)(5640700001)(87936001)(33656002)(6116002)(81156014)(81166006)(5660300001)(5630700001)(86362001)(66066001)(76576001)(74316002)(790700001)(3660700001)(2501003)(3280700002)(7696004)(8936002)(450100001)(77096005)(1730700003)(2900100001)(92566002)(54356999)(50986999)(122556002)(110136003)(105586002)(189998001)(99286002)(6916009)(9686002)(106356001)(2906002)(97736004)(606004)(7906003)(68736007)(6506003)(7736002)(7846002)(38730400001)(101416001)(4326007)(8676002)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1910; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19102BAD31651905B51B10BA84B40BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 09:02:53.8364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1910 Archived-At: Cc: "pce-chairs@ietf.org" Subject: [Pce] PCE WG meeting minutes available X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 09:02:59 -0000 --_000_BY2PR0201MB19102BAD31651905B51B10BA84B40BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes for the PCE meeting at IETF 97 are now available. Thanks= to all our scribes! Please let me know if you have any comments or correc= tions. https://www.ietf.org/proceedings/97/minutes/minutes-97-pce-00.txt Best regards Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D PCE Working Group Meeting IETF 97 (Seoul) Working Group Chairs: Julien Meuric (julien.meuric@orange.com) JP Vasseur (jpv@cisco.com) Jonathan Hardwick (jonathan.hardwick@metaswitch.com) Working Group Secretary: Daniel King (daniel@olddog.co.uk) Responsible AD: Deborah Brungard (db3546@att.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Session I Time: November 16, 2016, 13:30-15:00 (1:30pm-3:00pm) Location: Park Ballroom 1, Conrad Seoul, Republic of Korea With thanks to our scribes: - Dhruv Dhody - Yuji Tochio (remote) - Haomian Zheng - Daniel King ---------------------------------------------------------------------------= ---- 1. Introduction --------------- 1.1. Administrivia, Agenda Bashing (chairs, 5 min) (13:30-13:35) [5/90] - The session is being co-chaired by Jon Hardwick and Daniel King. Unfortunately, Julien and JP were unable to travel to the IETF this time. - Agenda bashing: no agenda changes. 1.2. WG Status (chairs, 15 min) (13:35-13:50) [20/90] Adrian Farrel: Can you clarify "No renewal" on the "Early code point allocations" on slide: Documents beyond the WG Jon Hardwick: After requesting early code point allocation, only one renewa= l is permitted. Adrian Farrel: The AD can give special dispensation to renew a second time. Deborah Brungard: Yes, you can ask the IESG to do it. Jon Hardwick: I know that is an avenue we can take, but I very much don't w= ant to take it. I want to finish this work instead. Adrian Farrel: I would very much like to see these documents published as R= FC. Jon Hardwick: The stateful PCE authors have comitted to move within one wee= k. Dhruv Dhody: The [stateful-pce-inter-domain-lsp] I-D is not adopted, it was submitted using a WG doc name by mistake. Himanshu Shah: There is the auto-bandwidth draft we are interested in. We = have asked for WG adoption a few times. Jon Hardwick: Does anyone want to support (at the mic) the auto-bandwidth I= -D, or object to it? Jon Hardwick: The problem was that JP had a significant concern about this draft and emailed the list. Was this resolved? Dhruv Dhody: We replied to JP's comments and thought we addressed the questions. We would like to discuss how to move the I-D forwar= d and request adoption. Jon Hardwick: If JP's concerns have been addressed then we can call for adoption. 2. Work in Progress ------------------- 2.1. PCEP Extension for associating Policies and LSPs https://datatracker.ietf.org/doc/draft-dhody-pce-association-policy/ Dhruv Dhody, 5 min (13:50-13:55) [25/90] Dhruy Dhody: We would like to associate a user-defined policy to a group of LSPs. Adrian Farrel: How does this relate to the signaled policy that RSVP might = use? Also, is there a vendor independent mode capability? Dhruv Dhody: We would like to work with you on this. 2.2. PCEP Extension for LSP Diversity https://datatracker.ietf.org/doc/draft-litkowski-pce-association-diversity/ Stephane Litkowski, 10 min (13:55-14:05) [35/90] Haomian Zheng: This is useful. The resource sharing draft is related to thi= s work. Let's work together. Stephane Litkowski: Yes. Loa Andersson: Regarding the shortest path flag (P), is that strict (lowest= hop count)? George Swallow: If your shortest path won't allow totally disjoint, what wi= ll you get? Stephane Litkowski: Then the PCE can relax the requirement to be totally disjoint, but only if the PCC has indicated that this i= s acceptable by leaving the "strict disjointedness" flag = (S) unset. Daniele Ceccarelli: If you set both P and S flags, and you cannot meet both requiements, can you relax/prioritise one? Stephane Litkowski: It's strict currently, but we can discuss. Adrian Farrel: Please take care to distinguish between this disjointedness constraint and an objective function. We will have an offlin= e discussion. Lou Berger: Have you looked at lsp-diversity draft in CCAMP and now in TEAS= ? Stephane Litkowski: No. Can you send me the pointer? Jon Hardwick: This is good, missing function. I have two comments. 1) Please don't suggest code points in your draft. Before we= can poll for adoption, please remove these code points and sub= mit a new version of the draft. Once adopted, we can proceed = to an IANA early allocation, which is a fast process. 2) If the PCE relaxes the diversity criteria for some of the LSPs, you need a way to tell the PCC which LSPs got relaxe= d. If the PCC gets less than it asked for, then it needs to k= now. Stephane: OK. Himanshu Shah: I particularly agree with Jon's second point. 3. New Work ----------- 3.1. Association-aware Computation https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/ Stephane Litkowski, 10 min (14:05-14:15) [45/90] Danielle Ceccarelli: This is a good solution for a problem that doesn't exi= st. What you need is a PCE server with a good internal reliability mechanism. SDN controllers are already offering this. Stephane Litkowski: We have the problem. We are doing this for resilency, scalability, and to avoid a computation loop. We have = an SDN-like availability solution, which can be issued. Danielle Ceccarelli: You may also have IGP, BGP database issue. Haomian Zheng: Is the role master/slave permanent? Or per LSP? Stephane Litkowski: You can decide it flexibly. Haomian Zheng: If everything is configured manually, it may be controversia= l. Stephane Litkowski: We never say it's the best. Adrian Farrel: In the real world, i.e. non-Unicorn networks, this is good solution for a real problem. Dhruv Dhody: The solution should be applicable to multiple deployment optio= ns: H-PCE, stateful, et al. 3.2. Ability for a stateful PCE to request and obtain control of a LSP https://datatracker.ietf.org/doc/draft-raghu-pce-lsp-control-request/ Dhruv Dhody, 5 min (14:15-14:20) [50/90] Jon Hardwick: (Chair hat off) This seems like useful function to have. Haomian Zheng: How does this work with pce-initiate? Dhruv Dhody: It's applicable if the LSP is orphaned, this is not for creati= ng a new LSP. 3.3. P2MP Updates (RFC 6006bis) https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/ Dhruv Dhody, 5 min (14:20-14:25) [55/90] Jon Hardwick: Should we spin a new RFC or simply submit an errata? George Swallow: Coders are more likely to look at the RBNF than to read the text. They may not notice an errata. I say spin a new RFC. Adrian Farrel: Do both, the WG can publish a bis quickly. Jon Hardwick: Action for Dhruv to enter this in the errata system. 3.4. PCE for Native IP https://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/ https://datatracker.ietf.org/doc/draft-wang-pce-extension-native-ip/ Aijun Wang, 10 min (14:30-14:40) [65/90] Jescia Chen: I have not read this carefully, but I am confused. How do you modify forwarding behavior? There is bgp-flowspec and pce-flowspec. George Swallow: Are you assuming every node in the slides is running BGP? Jon Hardwick: There ia an architecture and solution dicussion to be had fir= st. There is already a TEAS document covering this, so I suggest = you continue to discuss the architecture and use case in TEAS, th= en we can continue the dicussion on solution (PCEP) work if ther= e is consensus in TEAS around this idea. George Swallow: Suggest you also include the IDR WG in the dicussion. 3.5. Connections and Accesses for Hierarchical PCE https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/ Huaimo Chen, 10 min (14:40-14:50) [75/90] Jon Hardwick: Are you implementing this? Huaimo Chen: Not yet, but we are thinking about it. Dhruv Dhody: We have function in PCEP-LS that solves some of the function required. Jon Hardwick: Please continue this dicussion on the list. 3.6. Optical Link-State Distribution in PCEP https://datatracker.ietf.org/doc/draft-lee-pce-pcep-ls-optical/ Young Lee, 10 min (14:50-14:55) [85/90] Jon Hardwick: This work assumes that we have already accepted PCEP-LS. PCEP= -LS has been discussed before, but it's not clear what the suppor= t is from the WG, beyond the existing document authors. We have ha= d negative comments that this work re-invents the function alre= ady in BGP-LS. A question I have is what support do we have in t= he PCE WG for PCEP-LS generally (not just this draft)? Anyone l= ike to voice support in the room? Or anyone not agreeing that we should adopt it? Young Lee: I would remind eveyone that BGP-LS is for packet and we need opt= ical support. Jon Hardwick: Are you saying that BGP-LS lacks TLVs to describe the optical domain, or that the devices you have deployed in the optical domain do not have a BGP stack running on them? Young Lee: It is both. Jon Hardwick: You can fix the lack of optical TLVs in BGP. However, it is harder to see how you can fix the lack of deployment of BGP i= n those networks. Haomian Zheng: We need to make clear what PCEP-LS is competing with. If BGP-LS, unfortunately optical networks don't have BGP and we will fail on IP+Optical without optical PCEP-LS. If competi= ng with other protocols, we need a gap analysis. Currently PCEP= -LS is the only solution for optical. Adrian Farrel: Putting in new TLVs in any protocol is doable; if optical TL= Vs do not exist in BGP-LS then they can always be added. So th= is is not a lever for creating PCEP-LS. The real reason is the lack of BGP in optical deployments. However, if we are look= ing at mechanisms then maybe we also need to consider netconf. Jon Hardwick: We need further dicussion, I'll start a thread on thread in t= he PCE list. 3.7. PCEP Link-State extensions for Segment Routing https://datatracker.ietf.org/doc/draft-li-pce-pcep-ls-sr-extension/ Jiajia Fan, 5 min (14:55-14:60) [90/90] - No comments. End of session 14:59. --_000_BY2PR0201MB19102BAD31651905B51B10BA84B40BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes for the PCE meeting at IETF 97 are= now available.  Thanks to all our scribes!  Please let me know i= f you have any comments or corrections.

https://www.ietf.org/proceedings/97/minutes/minut= es-97-pce-00.txt

 

Best regards

Jon

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

PCE Working Group Meeting

IETF 97 (Seoul)

 

Working Group Chairs:

     Julien Meuric (julien.meuri= c@orange.com)

     JP Vasseur (jpv@cisco.com)<= o:p>

     Jonathan Hardwick (jonathan= .hardwick@metaswitch.com)

 

Working Group Secretary:

     Daniel King (daniel@olddog.= co.uk)

 

Responsible AD:

     Deborah Brungard (db3546@at= t.com)

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Session I

 

Time:

     November 16, 2016, 13:30-15= :00 (1:30pm-3:00pm)

 

Location:

     Park Ballroom 1, Conrad Seo= ul, Republic of Korea

 

With thanks to our scribes:

     - Dhruv Dhody

     - Yuji Tochio (remote)=

     - Haomian Zheng<= /p>

     - Daniel King

 

----------------------------------------------------= ---------------------------

 

1. Introduction

---------------

 

1.1. Administrivia, Agenda Bashing (chairs, 5 min) (= 13:30-13:35) [5/90]

 

-  The session is being co-chaired by Jon Hardw= ick and Daniel King.

  Unfortunately, Julien and JP were unable= to travel to the IETF this time.

-  Agenda bashing: no agenda changes.

 

 

1.2. WG Status (chairs, 15 min) (13:35-13:50) [20/90= ]

 

Adrian Farrel: Can you clarify "No renewal"= ; on the "Early code point

        &nbs= p;      allocations" on slide: Documents beyo= nd the WG

Jon Hardwick: After requesting early code point allo= cation, only one renewal is

        &nbs= p;     permitted.

Adrian Farrel: The AD can give special dispensation = to renew a second time.

Deborah Brungard: Yes, you can ask the IESG to do it= .

Jon Hardwick: I know that is an avenue we can take, = but I very much don't want

        &nbs= p;     to take it.  I want to finish this work ins= tead.

Adrian Farrel: I would very much like to see these d= ocuments published as RFC.

Jon Hardwick: The stateful PCE authors have comitted= to move within one week.

 

Dhruv Dhody: The [stateful-pce-inter-domain-lsp] I-D= is not adopted, it was

        &nbs= p;    submitted using a WG doc name by mistake.

 

Himanshu Shah: There is the auto-bandwidth draft we = are interested in.  We have

        &nbs= p;      asked for WG adoption a few times.

Jon Hardwick: Does anyone want to support (at the mi= c) the auto-bandwidth I-D,

        &nbs= p;     or object to it?

        &nbs= p;     <nobody except authors showed support>

Jon Hardwick: The problem was that JP had a signific= ant concern about this

        &nbs= p;     draft and emailed the list.  Was this resol= ved?

Dhruv Dhody: We replied to JP's comments and thought= we addressed the

        &nbs= p;    questions. We would like to discuss how to move the I-= D forward

        &nbs= p;    and request adoption.

Jon Hardwick: If JP's concerns have been addressed t= hen we can call for

        &nbs= p;     adoption.

 

 

2. Work in Progress

-------------------

 

2.1. PCEP Extension for associating Policies and LSP= s

https://datatracker.ietf.org/doc/draft-dhody-pce-ass= ociation-policy/

Dhruv Dhody, 5 min (13:50-13:55) [25/90]<= /p>

Dhruy Dhody: We would like to associate a user-defin= ed policy to a group of

        &nbs= p;    LSPs.

 

Adrian Farrel: How does this relate to the signaled = policy that RSVP might use?

        &nbs= p;      Also, is there a vendor independent mode c= apability?

Dhruv Dhody: We would like to work with you on this.=

 

 

2.2. PCEP Extension for LSP Diversity

https://datatracker.ietf.org/doc/draft-litkowski-pce= -association-diversity/

Stephane Litkowski, 10 min (13:55-14:05) [35/90]

 

Haomian Zheng: This is useful. The resource sharing = draft is related to this

        &nbs= p;      work. Let's work together.

Stephane Litkowski: Yes.

 

Loa Andersson: Regarding the shortest path flag (P),= is that strict (lowest hop

        &nbs= p;      count)?

 

George Swallow: If your shortest path won't allow to= tally disjoint, what will

        &nbs= p;       you get?

Stephane Litkowski: Then the PCE can relax the requi= rement to be totally

        &nbs= p;           disjoint, bu= t only if the PCC has indicated that this is

        &nbs= p;           acceptable b= y leaving the "strict disjointedness" flag (S)

        &nbs= p;           unset.<= /o:p>

 

Daniele Ceccarelli: If you set both P and S flags, a= nd you cannot meet both

        &nbs= p;           requiements,= can you relax/prioritise one?

Stephane Litkowski: It's strict currently, but we ca= n discuss.

 

Adrian Farrel: Please take care to distinguish betwe= en this disjointedness

        &nbs= p;      constraint and an objective function. We w= ill have an offline

        &nbs= p;      discussion.

 

Lou Berger: Have you looked at lsp-diversity draft i= n CCAMP and now in TEAS?

Stephane Litkowski: No. Can you send me the pointer?=

 

Jon Hardwick: This is good, missing function. I have= two comments.

        &nbs= p;     1) Please don't suggest code points in your draf= t.  Before we can

        &nbs= p;        poll for adoption, please remo= ve these code points and submit

        &nbs= p;        a new version of the draft.&nb= sp; Once adopted, we can proceed to

        &nbs= p;        an IANA early allocation, whic= h is a fast process.

        &nbs= p;     2) If the PCE relaxes the diversity criteria for= some of the

        &nbs= p;        LSPs, you need a way to tell t= he PCC which LSPs got relaxed.

        &nbs= p;        If the PCC gets less than it a= sked for, then it needs to know.

Stephane: OK.

 

Himanshu Shah: I particularly agree with Jon's secon= d point.

 

 

3. New Work

-----------

 

3.1. Association-aware Computation

https://datatracker.ietf.org/doc/draft-litkowski-pce= -state-sync/

Stephane Litkowski, 10 min (14:05-14:15) [45/90]

 

Danielle Ceccarelli: This is a good solution for a p= roblem that doesn't exist.

        &nbs= p;            What y= ou need is a PCE server with a good internal

        &nbs= p;            reliab= ility mechanism.  SDN controllers are already

        &nbs= p;            offeri= ng this.

Stephane Litkowski: We have the problem. We are doin= g this for resilency,

        &nbs= p;           scalability,= and to avoid a computation loop.  We have an

        &nbs= p;           SDN-like ava= ilability solution, which can be issued.

Danielle Ceccarelli: You may also have IGP, BGP data= base issue.

 

Haomian Zheng: Is the role master/slave permanent? O= r per LSP?

Stephane Litkowski:  You can decide it flexibly= .

Haomian Zheng: If everything is configured manually,= it may be controversial.

Stephane Litkowski: We never say it's the best.=

Adrian Farrel: In the real world, i.e. non-Unicorn n= etworks, this is good

        &nbs= p;      solution for a real problem.

Dhruv Dhody: The solution should be applicable to mu= ltiple deployment options:

        &nbs= p;    H-PCE, stateful, et al.

 

 

3.2. Ability for a stateful PCE to request and obtai= n control of a LSP

https://datatracker.ietf.org/doc/draft-raghu-pce-lsp= -control-request/

Dhruv Dhody, 5 min (14:15-14:20) [50/90]<= /p>

 

Jon Hardwick: (Chair hat off) This seems like useful= function to have.

Haomian Zheng: How does this work with pce-initiate?=

Dhruv Dhody: It's applicable if the LSP is orphaned,= this is not for creating a

        &nbs= p;    new LSP.

 

 

3.3. P2MP Updates (RFC 6006bis)

https://datatracker.ietf.org/doc/draft-palleti-pce-r= fc6006bis/

Dhruv Dhody, 5 min (14:20-14:25) [55/90]<= /p>

 

Jon Hardwick: Should we spin a new RFC or simply sub= mit an errata?

George Swallow: Coders are more likely to look at th= e RBNF than to read the

        &nbs= p;       text. They may not notice an errata.= I say spin a new RFC.

Adrian Farrel: Do both, the WG can publish a bis qui= ckly.

Jon Hardwick: Action for Dhruv to enter this in the = errata system.

 

 

3.4. PCE for Native IP

https://datatracker.ietf.org/doc/draft-wang-teas-pce= -native-ip/

https://datatracker.ietf.org/doc/draft-wang-pce-exte= nsion-native-ip/

Aijun Wang, 10 min (14:30-14:40) [65/90]<= /p>

 

Jescia Chen: I have not read this carefully, but I a= m confused. How do you

         &nb= sp;   modify forwarding behavior? There is bgp-flowspec and<= o:p>

        &nbs= p;    pce-flowspec.

George Swallow: Are you assuming every node in the s= lides is running BGP?

Jon Hardwick: There ia an architecture and solution = dicussion to be had first.

        &nbs= p;     There is already a TEAS document covering this, = so I suggest you

        &nbs= p;     continue to discuss the architecture and use cas= e in TEAS, then

        &nbs= p;     we can continue the dicussion on solution (PCEP)= work if there is

        &nbs= p;     consensus in TEAS around this idea.

George Swallow: Suggest you also include the IDR WG = in the dicussion.

 

 

3.5. Connections and Accesses for Hierarchical PCE

https://datatracker.ietf.org/doc/draft-chen-pce-h-co= nnect-access/

Huaimo Chen, 10 min (14:40-14:50) [75/90]=

 

Jon Hardwick: Are you implementing this?<= /p>

Huaimo Chen: Not yet, but we are thinking about it.<= o:p>

Dhruv Dhody: We have function in PCEP-LS that solves= some of the function

        &nbs= p;    required.

Jon Hardwick: Please continue this dicussion on the = list.

 

 

3.6. Optical Link-State Distribution in PCEP

https://datatracker.ietf.org/doc/draft-lee-pce-pcep-= ls-optical/

Young Lee, 10 min (14:50-14:55) [85/90]

 

Jon Hardwick: This work assumes that we have already= accepted PCEP-LS. PCEP-LS

        &nbs= p;     has been discussed before, but it's not clear wh= at the support is

        &nbs= p;     from the WG, beyond the existing document author= s. We have had

        &nbs= p;     negative comments that this work re-invents the = function already

        &nbs= p;     in BGP-LS.  A question I have is what suppo= rt do we have in the

        &nbs= p;     PCE WG for PCEP-LS generally (not just this draf= t)?  Anyone like

        &nbs= p;     to voice support in the room? Or anyone not agre= eing that we

        &nbs= p;     should adopt it?

        &nbs= p;     <Nobody spoke on either side.><= /p>

Young Lee: I would remind eveyone that BGP-LS is for= packet and we need optical

        &nbs= p;  support.

Jon Hardwick: Are you saying that BGP-LS lacks TLVs = to describe the optical

        &nbs= p;     domain, or that the devices you have deployed in= the optical

        &nbs= p;     domain do not have a BGP stack running on them?<= o:p>

Young Lee: It is both.

Jon Hardwick: You can fix the lack of optical TLVs i= n BGP.  However, it is

        &nbs= p;     harder to see how you can fix the lack of deploy= ment of BGP in

        &nbs= p;     those networks.

Haomian Zheng: We need to make clear what PCEP-LS is= competing with.  If

        &nbs= p;      BGP-LS, unfortunately optical networks don= 't have BGP and we

        &nbs= p;      will fail on IP+Optical without optica= l PCEP-LS.  If competing

        &nbs= p;      with other protocols, we need a gap analys= is. Currently PCEP-LS

        &nbs= p;      is the only solution for optical.

Adrian Farrel: Putting in new TLVs in any protocol i= s doable; if optical TLVs

        &nbs= p;      do not exist in BGP-LS then they can alway= s be added.  So this

        &nbs= p;      is not a lever for creating PCEP-LS. = The real reason is the

        &nbs= p;      lack of BGP in optical deployments.  = However, if we are looking

        &nbs= p;      at mechanisms then maybe we also need to c= onsider netconf.

Jon Hardwick: We need further dicussion, I'll start = a thread on thread in the

        &nbs= p;     PCE list.

 

 

3.7. PCEP Link-State extensions for Segment Routing<= o:p>

https://datatracker.ietf.org/doc/draft-li-pce-pcep-l= s-sr-extension/

Jiajia Fan, 5 min (14:55-14:60) [90/90]

 

- No comments.

 

 

End of session 14:59.

 

--_000_BY2PR0201MB19102BAD31651905B51B10BA84B40BY2PR0201MB1910_-- From nobody Tue Nov 22 09:31:35 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2539A1294E3; Tue, 22 Nov 2016 09:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=metaswitch.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 5yahskoMRWjJ; Tue, 22 Nov 2016 09:31:32 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0126.outbound.protection.outlook.com [104.47.33.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1A21294AD; Tue, 22 Nov 2016 09:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PmOkIj+7ET3ay7rvQWY2F3aGycw8+Q6i/QVqJdd54TM=; b=VX+XabHhWwixIgyQDrASzioFVvbLZfEfHkOP0E7oOyiCYpL/Xfba+DlR2rurjwtKtgglnwuD10tD0mbYlzayYBnO1u5spLEi9BJL6gI5WaA1V83lXSxvqHfYnM5dfh91m/AkF6b73vNi56+0mojL679CkBxcPADUjyQl75d9HMc= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 17:31:26 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 17:31:25 +0000 From: Jonathan Hardwick To: "pce@ietf.org" , "draft-ietf-pce-wson-rwa-ext@ietf.org" Thread-Topic: Working group last call (including final IPR check) for draft-ietf-pce-wson-rwa-ext Thread-Index: AdJE5eHDlGqlwZd7R6W/piT+TJWxlg== Date: Tue, 22 Nov 2016 17:31:25 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.164.131.250] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 7:Ot2ctkYaWTxcOMiCcQufqjo5+foQJjWIuKvQsY+Hiw4M2wZavty7zy5lQ/Bh+H33GPTP7V/58JQj5qAguaIm+0mVpA8hU/yGtxf0e9mNYJ45UaJqaNLbnfEE5ldnagBCyIC+PXD4rqyZYOU4BslGraK9w9UzUbkZI0fu59gxeQwYwzenGCnE2829yYJQmLG+Laqwj8f6Asuh3lY4tNK8Vp4JhvcYiN8h6+XDcc9EViOz06aNKn+c1OqOP7hcRgDFMRMxfcvFukBq6miZtDuxtCXugYNYdL2oujFhnUdV/aPSf0VOL1u90hz9jmc5o74FPROfK26UfG65B1I+M0GSOx+CmgVc4rAlUP+P/sTlMDQ= x-ms-office365-filtering-correlation-id: b35b595c-6121-4770-8765-08d412fd62d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6040307)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041248)(6042181)(6072148); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(66654002)(199003)(6116002)(50986999)(3280700002)(122556002)(3660700001)(790700001)(54356999)(99286002)(105586002)(9686002)(8936002)(189998001)(6506003)(606004)(68736007)(106356001)(102836003)(81166006)(81156014)(97736004)(3846002)(5001770100001)(66066001)(5660300001)(8676002)(2906002)(230783001)(2501003)(101416001)(7846002)(74316002)(2900100001)(92566002)(7906003)(7736002)(7696004)(77096005)(86362001)(4326007)(38730400001)(33656002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910189A7BA18375E012C9A584B40BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 17:31:25.7349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Cc: "pce-chairs@ietf.org" Subject: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-wson-rwa-ext X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 17:31:34 -0000 --_000_BY2PR0201MB1910189A7BA18375E012C9A584B40BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear PCE working group, This email starts a working group last call for draft-ietf-pce-wson-rwa-ext= -05. https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/ Please read the document and reply to the PCE mailing list whether you beli= eve this document is ready to be published, or not (including any comments = on why not). The last call will end on Tuesday 6 December. We are also polling for knowledge of any undisclosed IPR that applies to dr= aft-ietf-pce-wson-rwa-ext-05, to ensure that IPR has been disclosed in comp= liance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more det= ails) prior to moving forward. If you are a document author, please respon= d to this email and indicate whether or not you are aware of any relevant u= ndisclosed IPR. The document won't progress without answers from all the au= thors. No IPR disclosures currently exist against this document. Many thanks Jon, Julien and JP --_000_BY2PR0201MB1910189A7BA18375E012C9A584B40BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear PCE working group,

 

This email starts a working group last call for draf= t-ietf-pce-wson-rwa-ext-05.

https://datatracker.ietf.org/doc/draft-ietf-pce-wson-= rwa-ext/

 

Please read the document and reply to the PCE mailin= g list whether you believe this document is ready to be published, or not (= including any comments on why not).  The last call will end on Tuesday 6 December.

 

We are also polling for knowledge of any undisclosed= IPR that applies to draft-ietf-pce-wson-rwa-ext-05, to ensure that IPR has= been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 366= 9 and 5378 for more details) prior to moving forward.  If you are a document author, please respond to t= his email and indicate whether or not you are aware of any relevant undiscl= osed IPR. The document won't progress without answers from all the authors.=   No IPR disclosures currently exist against this document.

 

Many thanks

Jon, Julien and JP

 

 

--_000_BY2PR0201MB1910189A7BA18375E012C9A584B40BY2PR0201MB1910_-- From nobody Thu Nov 24 08:04:23 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC911294E0 for ; Thu, 24 Nov 2016 08:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 D7teBV9xDk_P for ; Thu, 24 Nov 2016 08:04:19 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7012959E for ; Thu, 24 Nov 2016 08:04:19 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB50CE30094 for ; Thu, 24 Nov 2016 17:04:18 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id E388FE3007D for ; Thu, 24 Nov 2016 17:04:18 +0100 (CET) Received: from [10.193.71.173] (10.193.71.173) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Thu, 24 Nov 2016 17:04:18 +0100 To: "pce@ietf.org" From: Julien Meuric Organization: Orange Message-ID: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> Date: Thu, 24 Nov 2016 17:04:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 16:04:21 -0000 Hi all, Though it is a -00, draft-dhody-pce-association-policy already has a long history: thanks to the authors for the common work. During our meeting in Seoul, it received some support from the room. We now want to know whether the list agrees to adopt it as a foundation for a PCE WG document. Please, share your comments on the mailing list. Regards, Julien From nobody Thu Nov 24 13:16:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD21296F2 for ; Thu, 24 Nov 2016 13:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 JS7pIL8PIQ35 for ; Thu, 24 Nov 2016 13:16:53 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 B3BA9129C96 for ; Thu, 24 Nov 2016 13:16:52 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id 3so21925378pgd.0 for ; Thu, 24 Nov 2016 13:16:52 -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=ebB6Rvdx0Dhz3wPRkd98GbcsZ3gWFyXpfDAayjrNYas=; b=tQmP4E3zFnlRSgUXIi9obha2uEEpjJnch1Suf1XA1aZNxRj2MEAZkUmq8zgNa18rHY g0CF6PrMjvntQhz/hNLMB9DH39cL+3A/utnxwer+AYIHYVJguiHtQYWe+Z/V+gb+MuUM 1AHeEjR/Z9Qa6jFLXU2zFox6dG/F7mJPcuPuXHcuG4/oW/rbPXISUAB28ZrrfJE2zKuZ CYzVlDVCs8VZrSS483MS66SDHDPNeV3NR8BQSqzpJqSCv+wjAfsEQNMDlw5CpLDBPaLc kZJXub9IPZB0LDenZb2m4nMVWHB/9BU6+mAfvemjf9Rgn2EP1AfpWZ8m5DQV3R8exT+o ZP+w== 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=ebB6Rvdx0Dhz3wPRkd98GbcsZ3gWFyXpfDAayjrNYas=; b=mbW6m++Ap2GwrhIZ87/Blu0siWaC+9QvRLuDPdQ0fflZnFZLcKeAsRxl15V9HP2qdX fwSrirQ8xWCWWoliyoYQXem8kn+C6DaVIXqBK0wNFQ+CTemmWM+w+sL8UOge993jSAxY HzFf8cz8J4nkIMLEvE0bEahGeX6xGzbszReRq4BUazSdlMdCr6SoKf4nstmMmynwfq7O 7kRQKfqOZduCIM1WtFiQniNezRRhBp6U4r2ksNbD6bHB1EHT0H6TINmPgxsF6uP/F0pZ oXkRvuBOdpqD4JxPZZonFzWraipCQp0WcKV+d1fv/eclnHF6ihf37DClEN3BRULeiWVW huSA== X-Gm-Message-State: AKaTC02B1rGtJQTgU8rqw410Dzzi2QPNN3BfvJ5DliQzH404aNzBdLObWZuKWEM1gpGPGQ== X-Received: by 10.99.154.9 with SMTP id o9mr7736813pge.123.1480022212135; Thu, 24 Nov 2016 13:16:52 -0800 (PST) Received: from [192.168.1.7] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id a24sm46348352pfh.57.2016.11.24.13.16.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 13:16:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14B100) In-Reply-To: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> Date: Thu, 24 Nov 2016 13:16:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6BA679EE-334F-401D-8FA9-D86D53A7E613@gmail.com> References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> To: Julien Meuric Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 21:16:54 -0000 Hi, This is a very much needed addition with variety of use cases, support as co= -author. Regards, Jeff > On Nov 24, 2016, at 08:04, Julien Meuric wrote:= >=20 > Hi all, >=20 > Though it is a -00, draft-dhody-pce-association-policy already has a long h= istory: thanks to the authors for the common work. During our meeting in Seo= ul, it received some support from the room. We now want to know whether the l= ist agrees to adopt it as a foundation for a PCE WG document. > Please, share your comments on the mailing list. >=20 > Regards, >=20 > Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 24 16:19:34 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4D12A075 for ; Thu, 24 Nov 2016 16:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 W-OgGeWDz1OC for ; Thu, 24 Nov 2016 16:19:31 -0800 (PST) Received: from smfilter1.kt.com (unknown [14.63.245.208]) by ietfa.amsl.com (Postfix) with ESMTP id 42A3F12A07F for ; Thu, 24 Nov 2016 16:19:30 -0800 (PST) Received: from external ([147.6.42.86]) by smfilter1.kt.com (1.0) id uAP0Imk00BBC; Fri, 25 Nov 2016 09:18:48 +0900 Received: from localhost.localdomain (localhost [127.0.0.1]) by KTEX1.localdomain (Postfix) with SMTP id 3tPxWX0DRjzPyKh for ; Fri, 25 Nov 2016 09:18:48 +0900 (KST) Received: from MAIL-FRT-02.corp.ktad.kt.com (unknown [147.6.42.85]) by KTEX1.localdomain (Postfix) with ESMTP id 3tPxWW5fvSzPyKD for ; Fri, 25 Nov 2016 09:18:47 +0900 (KST) Received: from MAIL-MBX-05.corp.ktad.kt.com ([10.215.33.75]) by MAIL-FRT-02.corp.ktad.kt.com ([10.215.33.52]) with mapi id 14.03.0210.002; Fri, 25 Nov 2016 09:18:47 +0900 From: =?ks_c_5601-1987?B?udrD4bDJKFRyYW5zcG9ydCBTRE4gUHJvamVjdCk=?= To: "pce@ietf.org" Thread-Topic: Supporting PCEP-LS work as PCE WG's WG item Thread-Index: AdJGsETjBParR/NSTH6wgXfBgXypPw== Date: Fri, 25 Nov 2016 00:18:47 +0000 Message-ID: <64B123AD47B4514BA507B0376760B2848942ED7C@MAIL-MBX-05> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dispnameaddress: peter.park@kt.com x-originating-ip: [10.207.248.48] Content-Type: multipart/alternative; boundary="_000_64B123AD47B4514BA507B0376760B2848942ED7CMAILMBX05_" MIME-Version: 1.0 Archived-At: Subject: [Pce] Supporting PCEP-LS work as PCE WG's WG item X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 00:19:33 -0000 --_000_64B123AD47B4514BA507B0376760B2848942ED7CMAILMBX05_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBleHBlcnRzIG9mIFBDRSBXRywNCg0KSaGvbSBQZXRlciBQYXJrIG9uZSBvZiBhIHNlbmlv ciByZXNlYXJjaGVyIG9mIEtUIEluZnJhIExhYi4NCkR1cmluZyBJRVRGIEImQiBpbiBTZW91bCwg S1QgZGVtb25zdHJhdGVkIHJlc2lsaWVudCBBQ1ROIGFyY2hpdGVjdHVyZSB3aXRoIEVUUkkgYW5k IG90aGVyIHZlbmRvciB1c2luZyBQQ0VQLUxTIHVzaW5nIFBDRVAtTFMgZm9yIHBhY2tldCBvcHRp Y2FsIG5ldHdvcmsgdG8gcXVpY2tseSBkZXRlcm1pbmVkIG5ldHdvcmsgZmFpbHVyZSBhbmQgcmVw b3J0ZWQgdG8gdGhlIE1EU0MgdXNpbmcgUENFUCBSZXBvcnQgbWVjaGFuaXNtLg0KSSBiZWxpZXZl IFBDRVAtTFMgaXMgYW4gaW1wb3J0YW50IHdvcmsgZm9yIHVzLg0KQW5kIEkgc3Ryb25nbHkgc3Vw cG9ydCBQQ0VQLUxTIHRvIGJlIGNvbnNpZGVyZWQgYXMgUENFIFdHoa9zIFdHIGl0ZW0NCg0KVGhh bmsgeW91LA0KUGV0ZXINCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCkRyLiBQZXRlcihDaG9vbmd1bCkgUGFyaw0KU2VuaW9yIFJlc2Vh cmNoZXIgLyBLVCBJbmZyYSBMYWIuDQo0NjMtMSBDaGVvbm1pbmRvbmcgWXVzZW9uZ2d1IERhZWpl b24gS29yZWEoU291dGgpDQpUOiArODIuMTAuMjg3OS43NDYzIC8gRjogKzgyLjQyLjg3MC44MDg5 DQoNCg0KDQrAzCC43sDPwLogwfbBpLXIILz2w+vAzri4wLsgwKfH2CDA27y6tce++sC4uOcsIMHf v+TH0SDBpLq4s6ogwPrA27HHwLsgxvfH1MfPsO0gwNbAuyC89iDA1r3AtM+02S4gvu62sMfRILHH x9EgvvjAzCwgursgua68rb+hIMb3x9S1yCDBpLq4wMcgwPy6ziC2x7TCIMDPus64piC5q7TcwLi3 ziDBpjPA2r+hsNQgsPiwsywguejG9ywgurm75yC2x7TCILvnv+vHz7TCILDNwLsgvvaw3cj3ILHd wfbH1bTPtNkuILi4vuAsILq7ILjewM/AzCDA37j4IMD8vNu1yCCw5r/sLCC5373FwM4gtse0wiC0 57vnv6Egvsu3wcHWvcOw7SwgursguN7Az8C7IMHvvcMgu+jBpsfPv6kgwda9w7HiILnZtvi0z7TZ Lg0KVGhpcyBFLW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZC9v ciBjb3B5cmlnaHQgbWF0ZXJpYWwuIFRoaXMgZW1haWwgaXMgaW50ZW5kZWQgZm9yIHRoZSB1c2Ug b2YgdGhlIGFkZHJlc3NlZSBvbmx5LiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGVtYWlsIGJ5IG1pc3Rh a2UsIHBsZWFzZSBlaXRoZXIgZGVsZXRlIGl0IHdpdGhvdXQgcmVwcm9kdWNpbmcsIGRpc3RyaWJ1 dGluZyBvciByZXRhaW5pbmcgY29waWVzIHRoZXJlb2Ygb3Igbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkuDQo= --_000_64B123AD47B4514BA507B0376760B2848942ED7CMAILMBX05_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Dear experts of PCE WG,

 

I=A1=AFm Peter Park one of a se= nior researcher of KT Infra Lab.

During IETF B&B in Seoul, K= T demonstrated resilient ACTN architecture with ETRI and other vendor using= PCEP-LS using PCEP-LS for packet optical network to quickly determined net= work failure and reported to the MDSC using PCEP Report mechanism.

I believe PCEP-LS is an importa= nt work for us.

And I strongly support PCEP-LS = to be considered as PCE WG=A1=AFs WG item

 

Thank you,

Peter

 

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Dr. Peter(Choongul= ) Park

Senior Researcher = / KT Infra Lab.

463-1 Cheonmindong= Yuseonggu Daejeon Korea(South)

T: +82.10.2879.7463 / F: &#= 43;82.42.870.8089

 

 

=C0=CC =B8=DE=C0=CF=C0=BA =C1=F6=C1=A4=B5=C8 =BC=F6=C3=EB=C0=CE=B8=B8=C0=BB= =C0=A7=C7=D8 =C0=DB=BC=BA=B5=C7=BE=FA=C0=B8=B8=E7, =C1=DF=BF=E4=C7=D1 =C1= =A4=BA=B8=B3=AA =C0=FA=C0=DB=B1=C7=C0=BB =C6=F7=C7=D4=C7=CF=B0=ED =C0=D6=C0= =BB =BC=F6 =C0=D6=BD=C0=B4=CF=B4=D9. =BE=EE=B6=B0=C7=D1 =B1=C7=C7=D1 =BE=F8= =C0=CC, =BA=BB =B9=AE=BC=AD=BF=A1 =C6=F7=C7=D4=B5=C8 =C1=A4=BA=B8=C0=C7 =C0= =FC=BA=CE =B6=C7=B4=C2 =C0=CF=BA=CE=B8=A6 =B9=AB=B4=DC=C0=B8=B7=CE =C1=A63= =C0=DA=BF=A1=B0=D4 =B0=F8=B0=B3, =B9=E8=C6=F7, =BA=B9=BB=E7 =B6=C7=B4=C2 = =BB=E7=BF=EB=C7=CF=B4=C2 =B0=CD=C0=BB =BE=F6=B0=DD=C8=F7 =B1=DD=C1=F6=C7=D5= =B4=CF=B4=D9. =B8=B8=BE=E0, =BA=BB =B8=DE=C0=CF=C0=CC =C0=DF=B8=F8 =C0=FC= =BC=DB=B5=C8 =B0=E6=BF=EC, =B9=DF=BD=C5=C0=CE =B6=C7=B4=C2 =B4=E7=BB=E7=BF= =A1 =BE=CB=B7=C1=C1=D6=BD=C3=B0=ED, =BA=BB =B8=DE=C0=CF=C0=BB =C1=EF=BD=C3 = =BB=E8=C1=A6=C7=CF=BF=A9 =C1=D6=BD=C3=B1=E2 =B9=D9=B6=F8=B4=CF=B4=D9.
This E-mail may contain confidential information and/or copyright material.= This email is intended for the use of the addressee only. If you receive t= his email by mistake, please either delete it without reproducing, distribu= ting or retaining copies thereof or notify the sender immediately.

--_000_64B123AD47B4514BA507B0376760B2848942ED7CMAILMBX05_-- From nobody Thu Nov 24 17:01:22 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10612129412 for ; Thu, 24 Nov 2016 17:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zF2k6HP7hzeu for ; Thu, 24 Nov 2016 17:01:15 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880BA12A0AA for ; Thu, 24 Nov 2016 16:59:35 -0800 (PST) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Nov 2016 09:59:33 +0900 Received: from SMTP1.etri.info ([169.254.1.7]) by SMTP2.etri.info ([10.2.6.31]) with mapi id 14.01.0355.002; Fri, 25 Nov 2016 09:59:33 +0900 From: =?utf-8?B?7Jyk67mI7JiB?= To: =?utf-8?B?67CV7LaY6rG4KFRyYW5zcG9ydCBTRE4gUHJvamVjdCk=?= , "pce@ietf.org" Thread-Topic: Supporting PCEP-LS work as PCE WG's WG item Thread-Index: AdJGsETjBParR/NSTH6wgXfBgXypPwAA4XUc Date: Fri, 25 Nov 2016 00:59:32 +0000 Message-ID: <23C934174FAD8C4EACF66FEFB6AE43392A75FF95@SMTP1.etri.info> References: <64B123AD47B4514BA507B0376760B2848942ED7C@MAIL-MBX-05> In-Reply-To: <64B123AD47B4514BA507B0376760B2848942ED7C@MAIL-MBX-05> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.28.42] Content-Type: multipart/alternative; boundary="_000_23C934174FAD8C4EACF66FEFB6AE43392A75FF95SMTP1etriinfo_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Supporting PCEP-LS work as PCE WG's WG item X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 01:01:21 -0000 --_000_23C934174FAD8C4EACF66FEFB6AE43392A75FF95SMTP1etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KV2UgaGF2ZSBpbXBsZW1lbnRlZCBQQ0VQLUxTIGZvciBwYWNrZXQgb3B0aWNhbCBu ZXR3b3JrIHdoaWNoIHdhcyBkZW1vbnN0cmF0ZWQgaW4gSUVURiA5NyBCJkIuIFRoZSBpbnRlci1v cGVyYWJpbGl0eSBvZiBQQ0VQLUxTIHdhcyBkZW1vbnN0cmF0ZWQgYWNyb3NzIEVUUkksIEtUIGFu ZCBXb29yaS1OZXQuIEkgc3VwcG9ydCBQQ0VQLUxTIHRvIGJlIGFkb3B0ZWQgaW4gdGhlIFBDRSBX Ry4NCg0KDQpXZSB0aGluayB0aGF0IFBDRVAgY2FuIHByb3ZpZGUgb25lIG9mIHdheXMgdG8gaW1w bGVtZW50IGFsbCBvZiB0aGUgbWFpbiBmdW5jdGlvbnMgb2YgU0ROIGNvbnRyb2xsZXIuDQoNClNv LCB3ZSB3YW50IFBDRSBXRyB0byBwcm92aWRlIGEgdG90YWwgc29sdXRpb24gdG8gaW1wbGVtZW50 IFNETiBjb250cm9sbGVyIGFzIG11Y2ggYXMgaXQgY2FuDQoNCnJhdGhlciB0aGFuIHVzaW5nIG90 aGVyIFdHJ3MgcHJvdG9jb2xzIHN1Y2ggYXMgQkdQLUxTLg0KDQoNClRoYW5rcy4NCg0KQkluDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuuztOuCuCDsgqzrnowgOiAi67CV 7LaY6rG4KFRyYW5zcG9ydCBTRE4gUHJvamVjdCkiIDxwZXRlci5wYXJrQGt0LmNvbT4NCuuztOuC uCDrgqDsp5wgOiAyMDE2LTExLTI1IDA5OjE5OjQyICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowg OiBwY2VAaWV0Zi5vcmcgPHBjZUBpZXRmLm9yZz4NCuywuOyhsCA6DQrsoJzrqqkgOiBbUGNlXSBT dXBwb3J0aW5nIFBDRVAtTFMgd29yayBhcyBQQ0UgV0cncyBXRyBpdGVtDQoNCg0KRGVhciBleHBl cnRzIG9mIFBDRSBXRywNCknigJltIFBldGVyIFBhcmsgb25lIG9mIGEgc2VuaW9yIHJlc2VhcmNo ZXIgb2YgS1QgSW5mcmEgTGFiLg0KRHVyaW5nIElFVEYgQiZCIGluIFNlb3VsLCBLVCBkZW1vbnN0 cmF0ZWQgcmVzaWxpZW50IEFDVE4gYXJjaGl0ZWN0dXJlIHdpdGggRVRSSSBhbmQgb3RoZXIgdmVu ZG9yIHVzaW5nIFBDRVAtTFMgdXNpbmcgUENFUC1MUyBmb3IgcGFja2V0IG9wdGljYWwgbmV0d29y ayB0byBxdWlja2x5IGRldGVybWluZWQgbmV0d29yayBmYWlsdXJlIGFuZCByZXBvcnRlZCB0byB0 aGUgTURTQyB1c2luZyBQQ0VQIFJlcG9ydCBtZWNoYW5pc20uDQpJIGJlbGlldmUgUENFUC1MUyBp cyBhbiBpbXBvcnRhbnQgd29yayBmb3IgdXMuDQpBbmQgSSBzdHJvbmdseSBzdXBwb3J0IFBDRVAt TFMgdG8gYmUgY29uc2lkZXJlZCBhcyBQQ0UgV0figJlzIFdHIGl0ZW0NClRoYW5rIHlvdSwNClBl dGVyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KRHIuIFBldGVyKENob29uZ3VsKSBQYXJrDQpTZW5pb3IgUmVzZWFyY2hlciAvIEtUIElu ZnJhIExhYi4NCjQ2My0xIENoZW9ubWluZG9uZyBZdXNlb25nZ3UgRGFlamVvbiBLb3JlYShTb3V0 aCkNClQ6ICs4Mi4xMC4yODc5Ljc0NjMgLyBGOiArODIuNDIuODcwLjgwODkNCg0KDQoNCg0K7J20 IOuplOydvOydgCDsp4DsoJXrkJwg7IiY7Leo7J2466eM7J2EIOychO2VtCDsnpHshLHrkJjsl4js nLzrqbAsIOykkeyalO2VnCDsoJXrs7Trgpgg7KCA7J6R6raM7J2EIO2PrO2VqO2VmOqzoCDsnojs nYQg7IiYIOyeiOyKteuLiOuLpC4g7Ja065ag7ZWcIOq2jO2VnCDsl4bsnbQsIOuzuCDrrLjshJzs l5Ag7Y+s7ZWo65CcIOygleuztOydmCDsoITrtoAg65iQ64qUIOydvOu2gOulvCDrrLTri6jsnLzr oZwg7KCcM+yekOyXkOqyjCDqs7XqsJwsIOuwsO2PrCwg67O17IKsIOuYkOuKlCDsgqzsmqntlZjr ipQg6rKD7J2EIOyXhOqyqe2eiCDquIjsp4Dtlanri4jri6QuIOunjOyVvSwg67O4IOuplOydvOyd tCDsnpjrqrsg7KCE7Iah65CcIOqyveyasCwg67Cc7Iug7J24IOuYkOuKlCDri7nsgqzsl5Ag7JWM 66Ck7KO87Iuc6rOgLCDrs7gg66mU7J287J2EIOymieyLnCDsgq3soJztlZjsl6wg7KO87Iuc6riw IOuwlOuejeuLiOuLpC4NCg0KDQoNClRoaXMgRS1tYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiBhbmQvb3IgY29weXJpZ2h0IG1hdGVyaWFsLiBUaGlzIGVtYWlsIGlzIGlu dGVuZGVkIGZvciB0aGUgdXNlIG9mIHRoZSBhZGRyZXNzZWUgb25seS4gSWYgeW91IHJlY2VpdmUg dGhpcyBlbWFpbCBieSBtaXN0YWtlLCBwbGVhc2UgZWl0aGVyIGRlbGV0ZSBpdCB3aXRob3V0IHJl cHJvZHVjaW5nLCBkaXN0cmlidXRpbmcgb3IgcmV0YWluaW5nIGNvcGllcyB0aGVyZW9mIG9yIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5Lg0K --_000_23C934174FAD8C4EACF66FEFB6AE43392A75FF95SMTP1etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij5IaSw8 L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxicj4N CjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PHNw YW4gc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgQ09MT1I6IHJnYigzMSw3MywxMjUpIj5XZSBoYXZl IGltcGxlbWVudGVkIFBDRVAtTFMgZm9yIHBhY2tldCBvcHRpY2FsIG5ldHdvcmsgd2hpY2ggd2Fz IGRlbW9uc3RyYXRlZCBpbiBJRVRGIDk3IEImYW1wO0IuIFRoZSBpbnRlci1vcGVyYWJpbGl0eSBv ZiBQQ0VQLUxTDQogd2FzIGRlbW9uc3RyYXRlZCBhY3Jvc3MgRVRSSSwgS1QgYW5kIFdvb3JpLU5l dC4gSSBzdXBwb3J0IFBDRVAtTFMgdG8gYmUgYWRvcHRlZCBpbiB0aGUgUENFIFdHLjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxzcGFu IHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiAmcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IENPTE9SOiByZ2IoMzEsNzMsMTI1KSI+PGJyPg0KPC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgQ09MT1I6IHJnYigzMSw3MywxMjUpIj5XZSZu YnNwO3RoaW5rIHRoYXQgUENFUCBjYW4gcHJvdmlkZSBvbmUgb2Ygd2F5cyB0byBpbXBsZW1lbnQg YWxsIG9mIHRoZSBtYWluIGZ1bmN0aW9ucyBvZiBTRE4gY29udHJvbGxlci48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48c3BhbiBzdHls ZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBDT0xPUjogcmdiKDMxLDczLDEyNSkiPlNvLCB3ZSB3YW50IFBD RSBXRyZuYnNwO3RvIHByb3ZpZGUgYSB0b3RhbCBzb2x1dGlvbiB0byBpbXBsZW1lbnQgU0ROIGNv bnRyb2xsZXIgYXMgbXVjaCBhcyBpdCBjYW48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1C T1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0 OyBGT05ULUZBTUlMWTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBDT0xPUjogcmdiKDMxLDczLDEyNSkiPnJhdGhlciB0aGFuIHVzaW5nIG90aGVyIFdHJ3MgcHJv dG9jb2xzIHN1Y2ggYXMgQkdQLUxTLjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZP TlQtRkFNSUxZOiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IENP TE9SOiByZ2IoMzEsNzMsMTI1KSI+PGJyPg0KPC9zcGFuPjwvcD4NCjxkaXYgaWQ9Ik1haWxTaWdu U2VudCI+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPlRo YW5rcy48L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgi PkJJbjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ PGJyPg0KPC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJPUkdNQUlMX0NPTlRFTlQiPg0KPGhyIHRhYmlu ZGV4PSItMSI+DQo8ZGl2PjxiPuuztOuCuCDsgqzrnowgOiA8L2I+JnF1b3Q767CV7LaY6rG4KFRy YW5zcG9ydCBTRE4gUHJvamVjdCkmcXVvdDsgJmx0O3BldGVyLnBhcmtAa3QuY29tJmd0OzwvZGl2 Pg0KPGRpdj48Yj7rs7Trgrgg64Kg7KecIDogPC9iPjIwMTYtMTEtMjUgMDk6MTk6NDIgKCAmIzQz OzA5OjAwICk8L2Rpdj4NCjxkaXY+PGI+67Cb64qUIOyCrOuejCA6IDwvYj5wY2VAaWV0Zi5vcmcg Jmx0O3BjZUBpZXRmLm9yZyZndDs8L2Rpdj4NCjxkaXY+PGI+7LC47KGwIDogPC9iPjwvZGl2Pg0K PGRpdj48Yj7soJzrqqkgOiA8L2I+W1BjZV0gU3VwcG9ydGluZyBQQ0VQLUxTIHdvcmsgYXMgUENF IFdHJ3MgV0cgaXRlbTwvZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lO LVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4 Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBleHBlcnRzIG9mIFBDRSBXRyw8IS0tP3htbDpuYW1l c3BhY2UgcHJlZml4ID0gIm8iIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl Om9mZmljZSIgLy0tPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PHNwYW4gbGFu Zz0iRU4tVVMiPknigJltIFBldGVyIFBhcmsgb25lIG9mIGEgc2VuaW9yIHJlc2VhcmNoZXIgb2Yg S1QgSW5mcmEgTGFiLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxzcGFuIGxhbmc9IkVOLVVTIj5EdXJp bmcgSUVURiBCJmFtcDtCIGluIFNlb3VsLCBLVCBkZW1vbnN0cmF0ZWQgcmVzaWxpZW50IEFDVE4g YXJjaGl0ZWN0dXJlIHdpdGggRVRSSSBhbmQgb3RoZXIgdmVuZG9yIHVzaW5nIFBDRVAtTFMgdXNp bmcgUENFUC1MUyBmb3IgcGFja2V0IG9wdGljYWwgbmV0d29yayB0byBxdWlja2x5IGRldGVybWlu ZWQNCiBuZXR3b3JrIGZhaWx1cmUgYW5kIHJlcG9ydGVkIHRvIHRoZSBNRFNDIHVzaW5nIFBDRVAg UmVwb3J0IG1lY2hhbmlzbS48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48c3BhbiBsYW5nPSJFTi1VUyI+ SSBiZWxpZXZlIFBDRVAtTFMgaXMgYW4gaW1wb3J0YW50IHdvcmsgZm9yIHVzLjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4t VE9QOiAwcHgiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmQgSSBzdHJvbmdseSBzdXBwb3J0IFBDRVAt TFMgdG8gYmUgY29uc2lkZXJlZCBhcyBQQ0UgV0figJlzIFdHIGl0ZW08L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDog MHB4Ij48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UsPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJ Ti1UT1A6IDBweCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBldGVyPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgVEVY VC1BTElHTjogbGVmdDsgTUFSR0lOLVRPUDogMHB4IiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9IkZPTlQtRkFNSUxZOiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsg VEVYVC1BTElHTjogbGVmdDsgTUFSR0lOLVRPUDogMHB4IiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtRkFNSUxZOiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ RHIuIFBldGVyKENob29uZ3VsKSBQYXJrPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IFRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTi1UT1A6 IDBweCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULUZBTUlM WTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbmlvciBSZXNlYXJjaGVyIC8gS1QgSW5mcmEg TGFiLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU4tVE9QOiAwcHgiIGFsaWduPSJsZWZ0Ij4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij40NjMtMSBDaGVvbm1pbmRvbmcgWXVzZW9uZ2d1IERhZWplb24gS29yZWEoU291dGgp PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+PHNwYW4gbGFuZz0iRU4tVVMiPlQ6ICYjNDM7ODIuMTAuMjg3 OS43NDYzIC8gRjogJiM0Mzs4Mi40Mi44NzAuODA4OTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjwvcD4N CjwvZGl2Pg0KJm5ic3A7DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9Q OiAwcHgiPiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9IkJPUkRFUi1UT1A6IHJnYigwLDUxLDUxKSAx cHggZG90dGVkOyBCT1JERVItUklHSFQ6IHJnYigwLDUxLDUxKSAxcHggZG90dGVkOyBCT1JERVIt Qk9UVE9NOiByZ2IoMCw1MSw1MSkgMXB4IGRvdHRlZDsgUEFERElORy1CT1RUT006IDAuOGVtOyBQ QURESU5HLVRPUDogMC44ZW07IFBBRERJTkctTEVGVDogMC44ZW07IEJPUkRFUi1MRUZUOiByZ2Io MCw1MSw1MSkgMXB4IGRvdHRlZDsgUEFERElORy1SSUdIVDogMC44ZW07IEJBQ0tHUk9VTkQtQ09M T1I6IHdoaXRlOyBib3JkZXItaW1hZ2U6IG5vbmUiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006 IDBweDsgRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiAmcXVvdDtDYW1icmlhJnF1b3Q7LCZx dW90O3RpbWVzIHJvbWFuJnF1b3Q7LHNlcmlmOyBDT0xPUjogcmdiKDE1MywxNTMsMTUzKTsgTUFS R0lOLVRPUDogMHB4OyBMSU5FLUhFSUdIVDogMTBwdCI+DQrsnbQg66mU7J287J2AIOyngOygleuQ nCDsiJjst6jsnbjrp4zsnYQg7JyE7ZW0IOyekeyEseuQmOyXiOycvOupsCwg7KSR7JqU7ZWcIOyg leuztOuCmCDsoIDsnpHqtozsnYQg7Y+s7ZWo7ZWY6rOgIOyeiOydhCDsiJgg7J6I7Iq164uI64uk LiDslrTrlqDtlZwg6raM7ZWcIOyXhuydtCwg67O4IOusuOyEnOyXkCDtj6ztlajrkJwg7KCV67O0 7J2YIOyghOu2gCDrmJDripQg7J2867aA66W8IOustOuLqOycvOuhnCDsoJwz7J6Q7JeQ6rKMIOqz teqwnCwg67Cw7Y+sLCDrs7Xsgqwg65iQ64qUIOyCrOyaqe2VmOuKlCDqsoPsnYQg7JeE6rKp7Z6I IOq4iOyngO2VqeuLiOuLpC4g66eM7JW9LCDrs7gg66mU7J287J20IOyemOuquyDsoITshqHrkJwg 6rK97JqwLCDrsJzsi6Dsnbgg65iQ64qUIOuLueyCrOyXkCDslYzroKTso7zsi5zqs6AsIOuzuCDr qZTsnbzsnYQg7KaJ7IucIOyCreygnO2VmOyXrCDso7zsi5zquLAg67CU656N64uI64ukLg0KPC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8 L3A+DQpUaGlzIEUtbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5k L29yIGNvcHlyaWdodCBtYXRlcmlhbC4gVGhpcyBlbWFpbCBpcyBpbnRlbmRlZCBmb3IgdGhlIHVz ZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuIElmIHlvdSByZWNlaXZlIHRoaXMgZW1haWwgYnkgbWlz dGFrZSwgcGxlYXNlIGVpdGhlciBkZWxldGUgaXQgd2l0aG91dCByZXByb2R1Y2luZywgZGlzdHJp YnV0aW5nIG9yIHJldGFpbmluZyBjb3BpZXMgdGhlcmVvZg0KIG9yIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5Lg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDog MHB4Ij48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_23C934174FAD8C4EACF66FEFB6AE43392A75FF95SMTP1etriinfo_-- From nobody Fri Nov 25 00:42:53 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE2812A240 for ; Fri, 25 Nov 2016 00:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wMb9HvZnPJFJ for ; Fri, 25 Nov 2016 00:42:47 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id C81F8129662 for ; Fri, 25 Nov 2016 00:42:46 -0800 (PST) Received: from WeiWang (unknown [98.238.242.119]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0B40419F383 for ; Fri, 25 Nov 2016 16:42:44 +0800 (HKT) Date: Fri, 25 Nov 2016 00:42:40 -0800 From: "weiw" To: "pce@ietf.org" In-Reply-To: <23C934174FAD8C4EACF66FEFB6AE43392A75FF95@SMTP1.etri.info> References: <64B123AD47B4514BA507B0376760B2848942ED7C@MAIL-MBX-05> <23C934174FAD8C4EACF66FEFB6AE43392A75FF95@SMTP1.etri.info> X-Mailer: NetEase FlashMail 2.4.1.30 X-Priority: 3 (Normal) MIME-Version: 1.0 Message-ID: <5837F97C.5050101@bupt.edu.cn> Content-Type: multipart/alternative; boundary="NetEase-FlashMail-003-ce3c5611-2310-49ff-9823-a2eb1ac9972d" Archived-At: Subject: Re: [Pce] Supporting PCEP-LS work as PCE WG's WG item X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 08:42:52 -0000 --NetEase-FlashMail-003-ce3c5611-2310-49ff-9823-a2eb1ac9972d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUENFIFdHLA0KDQpJIGFtIFdlaSBXYW5nIGZyb20gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBv c3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMoQlVQVCkuDQoNCldlIGltcGxlbWVudGVkIFBDRVAt TFMgZm9yIG9wdGljYWwgdG8gZGlzY292ZXIgbmV0d29yayByZXNvdXJjZSBpbmZvcm1hdGlvbiBm cm9tIG9wdGljYWwgZGV2aWNlIGRpcmVjdGx5IGluIFNCSSBhcyBzcGVjaWZpZWQgaW4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxlZS1wY2UtcGNlcC1scy1vcHRpY2FsLTAwIC4g SSB0aGluayBQQ0VQLUxTIGlzIGEgcHJvbWlzaW5nIHByb3RvY29sIGZvciBjZW50cmFsaXplZCBj b250cm9sIG5ldHdvcmtzLiBJIGFsc28gc3VwcG9ydCB0aGlzIHdvcmsgdG8gcHJvZ3Jlc3MgaW4g UENFIFdHLg0KDQpUaGFua3MgJiBCZXN0IFJlZ2FyZHMsDQpXZWkNCg0KDQoNCuWPkeS7tuS6uu+8 muycpOu5iOyYgSA8Ynl5dW5AZXRyaS5yZS5rcj4NCuWPkemAgeaXtumXtO+8mjIwMTYtMTEtMjQg MTY6NTkNCuS4u+mimO+8mlJlOiBbUGNlXSBTdXBwb3J0aW5nIFBDRVAtTFMgd29yayBhcyBQQ0Ug V0cncyBXRyBpdGVtDQrmlLbku7bkurrvvJoi67CV7LaY6rG4IjxwZXRlci5wYXJrQGt0LmNvbT4s InBjZUBpZXRmLm9yZyI8cGNlQGlldGYub3JnPg0K5oqE6YCB77yaDQoNCkhpLA0KDQoNCldlIGhh dmUgaW1wbGVtZW50ZWQgUENFUC1MUyBmb3IgcGFja2V0IG9wdGljYWwgbmV0d29yayB3aGljaCB3 YXMgZGVtb25zdHJhdGVkIGluIElFVEYgOTcgQiZCLiBUaGUgaW50ZXItb3BlcmFiaWxpdHkgb2Yg UENFUC1MUyB3YXMgZGVtb25zdHJhdGVkIGFjcm9zcyBFVFJJLCBLVCBhbmQgV29vcmktTmV0LiBJ IHN1cHBvcnQgUENFUC1MUyB0byBiZSBhZG9wdGVkIGluIHRoZSBQQ0UgV0cuDQoNCg0KV2UgdGhp bmsgdGhhdCBQQ0VQIGNhbiBwcm92aWRlIG9uZSBvZiB3YXlzIHRvIGltcGxlbWVudCBhbGwgb2Yg dGhlIG1haW4gZnVuY3Rpb25zIG9mIFNETiBjb250cm9sbGVyLg0KU28sIHdlIHdhbnQgUENFIFdH IHRvIHByb3ZpZGUgYSB0b3RhbCBzb2x1dGlvbiB0byBpbXBsZW1lbnQgU0ROIGNvbnRyb2xsZXIg YXMgbXVjaCBhcyBpdCBjYW4NCnJhdGhlciB0aGFuIHVzaW5nIG90aGVyIFdHJ3MgcHJvdG9jb2xz IHN1Y2ggYXMgQkdQLUxTLg0KDQoNClRoYW5rcy4NCkJJbg0KDQoNCg0KDQoNCuuztOuCuCDsgqzr nowgOiAi67CV7LaY6rG4KFRyYW5zcG9ydCBTRE4gUHJvamVjdCkiIDxwZXRlci5wYXJrQGt0LmNv bT4NCuuztOuCuCDrgqDsp5wgOiAyMDE2LTExLTI1IDA5OjE5OjQyICggKzA5OjAwICkNCuuwm+uK lCDsgqzrnowgOiBwY2VAaWV0Zi5vcmcgPHBjZUBpZXRmLm9yZz4NCuywuOyhsCA6IA0K7KCc66qp IDogW1BjZV0gU3VwcG9ydGluZyBQQ0VQLUxTIHdvcmsgYXMgUENFIFdHJ3MgV0cgaXRlbQ0KDQpE ZWFyIGV4cGVydHMgb2YgUENFIFdHLA0KSeKAmW0gUGV0ZXIgUGFyayBvbmUgb2YgYSBzZW5pb3Ig cmVzZWFyY2hlciBvZiBLVCBJbmZyYSBMYWIuDQpEdXJpbmcgSUVURiBCJkIgaW4gU2VvdWwsIEtU IGRlbW9uc3RyYXRlZCByZXNpbGllbnQgQUNUTiBhcmNoaXRlY3R1cmUgd2l0aCBFVFJJIGFuZCBv dGhlciB2ZW5kb3IgdXNpbmcgUENFUC1MUyB1c2luZyBQQ0VQLUxTIGZvciBwYWNrZXQgb3B0aWNh bCBuZXR3b3JrIHRvIHF1aWNrbHkgZGV0ZXJtaW5lZCBuZXR3b3JrIGZhaWx1cmUgYW5kIHJlcG9y dGVkIHRvIHRoZSBNRFNDIHVzaW5nIFBDRVAgUmVwb3J0IG1lY2hhbmlzbS4NCkkgYmVsaWV2ZSBQ Q0VQLUxTIGlzIGFuIGltcG9ydGFudCB3b3JrIGZvciB1cy4NCkFuZCBJIHN0cm9uZ2x5IHN1cHBv cnQgUENFUC1MUyB0byBiZSBjb25zaWRlcmVkIGFzIFBDRSBXR+KAmXMgV0cgaXRlbQ0KVGhhbmsg eW91LA0KUGV0ZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpEci4gUGV0ZXIoQ2hvb25ndWwpIFBhcmsNClNlbmlvciBSZXNlYXJjaGVy IC8gS1QgSW5mcmEgTGFiLg0KNDYzLTEgQ2hlb25taW5kb25nIFl1c2VvbmdndSBEYWVqZW9uIEtv cmVhKFNvdXRoKQ0KVDogKzgyLjEwLjI4NzkuNzQ2MyAvIEY6ICs4Mi40Mi44NzAuODA4OQ0KICAN Cg0K7J20IOuplOydvOydgCDsp4DsoJXrkJwg7IiY7Leo7J2466eM7J2EIOychO2VtCDsnpHshLHr kJjsl4jsnLzrqbAsIOykkeyalO2VnCDsoJXrs7Trgpgg7KCA7J6R6raM7J2EIO2PrO2VqO2VmOqz oCDsnojsnYQg7IiYIOyeiOyKteuLiOuLpC4g7Ja065ag7ZWcIOq2jO2VnCDsl4bsnbQsIOuzuCDr rLjshJzsl5Ag7Y+s7ZWo65CcIOygleuztOydmCDsoITrtoAg65iQ64qUIOydvOu2gOulvCDrrLTr i6jsnLzroZwg7KCcM+yekOyXkOqyjCDqs7XqsJwsIOuwsO2PrCwg67O17IKsIOuYkOuKlCDsgqzs mqntlZjripQg6rKD7J2EIOyXhOqyqe2eiCDquIjsp4Dtlanri4jri6QuIOunjOyVvSwg67O4IOup lOydvOydtCDsnpjrqrsg7KCE7Iah65CcIOqyveyasCwg67Cc7Iug7J24IOuYkOuKlCDri7nsgqzs l5Ag7JWM66Ck7KO87Iuc6rOgLCDrs7gg66mU7J287J2EIOymieyLnCDsgq3soJztlZjsl6wg7KO8 7Iuc6riwIOuwlOuejeuLiOuLpC4gDQoNClRoaXMgRS1tYWlsIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBhbmQvb3IgY29weXJpZ2h0IG1hdGVyaWFsLiBUaGlzIGVtYWlsIGlz IGludGVuZGVkIGZvciB0aGUgdXNlIG9mIHRoZSBhZGRyZXNzZWUgb25seS4gSWYgeW91IHJlY2Vp dmUgdGhpcyBlbWFpbCBieSBtaXN0YWtlLCBwbGVhc2UgZWl0aGVyIGRlbGV0ZSBpdCB3aXRob3V0 IHJlcHJvZHVjaW5nLCBkaXN0cmlidXRpbmcgb3IgcmV0YWluaW5nIGNvcGllcyB0aGVyZW9mIG9y IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LiA= --NetEase-FlashMail-003-ce3c5611-2310-49ff-9823-a2eb1ac9972d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04IiBodHRwLWVxdWl2PWNvbnRlbnQtdHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRl bnQ9Ik1TSFRNTCAxMC4wMC45MjAwLjE2Mzg0Ij48IS0tIGZsYXNobWFpbCBzdHlsZSBiZWdpbiAt LT4NCjxTVFlMRSB0eXBlPXRleHQvY3NzPgpib2R5IHtib3JkZXItd2lkdGg6MDttYXJnaW46MH0K aW1nIHtib3JkZXI6MDttYXJnaW46MDtwYWRkaW5nOjB9CjwvU1RZTEU+DQo8QkFTRSB0YXJnZXQ9 X2JsYW5rPjwhLS0gZmxhc2htYWlsIHN0eWxlIGVuZCAtLT48L0hFQUQ+DQo8Qk9EWSANCnN0eWxl PSJCT1JERVItTEVGVC1XSURUSDogMHB4OyBGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6 IOW+rui9r+mbhem7kTsgQk9SREVSLVJJR0hULVdJRFRIOiAwcHg7IEJPUkRFUi1CT1RUT00tV0lE VEg6IDBweDsgQ09MT1I6ICMwMDAwMDA7IE1BUkdJTjogMTJweDsgTElORS1IRUlHSFQ6IDEuNTsg Qk9SREVSLVRPUC1XSURUSDogMHB4IiANCm1hcmdpbndpZHRoPSIwIiBtYXJnaW5oZWlnaHQ9IjAi Pg0KPERJVj5IaSBQQ0UgV0csPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGFtIFdl aSBXYW5nIGZyb20gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCANClRlbGVjb21tdW5p Y2F0aW9ucyhCVVBUKS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPldlIGltcGxlbWVu dGVkIFBDRVAtTFMgZm9yIG9wdGljYWwgdG8gZGlzY292ZXIgbmV0d29yayByZXNvdXJjZSBpbmZv cm1hdGlvbiANCmZyb20gb3B0aWNhbCBkZXZpY2UgZGlyZWN0bHkgaW4gU0JJIGFzIHNwZWNpZmll ZCBpbiA8QSANCmhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWUtcGNl LXBjZXAtbHMtb3B0aWNhbC0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxl ZS1wY2UtcGNlcC1scy1vcHRpY2FsLTAwPC9BPiANCi4gSSB0aGluayZuYnNwO1BDRVAtTFMgaXMg YSBwcm9taXNpbmcgcHJvdG9jb2wgZm9yIGNlbnRyYWxpemVkIGNvbnRyb2wgDQpuZXR3b3Jrcy4m bmJzcDtJIGFsc28gc3VwcG9ydCB0aGlzIHdvcmsgdG8gcHJvZ3Jlc3MgaW4gUENFIFdHLjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzICZhbXA7IEJlc3QgUmVnYXJkcyw8L0RJ Vj4NCjxESVY+V2VpPC9ESVY+DQo8SFIgDQpzdHlsZT0iQk9SREVSLVRPUDogI2MwYzBjMCAxcHgg c29saWQ7IEhFSUdIVDogMXB4OyBCT1JERVItUklHSFQ6IDBweDsgQk9SREVSLUJPVFRPTTogMHB4 OyBCT1JERVItTEVGVDogMHB4Ij4NCg0KPEJMT0NLUVVPVEUgaWQ9bnRlcy1mbGFzaG1haWwtcXVv dGUgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgUEFERElO Ry1MRUZUOiAwcHg7IE1BUkdJTi1MRUZUOiAwcHgiPg0KICA8RElWPjxTVFJPTkc+5Y+R5Lu25Lq6 77yaPC9TVFJPTkc+7Jyk67mI7JiBICZsdDtieXl1bkBldHJpLnJlLmtyJmd0OzwvRElWPg0KICA8 RElWPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+MjAxNi0xMS0yNCZuYnNwOzE2OjU5 PC9ESVY+DQogIDxESVY+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz5SZTogW1BjZV0gU3VwcG9y dGluZyBQQ0VQLUxTIHdvcmsgYXMgUENFIFdHJ3MgV0cgDQogIGl0ZW08L0RJVj4NCiAgPERJVj48 U1RST05HPuaUtuS7tuS6uu+8mjwvU1RST05HPiLrsJXstpjqsbgiJmx0O3BldGVyLnBhcmtAa3Qu Y29tJmd0OywicGNlQGlldGYub3JnIiZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PC9ESVY+DQogIDxESVY+ PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAg PERJVj4NCiAgPERJViBpZD1lekZvcm1Qcm9jX2RpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTog6rW066a8Ij4NCiAgPERJViBpZD1tc2dib2R5Pg0KICA8RElWPg0KICA8RElW IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQogIDxQIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+SGksPC9QPg0KICA8UCBzdHlsZT0iTUFSR0lOLUJPVFRPTTog MHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxCUj48L1A+DQogIDxQIHN0eWxlPSJNQVJHSU4tQk9UVE9N OiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7 IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogcmdiKDMxLDczLDEy NSkiPldlIA0KICBoYXZlIGltcGxlbWVudGVkIFBDRVAtTFMgZm9yIHBhY2tldCBvcHRpY2FsIG5l dHdvcmsgd2hpY2ggd2FzIGRlbW9uc3RyYXRlZCBpbiANCiAgSUVURiA5NyBCJmFtcDtCLiBUaGUg aW50ZXItb3BlcmFiaWxpdHkgb2YgUENFUC1MUyB3YXMgZGVtb25zdHJhdGVkIGFjcm9zcyANCiAg RVRSSSwgS1QgYW5kIFdvb3JpLU5ldC4gSSBzdXBwb3J0IFBDRVAtTFMgdG8gYmUgYWRvcHRlZCBp biB0aGUgUENFIA0KICBXRy48L1NQQU4+PC9QPg0KICA8UCBzdHlsZT0iTUFSR0lOLUJPVFRPTTog MHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBG T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHJnYigzMSw3MywxMjUp Ij48QlI+PC9TUEFOPjwvUD4NCiAgPFAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lO LVRPUDogMHB4Ij48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6 ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiByZ2IoMzEsNzMsMTI1KSI+V2UmbmJzcDt0 aGluayANCiAgdGhhdCBQQ0VQIGNhbiBwcm92aWRlIG9uZSBvZiB3YXlzIHRvIGltcGxlbWVudCBh bGwgb2YgdGhlIG1haW4gZnVuY3Rpb25zIG9mIA0KICBTRE4gY29udHJvbGxlci48L1NQQU4+PC9Q Pg0KICA8UCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6IHJnYigzMSw3MywxMjUpIj5TbywgDQogIHdlIHdhbnQgUENFIFdHJm5i c3A7dG8gcHJvdmlkZSBhIHRvdGFsIHNvbHV0aW9uIHRvIGltcGxlbWVudCBTRE4gY29udHJvbGxl ciBhcyANCiAgbXVjaCBhcyBpdCBjYW48L1NQQU4+PC9QPg0KICA8UCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MXB0OyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHJnYigzMSw3 MywxMjUpIj5yYXRoZXIgDQogIHRoYW4gdXNpbmcgb3RoZXIgV0cncyBwcm90b2NvbHMgc3VjaCBh cyBCR1AtTFMuPC9TUEFOPjwvUD4NCiAgPFAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1J TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiByZ2IoMzEsNzMsMTI1KSI+PEJSPjwv U1BBTj48L1A+DQogIDxESVYgaWQ9TWFpbFNpZ25TZW50Pg0KICA8UCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPlRoYW5rcy48L1A+DQogIDxQIHN0eWxlPSJNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+QkluPC9QPg0KICA8UCBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxCUj48L1A+PC9ESVY+DQogIDxESVYg aWQ9T1JHTUFJTF9DT05URU5UPg0KICA8SFIgdGFiSW5kZXg9LTE+DQoNCiAgPERJVj48Qj7rs7Tr grgg7IKs656MIDogPC9CPiLrsJXstpjqsbgoVHJhbnNwb3J0IFNETiBQcm9qZWN0KSIgDQogICZs dDtwZXRlci5wYXJrQGt0LmNvbSZndDs8L0RJVj4NCiAgPERJVj48Qj7rs7Trgrgg64Kg7KecIDog PC9CPjIwMTYtMTEtMjUgMDk6MTk6NDIgKCArMDk6MDAgKTwvRElWPg0KICA8RElWPjxCPuuwm+uK lCDsgqzrnowgOiA8L0I+cGNlQGlldGYub3JnICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PC9ESVY+DQog IDxESVY+PEI+7LC47KGwIDogPC9CPjwvRElWPg0KICA8RElWPjxCPuygnOuqqSA6IDwvQj5bUGNl XSBTdXBwb3J0aW5nIFBDRVAtTFMgd29yayBhcyBQQ0UgV0cncyBXRyBpdGVtPC9ESVY+DQogIDxQ IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9QPg0K ICA8RElWIGNsYXNzPVdvcmRTZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PFNQQU4gDQogIGxhbmc9RU4tVVM+ RGVhciBleHBlcnRzIG9mIFBDRSBXRyw8IS0tP3htbDpuYW1lc3BhY2UgcHJlZml4ID0gIm8iIG5z ID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLy0tPjwvU1BBTj48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PFNQQU4gDQogIGxhbmc9RU4tVVM+SeKAmW0gUGV0 ZXIgUGFyayBvbmUgb2YgYSBzZW5pb3IgcmVzZWFyY2hlciBvZiBLVCBJbmZyYSANCiAgTGFiLjwv U1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPjxTUEFOIA0KICBsYW5nPUVOLVVTPkR1cmluZyBJRVRGIEImYW1w O0IgaW4gU2VvdWwsIEtUIGRlbW9uc3RyYXRlZCByZXNpbGllbnQgQUNUTiANCiAgYXJjaGl0ZWN0 dXJlIHdpdGggRVRSSSBhbmQgb3RoZXIgdmVuZG9yIHVzaW5nIFBDRVAtTFMgdXNpbmcgUENFUC1M UyBmb3IgcGFja2V0IA0KICBvcHRpY2FsIG5ldHdvcmsgdG8gcXVpY2tseSBkZXRlcm1pbmVkIG5l dHdvcmsgZmFpbHVyZSBhbmQgcmVwb3J0ZWQgdG8gdGhlIE1EU0MgDQogIHVzaW5nIFBDRVAgUmVw b3J0IG1lY2hhbmlzbS48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48U1BBTiANCiAgbGFuZz1FTi1VUz5J IGJlbGlldmUgUENFUC1MUyBpcyBhbiBpbXBvcnRhbnQgd29yayBmb3IgdXMuPC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+PFNQQU4gDQogIGxhbmc9RU4tVVM+QW5kIEkgc3Ryb25nbHkgc3VwcG9ydCBQQ0VQ LUxTIHRvIGJlIGNvbnNpZGVyZWQgYXMgUENFIFdH4oCZcyBXRyANCiAgaXRlbTwvU1BBTj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4t VE9QOiAwcHgiPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9UVE9N OiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PFNQQU4gDQogIGxhbmc9RU4tVVM+VGhhbmsgeW91LDwv U1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPjxTUEFOIA0KICBsYW5nPUVOLVVTPlBldGVyPC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAwcHg7IFRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTi1UT1A6IDBweCIgYWxpZ249bGVmdD48 U1BBTiANCiAgbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOLVRPUDogMHB4IiBhbGlnbj1sZWZ0PjxT UEFOIA0KICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+RHIu IFBldGVyKENob29uZ3VsKSANCiAgUGFyazwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bCANCiAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgVEVYVC1BTElHTjogbGVmdDsgTUFSR0lO LVRPUDogMHB4IiBhbGlnbj1sZWZ0PjxTUEFOIA0KICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZB TUlMWTogJ0NvdXJpZXIgTmV3JyI+U2VuaW9yIFJlc2VhcmNoZXIgLyBLVCBJbmZyYSANCiAgTGFi LjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOLVRPUDogMHB4IiBhbGlnbj1sZWZ0PjxT UEFOIA0KICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+NDYz LTEgQ2hlb25taW5kb25nIFl1c2VvbmdndSANCiAgRGFlamVvbiBLb3JlYShTb3V0aCk8L1NQQU4+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij48U1BBTiANCiAgbGFuZz1FTi1VUz5UOiArODIuMTAuMjg3OS43NDYzIC8g RjogKzgyLjQyLjg3MC44MDg5PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjwvUD48L0RJVj4mbmJz cDsgDQogIDxQIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5i c3A7PC9QPg0KICA8RElWIA0KICBzdHlsZT0iQk9SREVSLVRPUDogcmdiKDAsNTEsNTEpIDFweCBk b3R0ZWQ7IEJPUkRFUi1SSUdIVDogcmdiKDAsNTEsNTEpIDFweCBkb3R0ZWQ7IEJPUkRFUi1CT1RU T006IHJnYigwLDUxLDUxKSAxcHggZG90dGVkOyBQQURESU5HLUJPVFRPTTogMC44ZW07IFBBRERJ TkctVE9QOiAwLjhlbTsgUEFERElORy1MRUZUOiAwLjhlbTsgQk9SREVSLUxFRlQ6IHJnYigwLDUx LDUxKSAxcHggZG90dGVkOyBQQURESU5HLVJJR0hUOiAwLjhlbTsgQkFDS0dST1VORC1DT0xPUjog d2hpdGU7IGJvcmRlci1pbWFnZTogbm9uZSI+DQogIDxQIA0KICBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6ICdDYW1icmlhJywndGltZXMgcm9t YW4nLHNlcmlmOyBDT0xPUjogcmdiKDE1MywxNTMsMTUzKTsgTUFSR0lOLVRPUDogMHB4OyBMSU5F LUhFSUdIVDogMTBwdCI+7J20IA0KICDrqZTsnbzsnYAg7KeA7KCV65CcIOyImOy3qOyduOunjOyd hCDsnITtlbQg7J6R7ISx65CY7JeI7Jy866mwLCDspJHsmpTtlZwg7KCV67O064KYIOyggOyekeq2 jOydhCDtj6ztlajtlZjqs6Ag7J6I7J2EIOyImCDsnojsirXri4jri6QuIOyWtOuWoO2VnCDqtozt lZwg7JeG7J20LCDrs7gg66y47ISc7JeQIO2PrO2VqOuQnCDsoJXrs7TsnZggDQogIOyghOu2gCDr mJDripQg7J2867aA66W8IOustOuLqOycvOuhnCDsoJwz7J6Q7JeQ6rKMIOqzteqwnCwg67Cw7Y+s LCDrs7Xsgqwg65iQ64qUIOyCrOyaqe2VmOuKlCDqsoPsnYQg7JeE6rKp7Z6IIOq4iOyngO2VqeuL iOuLpC4g66eM7JW9LCDrs7gg66mU7J287J20IOyemOuquyDsoITshqHrkJwg6rK97JqwLCDrsJzs i6DsnbggDQogIOuYkOuKlCDri7nsgqzsl5Ag7JWM66Ck7KO87Iuc6rOgLCDrs7gg66mU7J287J2E IOymieyLnCDsgq3soJztlZjsl6wg7KO87Iuc6riwIOuwlOuejeuLiOuLpC4gPC9QPg0KICA8UCBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvUD5UaGlz IEUtbWFpbCBtYXkgDQogIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZC9vciBj b3B5cmlnaHQgbWF0ZXJpYWwuIFRoaXMgZW1haWwgaXMgDQogIGludGVuZGVkIGZvciB0aGUgdXNl IG9mIHRoZSBhZGRyZXNzZWUgb25seS4gSWYgeW91IHJlY2VpdmUgdGhpcyBlbWFpbCBieSANCiAg bWlzdGFrZSwgcGxlYXNlIGVpdGhlciBkZWxldGUgaXQgd2l0aG91dCByZXByb2R1Y2luZywgZGlz dHJpYnV0aW5nIG9yIA0KICByZXRhaW5pbmcgY29waWVzIHRoZXJlb2Ygb3Igbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkuIA0KICA8UCANCiAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsg TUFSR0lOLVRPUDogMHB4Ij48L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+ PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+ --NetEase-FlashMail-003-ce3c5611-2310-49ff-9823-a2eb1ac9972d-- From nobody Fri Nov 25 04:24:45 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AA7129853 for ; Fri, 25 Nov 2016 04:24: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, HK_RANDOM_ENVFROM=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 wvaJ9ftx4G7z for ; Fri, 25 Nov 2016 04:24:40 -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 1E3CD129ABA for ; Fri, 25 Nov 2016 03:58:46 -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 CWA25783; Fri, 25 Nov 2016 11:58:44 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 25 Nov 2016 11:58:44 +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.0301.000; Fri, 25 Nov 2016 03:58:41 -0800 From: Leeyoung To: Julien Meuric Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmx7XRvtX1NBfEy7pBDy4OfOAKDpmZ3Q Date: Fri, 25 Nov 2016 11:58:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8E0D61@dfweml501-mbx> References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> In-Reply-To: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58382775.0139, 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: 782dafb52732bf0a22ad31a4ded9a43d Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 12:24:44 -0000 Support, Young -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Thursday, November 24, 2016 10:04 AM To: pce@ietf.org Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Hi all, Though it is a -00, draft-dhody-pce-association-policy already has a long h= istory: thanks to the authors for the common work. During our meeting in Se= oul, it received some support from the room. We now want to know whether th= e list agrees to adopt it as a foundation for a PCE WG document. Please, share your comments on the mailing list. Regards, Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Fri Nov 25 16:41:46 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAE9129482 for ; Fri, 25 Nov 2016 16:41:44 -0800 (PST) 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 L4NkShl3x2TS for ; Fri, 25 Nov 2016 16:41: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 C7DD812948F for ; Fri, 25 Nov 2016 16:41:41 -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 CWA99551; Sat, 26 Nov 2016 00:41:39 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 26 Nov 2016 00:41:38 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.137]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Sat, 26 Nov 2016 08:41:33 +0800 From: "Zhangxian (Xian)" To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmx6Waw0P5bxqUSMKuvCM/9LMqDqbsLA Date: Sat, 26 Nov 2016 00:41:33 +0000 Message-ID: References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> In-Reply-To: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> 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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5838DA43.01B7, 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: 31d105889585a080715010dc5845974d Archived-At: Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 00:41:45 -0000 U3VwcG9ydC4gDQoNClJlZ2FyZHMsDQpYaWFuDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKdWxpZW4gTWV1cmljDQq3 osvNyrG85DogMjAxNsTqMTHUwjI1yNUgMDowNA0KytW8/sjLOiBwY2VAaWV0Zi5vcmcNCtb3zOI6 IFtQY2VdIFBvbGwgZm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWRob2R5LXBjZS1hc3NvY2lhdGlvbi1w b2xpY3kNCg0KSGkgYWxsLA0KDQpUaG91Z2ggaXQgaXMgYSAtMDAsIGRyYWZ0LWRob2R5LXBjZS1h c3NvY2lhdGlvbi1wb2xpY3kgYWxyZWFkeSBoYXMgYSBsb25nIGhpc3Rvcnk6IHRoYW5rcyB0byB0 aGUgYXV0aG9ycyBmb3IgdGhlIGNvbW1vbiB3b3JrLiBEdXJpbmcgb3VyIG1lZXRpbmcgaW4gU2Vv dWwsIGl0IHJlY2VpdmVkIHNvbWUgc3VwcG9ydCBmcm9tIHRoZSByb29tLiBXZSBub3cgd2FudCB0 byBrbm93IHdoZXRoZXIgdGhlIGxpc3QgYWdyZWVzIHRvIGFkb3B0IGl0IGFzIGEgZm91bmRhdGlv biBmb3IgYSBQQ0UgV0cgZG9jdW1lbnQuDQpQbGVhc2UsIHNoYXJlIHlvdXIgY29tbWVudHMgb24g dGhlIG1haWxpbmcgbGlzdC4NCg0KUmVnYXJkcywNCg0KSnVsaWVuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= From nobody Mon Nov 28 05:52:58 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] IETF 97 - Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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:30:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812921295EF for ; Mon, 28 Nov 2016 06:30:55 -0800 (PST) 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 QggI6UpUIwSX for ; Mon, 28 Nov 2016 06:30:53 -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 45F3E1295D6 for ; Mon, 28 Nov 2016 06:30:53 -0800 (PST) X-AuditID: c1b4fb30-c294498000000c18-14-583c3f9b9d59 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 1D.6C.03096.B9F3C385; Mon, 28 Nov 2016 15:30:51 +0100 (CET) Received: from EUR02-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; Mon, 28 Nov 2016 15:30: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=462NAEV21XwPacFe4UXnWzCuzsTShccL85Fal5QUkQ4=; b=RbZC50iTV2mZNsfukOkT+XjXU9Ur0la3t360tzuRoKl5R8dUN4uylsT9gMw34FDaKdVxjv9PFAJNYsFrFZ4NrMU+twfCqLm2cqx9iPNbRsutkA8y/Qzf9cSxdFdG9RdcIoUsXT0KAPzUIq9lO2Rdm+cua+JVOP7kc5Bnss7XanA= 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:30:31 +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:30:30 +0000 From: Daniele Ceccarelli To: Leeyoung , Julien Meuric Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmx5k60urowWTUuNCLFT6fofQKDpma6AgAThYAA= Date: Mon, 28 Nov 2016 14:30:30 +0000 Message-ID: References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> <7AEB3D6833318045B4AE71C2C87E8E172A8E0D61@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8E0D61@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: 234833bd-46b0-4c01-e355-08d4179b1b31 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0993; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0993; 7:nairvMg2GHdARiro3zluSNZw78TSWQuul4T9r2SmSVnT0h7iXM1YO2n37vYi65nbirJlaxNOXwqNXdseL+jGK345FEVeFXQXQHO6wMXXLKzHrdyjkVaSvVnKXvhV3EK3V7hYSveFTzL1zY9IBIZp9H0Omha7e+sa/aUT+iiYiB3O04NfyHOY1Q8VFiDEadeqfd9XeSLnyX1Wdm1YV40tvMNqrn3IJAhgq8SpBeUq+keDvZWzgs5gUQZPd7XpZiB256q8AmlLDf/TUrPOxFgYB88FNUTzw7UEK3B8cw+TD1brCj7A7vYf2D+fu6V4p6NLhTqIoKa4dmv/7m/fZiHkjtYsgwR4E7Om7xNvBYp/3Z3pGC11o2AWLiQWynn+2KPeA9zsktkHyv9WMjYABlfzhzP+JfK5feTdkyTLihsFczoSXcNBGvVKTjyrrbXxRI5tTn2gC4ADsA2Smczzjoo4Pg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692); 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)(6009001)(7916002)(199003)(13464003)(377454003)(189002)(53754006)(106356001)(6506003)(106116001)(5001770100001)(54356999)(81156014)(86362001)(66066001)(230783001)(33656002)(2900100001)(229853002)(105586002)(77096006)(81166006)(76176999)(50986999)(101416001)(76576001)(122556002)(92566002)(3280700002)(3660700001)(8676002)(97736004)(39400400001)(68736007)(7846002)(7696004)(8936002)(3846002)(39450400002)(2906002)(9686002)(39380400001)(102836003)(189998001)(74316002)(305945005)(38730400001)(5660300001)(4326007)(2950100002)(7736002)(39410400001)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0993; 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 14:30:30.8605 (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: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42KZGbHdT3e2vU2Ewco3mhZ/Tv9lspg2z9Wi 6f4Ndgdmj5Yjb1k9liz5yeTR8uwkWwBzFJdNSmpOZllqkb5dAlfG587tTAVtXBVvn65jaWBc ztHFyMEhIWAicW2nfxcjF4eQwDpGiafrjrJDOCcYJVoXvmUCcVgEepklHpxoYIHITGWS6Ol6 D+RwAjnHGCVmfjYEGcUmYCXx5JAPSFhEwEfixKLtjCA2s4CixPYDa8BsYQEviaW7lrBD1HhL XH35jx2kVQSo9dgPE5Awi4CqxKbJDWwgNq9AjMTJS4vYITZVSNzYuBpsDKeAq8SJj6tZQWxG ATGJ76fWMEGsEpe49WQ+mC0hICCxZM95ZghbVOLl439Q9UkS61t3QNUoSlxYNQvK9pXYsh/B frtjGjggJAR6WCSWTvnFApHIlui++oQJEnJWEou3iUOE5zBJNG10grBlJG6vuc8K0fuEVWLh nXXQoEqVWL62FRoOUhJ3r3QyTmDUmoXkbghbT+LG1ClsELa2xLKFr5lngcNCUOLkzCcsCxhZ VjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIEppCDW34b7GB8+dzxEKMAB6MSD++HL1YRQqyJ ZcWVuYcYJTiYlUR4061tIoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQ WgSTZeLglGpgDNmq8Nmv0nadWo6lhsf3rsYtqVeucrhXzny7nl14/5G302Rfzy0Sn7m2Jq03 8aG1fvI5Pc7GAyLVd6dX+Tu/7mApfeqevnLf5eYdLqkmWdNYAqQEXyu6/uPI5733nb1qlnmi zLddRyXlPJ2ORGzezW/dw3xdnF9xy62rVv/1HGXcph4W2yWkxFKckWioxVxUnAgAfiPGGR0D AAA= Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:30:55 -0000 Support, BR Daniele =20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Leeyoung > Sent: venerd=EC 25 novembre 2016 12:59 > To: Julien Meuric > Cc: pce@ietf.org > Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-polic= y >=20 > Support, >=20 > Young >=20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: Thursday, November 24, 2016 10:04 AM > To: pce@ietf.org > Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy >=20 > Hi all, >=20 > Though it is a -00, draft-dhody-pce-association-policy already has a long > history: thanks to the authors for the common work. During our meeting in > Seoul, it received some support from the room. We now want to know > whether the list agrees to adopt it as a foundation for a PCE WG document= . > Please, share your comments on the mailing list. >=20 > Regards, >=20 > Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Nov 28 06:49:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073D4129600 for ; Mon, 28 Nov 2016 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=metaswitch.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 VGuASMPBXs1M for ; Mon, 28 Nov 2016 06:48:57 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0097.outbound.protection.outlook.com [104.47.32.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D159A12953A for ; Mon, 28 Nov 2016 06:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=67/10BfH8hspXB4yXCxkBQ7YTJbTNVafg8g+pU2yOTo=; b=bW7Bk7p1y+itF+aUhbFYhPIXDFJ+itJQwF6+UIqj7BNa1VA0TGOgvsJUFJv8HMhoJIVn3+cz6tXuxmDRDCud58ZUTJxpFZmw88QMescmbDt7T8c9hV2YxTABpZnABwKPgtDIAu3bktpvax0pBwd3jo0NRI4XQJbFc1A3/PrGaP8= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 28 Nov 2016 14:48:55 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0747.015; Mon, 28 Nov 2016 14:48:55 +0000 From: Jonathan Hardwick To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmxvCEgiXDBA90eEXT9Znhl9/qDuf60A Date: Mon, 28 Nov 2016 14:48:54 +0000 Message-ID: References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> In-Reply-To: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.164.131.250] x-ms-office365-filtering-correlation-id: 4608361b-cfcf-4cbb-e7d3-08d4179dad66 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0201MB1911; x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:jrvCLMGNL5QykYWIZxXANDCnNNh4UA20pZUvfXOxdXzHWpuzsyju0l+Xcp861rvRhEGBq1mi5AQ3mLtcLGNSikMaq74QNrHwH5slAhTGS2jFqjcVpIi3/GnEa2n7lSQ006+aoJh9M/ik937ArG0Ea0+DmVc1wiMJslgm8G+4YuosnBP6r6/QTfhQR2KWDVFKnIUufObAOlsss+3sHIX4rnJDsisq5W/p46SRuUmwPpaQi22Bxlm6NBtF3MCN/0EsquAV86p2RN12SFtXQ+0ePYRe0Bu00F7wUQnG9X540QcOzMgS/6psClV9nW1J83eqwRq+vTuTyrDBGQJKeAGXvivYHsI2MzHU41fV09W6DW+PdBrwu8PbpKlBOplGnOX1fwrvRiUqpjcN98p1pwgQkCANuMzVbTwkUhreQhe2vku+kH9pszWpAhw5R4q1hySYWAAnX6g+ZC+APsJbNWIbFA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; 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:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(199003)(53754006)(33656002)(230783001)(2906002)(68736007)(305945005)(106356001)(6116002)(3846002)(102836003)(8676002)(106116001)(81156014)(8936002)(81166006)(105586002)(3280700002)(66066001)(9686002)(3660700001)(99286002)(7846002)(7736002)(39410400001)(2950100002)(76576001)(2900100001)(122556002)(107886002)(7696004)(6506003)(2501003)(229853002)(101416001)(97736004)(5001770100001)(39450400002)(189998001)(77096006)(38730400001)(39400400001)(39380400001)(92566002)(86362001)(5660300001)(54356999)(74316002)(76176999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 14:48:54.9186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911 Archived-At: Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:48:59 -0000 Replying as co-author - I support the adoption of this draft. Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: 24 November 2016 16:04 To: pce@ietf.org Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Hi all, Though it is a -00, draft-dhody-pce-association-policy already has a long h= istory: thanks to the authors for the common work. During our meeting in Se= oul, it received some support from the room. We now want to know whether th= e list agrees to adopt it as a foundation for a PCE WG document. Please, share your comments on the mailing list. Regards, Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Mon Nov 28 22:46:02 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A708A1295DC for ; Mon, 28 Nov 2016 22:45:57 -0800 (PST) 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 L4Fq02YQ1yDV for ; Mon, 28 Nov 2016 22:45: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 ECDC21295D7 for ; Mon, 28 Nov 2016 22:45:54 -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 CWF27693; Tue, 29 Nov 2016 06:45:52 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 29 Nov 2016 06:45:51 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 29 Nov 2016 14:45:39 +0800 From: Qin Wu To: Daniele Ceccarelli , Leeyoung , Julien Meuric Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmx6gbf618Gyt0e3/0oOOMs1baDpE5GAgAThagCAAZZ6MA== Date: Tue, 29 Nov 2016 06:45:39 +0000 Message-ID: References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> <7AEB3D6833318045B4AE71C2C87E8E172A8E0D61@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.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.583D2421.00C5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 782dafb52732bf0a22ad31a4ded9a43d Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 06:46:01 -0000 U3VwcG9ydC4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFBjZSBbbWFpbHRv OnBjZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERhbmllbGUgQ2VjY2FyZWxsaQ0Kt6LLzcqxvOQ6 IDIwMTbE6jEx1MIyOMjVIDIyOjMxDQrK1bz+yMs6IExlZXlvdW5nOyBKdWxpZW4gTWV1cmljDQqz rcvNOiBwY2VAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbUGNlXSBQb2xsIGZvciBBZG9wdGlvbiBvZiBk cmFmdC1kaG9keS1wY2UtYXNzb2NpYXRpb24tcG9saWN5DQoNClN1cHBvcnQsDQoNCkJSDQpEYW5p ZWxlICANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQY2UgW21haWx0 bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQo+IFNlbnQ6IHZl bmVyZKisIDI1IG5vdmVtYnJlIDIwMTYgMTI6NTkNCj4gVG86IEp1bGllbiBNZXVyaWMgPGp1bGll bi5tZXVyaWNAb3JhbmdlLmNvbT4NCj4gQ2M6IHBjZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W1BjZV0gUG9sbCBmb3IgQWRvcHRpb24gb2YgDQo+IGRyYWZ0LWRob2R5LXBjZS1hc3NvY2lhdGlv bi1wb2xpY3kNCj4gDQo+IFN1cHBvcnQsDQo+IA0KPiBZb3VuZw0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKdWxpZW4gTWV1cmljDQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAy NCwgMjAxNiAxMDowNCBBTQ0KPiBUbzogcGNlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtQY2VdIFBv bGwgZm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWRob2R5LXBjZS1hc3NvY2lhdGlvbi1wb2xpY3kNCj4g DQo+IEhpIGFsbCwNCj4gDQo+IFRob3VnaCBpdCBpcyBhIC0wMCwgZHJhZnQtZGhvZHktcGNlLWFz c29jaWF0aW9uLXBvbGljeSBhbHJlYWR5IGhhcyBhIA0KPiBsb25nDQo+IGhpc3Rvcnk6IHRoYW5r cyB0byB0aGUgYXV0aG9ycyBmb3IgdGhlIGNvbW1vbiB3b3JrLiBEdXJpbmcgb3VyIG1lZXRpbmcg DQo+IGluIFNlb3VsLCBpdCByZWNlaXZlZCBzb21lIHN1cHBvcnQgZnJvbSB0aGUgcm9vbS4gV2Ug bm93IHdhbnQgdG8ga25vdyANCj4gd2hldGhlciB0aGUgbGlzdCBhZ3JlZXMgdG8gYWRvcHQgaXQg YXMgYSBmb3VuZGF0aW9uIGZvciBhIFBDRSBXRyBkb2N1bWVudC4NCj4gUGxlYXNlLCBzaGFyZSB5 b3VyIGNvbW1lbnRzIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4g SnVsaWVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBQY2UgbWFpbGluZyBsaXN0DQo+IFBjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUGNlIG1haWxpbmcgbGlzdA0KPiBQY2VAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBjZSBtYWlsaW5n IGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wY2UNCg== From nobody Mon Nov 28 22:47:33 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ECE1295DF for ; Mon, 28 Nov 2016 22:47:30 -0800 (PST) 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 a6Td9Hsbj2yo for ; Mon, 28 Nov 2016 22:47:28 -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 D10441295CD for ; Mon, 28 Nov 2016 22:47:23 -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 DBO70074; Tue, 29 Nov 2016 06:47:21 +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.301.0; Tue, 29 Nov 2016 06:47:20 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.215]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Tue, 29 Nov 2016 14:47:18 +0800 From: Zhenghaomian To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmx6LogDr2ckL0GmH91jZzIaVaDvi/Ag Date: Tue, 29 Nov 2016 06:47:18 +0000 Message-ID: References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> In-Reply-To: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.194.248] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.583D2479.0434, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dc3d3449e8645b6ad5bcd2f6443d8f0e Archived-At: Subject: [Pce] =?gb2312?b?tPC4tDogIFBvbGwgZm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWRo?= =?gb2312?b?b2R5LXBjZS1hc3NvY2lhdGlvbi1wb2xpY3k=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 06:47:32 -0000 WWVzLCBTdXBwb3J0LiANCg0KQmVzdCB3aXNoZXMsDQpIYW9taWFuDQoNCi0tLS0t08q8/tStvP4t LS0tLQ0Kt6K8/sjLOiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKdWxp ZW4gTWV1cmljDQq3osvNyrG85DogMjAxNsTqMTHUwjI1yNUgMDowNA0KytW8/sjLOiBwY2VAaWV0 Zi5vcmcNCtb3zOI6IFtQY2VdIFBvbGwgZm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWRob2R5LXBjZS1h c3NvY2lhdGlvbi1wb2xpY3kNCg0KSGkgYWxsLA0KDQpUaG91Z2ggaXQgaXMgYSAtMDAsIGRyYWZ0 LWRob2R5LXBjZS1hc3NvY2lhdGlvbi1wb2xpY3kgYWxyZWFkeSBoYXMgYSBsb25nIGhpc3Rvcnk6 IHRoYW5rcyB0byB0aGUgYXV0aG9ycyBmb3IgdGhlIGNvbW1vbiB3b3JrLiBEdXJpbmcgb3VyIG1l ZXRpbmcgaW4gU2VvdWwsIGl0IHJlY2VpdmVkIHNvbWUgc3VwcG9ydCBmcm9tIHRoZSByb29tLiBX ZSBub3cgd2FudCB0byBrbm93IHdoZXRoZXIgdGhlIGxpc3QgYWdyZWVzIHRvIGFkb3B0IGl0IGFz IGEgZm91bmRhdGlvbiBmb3IgYSBQQ0UgV0cgZG9jdW1lbnQuDQpQbGVhc2UsIHNoYXJlIHlvdXIg Y29tbWVudHMgb24gdGhlIG1haWxpbmcgbGlzdC4NCg0KUmVnYXJkcywNCg0KSnVsaWVuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGlu ZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlDQo= From nobody Tue Nov 29 00:20:52 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF233129614 for ; Tue, 29 Nov 2016 00:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cyyoxHpQtZav for ; Tue, 29 Nov 2016 00:20:49 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C36E129613 for ; Tue, 29 Nov 2016 00:20:49 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 8081410012E for ; Tue, 29 Nov 2016 09:20:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 671904004C for ; Tue, 29 Nov 2016 09:20:47 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 09:20:45 +0100 From: To: MEURIC Julien IMT/OLN , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Thread-Index: AQHSRmxuBB8We2cRfEWGnUqLxiB5MaDvpfkw Date: Tue, 29 Nov 2016 08:20:44 +0000 Message-ID: <6019_1480407647_583D3A5F_6019_16409_1_552e8f2d-7d23-458e-9e85-298e21bd4800@OPEXCLILM33.corporate.adroot.infra.ftgroup> References: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> In-Reply-To: <9d42a74d-f24e-0d9c-44cc-461b6fe0cd22@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 08:20:51 -0000 Support as co-author -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Thursday, November 24, 2016 17:04 To: pce@ietf.org Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy Hi all, Though it is a -00, draft-dhody-pce-association-policy already has a long h= istory: thanks to the authors for the common work. During our meeting in Se= oul, it received some support from the room. We now want to know whether th= e list agrees to adopt it as a foundation for a PCE WG document. Please, share your comments on the mailing list. Regards, Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Nov 29 00:47:20 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699C1129620; Tue, 29 Nov 2016 00:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk 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 vUx871YXNzQ6; Tue, 29 Nov 2016 00:47:17 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF3612956F; Tue, 29 Nov 2016 00:47:16 -0800 (PST) Received: from [10.137.2.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id D5E1F242481; Tue, 29 Nov 2016 09:47:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1480409234; bh=CNxjo/kgbFsvDL0x56OMveSpvhCoxf2/3t2y7k9Znxg=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=IDZsgCjtOYufy9sARolWokJ1IjhaeUZUUcJ2xv3I4h70PzdDtsNqYhi8MAhrofcwN XRgMth9cuMII0oxsYXIkvdK9REOSql6QpL6imfDYe+yh96UcWeBlm3KIhoTDqGUOd2 9OMSu77F77qgmMUYMIWmxHOgxT4123gWoMlTLIjg= To: Julien Meuric , draft-ietf-pce-stateful-pce@ietf.org References: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> From: Robert Varga Message-ID: Date: Tue, 29 Nov 2016 09:47:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E6v5nxmtsMgqW7upa3R8bNXkNl62XBpqs" Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 08:47:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E6v5nxmtsMgqW7upa3R8bNXkNl62XBpqs Content-Type: multipart/mixed; boundary="SmppGXiVKHcIc1npGLePOb10flcpQCIQS"; protected-headers="v1" From: Robert Varga To: Julien Meuric , draft-ietf-pce-stateful-pce@ietf.org Cc: "pce@ietf.org" Message-ID: Subject: Re: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce References: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> In-Reply-To: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> --SmppGXiVKHcIc1npGLePOb10flcpQCIQS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/18/2016 03:35 PM, Julien Meuric wrote: > Dear authors of the aforementioned I-D, >=20 > Could you please share with the mailing list whether you are aware of > any IPR that applies to draft-ietf-pce-stateful-pce and, if so, if it > has been disclosed in compliance with IETF IPR rules? (See RFCs 3979, > 4879, 3669 and 5378 for more details.) If you are not aware of any IPR= > that applies, please reply saying =93I am not aware of any IPR that > applies to this draft=94. The only IPR applicable to this draft has been disclosed in https://mailarchive.ietf.org/arch/msg/pce/9ZnrJyonghEwXrYHqOmjQDxZdQU. Other than that, I am not aware of any IPR that applies to this draft. Regards, Robert --SmppGXiVKHcIc1npGLePOb10flcpQCIQS-- --E6v5nxmtsMgqW7upa3R8bNXkNl62XBpqs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIoBAEBCgASBQJYPUCLCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDToa0P/iLC//ci ws6umqhe47cAao5npqQA0QKv4jZ3zAeP4/8MKbPNGfyU2NhLCrnbyyLkfuUdZl/H oL3hB3XQVlM1d/gVmiQhIZIHfI0gtsw/Fs7AwRIT2sLXOnGTWFGmOb67NroTjPw7 j0Cs3JC94RJknSkll2QCEbtQ4yIajhi0HzxjVW3bjfDxacxByjeCsMLi0qqv4Oz3 /A09K9vBxUeJKse4hBUjR60AgUMOxvK3bJBWEDNM9GAmOfG4pJOojTMWiIgw5BUj E+KqMncRC+pCUOGXNeZId3mkKgPgH891Q2YUZvVgVO8jKwwPUlwCeDLwRY+3Sca8 ohUgqIOTkxLPfeRoAEjGIvdtj/rnYWOhdVqVrKMKBUqArrq4ReWcCPyvgN6UtZ22 7Akx8lFchZSHQMIc8GxawlRvSa0wPw38VkIpEX14AI1+QeGosnT1dIpVlXzXMn6P X03qiXKu3h136SsLjVHSz3yhKrGay5MUvRO4+aXofjR4MBO+UTXDyZh9+lESjNf3 sJGRibwwtgbW2UcWJT08Pje2Qi7dHOjcRES929YB6KB/FrwPOeqS5Pq2yHC/LLGi dUi3U379PuhchGgWj34VaQowwciev4tsRKx0MU8gmLfDjayUHNw5GCpV3kZM9POo wGega6ngeVB12tHW/NBKkJmpPa5orHjK5LSE =/DN+ -----END PGP SIGNATURE----- --E6v5nxmtsMgqW7upa3R8bNXkNl62XBpqs-- From nobody Tue Nov 29 08:22:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED86B129609 for ; Tue, 29 Nov 2016 08:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oao7jWG35OUS for ; Tue, 29 Nov 2016 08:21:53 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 A299C129C09 for ; Tue, 29 Nov 2016 08:21:49 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id n204so179646929qke.2 for ; Tue, 29 Nov 2016 08:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R4KDlQkNINRdYUSoOFCwU51eOWVLJlBiludT6bVovc0=; b=Uhg04CYXF3VdQjRH4qXF4Z+4MqhcZxcu69vTzfKuf7BaKjAUbg7qwfCg3U/1kYAHFO lMoVwB6xEqFYSo/DECgtVOL5sNs0QIDdA/wc2lZINJ8f4q6XpQmdRFT2dl1m8EopCxpO 0+5h22nLh8LHwqLVxn1lOZRjU5+2CkDZrgiSnsHQriXnw26bKBvUB/vY9ke5gKJr01co HPVZ6KBm0STv47uh5CePC6h8ucCwaeIPOYRPIlMJOVQYF0qn+XWpm8kcovQSkre9PUD6 DUPBVZSg680hcP/pSmJCG/R8sS1G80tVFbWF4KQJ1pjjcUsq5xdUeXsCg/haNVssOnsd k4mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R4KDlQkNINRdYUSoOFCwU51eOWVLJlBiludT6bVovc0=; b=Aw0uy4YmzrMIAOiz+hWZtNM0uSeGVNy6Jj3MAq3gyf3OErMwEsLv4nUB0HZ+01jNNY eMWrkJ+zI0ZSGAy7GYT4563nvWXbvke5LUyEokq8vSxgwTt+y5HzYb9k6i7MtOS9es6T OcLoPIAjrI+pDU7oB6btxOytS2skmh7IS4A0hb7XUuVbbMFvIhhKqwndBkVqpcXnNusH UtQgqyyU5i+3/pnmF8vvUh3ikvP1lLmVYg+YfoOEWRt8rxwsevspALYFueSoI4QGZmVq HYayx5DeTTwEkHi+2a/XSh+rWLybc40F3VnENoG/244VC38A4aYmjREKgqPRaS5L+wsW C7Cw== X-Gm-Message-State: AKaTC00bmHqDMw2L0ZWY0fx1FOAB2eWNOqBHWhjf3eK2nMZiXEQH+eTQrlYI5CKt0K5zx7R4+8XS8R8K+/fsONbt X-Received: by 10.55.183.3 with SMTP id h3mr27343286qkf.33.1480436508342; Tue, 29 Nov 2016 08:21:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.115.2 with HTTP; Tue, 29 Nov 2016 08:21:47 -0800 (PST) In-Reply-To: References: <2b75d160-3861-8557-00f5-f9731bcf3443@orange.com> From: Ina Minei Date: Tue, 29 Nov 2016 08:21:47 -0800 Message-ID: To: Robert Varga Content-Type: multipart/alternative; boundary=94eb2c07106a31b06c054272fc88 Archived-At: Cc: draft-ietf-pce-stateful-pce@ietf.org, "pce@ietf.org" Subject: Re: [Pce] Last IPR Check for draft-ietf-pce-stateful-pce X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 16:21:59 -0000 --94eb2c07106a31b06c054272fc88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not aware of any IPR except the one mentioned by Robert. Ina On Tue, Nov 29, 2016 at 12:47 AM, Robert Varga wrote: > On 11/18/2016 03:35 PM, Julien Meuric wrote: > > Dear authors of the aforementioned I-D, > > > > Could you please share with the mailing list whether you are aware of > > any IPR that applies to draft-ietf-pce-stateful-pce and, if so, if it > > has been disclosed in compliance with IETF IPR rules? (See RFCs 3979, > > 4879, 3669 and 5378 for more details.) If you are not aware of any IPR > > that applies, please reply saying =E2=80=9CI am not aware of any IPR th= at > > applies to this draft=E2=80=9D. > > The only IPR applicable to this draft has been disclosed in > https://mailarchive.ietf.org/arch/msg/pce/9ZnrJyonghEwXrYHqOmjQDxZdQU. > > Other than that, I am not aware of any IPR that applies to this draft. > > Regards, > Robert > > --94eb2c07106a31b06c054272fc88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR except the one mentioned by Robe= rt.=C2=A0

Ina=C2=A0

On Tue, Nov 29, 2016 at 12:47 AM, Robert V= arga <= nite@hq.sk> wrote:
On 11/18/2016 03:35 PM, Julien Meuric wrote:
> Dear authors of the aforementioned I-D,
>
> Could you please share with the mailing list whether you are aware of<= br> > any IPR that applies to draft-ietf-pce-stateful-pce and, if so, if it<= br> > has been disclosed in compliance with IETF IPR rules? (See RFCs 3979,<= br> > 4879, 3669 and 5378 for more details.)=C2=A0 If you are not aware of a= ny IPR
> that applies, please reply saying =E2=80=9CI am not aware of any IPR t= hat
> applies to this draft=E2=80=9D.

The only IPR applicable to this draft has been disclosed in
https://mailarchive.ietf.org/arch/msg/pce/9ZnrJyonghEwXrYHqOmjQDxZdQU.

Other than that, I am not aware of any IPR that applies to this draft.

Regards,
Robert


--94eb2c07106a31b06c054272fc88-- From nobody Tue Nov 29 13:56:47 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] [mpls] IETF 97 - Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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

 

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 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-- From nobody Wed Nov 30 01:39:47 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@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: [Pce] [Teas] [mpls] IETF 97 - Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element 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 09:12:58 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE91295E6; Wed, 30 Nov 2016 09:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.999, 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=-2.896, 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 qqnwjTPR7X8Y; Wed, 30 Nov 2016 09:12:52 -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 68AA31295BB; Wed, 30 Nov 2016 09:12:51 -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 CWH96799; Wed, 30 Nov 2016 17:12:48 +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.301.0; Wed, 30 Nov 2016 17:12:47 +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.0301.000; Wed, 30 Nov 2016 09:12:42 -0800 From: Leeyoung To: Jonathan Hardwick , "pce@ietf.org" , "draft-ietf-pce-wson-rwa-ext@ietf.org" Thread-Topic: Working group last call (including final IPR check) for draft-ietf-pce-wson-rwa-ext Thread-Index: AdJE5eHDlGqlwZd7R6W/piT+TJWxlgGRnjCw Date: Wed, 30 Nov 2016 17:12:42 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8E1832@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.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8E1832dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.583F0891.01A2, 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: 663185241344328661b9da74467f33e7 Archived-At: Cc: "pce-chairs@ietf.org" Subject: Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-wson-rwa-ext X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:12:55 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8E1832dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am not aware of any undisclosed IPR that applies to this draft. Thanks. Young From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Tuesday, November 22, 2016 11:31 AM To: pce@ietf.org; draft-ietf-pce-wson-rwa-ext@ietf.org Cc: pce-chairs@ietf.org; Daniele Ceccarelli Subject: Working group last call (including final IPR check) for draft-ietf= -pce-wson-rwa-ext Dear PCE working group, This email starts a working group last call for draft-ietf-pce-wson-rwa-ext= -05. https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/ Please read the document and reply to the PCE mailing list whether you beli= eve this document is ready to be published, or not (including any comments = on why not). The last call will end on Tuesday 6 December. We are also polling for knowledge of any undisclosed IPR that applies to dr= aft-ietf-pce-wson-rwa-ext-05, to ensure that IPR has been disclosed in comp= liance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more det= ails) prior to moving forward. If you are a document author, please respon= d to this email and indicate whether or not you are aware of any relevant u= ndisclosed IPR. The document won't progress without answers from all the au= thors. No IPR disclosures currently exist against this document. Many thanks Jon, Julien and JP --_000_7AEB3D6833318045B4AE71C2C87E8E172A8E1832dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I am not aware of any = undisclosed IPR that applies to this draft.

 

Thanks.

Young

 

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Tuesday, November 22, 2016 11:31 AM
To: pce@ietf.org; draft-ietf-pce-wson-rwa-ext@ietf.org
Cc: pce-chairs@ietf.org; Daniele Ceccarelli
Subject: Working group last call (including final IPR check) for dra= ft-ietf-pce-wson-rwa-ext

 

Dear PCE working group,

 

This email starts a working gro= up last call for draft-ietf-pce-wson-rwa-ext-05.

https://datatracker.ietf.org/doc= /draft-ietf-pce-wson-rwa-ext/

 

Please read the document and re= ply to the PCE mailing list whether you believe this document is ready to b= e published, or not (including any comments on why not).  The last cal= l will end on Tuesday 6 December.

 

We are also polling for knowled= ge of any undisclosed IPR that applies to draft-ietf-pce-wson-rwa-ext-05, t= o ensure that IPR has been disclosed in compliance with IETF IPR rules (see= RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward.  If you are a document author,= please respond to this email and indicate whether or not you are aware of = any relevant undisclosed IPR. The document won't progress without answers f= rom all the authors.  No IPR disclosures currently exist against this document.

 

Many thanks

Jon, Julien and JP

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8E1832dfweml501mbx_--