[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes, February 5th, 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
February 5th, 2020, 07:00 UTC
Webex meeting


Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Greg Mirsky, Tal Mizrahi,
Mickey Spiegel.

Minutes by Tal Mizrahi.


Summary:
========
- Tal will post an updated version of the profile draft. A slot will be
requested for IETF 107, and WG adoption will be suggested.
- Frank and Shwetha will map WG LC comments about the data draft to Github
issues.
- Mickey will propose alternative text for the Queue Depth data field to
resolve the units.
- Next meeting is in two weeks, February 19th.


Introduction:
=============
- Tal: on our agenda today we will have a short overview of the status of
each of the drafts: flag draft, DEX draft, profile draft. We will then talk
about open issues in the data draft.


Flag draft:
===========
- Tal: a revised version has been upload to the IETF repository. An email
was sent to the list with the main open issues. Hopefully discussion will
follow.


DEX draft:
==========
- Tal: the decision in IETF 106 was that DEX will be a candidate for WG
adoption after the data draft last call. We are currently waiting for the
working group adoption call, after which we will post an updated version.
- Barak: do we plan to merge the DEX draft back to the data draft?
- Shwetha: it is too late, since the data draft is in WG last call.
- Tal: that is my understanding too. DEX has not been adopted by the WG
yet, and the process for DEX will take more time.
- Barak: it makes sense to merge them.
- Tal: there are still open issues in the DEX draft. It will take time to
resolve them and reach maturity for publication.
- Barak: I would suggest to merge the DEX draft into the data draft.
- Greg: it will require another working group last call.
- Tal: right.
- Greg: once a draft goes through working group last call, any
non-editorial changes will require another working group last call.


Profile draft:
==============
- Tal: I have updated the current version on Github based on our previous
discussion in the virtual meeting. I wonder whether we are ready to suggest
WG adoption.
- Shwetha: let's present it in IETF 107, and then we can ask for WG
adoption.
- Tal: right. I will post an updated draft, and we will discuss it in IETF
107 and suggest WG adoption.


Data draft:
===========
- Tal: there were comments in working group last call. We need to work on a
revision. Are there any specific comments that we want to discuss now?
- Shwetha: were any comments translated to Github issues?
- Barak: I had comments that are also Github issues.
- Shwetha: I can break the comments from WG LC into Github issues.
- Frank: what are the substantial comments.
- Shwetha: for example there was a comment regarding the Opaque State
Snapshot.
- Tal: there were a a couple of comments from Barak.
- Barak: two main comments. One regarding the units of the queue size data
field. Another issue is how to report data from a port or a queue; it
should be defined whether the reported data correspond to a specific queue
or to a specific port.
- Frank: we discussed it in an earlier call, and decided that it needs to
be discussed in a larger group. It needs consolidation on the list. I
suggest some more discussion on the list.
- Tal: making changes in data fields at this point is pretty late.
- Barak: the current definition of the queue size is vague. The change I am
suggesting will not preclude existing implementations.
- Frank: maybe you can find another wording than "should".
- Barak: if anyone can suggest a different wording that would be welcome.
- Greg: "should" is not different than suggesting something as a
recommendation. Distinguish uppercase from lowercase. SHOULD means that you
can do something else if you have a reason to.
- Barak: I don't mind the exact normative language. If anyone has suggested
wording that will be welcome. MAY is an option here.
- Mickey: there are different use cases for IOAM. In some cases different
units are okay, in other cases not. Maybe the profile draft can address
this.
- Frank: in some cases the hardware may not count in bytes, but in units of
X bytes. This would be a use case in which different units are used. We are
inspiring to use bytes for interop, but we explain that in some cases it
will be in different units. As Greg mentioned in WG last call, in some
cases a 32-bit field may not be sufficient, but if you use more
coarse-grained units it enables the scale.
- Mickey: maybe this can be worded a bit weaker: if you report a queue size
it is best to normalize the units. One way to do this is by all devices
using the byte unit, or by having the "receiving entity" perform the
normalization. This may be the best way to phrase it.
- Frank: Barak, does this make sense?
- Barak: I will take a look at it, and maybe we can consider it. Do vendors
share their buffer cell size?
- Frank: I believe so.
- Mickey: I am not sure it is documented in the data sheet. I was hoping
this could be defined in the YANG model.
- Barak: it looks like you are forcing vendors to report the cell size.
- Frank: you have to report the size in a meaningful unit, or not support
this IOAM feature. If you report the queue size you are exposing something
about your queue/buffer sizes. That is not necessarily a problem. We are
trying not to put significant constraints on the hardware. Let's not force
anybody to implement byte units.
- Barak: Mickey, can you suggest text here?
- Mickey: yes.
- Frank: I will work with Shwetha on mapping the issues, and bring them
back to the list.
- Mickey: another issue is the timestamp in the E2E option type. In the
trace option the timestamp specifies the reception time, and in E2E it
specifies transmission time.
- Frank: are you suggesting the timestamp to be defined as the reception
time at the encapsulating node?
- Tal: what if the encapsulating node generates the packet?
- Mickey: it would be best for the timestamp to specify the reception time
on the encap node, and the transmission time at the decap node, allowing to
measure the overall delay, including the encap and decap nodes.
- Greg: you mainly want to measure the delay through the tunnel, and what
happens before and after it is not interesting.
- Frank: do we want to specify the timestamping point, or leave it to the
implementation? I would suggest to leave it to the implementation.
- Mickey: right now the definition of timestamp is different in E2E vs.
trace option.
- Frank: Shwetha and I will create Github issues for the main comments.
- Tal: I will create an issue for the security considerations comments.