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

[Greg Mirsky <[e-mail]>]

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.

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

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

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

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

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