Dear Med, Thanks a lot. This is really helpful. Especially the pointer to RFC 8969 I missed. I understood now from reading into
https://datatracker.ietf.org/doc/html/rfc8969#section-3.2 https://datatracker.ietf.org/doc/html/rfc8969#section-3.3 https://datatracker.ietf.org/doc/html/rfc8969#section-4 That network models can be derived from service models and that service delivery models do include assurance and closed loop. Therefore my assumptions on https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-lifecycle https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-semantics https://datatracker.ietf.org/doc/html/rfc9418 being service delivery models and https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang being customer service model appears to be correct. The description in section 3.5.1 of 8407bis makes sense to me. Best wishes Thomas From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Sent: Thursday, April 24, 2025 6:53 AM To: Graf Thomas, INI-NET-VNC-E2E <thomas.g...@swisscom.com>; opsawg@ietf.org; bill...@huawei.com; adr...@olddog.co.uk; liushuch...@huawei.com Cc: n...@ietf.org Subject: RE: RFC 8309, Service Delivery Model Clarification Be aware: This is an external email. Hi Thomas, all FWIW, 8407bis has a subset of classes that reflect the main flavors defined so far in the IETF (hence the use of "Specifically" below). I'm not sure adding more sub-categories (e.g., incident management) would be useful. == 3.5.1. YANG Module Classification The narrative section SHOULD include a mention about the classification of a given model. Such a mention is meant to ease positioning the module in the overall operational ecosystem. Specifically, the following types from [RFC8309] and [RFC8969] can be used: Service Model: Describes a service and the parameters of the service in a portable way that can be used uniformly and independent of the equipment and operating environment. Examples of service models are the L3VPN Service Model (L3SM) [RFC8299] and the L2VPN Service Model (L2SM) [RFC8466]. Network Model: Describes a network-level abstraction (or a subset of aspects of a network infrastructure), including devices and their subsystems, and relevant protocols operating at the link and network layers across multiple devices. This model corresponds to the network configuration model discussed in [RFC8309]. It can be used by a network operator to allocate resources (e.g., tunnel resource, topology resource) for the service or schedule resources to meet the service requirements defined in a service model. Examples of network models are the L3VPN Network Model (L3NM) [RFC9182] or the L2VPN Network Model (L2NM) [RFC9291]. Device Model: Refers to the Network Element YANG data model described in [RFC8199] or the device configuration model discussed in [RFC8309]. Device models are also used to refer to model a function embedded in a device (e.g., Access Control Lists (ACLs) [RFC8519]). A comprehensive list of device models is provided in Appendix 4.2 of [RFC8969]. == Cheers, Med (as contributor) De : thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Envoyé : dimanche 20 avril 2025 18:46 À : opsawg@ietf.org<mailto:opsawg@ietf.org>; bill...@huawei.com<mailto:bill...@huawei.com>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; liushuch...@huawei.com<mailto:liushuch...@huawei.com> Cc : n...@ietf.org<mailto:n...@ietf.org> Objet : [NMOP] RFC 8309, Service Delivery Model Clarification Dear Adrian, Qin, Will and OPSAWG, First of all. I enjoyed reading RFC 8309. It is very helpful in context with RFC8199 and RFC 3444 to distinguish between "Customer Service Model" and "Service Delivery Model. The explanations make perfectly sense to me. I have read the term "Service Delivery Model" in https://datatracker.ietf.org/doc/html/rfc8309#section-2 and understood its relations in Figure 3 in https://datatracker.ietf.org/doc/html/rfc8309#section-4 to BSS/OSS and its examples in https://datatracker.ietf.org/doc/html/rfc8309#section-6.2. I came to the conclusion that network assurance, monitoring and observability are not covered in the term "Service Delivery Model". It focuses solely on the fulfillment of the Network Service configuration if I am not mistaken and does not take closed loop operation into consideration. Within Network Service Models, there might be other categories such as "Network and VPN Service PM Models" as in Figure 1 in https://datatracker.ietf.org/doc/html/rfc9375#section-3. Taking figure 4 in https://datatracker.ietf.org/doc/html/draft-ietf-nmop-terminology-16#section-4, deriving the relevant state with its symptoms, how would you characterize the following YANG modules: https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-lifecycle https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-semantics https://datatracker.ietf.org/doc/html/rfc9418 My conclusion is that it is definitely in the category "Network Service Models", probably similar to RFC 9375, defining its own subcategory such as assurance or anomaly detection. Looking at https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang, I would categorize it in "Customer Service Model". Probably in a sub category incident management. Does that make sense? Continue my search on easter eggs... Best wishes Thomas ____________________________________________________________________________________________________________ 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
