Med and Neotec (NetOps4Clouds) participants: I uploaded the revised charter to the GitHub: https://github.com/xiechf974/NeoTec/compare/main...lindadunbar:NeoTec:patch-1
Linda On Fri, Jan 31, 2025 at 11:45 AM Linda Dunbar <dunbar...@gmail.com> wrote: > Med, > > Thank you very much for the comments and the suggested new names. > Can you please review the answers, the resolutions and the proposed > changes to your comments inserted below? > > Thank you, > Linda > > . > > On Fri, Jan 31, 2025 at 7:03 AM <mohamed.boucad...@orange.com> wrote: > >> Hi Chongfeng, Linda, all, >> >> >> >> (ccing CATS/OPSAWG as the current proposed scope seems to overlap with >> the work in these WGs) >> >> >> >> Thank you for starting this proposal. >> >> >> >> I thought that the email discussion we had clarified the relationship >> with existing WGs, but I’m afraid that the current work description is >> confusing and overlaps with the metrics work done in CATS, in particular. >> >> >> > [Linda] That is the main reason we put "focusing on defining > standardized interfaces for cloud-aware network operation" as the first > sentence for the Neotec (or NetOps4Clouds) charter. > There are several people asking about the key focus of Neotec > (NetOps4Clouds). > Neotec focuses on standardizing cloud-to-network coordination rather than > traffic engineering or routing metrics, which fall under CATS. > > Do you think changing the first sentence to the following can make it more > clear? > > *"The Neotec Working Group defines standardized interfaces, such as YANG > models, to enable dynamic network policy adjustments—such as time-sensitive > UCMP policies for routers—that accommodate the scaling of cloud-hosted > services and ensure that adequate network resources are adjusted for the > services in the clouds."* > > > >> I still don’t understand the issue about cloud scaling and its >> interaction with the network. For example, the use of ACaaS allows already >> to request on-demand more resourcing ** without revealing the internal >> service structure**. >> > > [Linda] ACaaS enables cloud services to scale on demand but does not > inform the network of these changes in real time. Without this awareness, > the network cannot adjust load balancing, and/or time-sensitive UCMP > policies, which may impact SLAs. > Neotec (NetOps4Clouds) standardizes an interface to dynamically update > network policies whenever ACaaS is triggered, ensuring the necessary > network resources are allocated to accommodate newly added or reduced cloud > services. Importantly, Neotec does not expose internal service structures. > > Do you think the following changes can address your concern? > > Old: > > "If the network controllers lack of awareness of cloud resources, status > and traffic characteristics of the services they carry, they could not > timely adjust network resource when service function instances are scaled > up or down, relocated, or could not timely adjust network paths when > traffic patterns between service functions change, which results in > suboptimal performance, failure to meet SLAs, and inefficient utilization > of network resources." > > New: > > *"While cloud services can scale dynamically using mechanisms like ACaaS, > network controllers are often unaware of these changes in real time. > Without this awareness, they cannot adjust network resources, load > balancing, or time-sensitive UCMP policies, potentially leading to SLA > violations and inefficient resource utilization. The Neotec (NetOps4Clouds) > Working Group defines standardized interfaces to enable the network to > dynamically update policies in response to cloud scaling events, ensuring > the necessary network adjustments without exposing internal service > structures."* > > Making the following wording changes in the Goal and the Scope: > Old: > > "The information will be provided by these models include: cloud resource > metrics, service status in clouds, dynamic adjustment of network > load-balancing policies, and inter-cloud network connectivity and status, > etc. " > > New: > > *"These models will provide abstracted cloud resource metrics and service > status updates, enabling real-time network policy adjustments—such as > dynamic UCMP changes and adaptive load-balancing—whenever cloud services > scale up or down. This ensures that the network can allocate adequate > resources to support cloud-hosted services while maintaining SLA > guarantees." * > > Revising the wording to reflect Network Response to Cloud Scaling: > Old: > > "Develop YANG models to provide network controllers with dynamic service > instance status to adjust network paths, or enable dynamic adjustments to > load-balancing policies, ensuring dynamic policy updates across ingress, > intermediate, and egress routers based on actual service demand and network > conditions." > > New: > > *"Develop YANG models to provide network controllers with dynamic service > instance status, ensuring real-time network adjustments—including UCMP > policy updates and adaptive load balancing—whenever cloud services scale up > or down. These updates allow the network to seamlessly accommodate changes > without requiring detailed visibility into internal cloud structures."* > > > >> >> The list of proposed items is TOO long. I reiterate the comment I made in >> the past to prioritize those and select few items to start the work. For >> example, the UCMP point seems to be more a routing/steering concern. May be >> leave out these items for a future work, when the WG will hopefully show >> evidence that it can deliver the contracted few items. >> > > [Linda] Agree with your observation. There are some duplicated wordings > in those proposed items. > > How about we tighten the proposed work items to the following: > > > - *Develop YANG models to expose cloud resource metrics and service > instance status, enabling real-time network policy adjustments such as > adaptive load balancing and bandwidth allocation when cloud services > scale.* > - *Define models to dynamically adjust UCMP (Unequal Cost Multipath) > policies across ingress, intermediate, and egress routers based on dynamic > cloud metrics.* > - *Define a shim layer acting as middleware between cloud telemetry > systems (e.g., AWS CloudWatch, Google Cloud Monitoring, Azure Monitor) and > network controllers. Standardize APIs for network controllers to convert > cloud metrics into IETF-compliant network telemetry formats (e.g., YANG, > gRPC-based streaming, NetConf APIs).* > > Plus the stuff normally documented for a WG, i.e. > - a set of informational Internet-Drafts, not necessarily for publication > as RFCs, such as: use cases, requirements, problem statement, gap analysis, > and applicability analysis. > - framework of network operation aware of cloud resources and service > status, including the key mechanism, major components, and main interfaces. > Provide a structured framework for policy-based traffic optimization among > multi-edge clouds. > > >> >> I like much the shim point to present APIs that can be readily consumed >> by cloud systems based on YANG models. This is important for integration >> (and operationalizing the solution given that distinct approaches are used >> in network vs. cloud). >> > > [Linda] Do you think changing the first sentence under "Goal and Scope" > can address your concern? > Old: > > The Neotec Working Group will define standardized mechanisms and > interfaces for dynamic exchange of cloud resource status, service instance > changes, and dynamic connectivity insights to enable efficient network > orchestration and traffic engineering across multiple clouds > > > New: > > *"The Neotec (NetOps4Clouds) Working Group will define standardized > mechanisms for real-time exchange of cloud resource status and service > instance changes. A key focus is a shim layer that bridges cloud telemetry > and network controllers, ensuring seamless API integration between cloud > and network environments."* > > >> >> Some first edits/suggestions can be found at: >> https://github.com/xiechf974/NeoTec/pull/1/files. I also suggested a new >> name :-) >> >> >> >> Feel free to grab whatever you think useful. >> >> >> >> Cheers, >> >> Med >> >> >> >> *De :* Chongfeng Xie <chongfeng....@foxmail.com> >> *Envoyé :* mercredi 29 janvier 2025 03:40 >> *À :* neotec <neo...@ietf.org> >> *Objet :* [neotec] Welcome to give comments for Neotec charter >> >> >> >> Hi folks, >> >> >> >> We have prepared the initial version of the Neotec charter. Your >> comments and suggestions are welcome. >> >> >> >> * https://github.com/xiechf974/NeoTec/blob/main/Neotec-charter.md >> <https://github.com/xiechf974/NeoTec/blob/main/Neotec-charter.md>* >> >> >> >> >> >> Moreover, Neotec BOF has been changed from Non-WG forming BOF into >> WG-forming BOF. The BOF reques is as follows, >> >> >> >> >> https://datatracker.ietf.org/doc/bofreq-xie-neotec-network-operations-in-telecom-cloud/ >> >> >> >> >> >> Best regards >> >> Chongfeng, 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. >> >> _______________________________________________ >> neotec mailing list -- neo...@ietf.org >> To unsubscribe send an email to neotec-le...@ietf.org >> >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
