Hi, Jordi
Some comments about the draft for discussion.
The service instances should be deployed firstly, and then the instance
selection would take place only if multiple instances exists for the client
request.
In the deployment procedure, the computer information is more detailed,
and I think that only the operators that has the right are able to obtain the
information.
The process in the Kubernets should be similar. They can manage the
cloud, select a node/place, and deploy a POD.
I notice that in table 1, it says, in the service placement, service
providers need compute and communication information.
However, the communication information perhaps is not E2E, such as
latency, unless we know where the client is connected into the network.
Perhaps, it means the "as well
as bandwidth capacity for forwarding the traffic generated in and out
of the corresponding data center." mentioned in the first Section?
In the service instance selection procedure, it can be decided in the
centralized server such as the ALTO server, or in the CATS ingress.
In the former case, the centralized server (decision point) can be
aware of more information, e.g. multiple metrics, and make a decision.
In the later case, which is called on-path decision, we perhaps need
simpler metrics, which is still under working.
Best Regards
Zongpeng Du
[email protected] & [email protected]
From: Jordi Ros Giralt
Date: 2023-10-24 19:47
To: [email protected]; [email protected]
Subject: [Cats] New draft on joint exposure of network and compute information
Dear CATS and ALTO WG mailing list members,
We submitted a new draft on joint exposure of network and compute information
for service placement and selection:
https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/
Joint Exposure of Network and Compute Information for Infrastructure-Aware
Service DeploymentJoint Exposure of Network and Compute Information for
Infrastructure-Aware Service Deployment
This draft focuses on the problem of exposing both network and compute
information to the service provider/application to support service placement
and selection decisions. ALTO provides an interface for network information
exposure to the service provider/application; thus, an approach is to leverage
and extend it with compute metrics. CATS also needs to develop compute metrics
to support traffic steering decisions. The common ground is in these compute
metrics, which could be reused across the various use cases (e.g., consumed by
the network as in CATS or consumed by the application as in ALTO).
This draft also aims at providing a framework for continuing the discussion
initiated during IETF 117 regarding the presentation "Compute-aware metrics:
CATS working with ALTO":
https://datatracker.ietf.org/doc/slides-117-alto-compute-aware-metrics-cats-working-with-alto/
We would like to seek feedback from both working groups on developing compute
metrics that can be reused for different use cases, to avoid duplicated work
and increase the effectiveness of future standards.
Thanks,
Jordi
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
