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

[Tal Mizrahi <[e-mail]>]

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 <[e-mail]>
wrote:

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