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

["Spiegel, Mickey" <[e-mail]>]

Tianran,

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

Mickey

From: Tianran Zhou <[e-mail]>
Date: Friday, November 20, 2020 at 1:55 AM
To: "Spiegel, Mickey" <[e-mail]>, 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

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


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

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?
[MS] I also encourage others to reply with their opinions on this issue.

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