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

[tom petch <[e-mail]>]

From: Italo Busi <[e-mail]>
Sent: 12 July 2021 11:26

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>
Here's a left field question for you.  Do you have the ability to view the IETF website in hex?

The IETF have abolished the FTP service for I-D (far too useful to be allowed to continue:-( so I am forced to use https: from the list of I-D under Active WG
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation/
and when I do, the downloaded I-D are corrupt.  The corruption is reproducible and slight, but annoying.  With -14, I get it in several places, such as p.14
The Multi-Domain Controller asks TE Domain
where 'E' is corrupted into something undisplayable.  My Windows system has no hex editor and hexed.it
does not work for me so I cannot see what it is in binary.  My guess is that it is something Unicode that the web browser is rendering as 'E' but my simple text editor is not.

I  could boot a DOS disk utility that renders the entire disk in hex but thought I would ask first.

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 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 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: <[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-computation
> > /
> > >
> >