Re: [ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state

[[e-mail]]

Hi Gyan,
many thanks for your comments and suggestions; all are much appreciated. Please find our answers and notes in-lined below under the GIM>> tag.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [e-mail]
www.zte.com.cn
------------------Original Mail------------------
Sender: GyanMishra
To: gregory mirsky10211915;
CC: [e-mail];tpauly=[e-mail];
Date: 2021/07/02 09:30
Subject: Re: [ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state

Dear Authors

Few questions.

The solution appear to be data plane agnostic and can apply to any data plane.  Correct?
GIM>> Yes. The scope of this draft is to define constract that can be re-used in echo request/reply mechanisms, e.g., ICMP, LSP ping.

I would add SR to list of data planes or just say that the solution is data plane agnostic applies to all data planes.
GIM>> Thank you for the suggestion. Will add in the next version.

Also the recommended feasible method of deployment is to use PCE or PCE CC  SDN centralized controller.

In the introduction towards the bottom below is stated.

“ The IOAM encapsulating node can acquire these IOAM capabilities info from the centralized controller, through, e.g., NETCONF/YANG, PCEP, or BGP.”
As for centralized controller do you mean to say PCE or PCE CC-CCI object PCE/SDN centralized controller.
GIM>> PCE or PCE CC-CCI object PCE/SDN controller is one of possible realizations of a centralized controller. in your opinion, would referring to it as an example be helpful?
You may want to state that the centralized controller option is the recommended method and reasons why.
GIM>> We'll work on a new text for the next version of the draft.
For IGP scenario would you need an IGP extension - much more complicated, or I guess you could use ISIS instance or OSPF transport mode to carry the metadata.  I think it maybe better to drop the IGP scenario.
GIM>> I agree, the optional use of IGP may bring challenges without sufficient benefits. We'll investigate it further and share our thoughts in short time.

Kind Regards
Gyan

On Fri, Jul 2, 2021 at 11:59 AM Gyan Mishra <[e-mail]> wrote:
Dear Authors

I support WG adoption.

This is a valuable telemetry tool in the operators toolbox for in-situ IOAM transit nodes data container  encap / decap within IOAM domain, with this extension to existing OAM echo-request/reply used in IPv6, MPLS, SFC, BIER, SR.

Highly valuable to operators.

Gyan

On Thu, Jul 1, 2021 at 10:30 PM <[e-mail]> wrote:
Hi Tommy and Ian,
I support the adoption of this draft (as co-author).

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [e-mail]
www.zte.com.cn
Original Mail
Sender: TommyPauly
To: IETF IPPM WG ([e-mail]);
Date: 2021/07/01 09:48
Subject: [ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm

Hello IPPM,
Back in November, we had a call for adoption for draft-xiao-ippm-ioam-conf-state that led to several questions, and we asked for revised drafts.

We’ve gotten several new versions, so Ian and I would like to re-start the adoption call to get people’s input on the current version.

https://datatracker.ietf.org/doc/html/draft-xiao-ippm-ioam-conf-state-10

Please review the document and reply to the list to indicate if you support adopting this work by Thursday, July 15.

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm
--

Gyan Mishra
Network Solutions Architect
Email [e-mail]
M 301 502-1347
--

Gyan Mishra
Network Solutions Architect
Email [e-mail]
M 301 502-1347