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

Hi Tianran,

I totally agree with Justin. 
For me all IOAM types defined in the IANA registry “IOAM Option-Types” should be considered part of “IOAM”. Otherwise, the definition of this registry is not right. I know it’s a bit extreme, but that’s only my opinion.
I noticed there are some bits allocated for draft-ietf-ippm-ioam-data-integrity but I see this draft as an extension of the existing ones and therefore would not include them in this draft yet.

As per the IOAM DEX YANG model part, I can also help.

Cheers,
Alex

> On 29 Mar 2023, at 08:57, Justin Iurman <justin.iurman@uliege.be> wrote:
> 
> Hi Tianran,
> 
> Please see inline.
> 
> On 3/29/23 00:44, Tianran Zhou 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 <https://datatracker.ietf.org/doc/html/rfc9197#section-4.1> describes the initial option types where https://datatracker.ietf.org/doc/html/rfc9326#abstract <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.
> 
> Justin> I tend to disagree here. Reading the definition again and again, it could very well work for DEX: "IOAM records OAM information within the packet" as a first part, which corresponds to the DEX encapsulating node, then "while the packet traverses a particular network domain" for the second part, where nothing happens (I mean, inside the packet, not talking about the triggering part). So, I guess it's a matter of how one reads the definition, which I agree might be misinterpreted for the DEX. Anyway, I don't see a difference between DEX and E2E for example. Indeed, in both cases, the encapsulating node inserts the IOAM Option-Type and then nothing on the path would add more data. AFAIK, E2E *is* an integral part of IOAM... and so is DEX. I understand the purpose of DEX is a little different but, from a pure definition point of view (and based on the IANA registry defining IOAM Option-Types), DEX *is* an integral part of IOAM. So, +1 to put DEX back into the yang model.
> 
> Thanks,
> Justin
> 
>> -----邮件原件-----
>> 发件人: Thomas.Graf@swisscom.com [mailto:Thomas.Graf@swisscom.com]
>> 发送时间: 2023年3月27日 9:17
>> 收件人: Tianran Zhou <zhoutianran@huawei.com>; Thomas.Graf@swisscom.com; alex.huang-feng@insa-lyon.fr; gregimirsky@gmail.com
>> 抄送: ippm@ietf.org
>> 主题: 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 <zhoutianran@huawei.com>
>> Sent: Tuesday, February 28, 2023 3:19 PM
>> To: Graf Thomas, INI-NET-VNC-HCS <Thomas.Graf@swisscom.com>; alex.huang-feng@insa-lyon.fr
>> Cc: ippm@ietf.org
>> 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:Thomas.Graf@swisscom.com [mailto:Thomas.Graf@swisscom.com]
>> Sent: Tuesday, February 28, 2023 1:34 PM
>> To: Tianran Zhou <mailto:zhoutianran@huawei.com>; mailto:alex.huang-feng@insa-lyon.fr
>> Cc: mailto:ippm@ietf.org
>> 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:ippm-bounces@ietf.org> On Behalf Of Tianran Zhou
>> Sent: Thursday, February 23, 2023 9:17 AM
>> To: Alex Huang Feng <mailto:alex.huang-feng@insa-lyon.fr>; Tianran Zhou <mailto:zhoutianran=40huawei.com@dmarc.ietf.org>
>> Cc: mailto:ippm@ietf.org
>> 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:ippm-bounces@ietf.org] On Behalf Of Alex Huang Feng
>> Sent: Monday, February 20, 2023 10:45 PM
>> To: Tianran Zhou <mailto:zhoutianran=40huawei.com@dmarc.ietf.org>
>> Cc: mailto:ippm@ietf.org
>> 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=40huawei.com@dmarc.ietf.org> 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:ippm-bounces@ietf.org] On Behalf Of mailto:internet-drafts@ietf.org
>>> Sent: Thursday, February 16, 2023 7:12 PM
>>> To: mailto:i-d-announce@ietf.org
>>> Cc: mailto:ippm@ietf.org
>>> 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:ippm@ietf.org
>>> 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:ippm@ietf.org
>>> 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:ippm@ietf.org
>> 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:ippm@ietf.org
>> 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
>> ippm@ietf.org <mailto:ippm@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>