Subject: [ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

From: Tianran Zhou <[email-masked]>
Date: Fri, 15 Feb 2019 09:27:06 +0000

Hi Authors,

I am reading this draft. And I think this is an interesting work.
I have several comments as follows based on our implementation.

1. In 2.1, I suggest to separate the IOAM capability TLV format in request and reply. Specifically, I do not see how the sub-tlv related fields is useful in the request.

2. " If there is no IOAM capabilities to be reported by the receiving node, then this TLV SHOULD be ignored by the receiving node. "
What's the exact meaning of "be ignored"? No reply or reply with a notification? It's better to be clear.

3. " List of Namespace-IDs MAY be included in this TLV of echo reply. It means that the IOAM capabilities included in this TLV match one of the Namespace-IDs."
This feature is useful. But I see each "Capabilities sub-TLV " also contains the "Namespace-ID". This is redundancy. We can infer the supported Namespace-IDs from the Capabilities sub-TLV.
So I suggest not to contain the "List of Namespace-IDs" in the echo reply.

4. "F bit is specified to indicate whether the pre-allocated trace or incremental trace is enabled. "
I suggest not to use the "F bit". Instead, why not use two "Sub-type", i.e., pre-allocated trace or incremental trace, for the capability?

5. "If the IOAM encapsulating node receives different F bit value from different IOAM transit node, then the IOAM encapsulating node will reserve data space in the IOAM header for the IOAM transit node that set F bit to 1, and the IOAM encapsulating node won't reserve data space in the IOAM header for the IOAM transit node that set F bit to 0."
I think this description is not comprehensive. There may be one use case (not sure) that both pre-allocated tracing node and incremental tracing node are in the same path.
I think how to deal with this case is out of the scope of this capability interaction draft. It's better to remove these words.

6. 2.1.4. IOAM End-of-Domain sub-TLV
I suggest not to have this sub-tlv. Other sub-tlvs should not indicate the action role(encap/transit/decap) of the node neither.
IMHO, IOAM operations could be flow based. That means, for one flow, one node could be an encap node. But for another flow, the same node could be an transit.

7. The Operational Guide part is very useful. It shows how this feature is used. But I am lost with your description. 
My understanding is the "ping" like request is send to a specific node for its capability.
But you said: "the IOAM encapsulating node will send a batch of echo requests that include the IOAM Capabilities TLV, first with TTL equal to 1 to ..., then with TTL equal to 2 to ..."
What's the transport protocol you used in this context? What's the destination address in the request? Does the TTL expiration trigger the reply?

8. Still in the Operational Guide part, "until the IOAM encapsulating node receives echo reply sent by the IOAM decapsulating node"
I think this should not be the termination condition for the request process. Are you indicating there is only one decapsulation node in one IOAM domain? This is not true in many cases.

Cheers,
Tianran

---

From: <[email-masked]>
Date: Tue, 19 Feb 2019 15:50:19 +0800 (CST)

Hi Tianran,

Thanks for the thorough review and concrete comments, pls see my reply inline with [XM]...

原始邮件

发件人：TianranZhou <[email-masked]>
收件人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年02月15日 17:29
主 题 ：[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

Hi Authors,

I am reading this draft. And I think this is an interesting work.
I have several comments as follows based on our implementation.
[XM]   Very glad to know you think this is an interesting work.

1. In 2.1, I suggest to separate the IOAM capability TLV format in request and reply. Specifically, I do not see how the sub-tlv related fields is useful in the request.
[XM]   Accepted. Will specify IOAM Capabilities TLV of echo request and that of echo reply in different sections, to make it more readable.

2. " If there is no IOAM capabilities to be reported by the receiving node, then this TLV SHOULD be ignored by the receiving node. "
What's the exact meaning of "be ignored"? No reply or reply with a notification? It's better to be clear.
[XM]   Here "be ignored" means echo reply without IOAM Capabilities TLV if the echo request includes other TLVs, or no echo reply if the echo request doesn't include any other TLV except for this TLV. Will make it more clear in the next revision.

3. " List of Namespace-IDs MAY be included in this TLV of echo reply. It means that the IOAM capabilities included in this TLV match one of the Namespace-IDs."
This feature is useful. But I see each "Capabilities sub-TLV " also contains the "Namespace-ID". This is redundancy. We can infer the supported Namespace-IDs from the Capabilities sub-TLV.
So I suggest not to contain the "List of Namespace-IDs" in the echo reply.
[XM]   Make sense. Will remove the "List of Namespace-IDs" in the echo reply.

4. "F bit is specified to indicate whether the pre-allocated trace or incremental trace is enabled. "
I suggest not to use the "F bit". Instead, why not use two "Sub-type", i.e., pre-allocated trace or incremental trace, for the capability?
[XM]   Good suggestion. This change makes the echo reply more flexible and more clear. Will include this change in the next rivision.

5. "If the IOAM encapsulating node receives different F bit value from different IOAM transit node, then the IOAM encapsulating node will reserve data space in the IOAM header for the IOAM transit node that set F bit to 1, and the IOAM encapsulating node won't reserve data space in the IOAM header for the IOAM transit node that set F bit to 0."
I think this description is not comprehensive. There may be one use case (not sure) that both pre-allocated tracing node and incremental tracing node are in the same path.
I think how to deal with this case is out of the scope of this capability interaction draft. It's better to remove these words.
[XM]   Accepted. Will remove these words in the next revision, and add a statement that this potentially feasible use case is out of scope of this draft.

6. 2.1.4. IOAM End-of-Domain sub-TLV
I suggest not to have this sub-tlv. Other sub-tlvs should not indicate the action role(encap/transit/decap) of the node neither.
IMHO, IOAM operations could be flow based. That means, for one flow, one node could be an encap node. But for another flow, the same node could be an transit.
[XM]   Actually I'v ever received a relevant question - How do you provide flow awareness?

The thoughts are straightforward that the echo request would follow the SR path or SFC path as the life traffic, and it helps the IOAM encap node to get IOAM capabilities of all nodes along the path, so we may say the mechanism defined in this draft is path-based. As to the IOAM-treatment differentiation of many flows that follow the same SR path or SFC path, it's out of scope of this draft.

Back to your comment, although I agree that this sub-TLV would rarely be used, I suggest to reserve it for the time being and revisit it afte we get more experience of IOAM operation.

[XM]   The typical usage of the feature described in this draft is similar to traceroute, which can be seen as a series of successive pings with incremental different TTL, and yes, TTL expiration triggers the echo reply.

With respect to the transport protocols, three kinds of them are identified in this draft, i.e. SR-MPLS, SRv6 and SFC, the type of destination address is tightly bound to the used transport protocol.

8. Still in the Operational Guide part, "until the IOAM encapsulating node receives echo reply sent by the IOAM decapsulating node"
I think this should not be the termination condition for the request process. Are you indicating there is only one decapsulation node in one IOAM domain? This is not true in many cases.
[XM]   No, the text doesn't indicate there is only one decapsulation node within an IOAM domain, nevertheless, the text indicates there is only one decapsulation node along a specific SR path or SFC path. For a specific SR path or SFC path, the process defined in this draft need to be executed only once, and the process would be repeated for every SR path or SFC path that runs IOAM.

Cheers,
Tianran

Best Regards,

Xiao Min

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 26 Feb 2019 07:10:44 +0000

Hi Min,

Thank you for accepting most of my suggestions. Here let’s focus on the remain questions.
Please see inline.

Best,
Tianran

[ZTR] I am not sure if I understand the “flow awareness” correctly. When we use IOAM in native IP network, not SR based, we can use ACL to identify a flow, and add IOAM header to packets. We do not know the exact path the flow traversed.

[XM] The thoughts are straightforward that the echo request would follow the SR path or SFC path as the life traffic, and it helps the IOAM encap node to get IOAM capabilities of all nodes along the path, so we may say the mechanism defined in this draft is path-based. As to the IOAM-treatment differentiation of many flows that follow the same SR path or SFC path, it's out of scope of this draft.

Back to your comment, although I agree that this sub-TLV would rarely be used, I suggest to reserve it for the time being and revisit it afte we get more experience of IOAM operation.
[ZTR] Do you assume this capability request feature can only be applied to the network with “strict explicit path”? If so, it’s better to claim this in the document.

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 19, 2019 3:50 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re:[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

Hi Tianran,

Thanks for the thorough review and concrete comments, pls see my reply inline with [XM]...
原始邮件
发件人：TianranZhou <[email-masked]<mailto:[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年02月15日 17:29
主 题 ：[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02
Hi Authors,

Cheers,
Tianran

Best Regards,

Xiao Min
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: <[email-masked]>
Date: Tue, 26 Feb 2019 17:42:29 +0800 (CST)

Hi Tianran,

Please see my reply inline with [XM2]...

原始邮件

发件人：TianranZhou <[email-masked]>
收件人：肖敏10093570;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年02月26日 15:11
主 题 ：RE: Re:[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

Hi Min,

Please see inline.

Best,

Tianran

[XM2] Following your example when IOAM is used in native IP network, I have the below question:

How can the IOAM encap node know what kind of IOAM header (e.g. data space size within the trace option) it should add if the exact path is unknown?

[XM2] Yes, that's my assumption. Will add this claim as you suggest in the next revision.

Best Regards,

Xiao Min 

 

Hi Tianran,

原始邮件

日 期 ：2019年02月15日 17:29

Hi Authors,

Cheers,
 Tianran

Best Regards,

Xiao Min

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 27 Feb 2019 02:03:29 +0000

Hi Min,

For this question:

How can the IOAM encap node know what kind of IOAM header (e.g. data space size within the trace option) it should add if the exact path is unknown?
[ztr]: The kind of IOAM header depends on the user’s intent. What function the operator wants to achieve. Say if the operator wants to trace the nodes/path the flow traversed, the tracing option may be applied, with node-id/interface-id attached.
The size of the data space is unknown. For the incremental tracing option, the header space is not fixed. For the pre-allocated tracing option, the header space is fixed with prediction.

Yours,
Tianran

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 26, 2019 5:42 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re:RE: Re:[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

Hi Tianran,

Please see my reply inline with [XM2]...
原始邮件
发件人：TianranZhou <[email-masked]<mailto:[email-masked]>>
收件人：肖敏10093570;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年02月26日 15:11
主 题 ：RE: Re:[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02
Hi Min,

Best,
Tianran

Best Regards,

Xiao Min

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, February 19, 2019 3:50 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

Hi Tianran,

Cheers,
Tianran

Best Regards,

Xiao Min

---

From: <[email-masked]>
Date: Wed, 27 Feb 2019 11:53:54 +0800 (CST)

Hi Tianran,

Please see my reply inline with [XM3]...

原始邮件

发件人：TianranZhou <[email-masked]>
收件人：肖敏10093570;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年02月27日 10:25
主 题 ：RE: Re:RE: Re:[ippm] Comments on draft-xiao-ippm-ioam-conf-state-02

Hi Min,

For this question:

[XM3] Thank you for the clear answer. I see much uncertainty in this example, although I agree that we can predict the data space size for the pre-allocated tracing option, we can predict the path MTU, we can predict the supported timestamp format, we can predict the supported Namespace-ID, and so on, I'm sure this scenario of native IP network is outside the scope of this draft.

Yours,

Tianran

Best Regards,

Xiao Min 

 

Hi Tianran,

原始邮件

收件人：肖敏10093570;

日 期 ：2019年02月26日 15:11

Hi Min,

Please see inline.

Best,

Tianran

Best Regards,

Xiao Min 

 

Hi Tianran,

原始邮件

日 期 ：2019年02月15日 17:29

Hi Authors,

Cheers,
 Tianran

Best Regards,

Xiao Min