Hi all, (adding ALTO mailing list for this comment)
My apologies since I couldn't go through this during the weekend. One comment from my side. Since ALTO is explicitly mentioned in the charter, I think it would be fair to differentiate this work wrt ALTO work in relation with network and compute information (due to the fact that there are some individual drafts in ALTO dealing from long with the joint exposure of network and compute information). As mentioned in the proposed charter, CAN solution can take the decision on "... integrate both network and compute conditions in the optimization function ...", while ALTO could be one of the solutions that precisely expose the combined network and compute conditions. So, CAN could act on top of ALTO's information. I think they are not exclusive, but could be complementary in the mission of taking into consideration network and compute information (apart from other differences that is not worthy to detail for the purpose of chartering CAN). I would simply add the sentence that "Exposure of network and compute conditions to applications is not in the scope of CAN" in this way: OLD The IETF has done past work on exposing network conditions to endpoints (notably ALTO) and load balancing/service selection at layers 4 and 7 (for example, related to the selection of SIP servers). Specific characteristics that may distinguish CAN from other work include the desire to integrate both network and compute conditions in the optimization function, and the desire to operate that function on nodes within the service provider's network, logically separated from service operation. As part of its work, the CAN WG will seek advice and expertise from the ART and TSV areas. NEW The IETF has done past work on exposing network conditions to endpoints (notably ALTO) and load balancing/service selection at layers 4 and 7 (for example, related to the selection of SIP servers). Specific characteristics that may distinguish CAN from other work include the desire to integrate both network and compute conditions in the optimization function, and the desire to operate that function on nodes within the service provider's network, logically separated from service operation. Exposure of network and compute conditions to applications is not in the scope of CAN. As part of its work, the CAN WG will seek advice and expertise from the ART and TSV areas. Best regards, and apologies for this late comment. Luis De: Can <[email protected]> En nombre de Peng Liu Enviado el: lunes, 13 de febrero de 2023 5:06 Para: adrian <[email protected]>; jgs <[email protected]> CC: can <[email protected]>; Cheng Li <[email protected]>; Joel M. Halpern <[email protected]> Asunto: Re: [Can] Clean copy CAN charter updated Thanks. This version also looks good to me. Hope to see the progress in the IESG meeting. Regards, Peng ________________________________ [email protected]<mailto:[email protected]> From: Cheng Li<mailto:[email protected]> Date: 2023-02-13 11:38 To: Joel Halpern<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]> Subject: Re: [Can] Clean copy CAN charter updated The updated Charter looks good enough to me as well. It provides a good baseline for discussion in IESG review. BR, Cheng -----Original Message----- From: Can [mailto:[email protected]] On Behalf Of Joel Halpern Sent: Monday, February 13, 2023 4:58 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [Can] Clean copy CAN charter updated Just to close the loop, the charter (still below) that Adrian distributed today looks good enough to me. Yours, Joel On 2/12/2023 3:07 PM, Adrian Farrel wrote: > Hi, > > Per the planned schedule, here is a -00-03.txt revision for you to > post. The changes are as noted in the previous mail to the CAN list. > > I believe that the delta in this revision: > - captures comments and discussions on the list > - includes no change of substance from the previous > - tightens (and simplifies) some of the terminology > - fixes my breakage of your bullets > > Good luck on Thursday. Do you *want* anyone from the community to show > on the telechat? (Obviously, everyone is welcome to be there.) > > Cheers, > Adrian > > === > > Computing-Aware Networking (can) > > Many service architectures create multiple service instances. These > instances are often geographically distributed to multiple sites, and > a single site may support multiple instances of a service. The > services are provided on computing platforms and are generically > referred to as "compute services". The CAN (Computing-Aware > Networking) working group (WG) is chartered to consider the problem of > how the network edge can steer traffic between clients of a service > and sites offering the service. > > Since, for some services (for example, VR/AR, intelligent > transportation), the performance experienced by clients will depend on > both network metrics such as bandwidth and latency, and compute > metrics such as processing, storage capabilities, and capacity, there > is a need for a solution that can optimize how a network edge node > steers traffic based on these metrics, as appropriate to the service. > > Although the specific optimization function will likely differ between > services, implementations, and deployments, there is a need for a > general framework for the distribution of compute and network metrics > and transport of traffic from network edge to service instance. It > also is likely that some set of common metrics can be identified. The > CAN WG will concern itself with these issues. > > The IETF has done past work on exposing network conditions to > endpoints (notably ALTO) and load balancing/service selection at > layers 4 and 7 (for example, related to the selection of SIP servers). > Specific characteristics that may distinguish CAN from other work > include the desire to integrate both network and compute conditions in > the optimization function, and the desire to operate that function on > nodes within the service provider's network, logically separated from > service operation. As part of its work, the CAN WG will seek advice > and expertise from the ART and TSV areas. > > The assumed model for the CAN WG is an overlay network, where a > network edge node makes a decision based on the metrics of interest, > and then steers the traffic to a node that serves a service instance, > for example using a tunnel. Architectures that require the underlay > network to be service-aware are out of scope. > > The CAN WG will analyze the problem in further detail and produce an > architecture for a solution. Ideally, that architecture will be one > that can be instantiated using existing technologies. > > The CAN WG is chartered to work on the following items: > > o Groundwork may be documented via a set of informational Internet- > Drafts, not necessarily for publication as RFCs: > > * Problem statement for the need to consider both network and > computing resource status. > > * Use cases for steering traffic from applications that have critical > SLAs that would benefit from the integrated consideration of network > and computing resource status. > > * Requirements for commonly agreed computing metrics and their > distribution across the overlay network, as well as the appropriate > frequency and scope of distribution. > > o Overall CAN framework & architecture: > > * This work encompasses the various building blocks and their > interactions, realizing a CAN control and data plane that addresses > the identified problems and requirements in the groundwork, > including methods for distributing necessary information to utilize > the identified metrics in CAN use cases. This will also cover OAM, > scalability, and security aspects. > > o Additional groundwork to include: > > * Analyze the suitability and usefulness of computing and networking > metrics for traffic steering decisions in CAN with a CAN metrics > ontology as a possible outcome. > > * Analyze methods for distributing the necessary information to > utilize the identified metrics in CAN use cases. > > o Applicability of existing tools and mechanisms: > > * Analysis of implementing the CAN control and data plane using > existing mechanisms, including identifying the limitations of > existing tools in fulfilling requirements. > > * Study potential new approaches for the CAN control and data plane > solution that can fill the identified gaps in existing tools and > solutions. > > * Study FCAPS (fault, configuration, accounting, performance, > security) requirements, mechanisms, and suitability of existing > messaging protocols (NETCONF) and data models (YANG). > > Milestones: > > Jul 2023 Adopt the CAN Problem Statement, Use Cases, Gap Analysis, and > Requirements documents > > Jul 2024 Adopt the CAN Framework and Architecture document > > Nov 2025 Submit the CAN Framework and Architecture document to the IESG > for publication > -- Can mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/can -- Can mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/can ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
