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

From: Tommy Pauly <[email-masked]>
Date: Thu, 01 Jul 2021 09:48:28 -0700

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 <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

---

From: <[email-masked]>
Date: Fri, 2 Jul 2021 09:08:36 +0800 (CST)

Hi Tommy & Ian,

I support WG adoption of this draft (as co-author).

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：TommyPauly
收件人：IETF IPPM WG ([email-masked]);
日 期 ：2021年07月02日 00:49
主 题 ：[ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state
_______________________________________________
ippm mailing list
[email-masked]
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

---

From: <[email-masked]>
Date: Fri, 2 Jul 2021 10:30:00 +0800 (CST)

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: [email-masked] 
www.zte.com.cn

Original Mail

Sender: TommyPauly
To: IETF IPPM WG ([email-masked]);
Date: 2021/07/01 09:48
Subject: [ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

Best,

Tommy & Ian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 2 Jul 2021 11:59:44 -0400

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 <[email-masked]> wrote:

> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> *Sender: *TommyPauly
> *To: *IETF IPPM WG ([email-masked]);
> *Date: *2021/07/01 09:48
> *Subject: **[ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state*
> 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.
>
> Please review the document and reply to the list to indicate if you
> support adopting this work by *Thursday, July 15*.
>
> Best,
> Tommy & Ian
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 2 Jul 2021 12:29:45 -0400

Dear Authors

Few questions.

The solution appear to be data plane agnostic and can apply to any data
plane.  Correct?

I would add SR to list of data planes or just say that the solution is data
plane agnostic applies to all data planes.

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.

You may want to state that the centralized controller option is the
recommended method and reasons why.

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.

Kind Regards

Gyan

On Fri, Jul 2, 2021 at 11:59 AM Gyan Mishra <[email-masked]> 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.
>
>> 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.
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Sun, 4 Jul 2021 11:33:21 +0800 (CST)

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
------------------Original Mail------------------
Sender: GyanMishra
To: gregory mirsky10211915;
CC: [email-masked];tpauly=[email-masked];
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.

“ 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

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.

Gyan

Regards,
Greg Mirsky

Hello IPPM,

Best,
Tommy & Ian

Gyan Mishra
Network Solutions Architect
Email [email-masked]
M 301 502-1347
--

Gyan Mishra
Network Solutions Architect
Email [email-masked]
M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 4 Jul 2021 19:21:48 -0400

Hi Greg

Most Welcome.

Anything I can do to help advancement and improvement of the draft as this
draft is important for operators.

Responses in-line

On Sat, Jul 3, 2021 at 11:33 PM <[email-masked]> wrote:

> 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
> 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.

 Gyan> Ack

> “ The IOAM encapsulating node can acquire these IOAM capabilities info
> from the centralized controller, through, e.g., NETCONF/YANG, PCEP, or BGP.”
> 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?

Gyan> Yes I agree that would be helpful.  Maybe in the section where you
add the example you can add corresponding verbiage as to the reasons for
recommendation of use of centralized controller.

> GIM>> We'll work on a new text for the next version of the draft.

    Gyan> Ack

> 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.

   Gyan> Ack.  I can investigate as well  with experts on LSR as to using
special non routing ‘transport style’ instance that we have available today
for metadata if possible to carry the IOAM data capability signaling.

> 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.
>
> support adopting this work by Thursday, July 15.
>
> Best,
> Tommy & Ian

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 9 Jul 2021 16:54:39 +0800 (CST)

Support the adoption. 
Thanks,
Sandy

------------------原始邮件------------------
发件人：TommyPauly

Hello IPPM,

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 16 Jul 2021 12:19:27 -0700

Hello IPPM,

Thanks to those who provided feedback! Hearing no objections, we will move forward with adoption. Authors, please submit a -00 version of the IETF draft for approval.

Best,
Tommy

> On Jul 1, 2021, at 9:48 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello IPPM,
>

---

From: <[email-masked]>
Date: Sat, 17 Jul 2021 09:38:20 +0800 (CST)

Thank you Chairs!
I'll submit a -00 version of the IETF draft after the I-D submission tool is reopened.
Thank you all who reviewed this draft.
Looking forward to more reviews and comments.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：TommyPauly
收件人：Tommy Pauly;IETF IPPM WG ([email-masked]);
日 期 ：2021年07月17日 03:19
主 题 ：Re: [ippm] Re-call for adoption: draft-xiao-ippm-ioam-conf-state
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Hello IPPM,
Thanks to those who provided feedback! Hearing no objections, we will move forward with adoption. Authors, please submit a -00 version of the IETF draft for approval.
Best,
TommyOn Jul 1, 2021, at 9:48 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
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 [email-masked]://www.ietf.org/mailman/listinfo/ippm