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