Chong Feng, Please see the replies inserted below:
On Mon, Apr 21, 2025 at 1:35 AM Chongfeng Xie <chongfeng....@foxmail.com> wrote: > > Hi Linda, > > After reading this draft, I have the following two comments, > > In section 4.1, it says "This API provides a read-only, low-latency > interface for workload schedulers to assess whether a given path meets > predefined service-level thresholds." I agree with this point, However, > based on our experiences, there should be some writable APIs too, so the > status and requirements information of cloud applications can be > transmitted to Network Service Orchestrator, these metrics can be further > converted into cloud-aware policies to send to the network controller. With > the advent of the AI era, same to communication, computing is becoming a > critical capability in operator's information infrastructure. Consequently, > network operation systems must facilitate unified scheduling of both > network and computing resources. > [Linda] You raised a very good point that writable APIs are also needed for cloud applications to convey service requirements to the Network Service Orchestrator. However, writable APIs require strong authentication and authorization mechanisms. Defining secure access control for such APIs should be a key work item for the proposed Neotec WG. > > In addition, In section 6.3, it says " There is no YANG model or API that > allows the cloud controller to associate a workload (e.g., "AI inference > service X") with network traffic that should receive enhanced treatment. > ", the term of "AI inference service X" here can be considered as a kind > of service instance ID? If so, it is same to CS-ID in CATS when Neotec > interact with CATS, which mainly works at control and forwarding layers. > [Linda] That is a valid point. We can expand the sentence in Section 6.3 to indicate the analogy: *There is no YANG model or API that allows the cloud controller to associate a workload (e.g., "AI inference service X")—which can be interpreted as a service instance identifier similar to the CS-ID used in the CATS architecture—with network traffic that should receive enhanced treatment.* Linda > > Best regards > Chongfeng > > > *From:* Linda Dunbar <linda.dun...@futurewei.com> > *Date:* 2025-04-18 10:31 > *To:* neo...@ietf.org; 'opsawg' <opsawg@ietf.org>; > mohamed.boucad...@orange.com > *CC:* Joel Halpern Direct <jmh.dir...@joelhalpern.com>; Mahesh > Jethanandani <mjethanand...@gmail.com> > *Subject:* [neotec] 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 > > > > _______________________________________________ > 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
