[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes, September 30th, 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
September 30th, 2020, 06:00 UTC
Webex meeting

Attendees:
Frank Brockners, Barak Gafni, Mickey Spiegel, Tal Mizrahi.

Minutes by Tal Mizrahi.


Summary:
========
- Barak is looking for some more feedback about the draft he is working on.

https://github.com/inband-oam/ietf/blob/master/drafts/draft-gafni-ippm-ioam-additional-data-fields.xml
- Tal will creat a pull request with the suggested updates to the flag
draft.
- The next meeting will be on the 14th of October.


Discussion:
===========

Additional Data Fields
======================
Barak's suggested draft:
https://github.com/inband-oam/ietf/blob/master/drafts/draft-gafni-ippm-ioam-additional-data-fields.xml

- Tal: if new fields are defined it would be best to define the semantics.
For example, port speed - it would be more useful if the field was
well-defined with the possible speed values.
- Barak: I prefer to keep the flexibility, and not to limit the possible
values.
- Frank: not sure port speed will help. There are many port speed modes.
How far do we want to go? Once you think beyond Ethernet 6 bits may not be
enough. Another question is: the draft refers to a 'port' - is it the same
as interface?
- Barak: not sure yet.
- Frank: if a port is a separate entity than an interface it needs to be
well-defined. You may want to just refer to an interface. There are many
requests for new fields. I would suggest to add more text about the use
cases. Also consider using the Namespace-specific field.
- Barak: 32 bits may not be enough. By the way, there is running code that
does what the draft describes.
- Frank: you may want to add a reference to that running code or to a paper
that describes it.
- Mickey: the motivation of this draft sounds good. Whether the actual way
it suggests to do it is the right way - I will look into it.


Flag draft
==========
- Tal: regarding the loopback open issue - I sent our suggested solution to
the mailing list, with no responses so far. I suggest to create a pull
request that we can review, and take it from there.
- Frank: right.


Direct Exporting Draft
======================
- Tal: we asked the WG chairs to help resolve the open issue. Tommy has
sent a response with some clarifying questions. It is important that we
will have some time in IETF 109 to resolve this issue. Hopefully the chairs
will suggest a solution.
Frank: yes, we can wait for that discussion.
Tal: the draft already defines two flavors of the DEX option (with /
without flow ID), so it may become also two flavors in terms of the hop
count field.
Mickey: the hop count can't be optional. By 'optional' I mean that some
nodes support it and some nodes do not. That will not work.
Barak: you can define by management whether the network as a whole supports
hop count or not.
Mickey: that would mean you had to support both options.
Frank: so if I do not support the hop count option, what would I do?
Barak: that would be a management issue. If one of the nodes can't support
hop count, then the network can't use the hop count. This is the simplest
solution.
Mickey: I believe it is not important enough to create an interoperability
issue.
Frank: the problem is that it is just a re-implementation of something you
can already do with existing data fields.
Mickey: I believe it was claimed that the Hop Count has advantages over
copying the TTL field from lower layers.
Frank: the main thing is that we do not want to end up with a variety of
options. Then the simplicity of DEX would be gone.
Barak: I agree.
Tal: I will send another reminder on the mailing list.