[Teas] Comments on draft-busibel-teas-yang-path-computation

"Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com> Wed, 01 November 2017 09:19 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2448213F4FA; Wed, 1 Nov 2017 02:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 Ypss77Bl1Yah; Wed, 1 Nov 2017 02:19:18 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0096.outbound.protection.outlook.com [104.47.0.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C540A13F5CC; Wed, 1 Nov 2017 02:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Buy/mQiGf0sFbXBY9tZ0ep41NuhsR0GmgHE+ckxPFcs=; b=S8r2WzOKB4IBb3eQ10OnUYprAAN9NDJgB7V0iG/VCf29m2Io41YDwC4Ed2HOBcCWv0lb3cfyN3kAmHIpdOnk+UakkSXoLNDmwfgtld3+5g/PMZ1+1a0+SsAKu9SALeYK5R/Zb2jaTUeu2JThZDBI/CYHbWIc/WfScu15HJkWgcg=
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Wed, 1 Nov 2017 09:19:15 +0000
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::14d8:6acd:f568:98f]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::14d8:6acd:f568:98f%17]) with mapi id 15.20.0197.013; Wed, 1 Nov 2017 09:19:15 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
To: "draft-busibel-teas-yang-path-computation@ietf.org" <draft-busibel-teas-yang-path-computation@ietf.org>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Comments on draft-busibel-teas-yang-path-computation
Thread-Index: AdNS8IOmspNKN6VHR8O3OQ52leEFGQ==
Date: Wed, 1 Nov 2017 09:19:14 +0000
Message-ID: <AM5PR0701MB2547B3C6BB44A63FA053191C935F0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com;
x-originating-ip: [92.203.240.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 6:v5yaihwAXI2bB75Ephbo301P8wpSuMrPcyhczmHs8w0u81KjF8b9UlZWP2JldbMNLL51s0ALD7zdUqhuZZdmZMZnPxYeNd+eT8nYuIl/FMd3YyZNXAaOJlEZgzrra86Ex+6LDoJ5+vD10wPXMCQGjaCL5qHcrKSHRveyfOincbfzJbN0gG9DkEDx8wjUA6Im11WsuJjz34Ts61HZi5uBdRNsD5S7+Gu4/FBmpsyY3BlhfJHB0NLVc1U3N0ZoiFmqIBaYgFZpF1GtYY5QwSS/ql1XkAbqpXuMDBAo+dLLOFk0woDo7VVvLDJsjUYmrCHhSmjfHi7Tzu8dlTkOLPpBoYlIiFUcFocIy4shESkIDpk=; 5:0GVkyK5f9r3NEWO4QP2KEM+PnMHR95cdpwPGKP9EjscPLYQWpowHdmb7DFe27PN6jj0sN6kO11JftGTQVJ38sExGpUrroMjIwaNv545ayTNtlqMS6Jr4fREtoCZkrpnpiSBFGE6dr6ZfWon5vbflxyIjOoEePHzDm8Od9HyFnJM=; 24:hlRJABtbMJKE01V28jdPuQ3VLE3x/rk1dKSzGj9Oqw0GdIvDUTBLJh3mY/MMUwR0mBolHhVQ+sXovgcUYtK4t90k0USplwv1YCsoVCbgTGc=; 7:GKVhK2Ga7EN0B0fSVcdBujf7DcBoaWE36hxsU+boPwrzRkk+g0V2aGUh3wjcynTepu3ZWcev9hFH5bClFTh6BG62icAq4ACTUIoykX8OQ/KscqN4yrwIYQ8hjBJLI/BR7p+wlxk/yx0TgeC/G3C6y1l0QZ1lrLkJFtvxdhmBYj2/NT0qPJkyXaFJZqvWb+EnFVIoYSW8NUjYmD3bA87VlsT0wlviKHa6pn971icidsNHYcykzq/wihi1EZNwfesa
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 416facd6-d902-41f5-5af0-08d521099f20
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2547;
x-ms-traffictypediagnostic: AM5PR0701MB2547:
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-microsoft-antispam-prvs: <AM5PR0701MB2547C1588ED28FA103C6B8FB935F0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2547;
x-forefront-prvs: 0478C23FE0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(53754006)(52314003)(189002)(2501003)(53936002)(101416001)(55016002)(33656002)(305945005)(74316002)(7696004)(2900100001)(14454004)(6916009)(99286003)(230783001)(2351001)(5250100002)(7736002)(106356001)(5890100001)(105586002)(66066001)(9686003)(97736004)(8936002)(81156014)(3846002)(102836003)(6116002)(189998001)(25786009)(3660700001)(450100002)(4326008)(3280700002)(2906002)(8676002)(81166006)(478600001)(68736007)(4743002)(86362001)(6506006)(5660300001)(316002)(50986999)(6436002)(5640700003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.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: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 416facd6-d902-41f5-5af0-08d521099f20
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 09:19:15.0132 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/auH8nXehAHROtiru4P4jX6YSabc>
Subject: [Teas] Comments on draft-busibel-teas-yang-path-computation
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2017 09:19:20 -0000

Hi all,

I have read draft-busibel-teas-yang-path-computation-03 again after a while, and this has triggered some comments. As far as I can see, my observations are mostly about content organization, and none of these comments affects the YANG model itself. As a result, I believe these are all non-blocking comments that can be sorted out when the I-D is a WG document. The document is certainly the right starting point for a WG document. I support WG adoption.

As I am an author, I have explicitly flagged comments related own text.

Comments:

* "Intended status: Informational": I believe the YANG model should be published on standards track

* Abstract and introduction: If the objective is to standardize the YANG model, the abstract and introduction could focus more on that aspect

* Introduction and other sections: The exact use of the term "PCE" may have to be reviewed, e.g., in statements such as "... allowing the Path Computation Element (PCE) within the Orchestrator to perform multi-domain path computation...". An orchestrator may not necessarily implement exactly what I think is defined as "PCE", e.g., when the orchestrator deals with multi-point services. But this is orthogonal to the content of the document.

* Section 2.1: I think this use case 1 should be renamed, as there is no real IP/optical integration in the use case. To me, the use case is about providing optical connectivity, not about any multi-layer functionality in the IP layer. Also, I think the use case could also be applied to non-IP traffic - the question what traffic is transported IMHO does not affect the path computation in scope of the document.

* Figure 1: This figure should either be improved or removed. One could understand from this rendering that the considered routers in the IP network are *all* edge routers (PEs or ASBR). If a full IP network should be rendered, P routers would have to be shown, too, in order to make the figure realistic. As already explained, the IP network topology and the "IP controller" probably do not matter for this use case. They should IMHO be removed as that aspect doesn't matter for this document. For the use case only the interface between the orchestrator and the optical domain controller matters.

* Figure 2: This figure is not correct in the IP layer. For instance, the IP domain controller will know the IP links (IGP links) between the "IP nodes", and these IP links are missing in this figure. I find this figure in the IP layer confusing. Anyway, I don't think this figure is needed for the following discussion of how to provision optical services.

* Section 2.1.1: "In this use case, the orchestrator needs to setup an optimal path between two IP routers R1 and R2." This wording is confusing as "path" could also refer to an IP path. I think a better alternative would be: "In this use case, the orchestrator needs to setup optimal (optical) connectivity between two IP routers R1 and R2" (or whatever other term that cannot be confused).

* Section 2.3: This use case 3 makes some assumptions that can be questioned, e.g., "In this use case, a virtual machine within Data Center 1 (DC1) needs to transfer data to another virtual machine that can reside either in DC2 or in DC3.". I think we have already discussed in the context of an ACTN framework whether a WAN controller would really deal with individual virtual machines, and whether this is a useful granularity for an EMS/NMS/controller in the WAN. For the ACTN framework, I think the consensus was to focus on the attachment points of the data center, not VMs. At minimum, a similar change seems to make sense here. In addition, this use case also neglects the impact of the data center network, which would require a lot of additional discussion. For connectivity provisioning, I think use case 3 is identical to use case 1, and beyond that there are no clear requirements. As a result, use case 3 could IMHO be removed from the document without any impact.

* Section 3: "Interactions with TE Topology": If the objective is to standardize a YANG model, one might expect in a section with this title a discussion on how the YANG models uses the TE model, e.g., how the RPC is augmented etc. Instead I believe this section more focuses on *why* a path computation YANG model is needed. The content is highly useful, but I think it overlaps with Section 4. I think Section 3 and 4 (and partly even Section 6) could be merged into an overall motivation section with less overlap. The numerical examples could perhaps also be moved to an appendix. Note that I do believe that the numerical examples are very useful and should be included in the document - but it may not have to be normative.

* Section 4 (well, my own text): "Path computation requests should be closely aligned with the YANG data models that provide (abstract) TE topology information, i.e., [TE-TOPO] as well as that are used to configure and manage TE Tunnels, i.e., [TE-TUNNEL]." This and following text is very old wording from early drafts. I think this objective is achieved now, and this text can be rephrased in a follow-up version of the I-D. I apologize for the legacy text, I should have looked at this earlier.

* Section 5: While the document may reference ACTN in the introduction as context, I believe the main content of the I-D should be agnostic of whether the ACTN framework is assumed, or not. Path computation can also be used in context outside of ACTN, e.g., within systems that make different assumptions and design choices. I think this draft should be agnostic to ACTN outside e.g. the introduction. Otherwise e.g. the I-D would have to be updated if the ACTN framework is modified. And I don't think that any dependency on ACTN is needed for the actual modeling. As this draft is useful no matter whether an implementation follows the ACTN assumptions or not, I think in Section 5 all ACTN terminology should be removed.

* If the YANG model shall be the main contribution, Section 6 has to be extended with an introduction of the actual YANG model and its modeling design choices, e.g., how to use "synchronization" in the YANG model.

* Section 6.2 could be a main section, IMHO.

* Section 6.2.1: I wonder why "pathComputationService" and some few other YANG constructs uses capital letters; this is certainly possible but is it intentional?

* In a later version of the ID, it may make sense to include an actual example for a path computation request (e.g., for XML encoding in NETCONF).


As mentioned earlier, I believe all these issues can be addressed when the document is a WG document.

Thanks

Michael