Re: [Ippm-ioam-ix-dt] Proposed change to the draft

[Haoyu Song <[e-mail]>]

I also think Tianran raised a legitimate question: what if you can’t extract a changing TTL field to fill the Hop_Lim, such as in a L2 network？There are more complicated scenarios such as  tunneling to make TTL unreliable.
Also, the essence of the direct export is that the intermediate node wont insert new data to the packet. This hop count is not a trace data. It’s just a metadata helping to correlate the exported postcard packets.
Except that it needs an update operation per hop, I can’t see any other problem.
Haoyu

From: Tianran Zhou <[e-mail]>
Sent: Tuesday, September 24, 2019 3:57 AM
To: Frank Brockners (fbrockne) <[e-mail]>; Haoyu song <[e-mail]>; ippm-ioam-ix-dt <[e-mail]>; Tal Mizrahi <[e-mail]>
Subject: RE: Proposed change to the draft

Hi Frank,

I do not think update the hop count violate the directly export.
We directly export the metadata collected according to the ioam data types, without accumulating them in the packet. That’s the big difference to existing two trace types.
Hop count is something need to assist the correlation. It’s part of the mechanism for the directly export of metadata.

Tianran



________________________________
Sent from WeLink
发件人： Frank Brockners (fbrockne)<[e-mail]<mailto:[e-mail]>>
收件人： Tianran Zhou<[e-mail]<mailto:[e-mail]>>;Haoyu song<[e-mail]<mailto:[e-mail]>>;ippm-ioam-ix-dt<[e-mail]<mailto:[e-mail]>>;Tal Mizrahi<[e-mail]<mailto:[e-mail]>>
主题： RE: Proposed change to the draft
时间： 2019-09-24 18:09:41


IMHO we should separate the discussion on Direct Export from the hop-count discussion:
The original approach of Immediate Export, now called Direct Export, was to create a mode for IOAM, which avoids collecting information in the packet while the packet progresses through the network, but exports the information at every hop.
This makes Direct Export different from IOAM tracing, which updates the IOAM fields while the packet progresses through the network.
If we start to update IOAM fields, like hop-count, while the packet progresses through the network, we create a new flavor of IOAM tracing, as opposed to do immediate export – and we should call it as such.
Frank

From: Ippm-ioam-ix-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Tianran Zhou
Sent: Dienstag, 24. September 2019 11:49
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>; Haoyu song <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Tal Mizrahi <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Ippm-ioam-ix-dt] Proposed change to the draft

Hi Team,

Again, about the hop count.
I would suggest to allocate a 1 byte field from flags for the hop count.
At the same time, we can use one bit flag to enable/disable the hop count function.
That is to say, if the flag is set to zero, do not operate the hop count.
If the flag is set to one, hop count ++.
In this way, I think there is no worry for the transit node to operate when the use case does not need hop count.
What’s your thoughts.

Tianran

From: Ippm-ioam-ix-dt [mailto:[e-mail]] On Behalf Of Tianran Zhou
Sent: Monday, September 23, 2019 3:40 PM
To: Haoyu song <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Tal Mizrahi <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Ippm-ioam-ix-dt] Proposed change to the draft

Hi All,

I am sorry I cannot access the meeting due to the link quality. I would like to know some discussion details on the hop count.
Firstly, I think this field is necessary. In addition to Haoyu’s comments, my add on is the usage when the lower layer encapsulation does not have the ttl information. This is common case. I also know some case that the ttl is not continued, e.g., hvpn. So in anyway, I wish it could be attached, optional or fixed.
Secondly, the IOAM-Trace-Type bitmap has one bit to indicate the presence of hop_lim. I am thinking if we can reuse it. If this bit is set, where to put this field? So that every transit node can operate it?

Thanks,
Tianran


From: Ippm-ioam-ix-dt [mailto:[e-mail]] On Behalf Of Haoyu song
Sent: Thursday, September 19, 2019 1:41 AM
To: ippm-ioam-ix-dt@ietf..org<mailto:[e-mail]>; Tal Mizrahi <[e-mail]<mailto:[e-mail]>>
Subject: [Ippm-ioam-ix-dt] Proposed change to the draft

Hi Team,
Below is my proposed change. I tried to directly update in Github but the format is not correct, so Tal please help to edit the text and merge it into the current draft. Thanks!
Haoyu
-----------------------------------
To help correlate and order the exported postcard packets for the same original packet, it is possible to include a 1-byte Hop_Count field in the DEX header (presumably by claiming some space from the Flags field), which starts from 0 and increments its value by one at every IOAM-enabled hop. The Hop_Count field value needs to be included in the exported postcard packet. An issue of this field is that it needs to be updated at every IOAM-enabled hop. Without it, the DEX header is basically read-only except that it will be inserted at a head node and removed at an end node.
An alternative approach is to request to collect the Hop_Lim/Node_ID data by setting the corresponding bit in the IOAM-Trace-Type bitmap.  The Hop_Lim data is acquired from the lower level protocol header such as TTL for IPv4 and Hop Limit for IPv6. In addition to requiring extra packet parsing, Hop_Lim must be coupled with Node_ID which means 4 bytes are needed to be exported. More important, Hop_Lim is not exactly equivalent to Hop_Count, because Hop_Lim is updated at every hop, whether the hop is IOAM-enabled or not. A consequence is, by monitoring Hop_Lim only, if some value is missing, one cannot tell whether or not an exported postcard packet is missing.
Therefore, further discussion is needed to decide if the DEX header should include an explicit Hop_Count field, or by default, set the IOAM-Trace-Type bit to collect the Hop_Lim/Node_ID data field.