Hi Linda, all, Thank you for the follow-up and for considering this approach. This exercise is really important as it is a walk trough a set of models and assess whether they can address your needs. That exercise is also important because it further shows how the various modules can be invoked for a single use. That's something we are lacking in the IETF: applicability of the modules to fit ops needs and how we graft them for a single use (RFC8969 sketches a path but we don't have concrete examples to put this into effect).
I'm also sympathetic to the discussion about the need to expose APIs that are readily consumable by entities such as cloud managers. That's said, the document seems to mix service models vs. network models. For example, the use of the network topology and TE modules requires some elaboration because these matters are internal/hidden by network controllers and not exposed to external entities such as a cloud manager. Also, we are allowed to look outside the IETF for the transport service part. For example, and without making any recommendation here, would TAPI model be suitable for the PE-to-PE part? The assessment approach should not make an assumption about the origin of the data models. That's after all, what we are doing in real operations todays. Back to the document, there are actually two styles in the same document. I like more the first part where you objectively walked through the needs and then assessed how the various modules can be used to meet the needs. Then, there is the second part with many statements that I think are not currently backed with the assessment exercise. I suggest we follow the same approach as you had in you're the first part of the document and forgot for a moment the need to justify a WG (that's a logistic matter that we can figure out, as appropriate). Some of the needs (e.g., retrieve the available BW) are not justified as this information is already available at the cloud site. Knowing the capacity reserved for an attachment circuit and monitoring the actual use of that AC will naturally help deduce the available capacity without needing to place an API call to a network orchestrator. You can find more comments at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-dunbar-neotec-ac-te-applicability-02-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-dunbar-neotec-ac-te-applicability-02-rev%20Med.doc Hope this helps. Cheers, Med De : Linda Dunbar <linda.dun...@futurewei.com> Envoyé : vendredi 18 avril 2025 04:31 À : neo...@ietf.org; 'opsawg' <opsawg@ietf.org>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Joel Halpern Direct <jmh.dir...@joelhalpern.com>; Mahesh Jethanandani <mjethanand...@gmail.com> Objet : Feedback Wanted: Is Attachment Circuit YANG Sufficient for Neotec Use Case? Med, Following your suggestion during IETF 122 for us to take a simple Neotec use case and "do our homework" by applying existing IETF YANG models-specifically the Attachment Circuit model- we've completed an initial exercise and documented it in the following draft: "Applicability of Attachment Circuit and TE YANG Models to a Neotec Use Case" https://datatracker.ietf.org/doc/draft-dunbar-neotec-ac-te-applicability/ Our goal with this draft is to evaluate whether the AC and TE YANG models are sufficient to support the selected use case, and to identify any potential modeling or architectural gaps. This is intended as an exploratory step to evaluate whether there is substantive, standards-relevant work that could justify a Neotec WG. We would greatly appreciate your feedback: Does this exercise align with what you envisioned? Are we on the right track? Any guidance or suggestions on how to refine the framing would be greatly appreciated. Cc'ing the opsawg mailing list here in case others would like to help us evaluate the approach and share perspectives on the usefulness of this line of inquiry. Best regards, Linda ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
