Hi Benoit / All, Thanks for the feedback. We seem to have consensus on option 2. We’ll publish a minor revision shortly incorporating the feedback received on draft-ietf-opsawg-discardmodel-05.
> My main argument is that > draft-evans-opsawg-ipfix-discard-class-ie-00<https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/> > is still a 00 version … > On top of that, this document wants a new IPFIX registry, as far as I can > tell: Please don’t imagine that I have a good grasp on IETF process 😊 The intent here is to propose an new IPFIX IE for flow discard reporting, mapped from the IM in draft-ietf-opsawg-discardmodel. Hence, any and all feedback on the best way to represent that in the draft appreciated. Cheers John= From: Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org> Date: Wednesday 2 April 2025 at 15:13 To: Reshad Rahman <res...@yahoo.com>, Mahesh Jethanandani <mjethanand...@gmail.com>, "Evans, John" <jevanamz=40amazon.co...@dmarc.ietf.org> Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "opsawg-cha...@ietf.org" <opsawg-cha...@ietf.org>, Jeff Haas <jh...@juniper.net>, "Rob Wilton (rwilton)" <rwil...@cisco.com>, "draft-ietf-opsawg-discardmo...@ietf.org" <draft-ietf-opsawg-discardmo...@ietf.org> Subject: RE: [OPSAWG]Re: draft-ietf-opsawg-discardmodel Resent from: <alias-boun...@ietf.org> Resent to: <akad...@cisco.com>, <jevan...@amazon.co.uk>, <jh...@juniper.net>, <mohamed.boucad...@orange.com>, <o...@amazon.com> Resent date: Wednesday 2 April 2025 at 15:13 Dear all, A preference for option 2. My main argument is that draft-evans-opsawg-ipfix-discard-class-ie-00<https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/> is still a 00 version, individual draft, which is at first glance not yet mapping correctly to the IM. Let's get first the WG feedback on this document. On top of that, this document wants a new IPFIX registry, as far as I can tell: Note: the very simple IANA considerations section completely overlooks that point. This implies that "a change in IM model would need to update both YANG and the IPFIX models" might be correct, but potentially simply by adding a new flowDiscardClass reason. This might not even require a RFC for that, if we speak of a Expert Review procedure. Regards, Benoit On 3/27/2025 3:01 PM, Reshad Rahman wrote: Hi, Small preference for option 2, reason being the unwieldy aspect of option 3. And having to push 2 documents together is nothing new. Regards,Reshad. On Thursday, March 27, 2025 at 02:25:07 PM GMT+1, Evans, John <jevanamz=40amazon.co...@dmarc.ietf.org><mailto:jevanamz=40amazon.co...@dmarc.ietf.org> wrote: Hi Mahesh, Thanks for your feedback. Given we have the other draft, option 3 is relatively straightforward to do - albeit it feels a bit unwieldy. Any other feedback from the group? Cheers John On 21/03/2025, 22:34, "Mahesh Jethanandani" <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> <mailto:mjethanand...@gmail.com><mailto:mjethanand...@gmail.com>> wrote: [Speaking as a contributor] Hi John, The advantage that I see with Option 3, and the reason I believe Rob suggested is that if there is change in the IM model, you would need to update both YANG and the IPFIX model. From a tracking perspective, it would be easier to do that if they are all in the same draft. Cheers. On Mar 22, 2025, at 4:56 AM, Evans, John <jevanamz=40amazon.co...@dmarc.ietf.org<mailto:jevanamz=40amazon.co...@dmarc.ietf.org> <mailto:40amazon.co...@dmarc.ietf.org><mailto:40amazon.co...@dmarc.ietf.org>> wrote: Hi All, Based on feedback from the last meeting we moved from option 1 to option 2 below. Rob Wilton proposed option 3 in the discussion at the WG meeting this week. Hence, we would like to solicit feedback from the group on whether there is consensus with the current approach (option 2 below), or whether there is support to transition to option 3. As an author, I think there's value both in separating concerns and in making incremental progress, hence my preference is to stick with option 2, 1. Previous approach: separate drafts for each IM and DM, e.g. a. draft-ietf-opsawg-discardmodel i. IM (YANG) b. draft-ietf-opsawg-… i. IM (references draft-ietf-opsawg-discardmodel) ii. DM (YANG) c. draft-evans-opsawg-ipfix-discard-class-ie i. IM (references draft-ietf-opsawg-discardmodel) ii. DM (IPFIX IE) 2. Current approach: one draft for YANG IM and YANG DM with other DMs in subsequent drafts: a. draft-ietf-opsawg-discardmodel: i. IM (YANG) ii. DM (YANG) b. draft-evans-opsawg-ipfix-discard-class-ie i. IM (references draft-ietf-opsawg-discardmodel) ii. DM (IPFIX IE) 3. Alternative approach proposed by Rob Wilton: single draft for IMs and DMs, e.g. a. draft-ietf-opsawg-discardmodel i. IM (YANG) ii. DM (YANG) iii. DM (IPFIX IE) cheers John ----------------------- From: "Evans, John" <jevan...@amazon.co.uk<mailto:jevan...@amazon.co.uk> <mailto:jevan...@amazon.co.uk><mailto:jevan...@amazon.co.uk>> Date: Tuesday 4 March 2025 at 10:29 To: "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>>, Benoit Claise <benoit.cla...@huawei.com<mailto:benoit.cla...@huawei.com> <mailto:benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com>>, "opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>>, "opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org>" <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org>>, Jeff Haas <jh...@juniper.net<mailto:jh...@juniper.net> <mailto:jh...@juniper.net><mailto:jh...@juniper.net>>, "Pylypenko, Oleksandr" <o...@amazon.com<mailto:o...@amazon.com> <mailto:o...@amazon.com><mailto:o...@amazon.com>> Cc: "draft-ietf-opsawg-discardmo...@ietf.org<mailto:draft-ietf-opsawg-discardmo...@ietf.org> <mailto:draft-ietf-opsawg-discardmo...@ietf.org><mailto:draft-ietf-opsawg-discardmo...@ietf.org>" <draft-ietf-opsawg-discardmo...@ietf.org<mailto:draft-ietf-opsawg-discardmo...@ietf.org> <mailto:draft-ietf-opsawg-discardmo...@ietf.org><mailto:draft-ietf-opsawg-discardmo...@ietf.org>> Subject: Re: draft-ietf-opsawg-discardmodel Hi All, We've checked in a updated version of draft-ietf-opsawg-discardmodel. The most significant change is that it incorporates both the YANG information model, and the YANG data model derived from the information model – as was proposed after the last meeting: https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/ <https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/><https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/> We have also checked in a complementary draft, which defines a new IPFIX Information Element for classifying flow-level discards that aligns with the information model defined in draft-ietf-opsawg-discardmodel: https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/ <https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/><https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/> We would appreciate feedback from the group to see if we have consensus on this approach, i.e.: 1. draft-ietf-opsawg-discardmodel: a. IM (YANG) b. DM (YANG) 2. draft-evans-opsawg-ipfix-discard-class-ie a. IM (references draft-ietf-opsawg-discardmodel) b. DM (IPFIX IE) The alternative would be to have a discrete draft for the information model, e.g.: 1. draft-ietf-opsawg-discardmodel a. IM (YANG) 2. draft-ietf-opsawg-… a. IM (references draft-ietf-opsawg-discardmodel) b. DM (YANG) 3. draft-evans-opsawg-ipfix-discard-class-ie a. IM (references draft-ietf-opsawg-discardmodel) b. DM (IPFIX IE) Cheers John From: "Evans, John" <jevan...@amazon.co.uk<mailto:jevan...@amazon.co.uk> <mailto:jevan...@amazon.co.uk><mailto:jevan...@amazon.co.uk>> Date: Friday 22 November 2024 at 13:43 To: "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>>, Benoit Claise <benoit.cla...@huawei.com<mailto:benoit.cla...@huawei.com> <mailto:benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com>>, "opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>>, "opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org>" <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org>>, Jeff Haas <jh...@juniper.net<mailto:jh...@juniper.net> <mailto:jh...@juniper.net><mailto:jh...@juniper.net>>, "Pylypenko, Oleksandr" <o...@amazon.com<mailto:o...@amazon.com> <mailto:o...@amazon.com><mailto:o...@amazon.com>> Cc: "draft-ietf-opsawg-discardmo...@ietf.org<mailto:draft-ietf-opsawg-discardmo...@ietf.org> <mailto:draft-ietf-opsawg-discardmo...@ietf.org><mailto:draft-ietf-opsawg-discardmo...@ietf.org>" <draft-ietf-opsawg-discardmo...@ietf.org<mailto:draft-ietf-opsawg-discardmo...@ietf.org> <mailto:draft-ietf-opsawg-discardmo...@ietf.org><mailto:draft-ietf-opsawg-discardmo...@ietf.org>> Subject: Re: draft-ietf-opsawg-discardmodel Resent from: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org> <mailto:alias-boun...@ietf.org><mailto:alias-boun...@ietf.org>> Resent to: <akad...@cisco.com<mailto:akad...@cisco.com> <mailto:akad...@cisco.com><mailto:akad...@cisco.com>>, <jevan...@amazon.co.uk<mailto:jevan...@amazon.co.uk> <mailto:jevan...@amazon.co.uk><mailto:jevan...@amazon.co.uk>>, <jh...@juniper.net<mailto:jh...@juniper.net> <mailto:jh...@juniper.net><mailto:jh...@juniper.net>>, <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>>, <o...@amazon.com<mailto:o...@amazon.com> <mailto:o...@amazon.com><mailto:o...@amazon.com>> Resent date: Friday 22 November 2024 at 13:42 Hi Med / Benoit / Jeff / All, I agree re option 2. If there are no objections we’ll refactor the draft on that basis. Cheers John From: "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>> Date: Friday 22 November 2024 at 07:35 To: Benoit Claise <benoit.cla...@huawei.com<mailto:benoit.cla...@huawei.com> <mailto:benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com>>, "Evans, John" <jevan...@amazon.co.uk<mailto:jevan...@amazon.co.uk> <mailto:jevan...@amazon.co.uk><mailto:jevan...@amazon.co.uk>>, "opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>>, "opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org>" <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org>> Cc: "draft-ietf-opsawg-discardmo...@ietf.org<mailto:draft-ietf-opsawg-discardmo...@ietf.org> <mailto:draft-ietf-opsawg-discardmo...@ietf.org><mailto:draft-ietf-opsawg-discardmo...@ietf.org>" <draft-ietf-opsawg-discardmo...@ietf.org<mailto:draft-ietf-opsawg-discardmo...@ietf.org> <mailto:draft-ietf-opsawg-discardmo...@ietf.org><mailto:draft-ietf-opsawg-discardmo...@ietf.org>> Subject: RE: [EXTERNAL] draft-ietf-opsawg-discardmodel Resent from: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org> <mailto:alias-boun...@ietf.org><mailto:alias-boun...@ietf.org>> Resent to: <akad...@cisco.com<mailto:akad...@cisco.com> <mailto:akad...@cisco.com><mailto:akad...@cisco.com>>, <jevan...@amazon.co.uk<mailto:jevan...@amazon.co.uk> <mailto:jevan...@amazon.co.uk><mailto:jevan...@amazon.co.uk>>, <jh...@juniper.net<mailto:jh...@juniper.net> <mailto:jh...@juniper.net><mailto:jh...@juniper.net>>, <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>>, <o...@amazon.com<mailto:o...@amazon.com> <mailto:o...@amazon.com><mailto:o...@amazon.com>> Resent date: Friday 22 November 2024 at 07:35 Hi Benoît, all, I think that I can convince myself that option 2 is better here (have both IM/DM in the same spec). The main challenge will be to find “where” to anchor the nodes (interface, NE, routing management, etc.). Otherwise, I expect the structures/groupings we already have in the IM will be reused nicely. However, we will need to register the IM as well as we need to import it. I’m not sure to understand the last part of the following: == 3. Should information models specified in YANG also be registered in IANA? This is where we might have different views. As mentioned during the meeting: "If you have it in IANA, then people will expect tooling to work.". = The tooling (pyang, etc.) still work even with the current IM in the draft. Also, the module can be imported/augmented/etc. Please note that even **fake** modules were registered! Think about ietf-template for example: == ietf-template ietf-templ...@2010-05-18.yang<mailto:ietf-templ...@2010-05-18.yang> <mailto:ietf-templ...@2010-05-18.yang><mailto:ietf-templ...@2010-05-18.yang> N urn:ietf:params:xml:ns:yang:ietf-template temp [RFC6087] === Thank you. Cheers, Med De : Benoit Claise <benoit.cla...@huawei.com<mailto:benoit.cla...@huawei.com> <mailto:benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com>> Envoyé : jeudi 21 novembre 2024 18:22 À : Joe Clarke (jclarke) <jcla...@cisco.com<mailto:jcla...@cisco.com> <mailto:jcla...@cisco.com><mailto:jcla...@cisco.com>>; Evans, John <jevan...@amazon.co.uk<mailto:jevan...@amazon.co.uk> <mailto:jevan...@amazon.co.uk><mailto:jevan...@amazon.co.uk>>; opsawg@ietf.org<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <mailto:opsawg-cha...@ietf.org><mailto:opsawg-cha...@ietf.org> Cc : Pylypenko, Oleksandr <o...@amazon.com<mailto:o...@amazon.com> <mailto:o...@amazon.com><mailto:o...@amazon.com>>; Jeff Haas <jh...@juniper.net<mailto:jh...@juniper.net> <mailto:jh...@juniper.net><mailto:jh...@juniper.net>>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>>; Aviran Kadosh (akadosh) <akad...@cisco.com<mailto:akad...@cisco.com> <mailto:akad...@cisco.com><mailto:akad...@cisco.com>> Objet : Re: draft-ietf-opsawg-discardmodel Dear all, Joe and I spoke. As we see it, there are multiple questions here. 1. Is the IETF interested into standardizing information models? As mentioned by Mahesh (in the OPSAWG meeting minutes, to be posted soon): "generally we don't spend too much time on info models and work on standardise data models". However, we believe, as we accepted the discard information as WG document already, let's not revisit this decision. 2. How should those information models be specified? Could be text, UML, whatever. YANG is also a possibility (even if not common practice) as YANG is a data modeling language. As John mentioned during the meeting, one argument in the favor of YANG is that it's well known. 3. Should information models specified in YANG also be registered in IANA? This is where we might have different views. As mentioned during the meeting: "If you have it in IANA, then people will expect tooling to work.". What do we do from here? 1. Information model published as informational document: YANG model in an appendix, not normative. In such a case, you don't register the YANG module in IANA. 2. Information and data models in a single standards-track document, with the data model registered as a YANG module with IANA. Number 2 might be better, as you mentioned that there are existing implementations. Plus it might ease maintainability and give other implementations something to root to and augment. This might also be the path of least resistance to publish. The YANG model in IANA would also justify the fact that you moved from Informational to Standard Track in this version (https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/03/ <https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/03/><https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/03/>) Jeff, at the microphone during the OPSAWG meeting, mentioned the issue of evolving/maintaining information models before going to a data model. We are not too sure how publishing an information model as RFC (as opposed to a WIKI or something similar) is actually helping out. Regards, Joe and Benoit On 11/13/2024 11:19 PM, Joe Clarke (jclarke) wrote: As a contributor, I think a data model approach would be far more useful. That said, I haven’t seen these proprietary implementations based on your draft info model to understand how they deviate or what data modeling approach they take. I still think that starting with a YANG data model wouldn’t preclude future drafts standardizing IPFIX-based approaches to packet discard reporting (just as we’ve seen MIBs move to YANG) Amazon Data Services UK Limited. Registered in England and Wales with registration number 09959151 with its registered office at 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
