Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt

[Greg Mirsky <[e-mail]>]

Hi Tianran,
I believe that there is a strong interest in the WG to see IOAM Yang data
model include IOAM-DEX, regardless of the semantics of how IOAM and
IOAM-DEX have been defined in respective RFCs. In my opinion, it is about
the usefulness of the YANG data model, not about formal naming. I feel that
it is well-understood already that, strictly speaking, IOAM-DEX behavior in
regard to transporting operational state and telemetry information is
different from how IOAM behaves. But, I am also convinced that that
difference has insignificant impact on the YANG data model which is far
smaller then staring a new draft.
I think it is time to set semantics aside and look into adding support of
IOAM-DEX into the YANG data model document. Let me know how I can help.

Regards,
Greg

On Wed, Mar 29, 2023 at 1:44 PM Tianran Zhou <[e-mail]> wrote:

> Hi Thomas,
>
> Greg> Whether IOAM DEX is an integral part of IOAM?
> Thomas> Yes I believe it is.
> https://datatracker.ietf.org/doc/html/rfc9197#section-4.1 describes the
> initial option types where
> https://datatracker.ietf.org/doc/html/rfc9326#abstract adds an IOAM
> option type called direct export.
>
> ZTR> I understand what Greg concerned is from the definition. In RFC9197:
> " IOAM records OAM information within the packet while the packet
> traverses a particular network domain."
> This is different from the IOAM-DEX behavior.
>
>
>
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 2023年3月27日 9:17
> 收件人: Tianran Zhou <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> 抄送: [e-mail]
> 主题: RE: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt
>
> Dear Tianran, Dear Greg
>
> Thanks a lot for the summary my apology for late reply.
>
> I have been reviewing Greg's comments and below my reply.
>
> Greg> 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?
> Thomas> I suggest to change the following sentence in the abstract from
>
> "This document defines a YANG module for the IOAM function."
>
> To
>
> "This document defines a YANG module for configuring IOAM functions."
>
>
> Greg> Whether IOAM DEX is an integral part of IOAM?
> Thomas> Yes I believe it is.
> https://datatracker.ietf.org/doc/html/rfc9197#section-4.1 describes the
> initial option types where
> https://datatracker.ietf.org/doc/html/rfc9326#abstract adds an IOAM
> option type called direct export.
>
> Greg> Should the IOAM YANG data model enable the configuration of an IOAM
> node in IOAM-DEX trace mode?
> Thomas> Yes it should. Reviewing
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-04#section-3.4,
> and looking at https://datatracker.ietf.org/doc/html/rfc9326#section-3.2,
> I think the configuration options proposed matches what can be configured.
> However, looking at
> https://datatracker.ietf.org/doc/html/rfc9326#section-6, I believe this
> needs to be addressed in draft-ietf-ippm-ioam-yang.
>
> Greg> 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?
> Thomas> This has already been answered in
> https://datatracker.ietf.org/doc/html/rfc9326#section-6. I suggest that
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang#section-5draft-ietf-ippm-ioam-yang
> is expanded by describing how the following objective
>
> - Selective DEX (Section 3.1.1) is applied by IOAM encapsulating nodes in
> order to limit the potential impact of DEX attacks to a small fraction of
> the traffic.
>
> Described in https://datatracker.ietf.org/doc/html/rfc9326#section-6 can
> be addressed by configuring filter. Since data export is out of scope, I
> believe the following objectives
>
> - Rate limiting of exported traffic (Section 3.1.2) is applied by IOAM
> nodes in order to prevent overloading attacks and to significantly limit
> the scale of amplification attacks.
> - IOAM encapsulating nodes are required to avoid pushing the DEX
> Option-Type into IOAM exported packets (Section 3.1.2), thus preventing
> some of the amplification and export loop scenarios.
>
> Are out of scope for draft-ietf-ippm-ioam-yang. Would you agree?
>
> Greg> Should the model support the presentation of the looped-back IOAM
> packet with the Loopback flag set?
> Thomas> You are referring to https://datatracker.ietf.org/doc/html/rfc9322.
> I think it should. Yes.
>
> Greg> Should the model support the use of (configuration and presentation
> of the test outcomes) the Active IOAM flag?
> Thomas> Not sure if I understand this question. If it means wherever
> draft-ietf-ippm-ioam-yang should cover operational metrics describing how
> many packets have been sent, this would indeed from a network operator
> point of view beneficial.
>
> Greg> Should the configuration of IOAM over IPv6 and/or NSH be part of
> this document?
> Thomas> Could you elaborate why configuration is different depending
> packet encapsulation being used.
>
> Best wishes
> Thomas
>
> -----Original Message-----
> From: Tianran Zhou <[e-mail]>
> Sent: Tuesday, February 28, 2023 3:19 PM
> To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>;
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt
>
> Hi Thomas,
>
> Please see the discussions during the LC, between Greg and me.
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fs91KTSsmbHMotegy9f-6zWUSUWw&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VYnv4VnFOg3zF665A7%2Fog6twTHHnQ5WLjIgJDxLC5JE%3D&reserved=0
>
> At last, there are still several concerns as follows. The authors
> discussed, we can eliminate most of the questions by excluding IOAM-DEX in
> this draft.
>
>       - 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?
>
> Cheers,
> Tianran
>
> -----Original Message-----
> From: mailto:[e-mail] [mailto:[e-mail]]
> Sent: Tuesday, February 28, 2023 1:34 PM
> To: Tianran Zhou <mailto:[e-mail]>; mailto:
> [e-mail]
> Cc: mailto:[e-mail]
> Subject: RE: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt
>
> Dear Tianran,
>
> I share Alex and Greg's concerns and would appreciate that you detail
> where IOAM-DEX does not follow the IOAM definition and where IOAM options
> adds complexity in YANG. I think this needs to be addresses within the
> working group. I gladly support the discussion.
>
> Best wishes
> Thomas
>
> -----Original Message-----
> From: ippm <mailto:[e-mail]> On Behalf Of Tianran Zhou
> Sent: Thursday, February 23, 2023 9:17 AM
> To: Alex Huang Feng <mailto:[e-mail]>; Tianran Zhou
> <mailto:zhoutianran=[e-mail]>
> Cc: mailto:[e-mail]
> Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt
>
> Hi Alex,
>
> There are several concerns from the WG wrt IOAM-DEX, including:
> 1. IOAM-DEX does not follow the IOAM definition. Maybe we need a new
> definition for both or exclude IOAM-DEX from this draft.
> 2. The IOAM-DEX configuration may be different from other IOAM options
> with more complexity.
>
> Follow the principle with max consensus, we decided to exclude IOAM-DEX
> from this draft. So that it aligns rfc9197.
> However, this yang model is still extensible.
> We can cooperate on a new draft if you have interest.
>
> Best,
> Tianran
>
>
> -----Original Message-----
> From: ippm [mailto:[e-mail]] On Behalf Of Alex Huang Feng
> Sent: Monday, February 20, 2023 10:45 PM
> To: Tianran Zhou <mailto:zhoutianran=[e-mail]>
> Cc: mailto:[e-mail]
> Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt
>
> Hi Tianran,
>
> I think it is pity the IOAM-DEX was removed from the draft. I feel that
> since it is already a standard, it should be in the draft.
> Any reasons why it was removed?
>
> Cheers,
> Alex
>
> > On 16 Feb 2023, at 12:15, Tianran Zhou <mailto:zhoutianran=
> [e-mail]> wrote:
> >
> > Hi WG,
> >
> > We just upload a new revision.
> > The main updates include:
> > 1. Remove the IOAM-DEX and two IOAM flags to align with rfc 9197.
> > 2. Add max length constraint to both pre-allocated and incremental
> tracing.
> > 3. Add examples in the appendix.
> >
> > Your comments are welcome.
> >
> > Cheers,
> > Tianran
> >
> > -----Original Message-----
> > From: ippm [mailto:[e-mail]] On Behalf Of mailto:
> [e-mail]
> > Sent: Thursday, February 16, 2023 7:12 PM
> > To: mailto:[e-mail]
> > Cc: mailto:[e-mail]
> > Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-05.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the IP Performance Measurement WG of the
> IETF.
> >
> >        Title           : A YANG Data Model for In-Situ OAM
> >        Authors         : Tianran Zhou
> >                          Jim Guichard
> >                          Frank Brockners
> >                          Srihari Raghavan
> >  Filename        : draft-ietf-ippm-ioam-yang-05.txt
> >  Pages           : 28
> >  Date            : 2023-02-16
> >
> > Abstract:
> >   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.  This
> >   document defines a YANG module for the IOAM function.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-yang%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1ceA%2FAd2SIza0QdMw9oYXBgz36%2BIroJE322LKUC%2FO8M%3D&reserved=0
> >
> > There is also an htmlized version available at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-yang-05&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7R3rriq85frIAQ6fRTlgAfzYZjw6hGNiWp3nAVxhExo%3D&reserved=0
> >
> > A diff from the previous version is available at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ippm-ioam-yang-05&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bt6pmx0st%2FqTmRViIasYVNvUSuBKlwBWYAUkD%2FifZ%2Bs%3D&reserved=0
> >
> >
> > Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
> >
> >
> > _______________________________________________
> > ippm mailing list
> > mailto:[e-mail]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nRuMA34DFp%2BDGGEfejBt2xD9WAOtjhIv4DZVlvEVX3U%3D&reserved=0
> >
> > _______________________________________________
> > ippm mailing list
> > mailto:[e-mail]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nRuMA34DFp%2BDGGEfejBt2xD9WAOtjhIv4DZVlvEVX3U%3D&reserved=0
>
> _______________________________________________
> ippm mailing list
> mailto:[e-mail]
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nRuMA34DFp%2BDGGEfejBt2xD9WAOtjhIv4DZVlvEVX3U%3D&reserved=0
>
> _______________________________________________
> ippm mailing list
> mailto:[e-mail]
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf10c733234bc42eec86c08db1953c342%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638131619769712596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nRuMA34DFp%2BDGGEfejBt2xD9WAOtjhIv4DZVlvEVX3U%3D&reserved=0
>