Summary:

This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS components, describes their interactions, and provides illustrative workflows of the control and data planes.

The document is well written. I have comments and suggestions as detailed below:

Comments/Suggestion:

1- Introduction:

1.1- The term "suboptimal utilization" could benefit from examples or clarification, (e.g. resource exhaustion)?.


2-  Section 2: 


2.1- It would be nice to add in Section 2 definition of "flow", "computing resources" and "computing domain".
 

2.2-  It would be helpful to clarify whether the document uses "service provider" and "provider" interchangeably, and likewise for "computing service" and "service", if that is the case. 


2.3- "(C-SMA): A functional entity that is responsible for collecting service capabilities and status" -> From whom is collecting the capabilities and status (service instances directly, or gets this from orchestrators or monitoring tools)?


3- Section 3.4: It would be nice to mention the Ingress CATS Forwarders in this section, as I understand they are the CATS-Forwarder 2 and CATS-Forwarder 4 (Figure 2).


4- Figure 2: It would be nice to indicate the direction of data flow and control flow, especially between clients, forwarders, and service instances. Also, clearly distinguish the data plane from the control/management plane, for example, using different line styles (solid vs dashed).


5- Section 3.4.1: It would be nice to clarify if multiple service contact instances at one site differ in capabilities or if they are identical.


6- Section 3.4.4: It would be nice to clarify whether multiple C-PSes coordinate or operate independently, and describe implications.

6.1- It is unclear how (or if) the C-PS interacts with existing routing protocols. Does it modify route computation or just provide forwarding policies to CATS-forwarders?


7- Section 3.4.6: CATS-Forwarders:

7.1- The draft states: "...In some cases, the choice of the service contact instance may be left open to the Egress CATS-Forwarder...."
Does the CATS framework provides any guarantees of loop-free forwarding in such scenarios? If so, how are these guarantees enforced, especially in distributed deployments where multiple forwarders may make independent decisions based on dynamic metrics? 

Also, it would be helpful to understand:

7.1.1- Whether loop prevention is assumed to be handled by the underlying routing layer,

7.1.2- Or whether CATS requires specific safeguards (e.g., forwarding constraints) to avoid persistent redirection or forwarding loops.

7.2- The draft states: "..the Egress CATS-Forwarder selects a service contact instance using its knowledge of service and network capabilities as well as the current load as observed by the CATS-Forwarder, among other considerations." It would be nice to clarify what is meant by "other considerations" in this context? It may be helpful a reference or examples.


8- Section 4.1: This section is incomplete "TBC: --detail required provisioning..."


9- Section 4.2: I understand that The CATS framework is agnostic to the specific name resolution mechanism used. Is this correct? Perhaps would be nice to clarify this in the text.
 
9.1- Are CS-ID to locator mappings expected to be distributed via routing protocols, or is the resolution process assumed to remain external to the routing plane, for example, resolved only by ingress nodes using mechanisms like DNS, without propagating the mappings to other routers?


10- Section 4.3: The draft states that metric distribution frequency will be defined by the communication protocol used. It may be helpful to note whether the CATS framework has any recommendations or constraints (e.g., minimum freshness requirements) that such protocols should consider to ensure reliable and accurate service selection.


11- Figure 3: The figure includes only three arrows, and it is not clear which components actively send metrics or control messages.

11.1- Should there be arrows from Service Sites to the C-SMAs to illustrate how service-specific metrics are collected?

11.2-  The roles of the arrows (e.g., data flow, control signaling, metric dissemination, client requests) are not labeled. It would be helpful to:

11.2.1- Label each arrow with the type of information being exchanged (as done for "Network metrics"), and

11.2.2- Explicitly illustrate the end-to-end paths that metrics take from service instances to the Path Selector, in order to better convey the logical flow and sequence of operations.

11.3- It would be nice to have a distinction between control-plane and data-plane flows, or a small legend.

11.4- The same comments apply to Figures 4 and 5.


12- Section 4.4: "...a service access may consist of one or more service packets (e.g., Session Initiation Protocol (SIP) [RFC3261], HTTP [RFC9112], IPv6 [RFC8200], SRv6 [RFC8754] or Real-Time Streaming Protocol (RTSP) [RFC7826]) that carry the CS-ID and potential parameters...."

12.1- Where in a packet the CS-ID is generally expected to appear (e.g., application-layer field, network-layer identifier)?

12.2- How a CATS-Forwarder is expected to extract or interpret the CS-ID for steering decisions?

12.3- Does the framework assumes any typical encoding or placement strategy (e.g., in headers or protocol-specific parameters)?


13. Section 4.5: "...a certain level of flexibility ..." 

"certain level " is vague, maybe directly to say something like: "when specifying a protocol to communicate information about service contact instance affinity, the protocol should support flexible mechanisms for identifying flows.", what do you think? 


14- Section 5: It would be nice to add examples in "aggregation techniques" and "dampening mechanisms".


15- Section 6: "This information is sensitive and should be encrypted."
It does not specify what encryption methods or protocols are recommended or required for securing sensitive CATS-related information.

15.1- Perhaps, it may be helpful to clarify whether encryption is expected at the transport layer, network layer, or at the application/protocol level.

15.2- Also, it would be nice to indicate whether key management and trust establishment are in scope, or explicitly state that encryption recommendations are left to the specifications of the underlying protocols used to carry CATS information.


16- Does CATS framework guarantees loop-free forwarding in multi-domain or multi-path deployments?


17- How CATS interacts with traditional routing both behaviorally and architecturally?

17.1- Does the CATS framework ensure that service instance selection and path steering decisions remain consistent with existing routing behavior (e.g., OSPF, BGP)?

17.2- In cases where CATS-based service selection results in a path that differs from the one chosen by traditional routing protocols, does CATS take precedence, or is it constrained by routing decisions?

17.3- Does the CATS framework operate entirely as a separate control plane overlay, or are there scenarios where it is expected to integrate with traditional routing control planes? For example, would CATS components ever inject service-aware information directly into routing advertisements, or is this considered out of scope.


18- Does the framework assume or require routing policy mechanisms to support integration with CATS forwarding logic across domains?


19- Which component is responsible for maintaining flow or instance affinity when routing changes occur?

19.1- Does the CATS framework allow the use of Equal-cost multi-path (ECMP), and if so, how is flow affinity preserved across equal-cost paths?

19.2- If the routing path changes mid-session due to metric updates or topology shifts, how is the preserving affinity across a session maintained to prevent service disruption?


20.- The draft mentions the use of aggregated per-site computing metrics for scalability. In addition to metric aggregation, does the framework support aggregation of CS-ID to locator mappings? For example, are multiple CS-IDs ever grouped or summarized under a common network locator to reduce control-plane or forwarding state? Or is each CS-ID treated as a unique entry in resolution and forwarding, even when service instances are co-located?


21- NITS:


"such an information" --> "such information"


"deployment independly" --> "deployment independently"


"Absent explicit policy" --> "In the absence of an explicit policy..." ?


"quite stable" --> "quite stable (change infrequently)". ? 


Thanks for this document,

Ines.