Subject: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Summary, November 4th, 2020

From: Tal Mizrahi <[email-masked]>
Date: Wed, 4 Nov 2020 09:49:45 +0200

IPPM IOAM Design Team
Virtual meeting
November 4th, 2020, 07:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Tal Mizrahi.

Minutes by Tal Mizrahi.

Summary:
========
- Draft presentations for IETF 109 will be sent out to the design team
for review in the next few days.
- The next IOAM virtual meeting will be on November 25th at 07:00 UTC.

Detailed Discussions:
=====================

Direct exporting draft:
=======================
- Tal: DEX  - we submitted a new version. Hop Count is not included in
the DEX option header, but the issue is discussed in an appendix. Will
be further discussed next week in IETF 109.
- Tal: another open issue that we discussed in the past was the DEX
option length, which is either 8 or 16 bytes, and the length is
implicitly known from lower layer headers. This is a problem if new
fields will ever be added in the future. There was a suggestion to add
one or two flags to the DEX option header, indicating whether the two
optional fields (Flow ID, Sequence Number) are there or not.
- Barak: why not a single flag?
- Tal: it is an open question whether we want one flag or two flags.
If there are two flags there is a question of what happens if only one
of the flags is set - is it a valid combination?
- Barak: I suggest a single flag.
- Frank: why do we need a sequence number field? We have it in the E2E
option. We do not want to have two options for doing the same thing.
- Barak: do we have a flow ID in E2E?
- Shwetha: no.
- Tal: regardless of this question, we still have the question about
the length of the DEX option, which requires a flag.
- Barak: or we can remove the optional fields and have a single length.
- Tal: that will not necessarily be acceptable by everyone.
- Frank: right, we may want to remove the optional fields and have
them in a separate place, such as the E2E option.
- Tal: it sounds like a new issue: whether to remove the optional fields.
- Frank: it is a matter of uniformly handling such fields, rather than
defining them in each option separately.
- Tal: do we want to raise this as an open issue in the IETF meeting?
- Frank: we should add it as a discussion item.
- Tal: I will prepare a draft presentation for IETF 109.

New data field draft
====================
https://datatracker.ietf.org/doc/draft-gafni-ippm-ioam-additional-data-fields/
- Barak: I have submitted a new draft that defines new IOAM data fields.
- Frank: regarding the new draft, why is the port speed in the data
plane? Why is it not in the control plane?
- Barak: the purpose was to be able to do a data plane reaction. We
need a quick reaction. It is challenging to maintain this in the
control plane.
- Frank: what is the use case?
- Barak: the use case is related to the HPCC++ draft. It is described
in the draft.

AOB
===
- Frank: regarding the POT draft, Shwetha finished the comments about
WG last call.
- Frank: regarding the IPv6 draft, we have addressed Tommy's comments.
We will need to reduce the number of front page authors.
- Frank: regarding the raw export draft, Mickey has posted an updated
version and has asked for a WG adoption call. No responses yet.
- Frank: the YANG model draft is up for WG adoption.
- Tal: the flag draft: looks like we resolved the open issues. Will
present it next week in the IETF 109 meeting.
- Frank: I will present the IPv6 options draft next week.
- Tal: I will present the DEX and flags drafts. Will have draft
presentations in the next few days.

---

From: Haoyu Song <[email-masked]>
Date: Thu, 5 Nov 2020 00:31:42 +0000

Hi all,

It's funny that the issue of the optional field for sequence number is raised again. 
Frank said that the sequence number is in E2E option so it's not necessary here. I don't understand why?
We are talking about a different DEX option, why does it matter for the E2E option to have something or not?    

I'd like to recapitulate the consideration for the DEX option here: 
Each node on a path can send postcard packets to a collector. Since many flows and many user packets can trigger the postcard packets asynchronously, it's critical for the collector to correlate the postcards: i.e., to determine which set of postcards (each from one node on the path) is associated with a particular user packet. 

This can be achieved by the following mechanism: 

Flow ID -> bind a postcard to a flow
Sequence number -> along with the flow ID, bind a postcard to a particular user packet
Hop Count -> properly order the set of postcards with the same flow ID and sequence number

In the past, we mainly argued about the hop count but people have agreed that flow ID and sequence number are necessary in many cases, so we have settled to make them optional. But it seems we are backing to the original point one more time.

Best regards,
Haoyu

-----Original Message-----
From: Ippm-ioam-ix-dt <[email-masked]> On Behalf Of Tal Mizrahi
Sent: Tuesday, November 3, 2020 11:50 PM
To: [email-masked]
Subject: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Summary, November 4th, 2020

IPPM IOAM Design Team
Virtual meeting

Attendees:

Minutes by Tal Mizrahi.

Summary:
========
- Draft presentations for IETF 109 will be sent out to the design team for review in the next few days.
- The next IOAM virtual meeting will be on November 25th at 07:00 UTC.

Detailed Discussions:
=====================

Direct exporting draft:
=======================
- Tal: DEX  - we submitted a new version. Hop Count is not included in the DEX option header, but the issue is discussed in an appendix. Will be further discussed next week in IETF 109.
- Tal: another open issue that we discussed in the past was the DEX option length, which is either 8 or 16 bytes, and the length is implicitly known from lower layer headers. This is a problem if new fields will ever be added in the future. There was a suggestion to add one or two flags to the DEX option header, indicating whether the two optional fields (Flow ID, Sequence Number) are there or not.
- Barak: why not a single flag?
- Tal: it is an open question whether we want one flag or two flags.
If there are two flags there is a question of what happens if only one of the flags is set - is it a valid combination?
- Barak: I suggest a single flag.
- Frank: why do we need a sequence number field? We have it in the E2E option. We do not want to have two options for doing the same thing.
- Barak: do we have a flow ID in E2E?
- Shwetha: no.
- Tal: regardless of this question, we still have the question about the length of the DEX option, which requires a flag.
- Barak: or we can remove the optional fields and have a single length.
- Tal: that will not necessarily be acceptable by everyone.
- Frank: right, we may want to remove the optional fields and have them in a separate place, such as the E2E option.
- Tal: it sounds like a new issue: whether to remove the optional fields.
- Frank: it is a matter of uniformly handling such fields, rather than defining them in each option separately.
- Tal: do we want to raise this as an open issue in the IETF meeting?
- Frank: we should add it as a discussion item.
- Tal: I will prepare a draft presentation for IETF 109.

New data field draft
====================
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gafni-ippm-ioam-additional-data-fields%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C214803bad46f4a63209308d880963ecd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637400730077989718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=D2Hm0bPj89%2FWjsaUS4ZoGPL%2FNlG%2FYWkuKJSW4zLuzZU%3D&amp;reserved=0
- Barak: I have submitted a new draft that defines new IOAM data fields.
- Frank: regarding the new draft, why is the port speed in the data plane? Why is it not in the control plane?
- Barak: the purpose was to be able to do a data plane reaction. We need a quick reaction. It is challenging to maintain this in the control plane.
- Frank: what is the use case?
- Barak: the use case is related to the HPCC++ draft. It is described in the draft.

AOB
===
- Frank: regarding the POT draft, Shwetha finished the comments about WG last call.
- Frank: regarding the IPv6 draft, we have addressed Tommy's comments.
We will need to reduce the number of front page authors.
- Frank: regarding the raw export draft, Mickey has posted an updated version and has asked for a WG adoption call. No responses yet.
- Frank: the YANG model draft is up for WG adoption.
- Tal: the flag draft: looks like we resolved the open issues. Will present it next week in the IETF 109 meeting.
- Frank: I will present the IPv6 options draft next week.
- Tal: I will present the DEX and flags drafts. Will have draft presentations in the next few days.

--
Ippm-ioam-ix-dt mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm-ioam-ix-dt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C214803bad46f4a63209308d880963ecd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637400730077989718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=aWOI%2BbkG8qTIHDy23Wqt%2BoPAzenWyESs77xW9gOe97c%3D&amp;reserved=0