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

[Tal Mizrahi <[e-mail]>]

Hi,

A correction to what I said in the meeting: the DEX draft was already
adopted by the WG. I just posted a draft-ietf version of this draft.

Cheers,
Tal.

On Wed, Feb 5, 2020 at 2:21 PM Tal Mizrahi <[e-mail]>
wrote:

> 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.
>