Hi Linda, Thanks for your reply. Please see inline comments at [Fan].
Regards, Fan On Sat, Apr 19, 2025 at 1:01 AM Linda Dunbar <[email protected]> wrote: > Fan, > > Please see below the answers to your questions: > > On Thu, Apr 17, 2025 at 11:49 PM Fan Zhang < > [email protected]> wrote: > >> Hi Linda, >> >> This draft introduces potential Neotec API interfaces designed to enable >> Kubernetes to make network-aware workload placement decisions. It also >> demonstrates how the AC and TE topology models can support a representative >> Neotec use case involving dynamic AI model placement at Edge Cloud sites. >> >> However, I have two questions for further clarification: >> >> 1) Compatibility Across Cloud Platforms >> Given the diversity of cloud platforms (e.g., Kubernetes, OpenStack), how >> can a common set of APIs ensure compatibility across different >> environments? Is there a plan to address platform-specific adaptations >> while maintaining universality? >> > > [Linda] The goal of the exercise documented in the draft is not to > prescribe a tightly-coupled integration with any single platform, but to > explore whether existing IETF YANG models (e.g., Attachment Circuit and TE > Topology) can be abstracted into a platform-agnostic API layer. > Neotec is to define a platform-agnostic API layer that exposes network > metrics (e.g., latency, bandwidth) derived from IETF YANG models in a way > that can be consumed by diverse cloud platforms like Kubernetes and > OpenStack. While platform-specific adapters or plugins may be needed, the > API semantics remain consistent. This separation—standardized behavior and > data models in IETF, with implementation flexibility in open-source—ensures > compatibility while supporting platform diversity > > > >> 2) Alignment with Neotec's Original Charter >> The draft emphasizes "network-aware" decisions from the cloud >> perspective. However, during the side meeting in Bangkok, Neotec was >> discussed as enabling network operating systems to be "cloud-aware." How do >> the proposed APIs align with this earlier vision? Are there plans to >> reconcile these two approaches? >> >> [Linda] The two directions—cloud becoming network-aware and network > becoming cloud-aware—are complementary and central to Neotec’s vision. This > draft starts with one side of the interaction: enabling the cloud (e.g., > Kubernetes) to make network-aware placement decisions using abstracted data > from IETF YANG models. This is also the desired outcome from the use case > presented by Luis from Telefonica. > You have a good point. We should expand the draft to include scenarios > where the network dynamically adapts to changes in cloud service > deployments, such as AI model scaling or migration. > [Fan] Yes. From the perspective of an operator, we hope that the network operation system can perceive the needs of the customer services and adjust resources accordingly, especially in the AI era. The network needs to transmit a large amount of data within a specific time, and it is very important for the network to choose a path based on AI scaling and available resources. I have also noticed Luis' draft, which models network and computing resources uniformly, which fits the requirements of operators, I think Neotec is the right place to do it. I have another question, is the algorithm for unified scheduling of computing and network within the scope of IETF standards in the future? > > Thanks, Linda > > > You feedback will be highly appreciated. >> >> Regards >> Fan >> >> >> On Fri, Apr 18, 2025 at 10:31 AM Linda Dunbar <[email protected]> >> wrote: >> >>> 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 >>> >>> >>> _______________________________________________ >>> neotec mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> neotec mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
