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

[Tianran Zhou <[e-mail]>]

Hi Mickey,

Thanks for your comments.
Please see in line.

Best,
Tianran
From: ippm [mailto:[e-mail]] On Behalf Of Spiegel, Mickey
Sent: Friday, November 20, 2020 12:54 PM
To: Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG ([e-mail]) <[e-mail]>
Cc: IPPM Chairs <[e-mail]>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

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


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

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

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?
<ZTR> Here I do not remember. It takes for a long time. It seems you are right. Could other coauthors helps on this?

Mickey


From: ippm <[e-mail]<mailto:[e-mail]>> on behalf of Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>
Date: Friday, October 30, 2020 at 11:41 AM
To: "IETF IPPM WG ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Cc: IPPM Chairs <[e-mail]<mailto:[e-mail]>>
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

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