Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

[Haoyu Song <[e-mail]>]

Inline

From: Frank Brockners (fbrockne) <[e-mail]>
Sent: Tuesday, January 21, 2020 5:41 AM
To: Haoyu Song <[e-mail]>; Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Haoyu,

Thanks. Please see inline ("...FB").

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of Haoyu Song
Sent: Dienstag, 7. Januar 2020 23:26
To: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

IPPM and IOAM authors,

I have a question about the variable length opaque data field in the trace option. Does that mean each node may add a variable length field (i.e., use a different scheme ID)?

     "When this field is part of the data field but a node populating
      the field has no opaque state data to report, the Length must be
      set to 0 and the Schema ID must be set to 0xFFFFFF to mean no
      schema."

>From the above description, it seems so.  Then there's a problem. If each node's data has different size, then one can't guarantee that the RemainingLen is exactly 0 when the data overflow happens.

...FB: Could you detail the problem a bit more: Why would the remaining length need to be exactly 0 in case of a data overflow? If RemainingLen < (NodeLen + sizeof(opaque snapshot)) in 4 octet units, then a node would not add data.

[HS] According to the draft text,  "RemainingLen:  7-bit unsigned integer.  This field specifies the data
      space in multiples of 4-octets remaining for recording the node
      data, before the node data list is considered to have overflowed.
      When RemainingLen reaches 0, nodes are no longer allowed to add
      node data. ", so I assume that the Remaining length of 0 means no more data can be added.

      Also, "NodeLen"  is fixed but the size of snapshot is not, which makes each node probably add different number of bytes.
      This will make it difficult to find the location for new data insertion in the pre-allocated trace mode.





Another issue:

    "If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the
      actual length added by each node.  If IOAM-Trace-Type bit 22 is
      set, then the actual length added by a node would be (NodeLen +
      Opaque Data Length)."

I think the "actual length added by a node would be (NodeLen+ size of opaque state snapshot field). Because the opaque data is only a part of the opaque state snapshot field, and  (opaque data length + 4 byte)=size of opaque state snapshot field.  Some other places need similar clarification.
...FB: Thanks. It makes sense to harmonize the description and at the same time, make it more specific - i.e. match it  to what is already used in section 4.4.1, i.e. "NodeLen + sizeof(opaque snapshot)" in 4 octet units.
Cheers, Frank

Haoyu

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of Tommy Pauly
Sent: Tuesday, January 07, 2020 8:48 AM
To: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Hello IPPM,

Happy New Year! This email starts a working group last call for "Data Fields for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-data%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C4f471415b6d84a2f65f508d79e778839%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637152108543542112&sdata=sDmCSLe4dQlxFEwqiPdfsWTWdf5q0MPSRwIL6lcDxZs%3D&reserved=0>).

The last call will end on Tuesday, January 21.. Please reply to [e-mail]<mailto:[e-mail]> with your reviews and comments. Please indicate whether you think this document is ready for publication.

Best,
Tommy (as co-chair)