Re: [ippm] New Version Notification for draft-ietf-ippm-ioam-yang-07.txt

[[e-mail]]

Dear Tianran,

Thanks a lot for add IOAM-DEX. That looks perfect to me.

Greg and I made the following editorial remarks on the mailing list:

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


I think that would make it clear that the specified YANG module doesn't cover IOAM data types.

Greg: Would the proposed sentence change in the abstract also address your concern?

Best wishes
Thomas

-----Original Message-----
From: Tianran Zhou <[e-mail]> 
Sent: Tuesday, June 27, 2023 12:08 PM
To: IETF IPPM WG <[e-mail]>
Cc: Greg Mirsky <[e-mail]>; Graf Thomas, INI-NET-VNC-HCS <[e-mail]>
Subject: FW: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt

Hi Greg, Thomas, and WG,

As requested in the WGLC, I updated the draft with ioam-dex included.
Please check if it works for you.

Cheers,
Tianran

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, June 27, 2023 6:05 PM
To: Frank Brockners <[e-mail]>; Jim Guichard <[e-mail]>; Srihari Raghavan <[e-mail]>; Tianran Zhou <[e-mail]>
Subject: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt


A new version of I-D, draft-ietf-ippm-ioam-yang-07.txt has been successfully submitted by Tianran Zhou and posted to the IETF repository.

Name:		draft-ietf-ippm-ioam-yang
Revision:	07
Title:		A YANG Data Model for In-Situ OAM
Document date:	2023-06-27
Group:		ippm
Pages:		30
URL:            https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-yang-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-ioam-yang-07

Abstract:
   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.  RFC9197
   discusses the data fields and associated data types for IOAM.  This
   document defines a YANG module for the IOAM function.

                                                                                  


The IETF Secretariat

--- Begin Message ---

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

--- End Message ---