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

From: Tianran Zhou <[email-masked]>
Date: Mon, 2 Nov 2020 09:38:45 +0000

Hi Chairs and the WG,

I've read this revision and think it's good to move forward. My previous comments are all addressed.
I support the adoption of this draft and would like to contribute.

Cheers,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Tommy Pauly
Sent: Saturday, October 31, 2020 2:46 AM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

This email starts a Working Group call for adoption for draft-xiao-ippm-ioam-conf-state. This document has been presented several times and discussed within the working group in the context of our overall IOAM work.

The document can be found here:

https://tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07<https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08>

Please provide your feedback on these document, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Tue, 3 Nov 2020 13:05:25 +0800 (CST)

Hi,

I believe this work is useful for IOAM deployment.

I support the adoption of this draft as co-author.

Best Regards,

Xiao Min

原始邮件

发件人：TommyPauly
收件人：IETF IPPM WG ([email-masked]);
抄送人：IPPM Chairs;
日 期 ：2020年10月31日 02:46
主 题 ：[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

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

Hello IPPM,

This email starts a Working Group call for adoption for draft-xiao-ippm-ioam-conf-state. This document has been presented several times and discussed within the working group in the context of our overall IOAM work.The document can be found here:https://tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07Please provide your feedback on these document, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.Best,Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 3 Nov 2020 08:34:31 -0800

Dear WG Chairs, et al.,
as co-author, I support adoption of this draft by the IPPM WG. I believe it
addresses practical use cases in the deployment of iOAM and the solution
proposed in the draft is technically sound.

Regards,
Greg

On Fri, Oct 30, 2020 at 11:46 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello IPPM,
>
> This email starts a Working Group call for adoption
> for draft-xiao-ippm-ioam-conf-state. This document has been presented
> several times and discussed within the working group in the context of our
> overall IOAM work.
>
> https://tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07
> <https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08>
>
> Please provide your feedback on these document, and state whether or not
> you believe the IPPM WG should adopt this work by replying to this email.
> Please provide your feedback by the start of the IETF 109 meeting week, on *Monday,
> November 16*.
>
> Best,
> Tommy & Ian

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 4 Nov 2020 23:28:14 +0800

Hello All,

I've read the doc and support the adoption.
BTW, the link goes wrong document. someone should fix it.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Tommy Pauly
Date: 2020-10-31 02:46
To: IETF IPPM WG ([email-masked])
CC: IPPM Chairs
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
Hello IPPM,

Best,
Tommy & Ian

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 5 Nov 2020 09:49:49 +0800

Hi,

I have read this draft，and I think it is useful for the deployment of iOAM. I support the adoption of it.

Best Regards
Jianglong Wang

From: Tommy Pauly
Date: 2020-10-31 02:46

Best,
Tommy & Ian

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 4 Nov 2020 19:59:41 -0800

yes/support

Cheers,
Jeff
On Oct 30, 2020, 11:46 AM -0700, Tommy Pauly <tpauly=[email-masked]>, wrote:
> tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07
>
> www.ietf.org/mailman/listinfo/ippm

---

From: <[email-masked]>
Date: Wed, 11 Nov 2020 10:10:13 +0800 (CST)

Support the adoption.

Thanks,

Sandy

原始邮件

发件人：TommyPauly

Hello IPPM,

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 13 Nov 2020 12:49:53 +0530

Hi WG,

I suggest adding some text to explain why you don't have an IANA
allocation when you are defining a new type and sub-types in this
document.  It took me a while to figure out that it might be
intentional.

Related question -
- Is it a good idea to use the same name 'IOAM Capabilities TLV' when
it has different formats in the echo request and echo reply message?
- What about an IANA registry for TSF and TSL field in IOAM
Edge-to-Edge Capabilities, some codepoints are reserved for future
standardization but no registry.

Other than that, I support adoption :)

Thanks!
Dhruv

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 16 Nov 2020 07:12:31 +0000

Hello IPPM,

per what I mentioned during the IPPM WG meeting today, I don't think we should adopt the document before we have a couple of key questions resolved:

* Why can't we use Netconf/YANG (with the existing capabilities discovery process - a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00) that were presented in the IPPM WG meeting today, mention "Changed from "IOAM Configuration Data" to "Enabled IOAM Capabilities" since the former is too associated with NETCONF/YANG." IMHO we need a bit more than just wordsmithing.

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP, which is a much broader topic. The TLV structures which are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?

Thanks, Frank

From: ippm <[email-masked]> On Behalf Of Tommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

Best,
Tommy & Ian

---

From: Mach Chen <[email-masked]>
Date: Mon, 16 Nov 2020 07:51:17 +0000

Hi all,

As mentioned on the mic, I shared the similar concern on the second point. Given the draft is going to define extensions to ICMP, MPLS echo/Request, IMHO those parts should be defined in those relevant WGs (e.g, 6man, MPLS WG), at least those WGs should be involved in this discussion.

Best regards,
Mach

From: ippm [mailto:[email-masked]] On Behalf Of Frank Brockners (fbrockne)
Sent: Monday, November 16, 2020 3:13 PM
To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

Thanks, Frank

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

Best,
Tommy & Ian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 16 Nov 2020 09:27:11 +0000

I have one simple question like I mentioned in the meeting: Is it secure to discover the non-routing capabilities info from the data plane?

For instance, a packet may travel several network domains, and the trusted scope is only within each domain. When we use ICMP Ping, we can get the non-routing info from other domains. Is it OK to do it?  I think we should consider more about security and privacy.

Furthermore, can we collect the IOAM data in multiple domain scenarios? Or only within a trusted domain?

Thanks,
Cheng

Hello IPPM,

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Tue, 17 Nov 2020 15:30:47 +0800 (CST)

Hello Frank,

Please see inline my response tagged with <XM>.

Best Regards,

Xiao Min

原始邮件

发件人：FrankBrockners(fbrockne)
收件人：Tommy Pauly;IETF IPPM WG ([email-masked]);
抄送人：IPPM Chairs;
日 期 ：2020年11月16日 15:13
主 题 ：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

per what I mentioned during the IPPM WG meeting today, I don’t think we should adopt the document before we have a couple of key questions resolved:

<XM> Considering you're the key proponent of In-situ OAM, I believe your concerns if any must be addressed, and that's why I had a face to face discussion with you on -01 version of this draft about two years ago. I thought I've convinced you of the intention of this draft, by some major updates, however it seems it's still not that case, hope we can converge through the on-list discussion.

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other
 IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind.
 The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00)
 that were presented in the IPPM WG meeting today, mention “Changed from “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

<XM> Although it's a little bit unusual to compare Echo Request/Reply with Netconf/Yang, I'd like to share my thoughts with you and seek your understanding. In my mind, there are several different methods for the IOAM encapsulating node to know the enabled IOAM capabilities of the IOAM transit nodes/decapsulating node as follows.

* In the deployment scenario there is a centralized Controller/NMS, the IOAM transit nodes/decapsulating node can report their enabled IOAM capabilities directly to the centralized Controller/NMS, and then the IOAM encapsulating node can get these capabilites via configuration by the centralized Controller/NMS, or by means of querying the centralized Controller/NMS for these capabilities. In this scenario, Netconf/Yang is not the only candidate, PCEP or BGP can also be used here.

* In the deployment scenario there is no centralized Controller/NMS, the IOAM encapsulating node can query the IOAM transit nodes/decapsulating node for their enabled IOAM capabilities. In this draft in question, Echo Request/Reply is proposed as the query mechanism because it's a native on-path traceroute method. In this scenario, I agree as you mentioned that Netconf/Yang can also be used, actually PCEP or BGP can be used too. Nevertheless, whether Netconf/Yang, PCEP or BGP are not native on-path traceroute method, further considering that the IOAM encapsulating node can be a host too, so using Netconf/Yang, PCEP or BGP as the IOAM capabilities discovery mechanism is not proposed in this draft.

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP, which is a much broader topic. The TLV structures which
 are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?

<XM> During this presentation, I've asked for guidance from the IPPM WG chairs on this question. My personal suggestion is to separate the IOAM capabilities definition and the extensions on ICMPv6, LSP-Ping and SFC-Ping, just like to separate IOAM-Data from IOAM-over-IPv6, IOAM-over-NSH, IOAM-over-MPLS, because it's possible to fall into egg-chicken loops if we bind them together. After rough consensus is reached on the IOAM capabilities definition in IPPM WG, respective proposals can be brought up in the WGs that are in charge of ICMPv6, LSP-Ping and SFC-Ping, and if the WGs are not interested to take up these IOAM related protocol extensions, which can be pushed back to the IPPM WG with their authorizations.

Thanks, Frank

 

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Tue, 17 Nov 2020 15:39:50 +0800 (CST)

Hello Mach,

I understand your concern, it's valid, so I've asked for guidance from the IPPM WG chairs during my presentation.

Furthermore, I've provided my personal suggestion when replied to Frank, hope it's acceptable to you.

Best Regards,

Xiao Min

原始邮件

发件人：MachChen
收件人：Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG ([email-masked]);
抄送人：IPPM Chairs;
日 期 ：2020年11月16日 15:51
主 题 ：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi all,

As mentioned on the mic, I shared the similar concern on the second point. Given the draft is going to define extensions to ICMP, MPLS echo/Request, IMHO those parts should be defined
 in those relevant WGs (e.g, 6man, MPLS WG), at least those WGs should be involved in this discussion.

Best regards,

Mach

From: ippm [mailto:[email-masked]]On Behalf Of Frank Brockners (fbrockne)

Hello IPPM,

 

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM
 capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that
 the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00)
 that were presented in the IPPM WG meeting today, mention “Changed from “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP, which is a much broader topic. The TLV
 structures which are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?

Thanks, Frank

From: ippm <[email-masked]>On Behalf Of Tommy Pauly

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Tue, 17 Nov 2020 15:52:11 +0800 (CST)

Hello Cheng,

I noticed that Frank has submitted an In-situ OAM deployment draft within OPSAWG, in section 3 of that draft it says:

"

IOAM is a network domain specific feature, with "network domain"
 being a set of network devices or entities within a single
 administration. IOAM is not targeted for a deployment on the global
 Internet. The part of the network which employs IOAM is referred to
 as the "IOAM-Domain".
"

To my understanding, the IOAM data is collected only within a trusted domain, of course, Frank can correct me if I'm wrong.

For your convenience, the link for this quoted draft is provided as below.

https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment 

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)
日 期 ：2020年11月16日 17:28

 

For instance, a packet may travel several network domains, and the trusted scope is only within each domain. When we use ICMP Ping, we can get the non-routing info from other domains. Is it OK to do it?  I think
 we should consider more about security and privacy.

 

Thanks,

Cheng

 

 

 

From: ippm [mailto:[email-masked]] On Behalf OfFrank Brockners (fbrockne)

Hello IPPM,

 

 

 

Thanks, Frank

 

Hello IPPM,

Best,
Tommy & Ian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 17 Nov 2020 08:09:11 +0000

Hi Min,

That is also my understanding. IOAM is limited in a trusted domain.

But ICMP can be used in the global Internet? I don’t think we can detect the capabilities of a node in another node. Privacy and security will be a big challenge.

So personally I prefer IGP/BGP/BGP-LS or NETCONF/YANG way.

Thanks,
Cheng

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: fbrockne=[email-masked]; tpauly=[email-masked]; [email-masked]; [email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

"

   as the "IOAM-Domain".

"

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG ([email-masked]<mailto:[email-masked]>);
抄送人：IPPM Chairs;
日 期 ：2020年11月16日 17:28
主 题 ：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm
I have one simple question like I mentioned in the meeting: Is it secure to discover the non-routing capabilities info from the data plane?

Thanks,
Cheng

To: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>

Hello IPPM,

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00) that were presented in the IPPM WG meeting today, mention “Changed from “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

Thanks, Frank

From: ippm <[email-masked]<mailto:[email-masked]>>On Behalf Of Tommy Pauly

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Tue, 17 Nov 2020 16:19:30 +0800 (CST)

Hello Dhruv,

Thanks for your support and good comments.

Best Regards,

Xiao Min

原始邮件

发件人：DhruvDhody
收件人：Tommy Pauly;
抄送人：IPPM Chairs;IETF IPPM WG ([email-masked]);
日 期 ：2020年11月13日 15:20
主 题 ：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi WG,

<XM> Yes, it's intentional. Will add some text to explain the reason as you suggested.

Related question -

<XM> I lean to change the name to "IOAM Capabilities Query TLV" in the echo request, and change the name to "IOAM Capabilities Response TLV" in the echo reply. Will talk with the co-authors to find good names.

<XM> I lean to accept this good suggestion. Will talk with the co-authors to figure out the potential new IANA registry.

Thanks!
Dhruv

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 17 Nov 2020 09:53:29 +0000

I meant I don’t think we can detect the (Non Routing ) capabilities of a node in another domain. Sorry for the typo.

From: ippm [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; fbrockne=[email-masked]; tpauly=[email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

Thanks,
Cheng

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Cc: fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

"

   as the "IOAM-Domain".

"

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Thanks,
Cheng

Hello IPPM,

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 17 Nov 2020 16:35:58 +0000

Hi Xiao Min,

Please see inline… (“..FB”)

From: ippm <[email-masked]> On Behalf Of [email-masked]
Sent: Dienstag, 17. November 2020 08:31
To: fbrockne=[email-masked]
Cc: [email-masked]; tpauly=[email-masked]; [email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Frank,

Best Regards,

Xiao Min
原始邮件
收件人：Tommy Pauly;IETF IPPM WG ([email-masked]<mailto:[email-masked]>);

…FB: Hmm – I still don’t follow what the use-case you have in mind would be. Most routers already implement a Netconf server. Any node can take the role of a Netconf client – as you note yourself above. And with the YANG model for IOAM becoming finalized, we have all the ingredients already available. Plus Netconf is built as a protocol for management operations – thus you also have the security part figured out if you use NC/Y (see the related discussion on the IPPM mailer). Why would anyone spend the effort to reimplement everything that is available with NC/Y into e.g. ICMPv6?

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP, which is a much broader topic. The TLV structures which are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?
<XM> During this presentation, I've asked for guidance from the IPPM WG chairs on this question. My personal suggestion is to separate the IOAM capabilities definition and the extensions on ICMPv6, LSP-Ping and SFC-Ping, just like to separate IOAM-Data from IOAM-over-IPv6, IOAM-over-NSH, IOAM-over-MPLS, because it's possible to fall into egg-chicken loops if we bind them together. After rough consensus is reached on the IOAM capabilities definition in IPPM WG, respective proposals can be brought up in the WGs that are in charge of ICMPv6, LSP-Ping and SFC-Ping, and if the WGs are not interested to take up these IOAM related protocol extensions, which can be pushed back to the IPPM WG with their authorizations.
…FB: IMHO there are no real circular dependencies: Your approach requires that ICMPv6 would be able to carry TLVs in echo request and reply messages. Once that capability would be there, you could use those TLVs to carry the particular IOAM capability data. This means you’d need to evolve ICMPv6 first. If and only if TLVs would already exist in ICMPv6 echo request/reply messages, then one could assume that you’d specify code-points for specific types (like the “Type = IOAM Capabilities” that you have in your draft), so that it would be worthwhile to focus on defining data types etc. So IMHO you’re really taking the second step before the first one.

Cheers, Frank

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: wangyali <[email-masked]>
Date: Wed, 18 Nov 2020 05:03:46 +0000

Hi Frank,

I agree with you that NC/YANG is an alternate way to retrieve the IOAM decapsulation capability.
And from the side of IGP/BGP, we also proposed extensions to IGP/BGP for IOAM/Alternate Marking transit node/decapsulation node capability in https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-01 and https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01 .

Please see the details of proposed extensions for IOAM transit/decapsulating node capability for two scenarios with and without the centralized controller in line [Yali].

Any questions and comments are welcome.

Best,
Yali

From: ippm [mailto:[email-masked]] On Behalf Of Frank Brockners (fbrockne)
Sent: Wednesday, November 18, 2020 12:36 AM
To: [email-masked]
Cc: [email-masked]; tpauly=[email-masked]; [email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Xiao Min,

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Dienstag, 17. November 2020 08:31
To: fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Frank,

Best Regards,

Xiao Min
原始邮件

* In the deployment scenario there is a centralized Controller/NMS, the IOAM transit nodes/decapsulating node can report their enabled IOAM capabilities directly to the centralized Controller/NMS, and then the IOAM encapsulating node can get these capabilites via configuration by the centralized Controller/NMS, or by means of querying the centralized Controller/NMS for these capabilities. In this scenario, Netconf/Yang is not the only candidate, PCEP or BGP can also be used here.
 [Yali] For this scenario having a centralized controller, since BGP-LS defines a way to advertise topology and associated attributes and capabilities of the nodes in that topology to a centralized controller [RFC7752]. And typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. Thus, in order for BGP-LS to signal IFIT node capabilities for all the IOAM transit node, the IOAM transit node capability should be advertised by every IGP router in the network. Therefore, draft https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-01 extends Node and Link Attribute TLVs to IGP.

[Yali] For this scenario without centralized controller and only considering the requirement that the IOAM encapsulation node query the IOAM decapsulation node capability, draft https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01 proposes two methods to extend to BGP, i.e., Option 1 is extension to BGP Extended Community and Option 2 is extension to BGP Next-Hop Capability.

Cheers, Frank

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Wed, 18 Nov 2020 15:57:16 +0800 (CST)

Hi Cheng,

I don't really understand your concern.

ICMPv6 is a mature protocol mechanism, and IOAM function is limited in a trusted domain, then using ICMPv6 to discover IOAM capabilities wouldn't introduce any big challenge on security and privacy.

I don't think IGP is better than ICMPv6 in this case. Firstly, flooding IOAM capabilities throughout the IGP domain is too heavy and unnecessary in my view. Secondly, IGP domain and IOAM domain don't always have the same coverage, one example is that when the IOAM encapsulating node is a host IGP flooding doesn't work for it.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)
收件人：Chengli (Cheng Li);肖敏10093570;
抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked];
日 期 ：2020年11月17日 17:53
主 题 ：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

I meantI don’t think we can detect the (Non Routing ) capabilities of a node in another domain. Sorry for the typo.

From: ippm [mailto:[email-masked]]On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; fbrockne=[email-masked]; tpauly=[email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

 

 

 

Thanks,

Cheng

 

From:[email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: fbrockne=[email-masked];tpauly=[email-masked];[email-masked]; [email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

"

IOAM is a network domain specific feature, with "network domain"   being a set of network devices or entities within a single   administration.  IOAM is not targeted for a deployment on the global   Internet.  The part of the network which employs IOAM is referred to   as the "IOAM-Domain"."

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

抄送人：IPPM Chairs;

日期：2020年11月16日 17:28

主题：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

 

For instance, a packet may travel several network domains, and the trusted scope is only within each domain. When we use ICMP Ping, we can get the non-routing
 info from other domains. Is it OK to do it?  I think we should consider more about security and privacy.

 

Thanks,

Cheng

 

 

 

From: ippm [mailto:[email-masked]]On Behalf OfFrank Brockners (fbrockne)

Hello IPPM,

 

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as
 a NC client) could retrieve the IOAM capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG
 is not suitable for the scenario that the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00)
 that were presented in the IPPM WG meeting today, mention “Changed from “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP,
 which is a much broader topic. The TLV structures which are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?

Thanks, Frank

From: ippm <[email-masked]>On Behalf OfTommy Pauly

Hello IPPM,

Best,
Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Nov 2020 00:35:59 -0800

Dear All,
I agree with Xiao Min's suggestion that IGP may be not the most effective
mechanism to collect information about a node's IAOM capability. Consider
the case when IOAM capability is controlled by a local policy that controls
the type of information available to different sources within an IOAM
domain. I think that it would be much more challenging to reflect that
through IGP than to discover that using ICMP.

Regards,
Greg

On Tue, Nov 17, 2020 at 11:57 PM <[email-masked]> wrote:

> ICMPv6 is a mature protocol mechanism, and IOAM function is limited in a
> trusted domain, then using ICMPv6 to discover IOAM capabilities wouldn't
> introduce any big challenge on security and privacy.
>
> I don't think IGP is better than ICMPv6 in this case. Firstly, flooding
> IOAM capabilities throughout the IGP domain is too heavy and unnecessary in
> my view. Secondly, IGP domain and IOAM domain don't always have the same
> coverage, one example is that when the IOAM encapsulating node is a host
> IGP flooding doesn't work for it.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人：*Chengli(ChengLi)
> *收件人：*Chengli (Cheng Li);肖敏10093570;
> *抄送人：[email-masked];[email-masked];fbrockne=
> [email-masked];tpauly=[email-masked];
> *日 期 ：*2020年11月17日 17:53
> *主 题 ：**RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state*
>
> I meantI don’t think we can detect the (Non Routing ) capabilities of a
> node in another domain. Sorry for the typo.
>
>
>
> *From:* ippm [mailto:[email-masked]]*On Behalf Of *Chengli (Cheng
> Li)
> *Sent:* Tuesday, November 17, 2020 4:09 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]; fbrockne=
> [email-masked]; tpauly=[email-masked]
> *Subject:* Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
>
>
>
> Hi Min,
>
>
>
> But ICMP can be used in the global Internet? I don’t think we can detect
> the capabilities of a node in another node. Privacy and security will be a
> big challenge.
>
>
>
> *From:[email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, November 17, 2020 3:52 PM
> *To:* Chengli (Cheng Li) <[email-masked]>
> *Cc:* fbrockne=[email-masked];
> tpauly=[email-masked];[email-masked]; [email-masked]
> *Subject:* Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
>
>
>
> Hello Cheng,
>
>
>
> I noticed that Frank has submitted an In-situ OAM deployment draft within
> OPSAWG, in section 3 of that draft it says:
>
> "
>
> To my understanding, the IOAM data is collected only within a trusted
> domain, of course, Frank can correct me if I'm wrong.
>
> *发件人：*Chengli(ChengLi)
> *收件人：*Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG ([email-masked]);
>
> *抄送人：*IPPM Chairs;
>
> *日**期**：*2020年11月16日 17:28
>
> *主**题**：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state*
>
> I have one simple question like I mentioned in the meeting: Is it secure
> to discover the non-routing capabilities info from the data plane?
>
>
>
> For instance, a packet may travel several network domains, and the trusted
> scope is only within each domain. When we use ICMP Ping, we can get the
> non-routing info from other domains. Is it OK to do it?  I think we should
> consider more about security and privacy.
>
>
>
> *From:* ippm [mailto:[email-masked] <[email-masked]>]*On
> Behalf Of*Frank Brockners (fbrockne)
> *Sent:* Monday, November 16, 2020 3:13 PM
> *To:* Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG (
> [email-masked]) <[email-masked]>
> *Cc:* IPPM Chairs <[email-masked]>
> *Subject:* Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
>
>
>
> Hello IPPM,
>
>
>
> per what I mentioned during the IPPM WG meeting today, I don’t think we
> should adopt the document before we have a couple of key questions resolved:
>
>
>
> * Why can’t we use Netconf/YANG (with the existing capabilities discovery
> process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes?
> E.g. the encapsulating node (as a NC client) could retrieve the IOAM
> capabilities from other IOAM nodes  (acting as a NC server). Plus there is
> already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At
> a minimum I would have expected that the draft discusses why NC/YANG is not
> suitable for the scenario that the authors have in mind. The slides (
> https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00)
> that were presented in the IPPM WG meeting today, mention “Changed from
> “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former
> is too associated with NETCONF/YANG.” IMHO we need a bit more than just
> wordsmithing.
>
>
>
> * While the draft uses IOAM capabilities discovery as the use-case, in
> more general terms, it proposes to add management/ops capabilities to
> echo-request/reply protocols like ICMP, which is a much broader topic. The
> TLV structures which are proposed to be added to echo-requests and
> echo-replies could obviously be leveraged for other use-cases. Does the
> work really fit the scope of the IPPM WG?
>
>
>
> Thanks, Frank
>
>
>
> *From:* ippm <[email-masked]>*On Behalf Of*Tommy Pauly
> *Sent:* Freitag, 30. Oktober 2020 19:46
> *To:* IETF IPPM WG ([email-masked]) <[email-masked]>
> *Cc:* IPPM Chairs <[email-masked]>
> *Subject:* [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
>
>
>
> Hello IPPM,
>
>

---

From: <[email-masked]>
Date: Wed, 18 Nov 2020 16:46:28 +0800 (CST)

Hi Frank,

Please see inline my comments with <XM2>.

Thanks,

Xiao Min

原始邮件

发件人：FrankBrockners(fbrockne)
收件人：肖敏10093570;
抄送人：[email-masked];tpauly=[email-masked];[email-masked];
日 期 ：2020年11月18日 00:36
主 题 ：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Xiao Min,

 

 

Hello Frank,

Best Regards,

Xiao Min

原始邮件

抄送人：IPPM Chairs;

日期：2020年11月16日
 15:13

Hello IPPM,

<XM> Considering you're the key proponent of In-situ OAM, I believe your concerns if any must be addressed, and that's why I had a face to face discussion with you on -01 version
 of this draft about two years ago. I thought I've convinced you of the intention of this draft, by some major updates, however it seems it's still not that case, hope we can converge through the on-list discussion.

<XM> Although it's a little bit unusual to compare Echo Request/Reply with Netconf/Yang, I'd like to share my thoughts with you and seek your understanding. In my mind, there are
 several different methods for the IOAM encapsulating node to know the enabled IOAM capabilities of the IOAM transit nodes/decapsulating node as follows.

* In the deployment scenario there is a centralized Controller/NMS, the IOAM transit nodes/decapsulating node can report their enabled IOAM capabilities directly to the centralized Controller/NMS, and then the IOAM encapsulating node can get these capabilites
 via configuration by the centralized Controller/NMS, or by means of querying the centralized Controller/NMS for these capabilities. In this scenario, Netconf/Yang is not the only candidate, PCEP or BGP can also be used here.

* In the deployment scenario there is no centralized Controller/NMS, the IOAM encapsulating node can query the IOAM transit nodes/decapsulating node for their enabled IOAM capabilities. In this draft in question, Echo Request/Reply is proposed as the query
 mechanism because it's a native on-path traceroute method. In this scenario, I agree as you mentioned that Netconf/Yang can also be used, actually PCEP or BGP can be used too. Nevertheless, whether Netconf/Yang, PCEP or BGP are not native on-path traceroute
 method, further considering that the IOAM encapsulating node can be a host too, so using Netconf/Yang, PCEP or BGP as the IOAM capabilities discovery mechanism is not proposed in this draft.

…FB: Hmm – I still don’t follow what the use-case you have in mind would be. Most routers already implement a Netconf server. Any node can take the role of a Netconf client – as you note yourself above. And with the YANG model for IOAM becoming finalized,
 we have all the ingredients already available. Plus Netconf is built as a protocol for management operations – thus you also have the security part figured out if you use NC/Y (see the related discussion on the IPPM mailer). Why would anyone spend the effort
 to reimplement everything that is available with NC/Y into e.g. ICMPv6?

<XM2> If I understand it correctly, you prefer to use Netconf/Yang, rather than Echo Request/Reply, to resolve the problem raised in this draft. If that's the case, then at least we converge on the problem raised in this draft. When Netconf/Yang is used here, I see several issues. Firstly, each IOAM encapsulating node (including the host when it takes the role of an IOAM encapsulating node) needs to implement a Netconf Client, which is not easy in my view. Secondly, each IOAM encapsulating node needs to establish netconf connection with each IOAM transit node and IOAM decapsulating node, the scalability can be an issue. Thirdly, Netconf/Yang is designed for communication between the NMS and the NE, if it's used for communication between NEs, just for capabilities discovery, then most of its functions are redundant.

<XM> During this presentation, I've asked for guidance from the IPPM WG chairs on this question. My personal suggestion is to separate the IOAM capabilities definition and the extensions
 on ICMPv6, LSP-Ping and SFC-Ping, just like to separate IOAM-Data from IOAM-over-IPv6, IOAM-over-NSH, IOAM-over-MPLS, because it's possible to fall into egg-chicken loops if we bind them together. After rough consensus is reached on the IOAM capabilities definition
 in IPPM WG, respective proposals can be brought up in the WGs that are in charge of ICMPv6, LSP-Ping and SFC-Ping, and if the WGs are not interested to take up these IOAM related protocol extensions, which can be pushed back to the IPPM WG with their authorizations.

…FB: IMHO there are no real circular dependencies: Your approach requires that ICMPv6 would be able to carry TLVs in echo request and reply messages. Once that capability
 would be there, you could use those TLVs to carry the particular IOAM capability data. This means you’d need to evolve ICMPv6 first. If and only if TLVs would already exist in ICMPv6 echo request/reply messages, then one could assume that you’d specify code-points
 for specific types (like the “Type = IOAM Capabilities” that you have in your draft), so that it would be worthwhile to focus on defining data types etc. So IMHO you’re really taking the second step before the first one.  

<XM2> I'm not sure I'm wrong or you're missing something, I believe in this draft we do provide references of ICMPv6 RFCs to support TLV-like extension objects. To my understanding, ICMPv6 supports new TLV definition, of course, IOAM Capabilities are a bit different with the currently defined ones, but I don't think it's an abnormal one.

Cheers, Frank

Thanks, Frank

 

Hello IPPM,

Please provide your feedback on these document, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday,
 November 16.

Best,
Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Nov 2020 00:50:25 -0800

Hi Frank,
many thank for your comments at the mike and the continued discussion on
the list.
I would point to RFC 4884 that defined Multi-part message as the mechanism
to extend ICMP functionality. To this day several RFCs that use that
mechanism equipped ICMP with capabilities to respond with various objects,
e.g., MPLS Label stack, a piece of interface information that includes its
IP address, name, and MTU. So, I think that the proposed mechanism to
extend ICMP for IAOM capability discovery is in line with RFC 4884.

Regards,
Greg

On Sun, Nov 15, 2020 at 11:12 PM Frank Brockners (fbrockne) <fbrockne=
[email-masked]> wrote:

> *From:* ippm <[email-masked]> *On Behalf Of * Tommy Pauly

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 18 Nov 2020 08:55:56 +0000

Hi Min,

Thanks for your reply.

Simple example, Domain A is an IOAM domain, Domain B is another IOAM domain. Logically, the IOAM capabilities info of nodes in domain B MUST NOT be leaked out side the domain, therefore, the node 1 in domain A should not get the info of nodes in domain B.

In your solution, I guess we can use the ICMPv6 to request the capabilities info within the IOAM domain or outside the domain, if I understand it correctly.
Nothing to stop anyone to get the IOAM capability info of any node from any corner in the world. Right?

The solution of preventing information leaking needs to be considered. That is my concern.

IGP/BGP/BGP-LS solution may have other issues like you mentioned, but they can be controlled within the trusted domain.
Also, I see many capabilities are advertised via these protocols.  But this is another topic.

Best,
Cheng

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 18, 2020 3:57 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>; [email-masked]; [email-masked]; fbrockne=[email-masked]; tpauly=[email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：Chengli (Cheng Li);肖敏10093570;
抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]<mailto:[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]>;
日 期 ：2020年11月17日 17:53
主 题 ：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
I meantI don’t think we can detect the (Non Routing ) capabilities of a node in another domain. Sorry for the typo.

From: ippm [mailto:[email-masked]]On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

Thanks,
Cheng

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Cc: fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>;tpauly=[email-masked]<mailto:tpauly=[email-masked]>;[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

"

   as the "IOAM-Domain".

"

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Thanks,
Cheng

Hello IPPM,

Thanks, Frank

From: ippm <[email-masked]<mailto:[email-masked]>>On Behalf OfTommy Pauly

Hello IPPM,

Best,
Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 18 Nov 2020 12:01:40 +0000

Hi Greg,

Thanks for the note. I’m not arguing that one cannot extend ICMP per RFC 4884, my point was rather that if decide to put a TLV structure in place as part of ICMP extension objects, we make this a generic extension. In a potential second step we can then use the generic structure for the IOAM capabilities discovery use case you have in mind.

Cheers, Frank

From: Greg Mirsky <[email-masked]>
Sent: Mittwoch, 18. November 2020 09:50
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: Tommy Pauly <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>; IPPM Chairs <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Frank,
many thank for your comments at the mike and the continued discussion on the list.
I would point to RFC 4884 that defined Multi-part message as the mechanism to extend ICMP functionality. To this day several RFCs that use that mechanism equipped ICMP with capabilities to respond with various objects, e.g., MPLS Label stack, a piece of interface information that includes its IP address, name, and MTU. So, I think that the proposed mechanism to extend ICMP for IAOM capability discovery is in line with RFC 4884.

Regards,
Greg

On Sun, Nov 15, 2020 at 11:12 PM Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:[email-masked]>> wrote:
Hello IPPM,

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Thu, 19 Nov 2020 13:49:46 +0800 (CST)

Hi Cheng,

We co-authors have discussed the example you provided, and we agree that this is a valid concern that needs to be addressed.

As what's been documented in draft-ietf-ippm-ioam-ipv6-options-04, leaking of IOAM-over-IPv6 packets outside the IOAM domain may happen in the case of device misconfiguration or device failure. It's similar here, leaking of  IOAM-Capabilities-over-ICMPv6 packets outside the IOAM domain may happen, but in my view IOAM-Capabilities-over-ICMPv6 packets are much less sensitive than IOAM-over-IPv6 packets, and the operator can add authentication to ICMPv6 packets if needed, so it's explicitly not a blocking issue.

The Security Consideration section of this draft will be enhanced in the next revision.

Thanks for your good comments.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)
收件人：肖敏10093570;
抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked];
日 期 ：2020年11月18日 17:01
主 题 ：RE: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

Thanks for your reply.

Simple example, Domain A is an IOAM domain, Domain B is another IOAM domain. Logically, the IOAM capabilities info of nodes in domain B MUST NOT be leaked out
 side the domain, therefore, the node 1 in domain A should not get the info of nodes in domain B.

 

 

 

Best,

Cheng

 

 

Hi Cheng,

I don't think IGP is better than ICMPv6 in this case. Firstly, flooding IOAM capabilities throughout the IGP domain is too heavy and unnecessary in my view. Secondly, IGP domain and IOAM domain
 don't always have the same coverage, one example is that when the IOAM encapsulating node is a host IGP flooding doesn't work for it.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

日期：2020年11月17日 17:53

主题：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

 

From: ippm [mailto:[email-masked]]On
 Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: [email-masked]
Cc: [email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

 

 

 

Thanks,

Cheng

 

From:[email-masked]
 [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: fbrockne=[email-masked];tpauly=[email-masked];[email-masked];[email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

"

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

抄送人：IPPM Chairs;

日期：2020年11月16日
 17:28

 

 

 

Thanks,

Cheng

 

 

 

 

Hello IPPM,

 

 

 

Thanks, Frank

 

Hello IPPM,

Best,
Tommy & Ian