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
