[Teas] Review of draft-ietf-teas-actn-pm-telemetry-autonomics-05

[Adrian Farrel <[e-mail]>]

Hi authors,

I thought it was probably time to give this document a review. Here
are some comments.

Having digested this document, I strongly advise the TEAS chairs to
send a notification to OPSAWG flagging that this work is handling
performance metrics and uses an intent-based approach.

Best,
Adrian

===

== Substance ==

In Section 1 you have 

   [Editor's Note: A suggestion is made to remove the word KPI from the
   name of the model.  Further discussion is needed.]

It seems that the only use of "KPI" is in the model names.  It would,
therefore, seem reasonable to remove the name and clean up the one 
paragraph in Section 1...

OLD
   [RFC8233] describes key network performance data to be considered for
   end-to-end path computation in TE networks.  Key performance
   indicator (KPI) is a term that describes critical performance data
   that may affect VN/TE-tunnel service.  The services provided can be
   optimized to meet the requirements (such as traffic patterns,
   quality, and reliability) of the applications hosted by the
   customers.
NEW
   [RFC8233] describes key network performance data to be considered for
   end-to-end path computation in TE networks.  The services provided
   can be optimized to meet the requirements (such as traffic patterns,
   quality, and reliability) of the applications hosted by the
   customers.

---

1.1

The only place the term "Key Performance Data" is used is in this 
section (apart from the Abstract and Introduction). Perhaps it doesn't
need to be in this section?

---

1.1.1 

With the nit fix to section 4 (see below) there is no use of 2119
language. So you can strike this section, remove the boilerplate from
the two models, and remove the references to 2119 and 8174.

---

2.

Is [I-D.xu-actn-perf-dynamic-service-control] the wisest reference to 
make here? That document expired as an individual submission in 2015.

Since this document mainly reproduces materials, why not just make the
points you want to make and move on.

---

The term "transport network" is used a few times. Is this a left-over
from when ACTN was "Transport" not "TE"?

---

Section 2, bullet 2

      However, for other performance parameters, there are
      no such mechanisms.

I think you mean "SLA requirements" not "performance parameters"

---

3.2

   This module describes performance telemetry for VN model.  The
   telemetry data is augmented both at the VN Level as well as
   individual VN member level.

Is it the telemetry data that is augmented?
I think the VN model is augmented by/with the telemetry data.

---

Question about the overlap between the models. 

I was going to write a long thing saying that there was overlap 
between the models and that you should have a common model that augments
both the TE and VN models and which is itself augmented by the
VN-telemetry model.

In fact, when I got to Section 7 I found this is exactly what you have!

However, the whole of the rest of the document talks about the two
models being entirely separate. Even the trees are out of date. That all
needs fixing.

---

When leaf threshold-value (which is a string) is applied to the 
different members of telemetry-param-type, I think more help is needed
to know how to interpret the value. For example, is one-way-delay
measured in hours or weeks, or is it a percentage?

I think the way to handle this is in the description clauses for each
telemetry-param-type where you can say:

   "The threshold-value for this type is interpreted as..."

---

I believe it would be helpful to explain why the TE model has
scaling-operation while the VN model adds grouping-operation. That is,
the reader wonders why grouping is not applicable to TE tunnels.

The answer is presumably that, with a VN, grouping can be applied across
a number of TE tunnels that are members of the VN, and that doesn't
apply to telemetry for a single tunnel. However, I didn't learn this 
from the text and had to work it out for myself.

---

It's great that Section 5 includes examples for notifications. This is a
considerable help to the reader.

I think that it would be useful to include an example of the use of the
models defined in this document for both a single TE tunnel and for a 
VN. This would also help explain the use of scaling and grouping.

---

8.

   These are the subtrees and data nodes
   and their sensitivity/vulnerability:

   o  /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent

   o  /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent

   o  /vn:vn/vn:vn/vn-scaling-intent/scale-in-intent

   o  /vn:vn/vn:vn/vn-scaling-intent/scale-out-intent

Seems to me that you have successfully listed the subtrees / data nodes,
but you haven't mentioned their sensitivity/vulnerability.

---

Prefix names...
I am not an expert, but it seems to me that the two names requested in 
Section 9 (te-tel and vn-tel) are not used consistently in the rest of
the document.
For example, in 7.2 I see vn-kpi instead of vn-tel.
Can you please look through the whole document and make sure everything
is clean.

== Nits==

General

A few places you have "YANG module" and others you have "YANG model". Is
there a preferred terminology you should be using?

---

Abstract

s/mechanism/mechanisms/  (twice)
s/(VN)/(VNs)/
s/draft/document/
s/their key/the key/
d/of their interest/

---

Section 1

Old
   during the VN
   instantiation, VN computation, and its life-cycle service management
   and operations.
NEW
   during the 
   computation of a VN, its instantiation, and its life-cycle service
   management and operations.

---

Section 1

s/models, which is mapped to/models.  These can be mapped to the/
s/these capability/the capabilities/

---

Section 1

OLD
   The term performance monitoring being used in this document is
   different from the term that has been used in transport networks for
   many years.
NEW
   The term performance monitoring is used in this document in a 
   different way from how the term that has been used in transport
   networks for many years.

---

Section 1

Please expand PNC on first use

---

Section 1

s/of client's VN or TE- tunnel/of a client's VN or TE-tunnel/
s/interfacing the client/interfacing to the client/
s/would require controller/requires the controller to have the/
s/new Network Management/Network Management/

---

1.1

s/This refers to the network/This refers to the network's/

OLD
   Scale out refers to improve network performance by
   increasing the allocated resources, while scale in refers to decrease
   the allocated resources
NEW
   "Scale out" refers to improving network performance by
   increasing the allocated resources, while "scale in" refers to 
   decreasing the allocated resources

OLD
   To declare scaling conditions, scaling intent is
   used.
NEW
   Scaling intent is used to declare scaling conditions.

OLD
   Specifically, scaling intent refers to the intent expressed by
   the client that allows the client to program/configure conditions of
   their key performance data either for scaling out or scaling in.
NEW
   Specifically, scaling intent refers to the how the client programs or
   configures conditions that will be applied to their key performance
   data to trigger either scaling out or scaling in.

s/allows client/allows a client/

---

OLD
1.2.  Tree diagram
NEW
1.2.  Tree Diagram

---

1.2

s/Section 5/Sections 4 and 6/

---

1.3

OLD
   Note: The RFC Editor will replace XXXX with the number assigned to
   the RFC once this draft becomes an RFC.
NEW
   Note: The RFC Editor is requested to replace XXXX with the number 
   assigned to the RFC once this draft becomes an RFC, and to remove
   this note.

---

2.

s/a high-level workflows/the high-level workflow/
s/Figure 1: Workflows/Figure 1: Workflow/

---

Figure 1

Some uses of "&" need a space before them.
There are two abbreviations in the figure that aren't explained (APP, DB)
s/optimize Req./optimize request/

---

2.

s/initiate the network optimization/initiate network optimization/

OLD
      save the Capital Expense (CAPEX) and the Operating
      Expense (OPEX).
NEW
      save Capital Expense (CAPEX) and Operating Expense (OPEX).

s/latency, latency jitter /latency, jitter /
s/according to customer SLA/according to the customer SLA/
s/in the client/at the client/

---

3.

OLD
   The YANG models developed in this document describe two models:
NEW
   This document describes two YANG models:

---

3.1

s/reconfiguration of TEs/reconfiguration of TE tunnels/

---

The figure in Section 3.1 needs:
- a figure number
- a caption
- a reference from the text

---

3.2

s/order the controller/order for the controller/
s/provides mechanism/provides a mechanism/
s/if maximum grouping/if a maximum grouping/

Expand "E2E"

---

The two figures in Section 3.2 need:
- a figure number
- a caption
- a reference from the text

---

3.2

Looks like the paragraph "The VN Telemetry Model augments..." and the
subsequent figure belong near the top of the section.

---

4.

s/Scaling intent configuration/The scaling intent configuration/
s/auto- scaling/auto-scaling/
s/Let say the client/Let's say the client/

---

4.

   o  Threshold-time: the duration for which the criteria MUST hold
      true.

This isn't a 2119 "MUST". You can make it lower case.

---

The examples in 5.1 would be better presented as Figures so that the
text can refer to them explicitly.

---

8.

s/The YANG module/The YANG modules/
s/document defines a schema/document define schemas/

---

8.

   A number of configuration data nodes defined in this document are
   writable/deletable (i.e., "config true").  These data nodes may be
   considered sensitive or vulnerable in some network environments.

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.

That looks like a duplication (modulo "creatable"). Can you just strike
the first paragraph?