Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

From: Haoyu Song <[email-masked]>
Date: Mon, 2 Nov 2020 18:27:53 +0000

I support the adoption of the draft. Thanks!

Haoyu

From: ippm <[email-masked]> On Behalf Of Tommy Pauly
Sent: Friday, October 30, 2020 11:41 AM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hello IPPM,

This email starts a Working Group call for adoption for draft-zhou-ippm-ioam-yang. Now that our IOAM documents are mature and progressing, the chairs believe it is time to consider the YANG work officially.

The document can be found here:

https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhou-ippm-ioam-yang-08&data=04%7C01%7Chaoyu.song%40futurewei.com%7C77d54e8c81d34706dbe308d87d036c27%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637396800968316931%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lMU0IR4WejJCw2Ex9Pt18HcOoPk96NXsJe7Xig4VDBs%3D&reserved=0>

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:07:49 +0800 (CST)

Hi,

I believe this work is useful for IOAM deployment.

I support the adoption of this draft.

Best Regards,

Xiao Min

原始邮件

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

_______________________________________________
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-zhou-ippm-ioam-yang. Now that our IOAM documents are mature and progressing, the chairs believe it is time to consider the YANG work officially.The document can be found here:https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08Please 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: Mach Chen <[email-masked]>
Date: Tue, 3 Nov 2020 06:24:06 +0000

Hi,

I have read the draft and think it's in a good shape. Therefore, I support the adoption on this draft.

Best regards,
Mach

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

Hello IPPM,

https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08

Best,
Tommy & Ian

---

From: Lizhenbin <[email-masked]>
Date: Tue, 3 Nov 2020 07:42:11 +0000

Hi All,

I support the adoption of the draft.

Best Regards,

Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068
Email: [email-masked]<mailto:[email-masked]>

发件人：Tommy Pauly <tpauly=[email-masked]>
收件人：ippm <[email-masked]>
抄 送：IPPM Chairs <[email-masked]>
时 间：2020-10-31 02:41:28
主 题：[ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hello IPPM,

Best,
Tommy & Ian

---

From: yanghongwei <[email-masked]>
Date: Wed, 4 Nov 2020 09:46:43 +0800

Hi，

I think this draft is useful for IOAM development and deployment.
I support the adoption of this draft.

Best,
Hongwei.

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

Best,
Tommy & Ian

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 4 Nov 2020 04:22:30 +0000

I have read the draft as an implementer of ioam. I think this draft adds value and hence support its adoption.

Thanks
Prasad

From: Tommy Pauly<mailto:tpauly=[email-masked]>
Date: 2020-10-31 02:40
To: IETF IPPM WG ([email-masked])<mailto:[email-masked]>
CC: IPPM Chairs<mailto:[email-masked]>
Subject: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang
Hello IPPM,

Best,
Tommy & Ian

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 4 Nov 2020 06:56:42 +0000

Dear All,
I have read it and I support its adoption.

Regards,

Giuseppe

Sent: Friday, October 30, 2020 7:41 PM

Hello IPPM,

Best,
Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 11 Nov 2020 08:43:25 +0000

Support (as co-author).

IOAM requires a common approach to configure IOAM encap/decap/transit nodes - and a YANG model is the natural facilitator to arrive at a common approach, which is what this draft supplies.

Cheers, Frank

Sent: Freitag, 30. Oktober 2020 19:41

Hello IPPM,

Best,
Tommy & Ian

---

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Wed, 11 Nov 2020 08:50:59 +0000

Hi all

Support Adoption (as a co-author).

A common YANG model is very valuable for iOAM and this draft helps arrive at the same and hence the need and support.

Thanks,
Srihari

From: ippm <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Saturday, 31 October 2020 at 12:11 AM
To: "IETF IPPM WG ([email-masked])" <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hello IPPM,

Best,
Tommy & Ian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 11 Nov 2020 15:46:49 +0000

Hi IPPM,

Yes, support WG adoption of this important work.

Thanks,
Rakesh

Hello IPPM,

Best,
Tommy & Ian

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 12 Nov 2020 19:21:05 +0530

Hi WG,

I support adoption of this YANG draft. A few high-level comments -

- Currently all 5 profiles can be configured at the same time in a single
ioam-profile (as each of them have a separate container of their own). Is
that intentional?

- Can I configure an ioam-profile that is applicable to both IPv6 and NSH?
The current yang model would force me to create two separate ioam-profile
and give them different names!

- Currently ACL is the only way to identify the flow for which the IOAM
profile needs to be applied. Think about how this could be used
alongside SR policy YANG for instance. Maybe a generic grouping that can be
used to augment SR Policy? Not sure how to make it work with the current
filter-type.

Hope these comments help to improve the YANG module!

Thanks!
Dhruv

On Sat, Oct 31, 2020 at 12:11 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello IPPM,
>
> This email starts a Working Group call for adoption
> for draft-zhou-ippm-ioam-yang. Now that our IOAM documents are mature and
> progressing, the chairs believe it is time to consider the YANG work
> officially.
>
> 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: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 15 Nov 2020 19:17:50 +0000

Hi,

I support adoption of this document by the IPPM WG.

Some comments/questions below, apologies if there’s any dead horses In there (I haven’t followed discussions on this document recently).

  1.  There are no config false nodes, is this on purpose? I believe operational data would be of use.
  2.  Some groupings are used only once, e.g. ioam-admin-config, ioam-filter. Don’t see the need for these groupings.
  3.  How is flow-id defined? Since it’s just a uint32 in the YANG, maybe add some text or reference if applicable?
  4.  Use unit statements where applicable, e.g. max-length
  5.  References would make it easier for readers/reviewers, espcially those who are not IOAM experts. e.g. for action-encapsulate or action-transit mean
  6.  Examples would be of great help to understand how the YANG moduel is to be used
  7.  Why is proof-of-transit  YANG defined in SFC? I understand how SFC makes use of POT, but couldn’t we use POT without SFC? It seems odd that a YANG module for a “protocol” would depend on an application making use of that “protocol”.

Regards,
Reshad.

Date: Friday, October 30, 2020 at 2:41 PM

Hello IPPM,

Best,
Tommy & Ian

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 16 Nov 2020 02:24:36 +0000

Hi Reshad,

Thank you very much for your support and valuable comments.
Please see in line with my reply.

Cheers,
Tianran
From: ippm [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Monday, November 16, 2020 3:18 AM
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-zhou-ippm-ioam-yang

Hi,

  1.  There are no config false nodes, is this on purpose? I believe operational data would be of use.
ZTR> We have no purpose to eliminate the operational data. We just expressed the data we have considered. We welcome proposals on the operational data.

  1.  Some groupings are used only once, e.g. ioam-admin-config, ioam-filter. Don’t see the need for these groupings.
ZTR> We sometimes used group just as a data structure to “group”. So that the container will not be too big.  Do you think this is reasonable or not?

  1.  How is flow-id defined? Since it’s just a uint32 in the YANG, maybe add some text or reference if applicable?
ZTR> flow-id follows the definition in IOAM-DEX draft, with the same data type. I can add some text on this.

  1.  Use unit statements where applicable, e.g. max-length
ZTR> OK. I will improve this.

  1.  References would make it easier for readers/reviewers, espcially those who are not IOAM experts. e.g. for action-encapsulate or action-transit mean
ZTR> OK. I will improve this.

  1.  Examples would be of great help to understand how the YANG moduel is to be used
ZTR> OK. I will add some examples in the appendix.

  1.  Why is proof-of-transit  YANG defined in SFC? I understand how SFC makes use of POT, but couldn’t we use POT without SFC? It seems odd that a YANG module for a “protocol” would depend on an application making use of that “protocol”.
ZTR>  I raised this discussion on the presentation and emails. I am open on this. Maybe because POT model is already there adopted in SFC. A reference is easier. I think Frank is better to reply on this.

Regards,
Reshad.

From: ippm <[email-masked]<mailto:[email-masked]>> on behalf of Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>
Date: Friday, October 30, 2020 at 2:41 PM
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-zhou-ippm-ioam-yang

Hello IPPM,

Best,
Tommy & Ian

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 16 Nov 2020 02:55:37 +0000

Hi Dhruv,

Thanks very much for your support and comments.
Please see in line for my reply.

Cheers,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Thursday, November 12, 2020 9:51 PM
To: Tommy Pauly <tpauly=[email-masked]>
Cc: IPPM Chairs <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi WG,

- Currently all 5 profiles can be configured at the same time in a single ioam-profile (as each of them have a separate container of their own). Is that intentional?
ZTR> Yes, we want to allow a packet to apply different IOAM at the same time.

- Can I configure an ioam-profile that is applicable to both IPv6 and NSH? The current yang model would force me to create two separate ioam-profile and give them different names!
ZTR> I can understand your question. But it seems right now the structure is not like a real profile or template. It do not allow the reuse. For example, apply to different protocols, apply to different flows(with acl).
Each profile is just one configuration.
If the working group would like to see more flexibility and reusability, we can try to revise in this direction.

- Currently ACL is the only way to identify the flow for which the IOAM profile needs to be applied. Think about how this could be used alongside SR policy YANG for instance. Maybe a generic grouping that can be used to augment SR Policy? Not sure how to make it work with the current filter-type.
ZTR> Interesting proposal. We need to think about it.

Thanks!
Dhruv

On Sat, Oct 31, 2020 at 12:11 AM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
Hello IPPM,

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 17 Nov 2020 15:14:19 +0530

Hi Tianran,

<snip>

> ZTR> Yes, we want to allow a packet to apply different IOAM at the same

[Dhruv]: That is true for some combinations, but it may not be the case for
others.
What would be the YANG best practice here - to me adding a must condition
in the YANG makes sense, something like when Incremental Tracing Option is
enabled, we check that the Pre-allocated Tracing Option is not already
enabled (provided you agree that they should not be enabled at the same
time)?

Thanks,
Dhruv

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 17 Nov 2020 14:42:33 +0000

Hi Tianran,

Thanks for your response. For operational data, this question should be answered by IOAM experts.

Regards,
Reshad.

From: ippm <[email-masked]> on behalf of Tianran Zhou <[email-masked]>
Date: Sunday, November 15, 2020 at 9:25 PM
To: "Reshad Rahman (rrahman)" <rrahman=[email-masked]>, Tommy Pauly <tpauly=[email-masked]>, "IETF IPPM WG ([email-masked])" <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi Reshad,

Cheers,
Tianran

Hi,

Regards,
Reshad.

Hello IPPM,

Best,
Tommy & Ian

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 19 Nov 2020 05:00:36 +0000

Hi Reshad,

Thanks, we will think about the optional data.

Cheers,
Tianran

From: Reshad Rahman (rrahman) [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 10:43 PM
To: Tianran Zhou <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi Tianran,

Regards,
Reshad.

From: ippm <[email-masked]<mailto:[email-masked]>> on behalf of Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 15, 2020 at 9:25 PM
To: "Reshad Rahman (rrahman)" <rrahman=[email-masked]<mailto:rrahman=[email-masked]>>, Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>, "IETF IPPM WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi Reshad,

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

Hi,

Regards,
Reshad.

Hello IPPM,

Best,
Tommy & Ian

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 19 Nov 2020 05:06:47 +0000

Hi Dhruv,

Indeed, I cannot give you the use case when the pre-allocated tracing and incremental tracing option present at the same time.
I think the IOAM data draft should be clear about this.
On the other hand, whether the management interface should be so strict?
Maybe here we can be somehow flexible, so that some use case comes out.

Best,
Tianran

From: Dhruv Dhody [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 5:44 PM
To: Tianran Zhou <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>; IPPM Chairs <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi Tianran,

<snip>

[Dhruv]: That is true for some combinations, but it may not be the case for others.
What would be the YANG best practice here - to me adding a must condition in the YANG makes sense, something like when Incremental Tracing Option is enabled, we check that the Pre-allocated Tracing Option is not already enabled (provided you agree that they should not be enabled at the same time)?

Thanks,
Dhruv

---

From: "Spiegel, Mickey" <[email-masked]>
Date: Fri, 20 Nov 2020 04:54:09 +0000

I believe that adoption of draft-zhou-ippm-ioam-yang would be premature. My concerns are in three areas:

  1.  Scope:
The proposed YANG model only addresses configuration, i.e. whatever is required to trigger encapsulation and decapsulation of IOAM data in flows.
There are other areas to which the scope could be expanded, where a YANG model would prove very useful:
     *   Typically, the IOAM data is exported to an offline monitoring system that analyzes the IOAM data from the nodes in the IOAM domain. By design, draft-ietf-ippm-ioam-data leaves many details open such as units or timestamp format. While this aids greatly in the ability of different hardware implementations to support IOAM, this makes it difficult for offline monitoring systems to interpret the data, unless mechanisms are defined for the offline monitoring systems to discover these details from individual nodes. IMO, a YANG model is the right way to define such a mechanism.
     *   Related to the previous item, there is currently an active thread about discovery of IOAM capabilities supported by nodes in the IOAM domain, in the context of draft-xiao-ippm-ioam-conf-state.
     *   Besides the flow-level configuration, draft-ietf-ippm-ioam-data also defines the concept of namespaces. Namespaces add context to IOAM-Option-Types and associated IOAM-Data-Fields. Namespaces may provide additional context for IOAM Data Fields such as units or timestamp format, and some IOAM Data Fields are namespace specific. The YANG model could be extended to support configuration of this namespace-related context.
  2.  The proposed YANG model relies on the ACL YANG model (RFC 8519) to specify flows, which is very much a good thing. However, the proposed method to link the IOAM YANG model and the ACL YANG model is far from optimal:
     *   In draft-zhou-ippm-ioam-yang-08, within each profile, there is a single reference to an ACL through “leaf acl-name”. Each referenced ACL contains an ordered list of ACEs. Each ACE contains a forwarding action (accept, drop, or reject) and/or a log action (currently only log-syslog and log-none), in addition to the match criteria and statistics.
If the only purposes in defining these ACEs is for IOAM, then presumably forwarding action "accept" would have to be used, though this is not explicitly stated in the current draft.
     *   There are cases where it is desirable to use different profiles for different subsets of traffic.
For example, traffic matching certain IP source and destination address prefixes use a general profile with trace types trace-hop-lim-node-id, trace-if-id, trace-timestamp-seconds, trace-timestamp-nanoseconds, and trace-queue-depth.
Traffic matching those same IP source and destination address prefixes and also using certain L4 ports (e.g. UDP port 4791 for RoCEv2) use a different profile that includes trace types for tx-bytes and interface-speed (see draft-gafni-ippm-ioam-additional-data-fields-00, draft-pan-tsvwg-hpccplus-02).
Using the current proposal in draft-zhou-ippm-ioam-yang-08, two different ACLs would have to be defined corresponding to the two different profiles.
How would the implementation know which ACE in which ACL to use, if both ACEs match?
The ordered list only extends within each ACL.
     *   A better approach is to flip the reference by augmenting ACE actions with choices such as ioam-encapsulate and associated leaf ioam-profile-name, so that each ACE can reference a different IOAM profile. This changes the granularity of the reference from ACLs to ACEs. For the case in the bullet immediately above this, there would be one ACL with two ACEs. The first ACE would reference the specific profile with tx-bytes and interface-speed. The second ACE would reference the general profile. The order of the ACEs within the ACL clarifies that a match on the first ACE wins.
  3.  There have been lots of IOAM discussions about preventing IOAM data from leaking outside of the IOAM domain. Depending on the encapsulation that is used and the deployment scenarios, there may be cases where this relies on configuration of the IOAM domain boundaries.
In draft-zhou-ippm-ioam-yang-08, this requires configuration of both an IOAM profile and an ACL.
The IOAM profile specifies node-action "action-decapsulate" and references the ACL by name.
The ACL specifies one or more ACEs, with traffic matching any of those ACEs taking the node-action specified in the IOAM profile.
While this approach is flexible, it is somewhat unwieldy. This approach significantly increases the chances of operational errors, where misconfiguration results in leaking of IOAM data outside of the IOAM domain.
A simpler approach would be to list interfaces at the edges of the IOAM domain.

Besides the three areas of concern above, there are smaller issues that should be discussed such as:

  *   Why does node-action "action-transit" need to be configured on a per flow basis?
Shouldn’t nodes receiving IOAM just follow the instructions in the IOAM headers, unless they act as decapsulating nodes?

Mickey

Date: Friday, October 30, 2020 at 11:41 AM

Hello IPPM,

Best,
Tommy & Ian

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 20 Nov 2020 09:55:12 +0000

Hi Mickey,

Thanks for your comments.
Please see in line.

Best,
Tianran
From: ippm [mailto:[email-masked]] On Behalf Of Spiegel, Mickey
Sent: Friday, November 20, 2020 12:54 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-zhou-ippm-ioam-yang

  1.  Scope:
The proposed YANG model only addresses configuration, i.e. whatever is required to trigger encapsulation and decapsulation of IOAM data in flows.
There are other areas to which the scope could be expanded, where a YANG model would prove very useful:
     *   Typically, the IOAM data is exported to an offline monitoring system that analyzes the IOAM data from the nodes in the IOAM domain. By design, draft-ietf-ippm-ioam-data leaves many details open such as units or timestamp format. While this aids greatly in the ability of different hardware implementations to support IOAM, this makes it difficult for offline monitoring systems to interpret the data, unless mechanisms are defined for the offline monitoring systems to discover these details from individual nodes. IMO, a YANG model is the right way to define such a mechanism.
<ZTR> We can augment the system Capabilities model and provides the IOAM capability attributes. This could be and usually is a separate data model. It would be good if you can provide a list of these data, and we can cooperate on a new draft.

<ZTR> The same as above.

     *   Besides the flow-level configuration, draft-ietf-ippm-ioam-data also defines the concept of namespaces. Namespaces add context to IOAM-Option-Types and associated IOAM-Data-Fields. Namespaces may provide additional context for IOAM Data Fields such as units or timestamp format, and some IOAM Data Fields are namespace specific. The YANG model could be extended to support configuration of this namespace-related context.
<ZTR> Yes, this could also be in the ioam capability model.

  1.  The proposed YANG model relies on the ACL YANG model (RFC 8519) to specify flows, which is very much a good thing. However, the proposed method to link the IOAM YANG model and the ACL YANG model is far from optimal:
     *   In draft-zhou-ippm-ioam-yang-08, within each profile, there is a single reference to an ACL through “leaf acl-name”. Each referenced ACL contains an ordered list of ACEs. Each ACE contains a forwarding action (accept, drop, or reject) and/or a log action (currently only log-syslog and log-none), in addition to the match criteria and statistics.
If the only purposes in defining these ACEs is for IOAM, then presumably forwarding action "accept" would have to be used, though this is not explicitly stated in the current draft.
<ZTR> We can state this in the next version.

<ZTR> So we can associate the ACE to each profile.

     *   A better approach is to flip the reference by augmenting ACE actions with choices such as ioam-encapsulate and associated leaf ioam-profile-name, so that each ACE can reference a different IOAM profile. This changes the granularity of the reference from ACLs to ACEs. For the case in the bullet immediately above this, there would be one ACL with two ACEs. The first ACE would reference the specific profile with tx-bytes and interface-speed. The second ACE would reference the general profile. The order of the ACEs within the ACL clarifies that a match on the first ACE wins.
<ZTR> I think this is a good idea. Thx. We can do this in the next version.

  1.  There have been lots of IOAM discussions about preventing IOAM data from leaking outside of the IOAM domain. Depending on the encapsulation that is used and the deployment scenarios, there may be cases where this relies on configuration of the IOAM domain boundaries.
In draft-zhou-ippm-ioam-yang-08, this requires configuration of both an IOAM profile and an ACL.
The IOAM profile specifies node-action "action-decapsulate" and references the ACL by name.
The ACL specifies one or more ACEs, with traffic matching any of those ACEs taking the node-action specified in the IOAM profile.
While this approach is flexible, it is somewhat unwieldy. This approach significantly increases the chances of operational errors, where misconfiguration results in leaking of IOAM data outside of the IOAM domain.
A simpler approach would be to list interfaces at the edges of the IOAM domain.
<ZTR> I do not understand this point. Do you mean, for the egress node, we use a wide filter(interface) for the decap action? What if one packet without IOAM encapsulation hit this ACL? I am afraid this will cause a forwarding error.

  *   Why does node-action "action-transit" need to be configured on a per flow basis?
Shouldn’t nodes receiving IOAM just follow the instructions in the IOAM headers, unless they act as decapsulating nodes?
<ZTR> Here I do not remember. It takes for a long time. It seems you are right. Could other coauthors helps on this?

Mickey

Hello IPPM,

Best,
Tommy & Ian

---

From: "Spiegel, Mickey" <[email-masked]>
Date: Fri, 20 Nov 2020 19:35:58 +0000

Tianran,

Thanks for your replies.
Please see my responses in line as [MS].

Mickey

From: Tianran Zhou <[email-masked]>
Date: Friday, November 20, 2020 at 1:55 AM
To: "Spiegel, Mickey" <[email-masked]>, Tommy Pauly <tpauly=[email-masked]>, "IETF IPPM WG ([email-masked])" <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: RE: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi Mickey,

Best,
Tianran

  1.  Scope:

     *   Besides the flow-level configuration, draft-ietf-ippm-ioam-data also defines the concept of namespaces. Namespaces add context to IOAM-Option-Types and associated IOAM-Data-Fields. Namespaces may provide additional context for IOAM Data Fields such as units or timestamp format, and some IOAM Data Fields are namespace specific. The YANG model could be extended to support configuration of this namespace-related context.
<ZTR> Yes, this could also be in the ioam capability model.
[MS] Whether this belongs in an IOAM capability model or with the rest of the configuration is not so clear to me.
Some of this is configuration.

     *   A better approach is to flip the reference by augmenting ACE actions with choices such as ioam-encapsulate and associated leaf ioam-profile-name, so that each ACE can reference a different IOAM profile. This changes the granularity of the reference from ACLs to ACEs. For the case in the bullet immediately above this, there would be one ACL with two ACEs. The first ACE would reference the specific profile with tx-bytes and interface-speed. The second ACE would reference the general profile. The order of the ACEs within the ACL clarifies that a match on the first ACE wins.
<ZTR> I think this is a good idea. Thx. We can do this in the next version.
[MS] Thanks for considering this. I am looking forward to seeing your next version.

  1.  There have been lots of IOAM discussions about preventing IOAM data from leaking outside of the IOAM domain. Depending on the encapsulation that is used and the deployment scenarios, there may be cases where this relies on configuration of the IOAM domain boundaries.
In draft-zhou-ippm-ioam-yang-08, this requires configuration of both an IOAM profile and an ACL.
The IOAM profile specifies node-action "action-decapsulate" and references the ACL by name.
The ACL specifies one or more ACEs, with traffic matching any of those ACEs taking the node-action specified in the IOAM profile.
While this approach is flexible, it is somewhat unwieldy. This approach significantly increases the chances of operational errors, where misconfiguration results in leaking of IOAM data outside of the IOAM domain.
A simpler approach would be to list interfaces at the edges of the IOAM domain.
<ZTR> I do not understand this point. Do you mean, for the egress node, we use a wide filter(interface) for the decap action? What if one packet without IOAM encapsulation hit this ACL? I am afraid this will cause a forwarding error.
[MS] The proposal is to allow the decapsulate action to be driven by a list of egress interfaces instead of ACLs.
Packets that egress out such interfaces that did not have any IOAM headers would have nothing to decapsulate.

[MS] I do not follow your concern about a forwarding error.
In the current draft-zhou-ippm-ioam-yang-08, when a profile has node-action "action-decapsulate", any packets matching the referenced ACL will decapsulate any IOAM headers with a matching namespace. There are no augments to the ACL match criteria to condition on presence of IOAM headers. This implies that packets without IOAM headers could match the ACL. I do not think such augments would be necessary. If the packet did not have any IOAM headers then there would be nothing to decapsulate, no harm done.

[MS] Another point to note is that the decapsulate action should be driven by an egress filter, whether that be a list of egress interfaces as I have proposed, or an egress ACL as supported by the current draft-zhou-ippm-ioam-yang-08.
My preference is to use ingress ACLs to drive IOAM encapsulation. If an ingress ACL says to do IOAM encapsulation and an egress filter says to do IOAM decapsulation, IMO that is normal behavior that must be supported. For example, communication between two hosts attached to the same ToR switch, where the ToR switch typically acts as an IOAM encapsulating node for traffic transmitted by the hosts, and as an IOAM decapsulating node for traffic received by the hosts. In this case, the packet would be transmitted without any IOAM headers due to decapsulation. This can be viewed logically as encapsulation followed by decapsulation. Whether the device actually carried out the encapsulation and decapsulation internally does not matter, as that is not visible externally.
If egress ACLs are used to drive IOAM encapsulation, then it would be a configuration error to define ACEs that say to do IOAM encapsulation on a packet that also matches filters for IOAM decapsulation, for the same namespace. This scenario could occur regardless of whether decapsulation is driven by a list of egress interfaces, or by egress ACL filters.

  *   Why does node-action "action-transit" need to be configured on a per flow basis?
Shouldn’t nodes receiving IOAM just follow the instructions in the IOAM headers, unless they act as decapsulating nodes?
<ZTR> Here I do not remember. It takes for a long time. It seems you are right. Could other coauthors helps on this?
[MS] I also encourage others to reply with their opinions on this issue.

Mickey

Hello IPPM,

Best,
Tommy & Ian