[ippm] Comments for draft-fz-ippm-alt-mark-deployment

[Chongfeng Xie <[e-mail]>]

Hello, folks,
I have given a review to draft-fz-ippm-alt-mark-deployment. This draft discusses the deployment considerations of Alternative Marking, which is helpful for operators to timely understand and master the performance of the network. therefore, I think this document is very useful and hope it can proceed smoothly in the future. In addition, I have the following comments and suggestions:
1) The first point is about the scope of the framework. Section 5 introduces "Manageability", which refers to configuring Alternate Marking in network nodes that support it, including to signal and configure the parameters to identify the flow to monitor. In Section 6, the main focus is on data collection and calculation, and an Alternative Marking Framework with Data Export, including NMS, is specifically provided. At present, it seems that this Framework in figure 2 does not include the configuration features described in section 5. In the operator network, it is likely that the configuration functions are implemented by the controller. I think that the Alternative Marking Framework should include both configuration and data export, in other words, the framework should also include so-called configuration functions, configuration and data collection form a closed loop between the system and the underlying network nodes. 
2) NMS is a general and vague terminology, different operators may have different understandings and scopes of it. In particular, over the years, network management and operation have undergone many changes, making it difficult to use NMS to precisely cover related content. Therefore, it is recommended to avoid using the term NMS here, instead, this framework can be illustrated by showing the functional modules and interfaces between the modules and underlying network nodes in handling Alternative Marking.
3) In addition, the IPv6 based Alternative Marking encapsulation utilizes HBH and Destination extension headers, so it is required that the underlying network enable functions related to the above extension headers. However, to my knowledge, most IPv6 networks do not pay much attention to the operation of HBH and Destination Option headers. Therefore, it is recommended to clearly indicate that the transmission and processing of extension headers should be enabled in order to support Alternative Marking.
In the end, I would like to express my thanks to the authors for their work.I also hope the comments above have some values for the authors. Thank you!

Cheers
Chongfeng