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

[<[e-mail]>]

Hi Tianran,






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




原始邮件



发件人：TianranZhou <[e-mail]>
收件人：[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
日 期 ：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.




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?
[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
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm