Telechat Review of draft-ietf-opsawg-ntf-10
review-ietf-opsawg-ntf-10-rtgdir-telechat-dhody-2021-11-19-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-opsawg-ntf-10
Reviewer: Dhruv Dhody
Review Date: 2021-11-19
IETF LC End Date: over
Intended Status: Informational

Summary:
Choose from this list…

   - I have some minor concerns about this document that I think should be
   resolved before publication.

Comments:

   - I find the document to be useful. It is well structured and easy to
   read. Since the aim of the document is to clarify the taxonomy and
   framework, I hope to see more drafts to refer to it when describing network
   telemetry. I have a few suggestions of things that are missing, some
   queries and nits that are easy to resolve, and hopefully improve the
   document further.

Minor Issues:

   - Well almost Major :)
      - Something that I find missing in the document is that the network
      controller could be a valuable source of network telemetry as well.
      Consider a PCE, the controller could be a source of network-wide
data, such
      as the association between network paths, cumulative network metrics,
      global network utilization, etc. The document is currently very
      network-device-specific (as a data source). My suggestion would be to
      handle the centralized controller either as a separate section or part of
      the control plane and management plane telemetry.
      - Something else that I find missing is the multi-domain aspects. You
      could mark it as out of scope or better yet do talk about it how there
      could possibly be a hierarchy and recursive nature in your framework to
      handle multi-domain. Currently, it is mentioned in passing while
describing
      data fusion in section 3.4.
   - Query
      - Section 4.1
         - In figure 2, why MIB is mentioned in the management plane only,
         why not control plane when various control plane protocols have MIBs?
         Similarly, there are forwarding statistics MIB that might work in the
         forwarding plane? Also, add SNMP and ASN.1(?) in the table
corresponding to
         MIB.
         - What is a ‘mirror’? Maybe expand it or put a * and expand it at
         the bottom
         - All external data coming from gRPC only?
      - Others
      - Section 6
         - The Independent management network is mentioned only in passing.
         Shouldn’t there be a much stronger recommendation for this instead?

Nits:

   - From IDNits

  == Outdated reference: draft-ietf-grow-bmp-adj-rib-out has been published
     as RFC 8671

  == Outdated reference: draft-ietf-ippm-multipoint-alt-mark has been
     published as RFC 8889

  == Outdated reference: A later version (-11) exists of
     draft-song-ippm-postcard-based-telemetry-10


   - Section 2
      - Add reference for
         - GPB - https://developers.google.com/protocol-buffers
         - IOAM - draft-ietf-ippm-ioam-data
         - NetFlow - reference is incorrect, it should be RFC 3954
         - SNMP - for the sake of covering all versions, we should mention
         v3 as well - RFC 3414
      - Section 3.3
      - Add reference for
         - Syslog - RFC 5424
         - sFlow - RFC 3176
      - Expand PSAMP - Packet Sampling
   - Section 4.1
      - The list of 6 angles in the text and the 1st column in the table do
      not match.
      - Expand ASICs - Application-Specific Integrated Circuits
   - Section 4.1.1
      - The use of the term “server” can be confusing here. Would you
      consider using “data source”?
   - Section 4.1.2
      - I am unaware of the term “video fluency”. Is it a term of art that
      I am unaware of?
      - Add reference to Y.1731 - “ITU-T, “OAM Functions and Mechanisms for
      Ethernet based networks”, ITU-T Y.1731, 2006.”
   - Section A.1.2
      - gNMI reference is marked as [I-D.openconfig-rtgwg-gnmi-spec]
      whereas, in the main body, it is [gnmi] “gNMI - gRPC Network Management
      Interface”,
      https://github.com/openconfig/reference/tree/master/rpc/gnmi. Any
      reason for different references?
      - same for gRPC!
   - Section A.3.6
      - Expand L2VPN, NVO3, BIER, SFC, DETNET
      - Is there anything about SR and Multicast worth adding to the list?

Thanks!
Dhruv