Re: [Teas] Fw: Re: I-D Action: draft-ietf-teas-yang-path-computation-11.txt

Italo Busi <Italo.Busi@huawei.com> Mon, 08 February 2021 16:48 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 685D03A11BF; Mon, 8 Feb 2021 08:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1pKeXg9KNfne; Mon, 8 Feb 2021 08:48:09 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD2E3A11B4; Mon, 8 Feb 2021 08:48:09 -0800 (PST)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DZBgt0zSRz67mH8; Tue, 9 Feb 2021 00:44:26 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Feb 2021 17:48:04 +0100
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.006; Mon, 8 Feb 2021 17:48:04 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: 'tom petch' <ietfa@btconnect.com>, "teas@ietf.org" <teas@ietf.org>
CC: "draft-ietf-teas-yang-path-computation.all@ietf.org" <draft-ietf-teas-yang-path-computation.all@ietf.org>
Thread-Topic: [Teas] Fw: Re: I-D Action: draft-ietf-teas-yang-path-computation-11.txt
Thread-Index: AQHWvq7pR/sotCFZk0qb9EumSMXwRqpO8uWg
Date: Mon, 8 Feb 2021 16:48:04 +0000
Message-ID: <7a3ee5b71cd341859503925c35c631a6@huawei.com>
References: <5FB65FE8.1030409@btconnect.com> <AM6PR07MB578489FBDC931A7E8AF60326A2E00@AM6PR07MB5784.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB578489FBDC931A7E8AF60326A2E00@AM6PR07MB5784.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.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/F0WW_gjGn3_WXwCTu8yLaB627GQ>
Subject: Re: [Teas] Fw: Re: I-D Action: draft-ietf-teas-yang-path-computation-11.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 08 Feb 2021 16:48:12 -0000

Hi Tom,

Thanks for your review and comments

We have addressed them in the -12 version we have just submitted

Please find some feedbacks and follow-up questions in line marked with "Authors > "

Thanks

Sergio and Italo (on behalf of co-authors)

> -----Original Message-----
> From: tom petch [mailto:ietfa@btconnect.com]
> Sent: giovedì 19 novembre 2020 13:12
> To: teas@ietf.org
> Subject: [Teas] Fw: Re: I-D Action: draft-ietf-teas-yang-path-computation-
> 11.txt
> 
> 
> Some mostly editorial comments
> 
> Capitalisation; confuses me
> I would use a general principle that capitals are used for technical terms,
> something special, and not elsewhere.  Thus I prefer Optical Domain Controller,
> Cloud Network Orchestrator, YANG(!) but domain, optical domain, child,
> parent, coordinator, packet, optical, multi-domain but above all, consistency
> in the use
> 

Authors> Ok

We have used the following conventions:

- Software-Defined Networking 
- YANG data model
- YANG module
- tree diagram
- TE tunnel
- TE topology
- Packet/Optical Integration
- Packet/Optical Coordinator
- optical network
- optical domain
- Optical Domain Controller
- packet network
- packet domain
- Packet Domain Controller
- multi-domain
- Multi-Domain Controller
- TE domain
- TE Domain Controller
- TE network
- TE Network Controller
- Data Center
- Data Center Interconnection
- orchestrator
- Cloud Network Orchestrator
- use case
- parent PCE
- child PCE

Please check if anything has been missed in the -12 version

> Expand on first use
> SDN, ABNO, ACTN, CMI, MPI, OTN, ODU, PCE, WSON, LSP,  PNC, SVEC, SRLG
> 

Authors> Ok: please check if anything has been missed in the -12 version

> XXXX  is standing in for two distinct I-D; the common convention is to use XXXX
> for this document, rather than 'this document' and then YYYY, ZZZZ etc for
> others - here, I would use YYYY for teas-te.
> 

Authors> Ok

> k-shortest could do with a reference
> 

Authors> We have looked for some references and found many papers which mainly described different algorithms that could be used for computing k-shorted paths as if the term is well-known.

Within IETF, we have found https://tools.ietf.org/html/rfc2386 which also references:

    [T88] D. M. Topkis, "A k-Shortest-Path Algorithm for Adaptive
    Routing in Communications Networks", IEEE Trans.
    Communications, pp. 855-859, July, 1988.

We are not really sure that this IEEE paper or RFC2386 would be a good reference for the definition.

Any opinion?

> /data-store/datastore/
> 

Authors> Ok

> /multi domain/multi-domain/
> 

Authors> Ok

> /setup/set up/ when this is a verb, set-up is the noun
> 

Authors> Ok

> I think that  there is only the one path delete RPC but I see several different
> phrases that seem to refer to it - consistency is good (and capitalisation is
> good!)
> 

Authors> Ok: we will use the term Path Delete RPC in -12 version
 
> Abstract
> 
> YANG-based protocols
> I know of none such:-)  perhaps YANG-supporting or some such
> 

Authors> The term "YANG-based protocols" is used in section 1.1 of RFC7950.
 
> s.1
> YANG, NETCONF, RESTCONF need references  and I would mention at this
> point that this is RPC-based
> 

Authors> This is stated some paragraph below when describing the content of the draft:

   This document defines a YANG data model [RFC7950] for an RPC to
   request path computation, which complements the solution defined in
   [TE-TUNNEL], to configure a TE tunnel path in "compute-only" mode.

> s.2.1
> /depend from/depend on/

Authors> Ok: for consistency, done also in s.2.2
 
> /even this is/ even if this is/
> 

Authors> Ok
 
> s.2.4
> /path computation to/path computation from/
> 

Authors> Ok: for consistency, done also in s.3.2 and s.3.2.2
 
> s.3.2
> /computation by its own/computation on its own/ /to compute unfeasible
> path/to compute an unfeasible path/ /and accurate the TE//and accurate TE/
> 

Authors> Ok
 
> s.3.2.2
> /is not good and need/is not good and it needs/

Authors> Ok

> /to get a suboptimal path that/     unsure perhaps /that/than/?

Authors> Proposed to rephrase as:

                                                                                                                there are
  more chances not to find a path or to get a suboptimal path than
  performing multiple per-domain path computations and then stitch
  them.

> 
> s.3.3
> /major issues in case the time /major issues when the time /
> 

Authors> Ok

> compute-only mode in the config data-store which datastore?  elsewhere you
> name the datastore
> 

Authors> Ok: c/config data-store/running datastore/

> /can request to setup /can request the set-up of/ /computation requests
> /computation request/ /path that have been /path that has been /
> 

Authors> Ok

> s.4
>   /not-synchronized /unsynchronized
> 

Authors> Ok

> s.5.1
> /The YANG model permits to synchronize/The YANG model permits the
> synchronization of/
> 

Authors> Ok

> including raw YANG seems odd - might be better in English with a line or two
> of explanation for each identity - I see this approach in yang-te-types
> 

Authors> Ok

> s.5.2
> /It also allows to request in the input/It also allows the request in the input/
> 

Authors> Not sure the change would be consistent with the intended meaning. What about rephrasing the text as:

   It also allows the client to request which information (metrics,
   srlg and/or affinities) should be returned:

> s.5.3
> 'is indented to be used'
> perhaps 'intended'- this occurs in several places
> 

Authors> Ok

> / primary paths, or/ primary path, or/
> 

Authors> Ok

> Since the IETF has expunged pagination, then it would be good to keep
> sections to a page or less, where this is technically feasible -  I know, diagrams
> make this difficult!.

Authors> It is a pity that pagination has been expunged. However, given the technical content of the draft and the diagrams, we think it is quite difficult to shorten the exiting sections.

> 
> Tom Petch
> 
> ----- Original Message -----
> From: <internet-drafts@ietf.org>
> To: <i-d-announce@ietf.org>
> Cc: <teas@ietf.org>
> Sent: Monday, November 16, 2020 2:58 PM
> Subject: I-D Action: draft-ietf-teas-yang-path-computation-11.txt
> 
> 
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Traffic Engineering Architecture and
> Signaling WG of the IETF.
> >
> >         Title           : Yang model for requesting Path Computation
> >         Authors         : Italo Busi
> >                           Sergio Belotti
> >                           Victor Lopez
> >                           Anurag Sharma
> >                           Yan Shi
> >         Filename        : draft-ietf-teas-yang-path-computation-11.txt
> >         Pages           : 93
> >         Date            : 2020-11-16
> >
> > Abstract:
> >    There are scenarios, typically in a hierarchical SDN context, where
> >    the topology information provided by a TE network provider may not
> >    be sufficient for its client to perform end-to-end path
> computation.
> >    In these cases the client would need to request the provider to
> >    calculate some (partial) feasible paths.
> >
> >    This document defines a YANG data model for an RPC to request path
> >    computation. This model complements the solution, defined in
> >    RFCXXXX, to configure a TE Tunnel path in "compute-only" mode.
> >
> >    [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of
> >    draft-ietf-teas-yang-te once it has been published.
> >
> >    Moreover this document describes some use cases where a path
> >    computation request, via YANG-based protocols (e.g., NETCONF or
> >    RESTCONF), can be needed.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation/
> >
>