Subject: [ippm] Comments on draft-ietf-ippm-ioam-data-04

From: Lizhenbin <[email-masked]>
Date: Sun, 4 Nov 2018 05:22:33 +0000

Hi Authors,
When have the Hackathon on IOAM in IETF103, I read the drafts and would like to propose following comments and some doubts for your reference.
1.
"Note that not every
   node in an IOAM domain needs to be an IOAM transit node.  For
   example, a Segment Routing deployment might require the segment
   routing path to be verified.  In that case, only the SR nodes would
   also be IOAM transit nodes rather than all nodes .
"
1) How to distinguish if all nodes or SR nodes will record IOAM info? If the both is necessary, how to process?
2) For SRv6 the SID list can be kept in the SRH. But for SR-MPLS, the Label/SID will be popped and the SID list cannot be kept. Would there be different process for SR-MSPL and SRv6.
3) In order to reduce the complexity, could the part be discussed in some SR iOAM draft instead of this draft?

2.
"While, for example, the
      IOAM node identifier (Node-ID) does not have to be unique in a
      deployment , the combination of Node-ID and Namespace-ID will
      always be unique.
"
Why assume that the node id will not be unique? It is only to increase complexity.The uniqueness should be guaranteed which is common in other protocols design such as LSR ID in MPLS signalling, Router ID in IGP, etc.

3.
"An IOAM encapsulating node must  set NodeLen."
In many places "must" should be changed to "MPLS".

4.
"      A node receiving an IOAM Pre-allocated or Incremental Trace Option
      may   rely on the NodeLen value, or it may ignore the NodeLen value
      and calculate the node length from the IOAM-Trace-Type bits.
"
Should "may" be changed to "MAY"?

5.
"
   IOAM-Trace-Type:  A 16-bit identifier  which specifies which data
      types are used in this node data list.
"
16-bit should be changed to 24-bit based the new design.

6.
"
      Bit 12-22  Undefined.  An IOAM encapsulating node must  set the
               value of each of these bits to 0.  If an IOAM transit
               node receives a packet with one or more of these bits set
               to 1, it must  either:
"
Why not directly ignore these bits which are not set as 0?

7.
"
The first element
      of the node data list (node data list [0]) contains the last node
      of the path while the last node data of the node data list (node
      data list[n]) contains the first node data of the path traced.
"
Is this for Incremental Trace option or for both Incremantal Trace option and Pre-allocated option?

8.
"
the field value MUST
   be set to 0xFFFFFFFF for 4-octet fields or 0xFFFFFFFFFFFFFFFF for
   8-octet fields
"
Since some customized data maybe encapsulated in the IOAM header, maybe it is not always aligned with 4-octet or 8-octet. Is it necessary to introduce some padding machanisms?

9.
"
      node_id:  3-octet unsigned integer.  Node identifier field to
         uniquely identify a node within in-situ OAM domain .
"
Though it is neccessary to save space, it is a little strange for 3-octet node-id comparing popular 4-octet and 16-octet node id in other protocols. The 3-octet node id remove the possibility of reuse and consistency. It may introduce the unnecessary confusion.

10.
"
   queue depth:  4-octet unsigned integer field.  This field indicates
      the current length of the egress interface queue of the interface
      from where the packet is forwarded out.
"
The queue length is not enough since there may be multiple queues for a specific outgoing interface. If there is H-QoS, it will be more complex.

11.
"
   buffer occupancy:  4-octet unsigned integer field.  This field
      indicates the current status of the buffer occupancy.  The buffer
      occupancy is expressed as the current number of memory buffers
      used by the set of queues that share a common buffer pool .
"
What is the unitsof the buffer occupancy? It is the number of bytes or the percentage?

12.
"
   0xD400:   IOAM-Trace-Type is 0xD400 then the format of node data is:
"
For "0xD400":
1) The trace type value already changes to 24-bit.
2) Based on the bit definition in the draft, the value is wrong. There are similar errors for values in the examples of the section. Please update.

Best Regards,

Zhenbin (Robin)