Re: [Teas] Comments on draft-busibel-teas-yang-path-computation
Italo Busi <Italo.Busi@huawei.com> Fri, 16 March 2018 11:57 UTC
Return-Path: <Italo.Busi@huawei.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 5B37D127077; Fri, 16 Mar 2018 04:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level:
X-Spam-Status: No, score=-4.231 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 juJQbfo2GsxP; Fri, 16 Mar 2018 04:57:33 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 10813126BF7; Fri, 16 Mar 2018 04:57:33 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 99916AE6BB258; Fri, 16 Mar 2018 11:57:29 +0000 (GMT)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml709-cah.china.huawei.com ([10.201.108.32]) with mapi id 14.03.0382.000; Fri, 16 Mar 2018 11:57:28 +0000
From: Italo Busi <Italo.Busi@huawei.com>
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>, "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: AdNS8IOmspNKN6VHR8O3OQ52leEFGRhrfqigAfcl/qAAKLY2IA==
Date: Fri, 16 Mar 2018 11:57:28 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B15826182@lhreml504-mbs>
References: <AM5PR0701MB2547B3C6BB44A63FA053191C935F0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <DB6PR0701MB26321C7AF003A2B3FDD7A95391DA0@DB6PR0701MB2632.eurprd07.prod.outlook.com> <AM5PR0701MB2547A2D0838FEF5D0231986093D00@AM5PR0701MB2547.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB2547A2D0838FEF5D0231986093D00@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.91.32]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/mqETLYMK_rgLRJh4vNjXfWu8KbY>
Subject: Re: [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: Fri, 16 Mar 2018 11:57:35 -0000
Thanks Michael -----Original Message----- From: Scharf, Michael (Nokia - DE/Stuttgart) [mailto:michael.scharf@nokia.com] Sent: Thursday, March 15, 2018 4:33 PM To: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; draft-busibel-teas-yang-path-computation@ietf.org Cc: teas@ietf.org Subject: RE: Comments on draft-busibel-teas-yang-path-computation I have quickly scanned through the changes. I agree that my comments are addressed in -01. Thanks Michael > -----Original Message----- > From: Belotti, Sergio (Nokia - IT/Vimercate) > Sent: Monday, March 05, 2018 5:54 PM > To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>; > draft-busibel-teas-yang-path-computation@ietf.org > Cc: teas@ietf.org > Subject: RE: Comments on draft-busibel-teas-yang-path-computation > > Hi Michael, > thanks for your comments. We have just uploaded the 01 version of the > draft addressing your comments as described in line below. > Please review, and let us know if you have pending concerns. > > Cheers > Italo and Sergio > > -----Original Message----- > From: Scharf, Michael (Nokia - DE/Stuttgart) > [mailto:michael.scharf@nokia.com] > Sent: Wednesday, November 1, 2017 10:19 AM > To: draft-busibel-teas-yang-path-computation@ietf.org > Cc: teas@ietf.org > Subject: Comments on draft-busibel-teas-yang-path-computation > > 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 > > We agree and updated the 01 version accordingly > > * Abstract and introduction: If the objective is to standardize the YANG > model, the abstract and introduction could focus more on that aspect > > We agree and addressed in new vesrion 01. > > * 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. > > > A clear PCE definition has been added aligned with IETF concepts and > clarified text where it was needed. > > * 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. > > As discussed we have updated the text to clarify (e.g. we used > packet/optical coordinator term) > > * 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. > > We have modified picture and clarified in a note the real IP connectivity > meaning in the picture. > > * 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. > > Linked to above comment, we have also modified this picture. > > * 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). > > > Update text as suggested > > * 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. > > > We have modified text using Data center resources terms , not "computing > resources" and not virtual machine. Clarified that the Cloud Orchestrator > needs to make a decision for optimal connection based on TE Network > constraints and data centers resources . > > * 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. > > > The sections 3, 4, and 6.1 have been restructured and put together in a > new section 3 . > > * 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. > > > Updated text as suggested by Michael. > > * 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. > > > We agree to avoid ACTN dependence terminology . Updated text > accordingly. > > * 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 has been restructured to host Yang model description. > > * Section 6.2 could be a main section, IMHO. > > > Done > > * 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? > > > We have cleaned and aligned the naming conventions for Yang constructs. > > * 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). > > > We have tracked this comments open issue in github (#40) > > > As mentioned earlier, I believe all these issues can be addressed when the > document is a WG document. > > Thanks > > Michael
- [Teas] Comments on draft-busibel-teas-yang-path-c… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [Teas] Comments on draft-busibel-teas-yang-pa… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Comments on draft-busibel-teas-yang-pa… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [Teas] Comments on draft-busibel-teas-yang-pa… Italo Busi