Subject: [Ippm-ioam-ix-dt] IPPM IOAM Exporting Design Team Meeting Minutes - Sep 4th, 2019

From: Tal Mizrahi <[email-masked]>
Date: Wed, 4 Sep 2019 10:56:29 +0300

IPPM IOAM Immediate Exporting Design Team
Virtual meeting
September 4th, 2019, 06:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Tal Mizrahi, Ramesh
Sivakolundu, Haoyu Song, Tianran Zhou.

Minutes by Tal Mizrahi.

Summary:
- The preliminary direct exporting draft was discussed:
https://github.com/inband-oam/ietf/blob/master/drafts/versions/00/draft-ioamteam-ippm-ioam-direct-export-00.txt
- The draft reflects the discussion we had over postcard telemetry and
immediate exporting.
- Open issues were discussed.
- An updated version of the draft will be posted on github next week.
- Next virtual meeting: September 18th at 06:00 UTC.
- Audio recording was not possible. Will try to arrange for an audio
recording in future meetings.

Introduction:
- Tal - a brief summary of the structure and content of the draft.
- Tal: this draft combines the concepts from the postcard draft and the
immediate export flag. A new term is used - "direct exporting". If there
are any comments about the term please let me know.

Immediate exporting flag:
- Tal: in the side meeting in Montreal it was suggested to define an
"immediate export" flag in the new option, but this seems redundant. Was
there a reason to have an explicit flag?
- Frank: no need for a flag if there is an explicit option.

Sequence number vs. timestamp field:
- Tal: there is an open issue about whether to use an optional sequence
number field, on a per flow basis, or a timestamp field, which does not
require per-flow state. Either way, this will be used for correlating
packets by the collector.
- Ramesh: why do we need a timestamp, and is it synchronized by IEEE 1588?
- Tianran: it may be heavy to require synchronization.
- Frank: no need for synchronization, as the timestamp would be pushed by
the encapsulating node, and only read by the collector. Similar to a
sequence number.
- Tal: right, no need for synchronization. The timestamp can be viewed as a
global sequence number (not per flow).
- Ramesh: why is the Flow ID field required?
- Frank: along with the Sequence Number it can be used by the collector for
correlating packets.
- Tianran: only the encapsulating node?
- Tal: yes.
- Tal: at this point the draft says Sequence Number per flow. If there is
no strong opinion to change it - we will stay with.

Flags field:
- Tal: currently there is a 16-bit flag field. No flags have been defined
yet. Flags will be allocated by IANA.
- Tianran: we also discussed conditional exporting (Actions).
- Tal: right, we discussed this in Montreal.
- Tianran: the flags field can be used for flags or for conditional
exporting. There is no need to add a separate "Actions" field.
- Tal: right.
- Tianran: I am okay with this. It captures the discussion we had in
Montreal.

Hop limit:
- Haoyu: having an explicit Hop Limit field in the Direct Exporting option
header is useful. I understand that the Hop_Lim/Node_ID data field can be
used, but let's remember that the Hop_Lim/Node_ID data field is optional.
Also, extracting the TTL from a lower layer requires some work. Having an
independent Hop Limit field is preferable. It is incremented by each IOAM
node. It can be useful to correlate packets. However, if there is no more
space available, then let's just use Hop_Lim/Node_ID data field.
- Barak: we had this discussion in Montreal. Let's stay with the
Hop_Lim/Node_ID data field. This is already an existing solution that is
used in the existing IOAM options. There is no reason for adding complexity
to transit nodes.
- Haoyu: the Hop_Lim/Node_ID data field is an optional data field. It is
not always present. That is the advantage of having a Hop Limit field.
- Barak: I understand that it is not the same, but if a hop limit is
required then you can enable the Hop_Lim/Node_ID data field. Anyway you
create an exported packet in each node, so it is more efficient to have a
Hop_Lim/Node_ID data field.
- Frank: I also do not see a reason to have an explicit Hop Limit field in
the option header. That would mean we would want to add this field across
the board to other option headers as well.
- Haoyu: here is a simple example where it is useful: if there is an IOAM
node that did not export a packet to the collector, then you don't know
whether the node dropped the exported packet, or it is just not there.
However, if the Hop Limit is not incremented you see that a node is missing.
- Shwetha: I see the value of having a Hop Limit, but its place is not
necessarily in the option header. It is more appropriate in the option
payload.
- Haoyu: along with the Flow ID and the Seq Number, the Hop Limit is used
to correlate the packets.
- Shwetha: the data packet that is being measured is copied, exported, and
forwarded. The TTL is copied. The question is should the TTL be part of the
option header or the option payload.
- Haoyu: the lower layer TTL value is not necesarily what you need. If
there is a missing TTL value, does it mean the exported packet was dropped,
or just an IOAM-encapable node?
- Frank: if the packet is dropped, then the collector doesn't see anything
at all. You do not have anything to correlate with.
- Haoyu: if hop count indicates one hop is missing, you know there is a
drop.
- Shwetha: Haoyu says that a Hop Limit in the IOAM layer indicates a
dropped exported packet at the IOAM layer.
- Frank: you are suggesting to add another field to the option header,
i.e., extend the header length?
- Haoyu: it can be part of the existing header, as suggested in the
Postcard draft.
- Frank: the disadvantage is that every single device will have to update
this field. The tradeoff here is you get more information, at the cost of
the burden of updating this field in each transit node. One of the main
reasons for direct exporting was to simplify transit nodes.
- Haoyu: yes, you need to update in each node, but it is not more
complicated than updating a TTL.
- Shwetha: in Incremental or Pre-allocated options if you have
Hop_Lim/Node_ID data field in the option payload, then you are editing the
data packet for this field. In Direct Exporting we do not want to edit the
data packet itself at all.
- Tianran: an alternative way is to define the Hop Limit as optional, and
use some bits from the flags as a Hop Limit. We do not need so many flags.
- Shwetha: editing the option while the packet travels - this issue is more
significant than the number of bits.
- Barak: updating the Hop Limit is a read-modify-write, which makes it
difficult.
- Haoyu: if there is no explicit field, then the only option is to use the
Hop_Lim/Node_ID data field with its drawbacks.

Removal by decapsulating nodes:
- Frank: I suggest to change "A decapsulating node that does not support
the DEX option SHOULD remove it" - let's change the SHOULD to a MUST.
Leaking is a major concern.
- Tal: I am fine with that.
- Haoyu: yes, it should be consistent with other IOAM options.
Decapsulating nodes MUST remove.
- Tianran: yes, it is important.
- Tal: makes sense.

Other issues:
- Tal: any other comments?
- Frank: barak - you okay with current Flow ID / Seq Number?
- Barak: will review it more. Mickey also had some comments about it.
- Frank: comments can be posted either on GitHub, or sent to the design
team maling list.
- Frank: another question - how do you know if optional fields (Flow ID and
Seq Number) are there or not?
- Tal: the draft says that based on the lower layer header you know the
length of the option - either 8 octets or 16 octets.
- Haoyu: another option would be to use flags to indicate the existence of
the Flow ID and Seq Number.
- Frank: that would be redundant. We went for this solution because it is
simply two possible options: either with the two optional fields or without
them.
- Frank: It would be great to post the draft and get feedback from the IPPM
working group before Singapore.
- Tal: Next meeting in two weeks. Updated draft to be posted on GitHub next
week.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 10 Sep 2019 14:54:40 +0300

Hi,

An updated version was posted on Github, based on the comments from the
meeting.
https://github.com/inband-oam/ietf/blob/master/drafts/versions/00/draft-ioamteam-
ippm-ioam-direct-export-00.txt

The next meeting will be on Sep. 18th at 06:00 UTC.

Thanks,
Tal.

On Wed, Sep 4, 2019 at 10:56 AM Tal Mizrahi <[email-masked]>
wrote:

> - Tal: right, no need for synchronization. The timestamp can be viewed as
> a global sequence number (not per flow).
> - Frank: along with the Sequence Number it can be used by the collector
> for correlating packets.
> - Shwetha: editing the option while the packet travels - this issue is
> more significant than the number of bits.
> - Frank: another question - how do you know if optional fields (Flow ID
> and Seq Number) are there or not?
> - Frank: It would be great to post the draft and get feedback from the
> IPPM working group before Singapore.
> - Tal: Next meeting in two weeks. Updated draft to be posted on GitHub
> next week.
>

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 18 Sep 2019 07:59:53 +0300

Hi,

This is a reminder that the IPPM IOAM Exporting virtual meeting will take
place in about an hour, at 06:00 UTC.

Webex details (ietf.webex.com) are as follows:

Meeting number (access code): 646 487 538
Meeting password: y2JXZa3H

Cheers,
Tal.

On Tue, Sep 10, 2019 at 2:54 PM Tal Mizrahi <[email-masked]>
wrote:

>> - Haoyu: having an explicit Hop Limit field in the Direct Exporting
>> option header is useful. I understand that the Hop_Lim/Node_ID data field
>> can be used, but let's remember that the Hop_Lim/Node_ID data field is
>> optional. Also, extracting the TTL from a lower layer requires some work.
>> Having an independent Hop Limit field is preferable. It is incremented by
>> each IOAM node. It can be useful to correlate packets. However, if there is
>> no more space available, then let's just use Hop_Lim/Node_ID data field.
>> - Frank: I also do not see a reason to have an explicit Hop Limit field
>> in the option header. That would mean we would want to add this field
>> across the board to other option headers as well.
>> - Shwetha: the data packet that is being measured is copied, exported,
>> and forwarded. The TTL is copied. The question is should the TTL be part of
>> the option header or the option payload.
>> - Frank: if the packet is dropped, then the collector doesn't see
>> anything at all. You do not have anything to correlate with.
>> - Haoyu: if there is no explicit field, then the only option is to use
>> the Hop_Lim/Node_ID data field with its drawbacks.
>>
>>
>> - Haoyu: another option would be to use flags to indicate the existence
>> of the Flow ID and Seq Number.