search

IETF-TEAS-WG / ietf-teas-yang-path-computation

0 stars 4 forks source link

Tom Petch's comments on 2020-11-19 #82

Closed italobusi closed 3 years ago

italobusi commented 3 years ago

See: https://mailarchive.ietf.org/arch/msg/teas/xIc0tBnZ9AHhkXKC47UorRNwxss/

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:

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 that 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 in the input of RPC 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.

italobusi commented 3 years ago

k-shortest could do with a reference

  • [ ] @italobusi , @sergiobelotti : check for a reference

I 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.

italobusi commented 3 years ago

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

  • [ ] @italobusi , @sergiobelotti : check NMDA terminology
  • [ ] we used the tern "running" and "operational" datastore that are both correct. The state of each created "compute-only" TE tunnel are maintained in the running or intended as well and operational datastore.

It seems that we need to change 'config data-store' with 'running data-store' in the text