Re: [ippm] about draft-zhou-ippm-enhanced-alternate-marking-03.txt

[Tianran Zhou <[e-mail]>]

Hi Haoyu,

Thank you very much for your interest and comments.
Please see in line.

Tianran

-----邮件原件-----
发件人: Haoyu Song [mailto:[e-mail]] 
发送时间: 2019年10月18日 3:24
收件人: '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>
主题: about draft-zhou-ippm-enhanced-alternate-marking-03.txt

(resent cause the original email didn't go through)

Hi Tianran and authors，

This draft provides a light-weighted solution to support both alternate marking and PBT-M at the same time. Given the use cases of alternate marking have been well established, I believe this enhanced proposal will support more interesting and powerful use cases and address a different set of in-band measurement problems from IOAM.

However, even the proposed data fields are short, the encapsulation requirement is the same as that for IOAM (note that the original PBT-M only needs to borrow a single existing header bit). Any thoughts on this?

ZTR> Yes, you are right. There is no free lunch. While a structure can take more information, we need to consider how to carry it in the encapsulation protocol. In IPv6, we consider the way to mitigate the compatibility with non-capable devices. It could be encapsulated in the DOH or SRH. So that the intermediate node will not drop packets.

The collisions of flow ID, even if the probability is low, can cause measurement errors. How can you avoid it?

ZTR> As mentioned in the draft, there are two ways to assign the flow ID. 
One is to be assigned by the central controller. So it's easy to avoid the collision.
The other way is to assign the flow ID by the ingress node locally. In our implementation, an extended flow ID is used. That is to say, the flow ID in this structure is for the basic need. It's used for a local/private part. An extended flow ID with global part information could be carried in other way in the encapsulation protocol.

Thanks!
Haoyu