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

[Tal Mizrahi <[e-mail]>]

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.