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

[Italo Busi <[e-mail]>]

Thanks Tom for your review

We have addressed all your comments in the editors' draft we have prepared for the -17 version

You can find a pre-view on github:

https://github.com/rvilalta/ietf-te-path-computation/blob/wg-lc/draft-ietf-teas-yang-path-computation.txt

The diffs are available here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-teas-yang-path-computation&url2=https://raw.githubusercontent.com/rvilalta/ietf-te-path-computation/wg-lc/draft-ietf-teas-yang-path-computation.txt

https://www.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-teas-yang-path-computation&url2=https://raw.githubusercontent.com/rvilalta/ietf-te-path-computation/wg-lc/draft-ietf-teas-yang-path-computation.txt

Sergio and Italo (on behalf of co-authors)

> -----Original Message-----
> From: tom petch [mailto:[e-mail]]
> Sent: martedì 13 luglio 2021 12:59
> To: Italo Busi <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Teas] Fw: Re: I-D Action: draft-ietf-teas-yang-path-computation-
> 11.txt
> 
> From: Italo Busi <[e-mail]>
> Sent: 12 July 2021 11:26
> To: tom petch; [e-mail]
> 
> Hi Tom.
> 
> Many thanks for your review and comments
> 
> We have just uploaded a -13 addressing your comments (followed up with a -
> 14 revision to update the affiliations of Young and Victor)
> 
> Please find our replies in line, marked as IBSB>
> 
> <tp>
> 
> Looks good (mostly:-)
> 
> You have probably seen yourselves that the ToC cannot cope with some of the
> headings, those for 3.2.3 and Appendix A; perhaps shortening them is simplest
> solution :-)
> 
> You have 'his' in a couple of places which will probably draw an adverse
> reaction; perhaps 'their' (which is asexual).
> 
> Some minor grammatical quirks, of which I go on seeing more each time I read
> the I-D - not worth a new version of the I-D IMHO.
> 
> /This types of scenarios/These types of scenarios/ or else /This type of
> scenario/
> 
> /modeled in the  augmented/modelled in the augmenting/ modelled certainly,
> augmenting I think
> 
> /provides a complete and accurate/provides complete and accurate/
> 
> /suboptimal path than performing/suboptimal path than by performing/
> /then stitch them/then stitching them/ or perhaps /stitching them together/.
> 
> Tom Petch
> 
> Sergio and Italo (on behalf of co-authors)
> 
> > -----Original Message-----
> > From: tom petch [mailto:[e-mail]]
> > Sent: martedì 30 marzo 2021 12:50
> > To: Italo Busi <[e-mail]>; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [Teas] Fw: Re: I-D Action:
> > draft-ietf-teas-yang-path-computation-
> > 11.txt
> >
> > From: Italo Busi <[e-mail]>
> > Sent: 08 February 2021 16:48
> >
> > 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 > "
> >
> > <tp>
> >
> > Looks good (mostly:-).  I like the capitalisation.  Bringing my
> > comments up to the top lest they get lost. Mostly editorial but
> >
> > te-types has a type for tp-id; why not use it? or explain why it is
> > not suitable
> >
> 
> IBSB> The te-types:te-tp-id can be used to reference LTPs. In order to
> reference TTPs, the binary type is needed because RFC 8795, defines the TTP
> IDs as binary. YANG model has been updated to clarify that this is a tunnel-tp-
> id.
> 
> >
> > I still see one inconsistency of YYYY and XXXX both of which get used
> > for teas- yang-te; I think YYYY better since XXXX is usually used for 'this' I-D.
> >
> 
> IBSB> we have used YYYY in -13 version
> 
> > Expansions needed for OSNR BER (which defaults to Basic Encoding
> > Rules), FEC, WDM, e2e(probably)
> >
> 
> IBSB>OK, done in -13 version
> 
> > s.1
> > /allows providing the TED/allows the provisioning of the TED/
> >
> 
> IBSB>OK, done in -13 version
> 
> > s.3.2
> > /may be not sufficient/may be insufficient/
> >
> 
> IBSB>OK, done in -13 version (also in the abstract and introduction)
> 
> > s.3.2.1
> > /by its own /on its own /
> >
> 
> IBSB>OK, done in -13 version
> 
> > s.3.3..3
> > / it is know/ it is known/
> >
> 
> IBSB>OK, done in -13 version
> 
> > s.3.3
> > /does not guaranteed /does not guarantee /
> >
> 
> IBSB>OK, done in -13 version
> 
> > s.6.2
> > "RFC XXXX: Yang model for requesting Path Computation";
> >
> > RFC XXXX: YANG Data Model for requesting Path Computation to match the
> > title of the I-D
> >
> 
> IBSB>OK, done in -13 version
> 
> > /as described in section 3.3.1.";/
> > as described in section 3.3.1 of RFC XXXX.";/
> >
> 
> IBSB>OK, done in -13 version
> 
> > /  "Information for synchonized path computation /  "Information for
> > synchronized path computation /
> >
> 
> IBSB>OK, done in -13 version
> 
> >      augment "/te:tunnels-actions/te:output" {
> >        description
> >          "Augment Tunnels Action RPC input ...
> > /input/output/?
> >
> 
> IBSB>It should be output: fixed in -13 version
> 
> > s.8 I think that the analysis by leaf is needed before Last Call.
> >
> 
> IBSB>Yes, we have planned to do before requesting WG LC once the YANG
> IBSB>model is stable. See open issue: #75
> 
> > on k-shortest, no I have no better idea.  Probably just ignorance on my part.
> > See what the AD or IESG come up with - it is the sort of technical
> > reference where they excel.
> 
> IBSB>Ok, let's see if we can get some suggestions from WG, AD or IESG
> 
> >
> > Tom Petch
> >
> > Thanks
> >
> > Sergio and Italo (on behalf of co-authors)
> >
> > > -----Original Message-----
> > > From: tom petch [mailto:[e-mail]]
> > > Sent: giovedì 19 novembre 2020 13:12
> > > To: [e-mail]
> > > 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
> > Authors> 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
> > Authors> 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
> > Authors> 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,
> > Authors> 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: <[e-mail]>
> > > To: <[e-mail]>
> > > Cc: <[e-mail]>
> > > 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-computati
> > > on
> > > /
> > > >
> > >