Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang

[Greg Mirsky <[e-mail]>]

Dear Tianran,
thank you for the discussion and for sharing your opinion. I've added
several notes under the GIM4>> tag below.

Dear WG Chairs,
I want to clarify my position on the WG LC for draft-ietf-ippm-ioam-yang:

   - I think the current draft version is not ready for publication.
   - it appears that in the course of the discussion, several questions may
   be considered by the WG:
      - The scope of the IOAM YANG data model - is limited to configuration
      or also includes the presentation of IOAM data types defined in RFC 9197?
      - Whether IOAM DEX is an integral part of IOAM?
      - Should the IOAM YANG data model enable the configuration of an IOAM
      node in IOAM-DEX trace mode?
      - Whether the control of only IOAM operational state (enable/disable)
      on a transit node creates a new DDoS attack vector against that node.
      Consequently, how can this risk be mitigated?
      - Should the model support the presentation of the looped-back IOAM
      packet with the Loopback flag set?
      - Should the model support the use of (configuration and presentation
      of the test outcomes) the Active IOAM flag?
      - Should the configuration of IOAM over IPv6 and/or NSH be part of
      this document?

Regards,
Greg

On Fri, Aug 19, 2022 at 12:12 AM Tianran Zhou <[e-mail]>
wrote:

> Hi Greg,
>
>
>
> Thanks for your quick reply. Please see inline.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Friday, August 19, 2022 12:16 PM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG <
> [e-mail]>
> *Subject:* Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang
>
>
>
> Hi Tianran,
>
> please find my follow-up notes below under the GIM3>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Aug 18, 2022 at 8:03 PM Tianran Zhou <[e-mail]>
> wrote:
>
> Hi Greg,
>
>
>
> Thanks for further discussions. Please see below.
>
>
>
> GIM2>> Yes, to a certain degree. Perhaps I was not clear in my question. I
> imagine that by applying IOAM, an operator expects to collect some
> information that reflects the operational state and performance experienced
> by the user packet. Could you point me to the part of the data model in the
> draft that allows that?
>
>
>
> ZTR> This model only considers IOAM configuration related to date
> collection across devices. The PM/operational data could be exported by
> YANG push, gRPC, IPFIX, etc. And the PM data YANG model is out of this
> document scope.
>
> GIM3>> I think that is a good question for the IPPM WG to discuss. IOAM
> collects essential information (not only PM), but it appears that the
> current version of the IOAM YANG data model does not allow that information
> to be presented. That, to me, appears as a very unfortunate shortcoming of
> the draft.
>
>
>
> ZTR> I have no position on this. I would like to hear inputs from the WG.
> But I could say, separation of configuration and PM data is normal in my
> opinion. For example,
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/,
> this draft specifies the vpn service realted pm data model specifically.
> Maybe someone from the WG would like to study on this.
>
> In my opinion, on the other hand, the separation makes sense. The PM data
> relates to services, not to one oam method.  I.e., one-way delay for
> example, could be achieved by ioam, stamp, etc. If a service (5G, VPN, …)
> need this metric, it should specify ***-pm model.
>
GIM4>> RFC 9197 defined IOAM data types that reflect the operational state
and enable the calculation of some performance metrics. Thus, I believe
that a data model of these data types in this draft is well-justified.

>
>
> GIM2>> If the scope of the data model is identical to IOAM Trace options
> discussed in RFC 9197, then that must be explicitly stated. But if it
> includes IOAM-DEX and IOAM Flags, then the characterization of IOAM must be
> modified accordingly. Tha applicability of IOAM in multicast flows is a
> separate matter.
>
>
>
> ZTR> I am not sure if RFC9197 definition is only for IOAM trace or not. At
> least it applies to PoT, E2E in the same RFC. What’s your suggestion on the
> description? Shall we just revise it here in this document, or in IOAM-DEX,
> IOAM Flags also? It seems need broader discussions.
>
> GIM3>> I am a bit confused. Earlier, you said that
>
>    In-situ Operations, Administration, and Maintenance (IOAM) records
>
>    operational and telemetry information in user packets while the
>
>    packets traverse a path between two points in the network.
>
> comes from RFC 9197. But IOAM-DEX does not record information into a user
> packet. I suggest changing either the wording or the scope of the document.
> I think that is a straightforward proposal and the WG can decide on it.
>
>
>
> ZTR> RFC9197 has this definition for IOAM “In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network.”. Based on this definition , my question:
>
> 1. Is IOAM-DEX  IOAM or not?
>
> GIM4>> In my opinion, IOAM-DEX is part of IOAM. On the other hand, the
particular mechanism that may be used to export data is not.

> 2. Should IOAM YANG model (this draft) include IOAM-DEX? Or if we want to include IOAM-DEX, can we name it IOAM model or other name?
>
> GIM4>> I clearly support including IOAM-DEX in the IOAM YANG data model.
No reason to change the name of the draft.

>
>
>
>
> GIM2>> Perhaps the behavior of a transit IOAM node is outside the scope,
> but it seems like that node must be configured with the information that
> enables the processing of the IOAM flow. Furthermore, the transit node is
> expected to generate a packet towards the encapsulating IOAM node. What
> controls the selection of the encapsulation of such packet? And on the
> encapsulating node that receives looped packets, what enables the operator
> to examine them and discover the list of traversed nodes?
>
>
>
> ZTR> For the transit node, we have an administrative enable knob to enable
> IOAM. All the other behaviors are triggered by data plane, e.g. flags. No
> need for explicit configurations.
>
>          +--rw ioam-profiles
>
>             +--rw admin-config
>
>             |  +--rw enabled?   boolean
>
> GIM3>> I cannot agree because that would create a very dangerous attack
> vector on the transit node. I believe that an operator must have mechanisms
> to control to which IOAM data flows the particular node performs as the
> transit IOAM node. Also, it seems like you've missed other parts of the
> note above:
>
>    -  Furthermore, the transit node is expected to generate a packet
>    towards the encapsulating IOAM node. What controls the selection of the
>    encapsulation of such packet?
>    - And on the encapsulating node that receives looped packets, what
>    enables the operator to examine them and discover the list of traversed
>    nodes?
>
> I hope you will share the author's opinion on them.
>
>
>
> ZTR> I am not an author of IOAM flag, I can only share my opinion as a
> contributor on this. :-)
>
> IMO, including the two explicit questions, the actions are triggered by
> data packet with IOAM option or flag set (as indicator). That’s the IOAM
> mechanism I understand. I do not see any document  (RFC9197, IOAM-flag,
> IOAM-deployment, …) mention the potential attack you raised.
>
>
>
>
>
> GIM2>> Thinking about "that model supports NSH and IPv6", I came to
> conclusion that the model as it is defined in the draft does not allow
> configuration of IOAM in these networks. I find that the data model doesn't
> have the means to specify the data flow  which will be monitored using
> IOAM. If understand the position of the authors correctly, the missing
> parts to be defined in separate documents. While that might be reasonable
> path for IPv6, we need to consider that the SFC WG is in its sunset and
> will be closed around IETF-115. Hence, I would propose that if this model
> is intended to support IPv6 and NSH, then it also includes all necessary
> constructs to define data flow for IOAM application.
>
>
>
> ZTR> For each profile, there is a filter which is used to identify the
> monitored data flow. This mode reuses acl model. Protocol type is to
> indicate where and how to encap IOAM data field, say in IPv6(
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-options-08)
> and NSH(https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-10).
>
> GIM3>> I cannot find in either of the drafts (I'm the Shepherd of IOAM in
> NSH) any discussion of extending the IOAM YANG data model. And considering
> the limited time for SFC-related documents, I don't see it possible to
> update the draft-ietf-sfc-ioam-nsh as that would require another WG LC.
>
>
>
> ZTR> I do not see why IOAM in NSH need to discuss the IOAM YANG model
> extension. Because IOAM YANG model already considered it by extending the
> “protocol type”. But for other potential encaps, like the mpls you
> mentioned, it’s necessary.
>
>
>
>             +--rw ioam-profile* [profile-name]
>
>                +--rw profile-name                    string
>
>                +--rw filter
>
>                |  +--rw filter-type?   ioam-filter-type
>
>                |  +--rw ace-name?      -> /acl:acls/acl/aces/ace/name
>
>                +--rw protocol-type?                  ioam-protocol-type
>
>
>
>
>
> GIM2>> One aspect, common for encapsulating, decapsulating, and transit
> IOAM nodes - the definition of the data flow monitored by IOAM. Second, the
> control of how a transit node handles operational state and telemetry
> information associated with the trigger packet. For example, would it
> export the raw information to the Collector or performs some processing
> locally and transmits the results?
>
>
>
> ZTR> For transit node, as I stated above, I think there is no need to
> identify the data flow nor any other configuration. All can triggered by
> data packet. The data export is out of this document scope.
>
> GIM3>> Again, I strongly disagree that a mere operational enable/disable
> switch provides sufficient control for the IOAM functionality on a transit
> node.
>
>
>
> ZTR> If it’s about security, I think we still have time to revise the IOAM
> deployment document which is now in WGLC.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Friday, August 19, 2022 6:19 AM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG <
> [e-mail]>
> *Subject:* Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang
>
>
>
> Hi Tianran,
>
> thank you for further clarification. These are helpful. I have several
> outstanding questions that I've added below in-line tagged bu GIM2>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Aug 17, 2022 at 7:21 PM Tianran Zhou <[e-mail]>
> wrote:
>
> Hi Greg,
>
>
>
> Thanks. Please see below.
>
>
>
> Cheers,
>
> Tianran
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Wednesday, August 17, 2022 10:36 AM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG <
> [e-mail]>
> *Subject:* Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang
>
>
>
> Hi Tianran,
>
> thank you for your kind consideration of my comments. Please find my
> follow-up notes in-lined below under the GIM>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Aug 14, 2022 at 8:33 PM Tianran Zhou <[e-mail]>
> wrote:
>
> Hi Greg,
>
> Thanks very much for your comments.
>
> Please see in line.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* ippm [mailto:[e-mail]] *On Behalf Of *Greg Mirsky
> *Sent:* Sunday, August 14, 2022 4:22 AM
> *To:* Tommy Pauly <tpauly=[e-mail]>
> *Cc:* IETF IPPM WG <[e-mail]>
> *Subject:* Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang
>
>
>
> Dear Authors, et al.,
>
> please kindly consider my notes as the WG LC comments on the draft:
>
>    - I read the document and left with a general question about the
>    applicability of this YANG model. Is it to be applied at:
>
>
>    - ingress IOAM node
>       - ingress and egress IOAM nodes
>       - ingress, egress, and transit IOAM nodes
>
> ZTR> Note ingress, egress, and transit are modeled as node action of a
> profile. That means for different measurements (e.g., tracing, e2e), one
> node role could change. As for one profile, there is no transit node
> configuration specified in this model.
>
> GIM>> Can you give an example of how an IOAM node would be configured as:
>
>    - ingress, i.e., encapsulating, IOAM node;
>    - egress, i.e., decapsulating, IOAM node.
>
> ZTR> Let’s take incremental tracing profile for example. Here is the yang
> tree.
>
>    +--rw incremental-tracing-profile {incremental-trace}?
>
>       +--rw enabled?                boolean
>
>       +--rw node-action?            ioam-node-action
>
>       +--rw trace-types
>
>       |  +--rw use-namespace?   ioam-namespace
>
>       |  +--rw trace-type*   ioam-trace-type
>
>       +--rw enable-loopback-mode?   boolean
>
>       +--rw enable-active-mode?   boolean
>
>       +--rw max-length?             uint32
>
> “node-action” indicates it’s encap or decap.
>
> For encap, more configurations are necessary. Like namespace, trace-type,
> flags, …
>
> For decap, no more configurations.
>
> Make sense?
>
> GIM2>> Yes, to a certain degree. Perhaps I was not clear in my question. I
> imagine that by applying IOAM, an operator expects to collect some
> information that reflects the operational state and performance experienced
> by the user packet. Could you point me to the part of the data model in the
> draft that allows that?
>
>
>    - Abstract and the first paragraph of the Introduction section
>    characterize IOAM as only collecting the operational data and telemetry
>    information in the data packet. That seems like a contradiction with the
>    list of IOAM options that include the IOAM Direct Export.
>
> ZTR> I am sorry I do not get you here. Could you please give some more
> hints?
>
> GIM>> Abstract and Introduction state that:
>
>     In-situ Operations, Administration, and Maintenance (IOAM) records
>
>    operational and telemetry information in user packets while the
>
>    packets traverse a path between two points in the network.
>
> It appears to me that there are two inaccuracies in that sentence:
>
>    - Direct Export IOAM Trace option does not record operational
>    information and telemetry information in a user packet
>    - IOAM, as I understand it, can be used in a multicast flow and with
>    user packets that traverse p2mp paths.
>
> I hope that clarifies my question.
>
>
>
> ZTR> The IOAM definition is the same as RFC9197. I agree with you on the
> two perspectives.  What’s your suggestion?
>
> GIM>> If the scope of the data model is identical to IOAM Trace options
> discussed in RFC 9197, then that must be explicitly stated. But if it
> includes IOAM-DEX and IOAM Flags, then the characterization of IOAM must be
> modified accordingly. Tha applicability of IOAM in multicast flows is a
> separate matter.
>
>
>
>
>
>    - The first paragraph of the Introduction is likely to benefit from
>    references to documents that define IOAM encapsulation in IPv6 and NSH.
>
> ZTR> OK. I will add.
>
> GIM>> Thank you
>
>
>    - The Proof-of-Transit option is listed in the Introduction section.
>    Can you give an example or reference of an IETF document that describes the
>    applicability of this trace option?
>
> ZTR> This model only gives the pointer to add PoT configuration, but does
> not specify the PoT configuration. As mentioned in the document “User need
> to augment this module for the configuration of a specifc POT type.”
>
> GIM>> Thank you for the clarification.
>
>
>    - It seems like "end to end data" in Section 3.1 should be
>    "edge-to-edge data".
>
> ZTR> Yes, thanks.
>
>    - Can you explain the behavior of a transit IOAM node that receives
>    IOAM with Loopback mode/flag? How "the source" is identified in a data
>    packet, for example, NSH?
>
> ZTR> I hope other co-authors could help on this. IMO, this should be
> defined in IOAM-flag document. Not this.
>
> GIM2>> Perhaps the behavior of a transit IOAM node is outside the scope,
> but it seems like that node must be configured with the information that
> enables the processing of the IOAM flow. Furthermore, the transit node is
> expected to generate a packet towards the encapsulating IOAM node. What
> controls the selection of the encapsulation of such packet? And on the
> encapsulating node that receives looped packets, what enables the operator
> to examine them and discover the list of traversed nodes?
>
>
>    - What is "active measurement"? Can you provide an example or
>    reference to an IETF document that describes active measurements using IOAM?
>
> ZTR> The same as above.
>
>    - I found only two data plane encapsulations - NSH and IPv6. Does that
>    mean that this model is not intended to support IOAM in an MPLS network?
>
> ZTR>We defined a base identity to represent the carrier protocol. More
> encapsulations could be extended. This document only considers mature ones
> which are wg docuemts. MPLS encapsulation is still in wg discussion.
>
> GIM>> Would you agree that the scope of this model must be explicitly
> stated?
>
>
>
> ZTR> How about I say “This model supports NSH and IPv6 data plane
> encapsulations.  User need to augment this module for more data plane
> encapsulations.”?
>
> GIM2>> Thinking about "that model supports NSH and IPv6", I came to
> conclusion that the model as it is defined in the draft does not allow
> configuration of IOAM in these networks. I find that the data model doesn't
> have the means to specify the data flow  which will be monitored using
> IOAM. If understand the position of the authors correctly, the missing
> parts to be defined in separate documents. While that might be reasonable
> path for IPv6, we need to consider that the SFC WG is in its sunset and
> will be closed around IETF-115. Hence, I would propose that if this model
> is intended to support IPv6 and NSH, then it also includes all necessary
> constructs to define data flow for IOAM application.
>
>
>    - Can you point out a part of the YANG model that can be used to
>    control a transit IOAM node for the IOAM Direct Export trace option?
>
> ZTR> There is no configuration on transit node for IOAM-DEX in this
> document.
>
> GIM>> I think that the IOAM YANG data model must support the configuration
> of a transit node for the Direct Export Trace option. Otherwise, the
> document must not state that it supports IOAM-DEX.
>
>
>
> ZTR> I am sorry, I am afraid I cannot get you. IMO, this model indeed
> specifies the encap and decap node configurations. And we indeed want to
> support IOAM-DEX.  I think what we need to discuss is if we need to
> configure the transit node. Could you please give more hints on the
> configurations on a transit node?
>
> GIM2>> One aspect, common for encapsulating, decapsulating, and transit
> IOAM nodes - the definition of the data flow monitored by IOAM. Second, the
> control of how a transit node handles operational state and telemetry
> information associated with the trigger packet. For example, would it
> export the raw information to the Collector or performs some processing
> locally and transmits the results?
>
>
>    - Nits:
>
>
>    - s/Edge to Edge/Edge-to--Edge/ per RFC 9197
>
> ZTR>Thanks. I will revise.
>
> Regards,
>
> Greg
>
>
>
> On Tue, Aug 9, 2022 at 9:15 AM Tommy Pauly <tpauly=
> [e-mail]> wrote:
>
> Hello IPPM,
>
>
>
> This email starts a Working Group Last Call for draft-ietf-ippm-ioam-yang.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/
>
> https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-yang-04.html
>
>
>
> Please review this document, and reply to this email to indicate your
> comments, and if you support publishing this document.
>
>
>
> The last call will go until *Wednesday, August 31*.
>
>
>
> Best,
>
> Tommy & Marcus
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>
>