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" <[email protected]>
Date: Tuesday 4 March 2025 at 10:29
To: "[email protected]" <[email protected]>, Benoit
Claise <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, Jeff Haas
<[email protected]>, "Pylypenko, Oleksandr" <[email protected]>
Cc: "[email protected]"
<[email protected]>
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/
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/
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" <[email protected]>
Date: Friday 22 November 2024 at 13:43
To: "[email protected]" <[email protected]>, Benoit
Claise <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, Jeff Haas
<[email protected]>, "Pylypenko, Oleksandr" <[email protected]>
Cc: "[email protected]"
<[email protected]>
Subject: Re: draft-ietf-opsawg-discardmodel
Resent from: <[email protected]>
Resent to: <[email protected]>, <[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>
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: "[email protected]" <[email protected]>
Date: Friday 22 November 2024 at 07:35
To: Benoit Claise <[email protected]>, "Evans, John"
<[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Cc: "[email protected]"
<[email protected]>
Subject: RE: [EXTERNAL] draft-ietf-opsawg-discardmodel
Resent from: <[email protected]>
Resent to: <[email protected]>, <[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>
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 [email protected] N
urn:ietf:params:xml:ns:yang:ietf-template temp [RFC6087]
===
Thank you.
Cheers,
Med
De : Benoit Claise <[email protected]>
Envoyé : jeudi 21 novembre 2024 18:22
À : Joe Clarke (jclarke) <[email protected]>; Evans, John
<[email protected]>; [email protected]; [email protected]
Cc : Pylypenko, Oleksandr <[email protected]>; Jeff Haas <[email protected]>;
BOUCADAIR Mohamed INNOV/NET <[email protected]>; Aviran Kadosh
(akadosh) <[email protected]>
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/)
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).
As a chair, I think it would be easier from a process standpoint if this was a
data model. There just isn’t a lot (any?) info models in the IETF developed in
YANG. That said, things don’t always have to be easy, and Med has already
commented having a YANG info model is not an insolvable problem.
I know Benoît is a bit busy, and I’m sure he’ll want to weigh in next week.
Joe
From: Evans, John mailto:[email protected]
Date: Wednesday, November 13, 2024 at 06:53
To: mailto:[email protected] mailto:[email protected],
mailto:[email protected] mailto:[email protected]
Cc: Pylypenko, Oleksandr mailto:[email protected], Jeff Haas
mailto:[email protected], mailto:[email protected]
mailto:[email protected], Aviran Kadosh (akadosh)
mailto:[email protected]
Subject: draft-ietf-opsawg-discardmodel
Hi All,
Following last week's discussion in Dublin regarding
draft-ietf-opsawg-discardmodel, we would appreciate feedback from the working
group and chairs on how to proceed.
To provide context, we initially defined an information model to establish a
common framework for discard reporting that could be implemented across
different data models, such as YANG and IPFIX.
We selected YANG to define the information model for three key reasons: 1) the
RFC8791 extensions enable the model to be decoupled from specific
implementations; 2) this approach allows for lossless translation to a
YANG-based data model; 3) the community has extensive experience with YANG.
During the discussion, two main perspectives emerged: continue with the current
approach of defining an information model; redefine the draft as a data model.
Given that the information model is already in YANG, creating data models for
interface, device, and control-plane would be straightforward. This could also
serve as a reference for a future IPFIX-based discard reporting data model.
Hence, we would appreciate feedback on whether the best path forward is to
continue with the current information model approach or to refocus on
developing data models instead?
thanks
John
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.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
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.
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 -- [email protected]
To unsubscribe send an email to [email protected]
