[OPS-DIR]Re: [Cats] Re: draft-ietf-cats-framework-15 early Opsdir review

[Giuseppe Fioccola <[e-mail]>]

Thank you for posting a new version!
The changes are ok for me.

Regards,

Giuseppe

From: [e-mail] <[e-mail]>
Sent: Friday, October 17, 2025 4:33 AM
To: Giuseppe Fioccola <[e-mail]>; [e-mail]
Cc: cats <[e-mail]>; draft-ietf-cats-framework.all <[e-mail]>
Subject: Re: [Cats] Re: draft-ietf-cats-framework-15 early Opsdir review

Hi Giuseppe ,

    Thanks for the review.

    We have some comments about the modifications on the Github. Also, a new version 16 of the draft has been updated.


    Some further explanation can be found inline. If any problem, please connect us. Thanks.

 Best Regrards
Zongpeng Du
________________________________
[e-mail]<mailto:[e-mail]> & [e-mail]<mailto:[e-mail]>



From: Giuseppe Fioccola<mailto:giuseppe.fioccola=[e-mail]>
Date: 2025-10-16 01:47
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: cats<mailto:[e-mail]>; draft-ietf-cats-framework.all<mailto:[e-mail]>
Subject: [Cats] Re: draft-ietf-cats-framework-15 early Opsdir review
Hi Zongpeng,
Thank you for addressing my comments.
Please see inline [GF]

Regards,

Giuseppe

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 15, 2025 5:49 AM
To: Giuseppe Fioccola <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: cats <[e-mail]<mailto:[e-mail]>>; draft-ietf-cats-framework.all <[e-mail]<mailto:[e-mail]>>
Subject: Re: Re: [Cats] draft-ietf-cats-framework-15 early Opsdir review

Hi Giuseppe ,

    We have made some modifications. Hope you can review it again, and check whether they make sense.



Update draft-ietf-cats-framework.md by dzpzp · Pull Request #131 · ietf-wg-cats/draft-ietf-cats-framework<https://github.com/ietf-wg-cats/draft-ietf-cats-framework/pull/131/commits/e208f6a50cb8a18a8691aecb3ae03cb436d8c7bf>



    The above link is in the Github, and some explanations can be seen inline.



    Thanks for your review.



 Best Regrards
Zongpeng Du

________________________________
[e-mail]<mailto:[e-mail]> & [e-mail]<mailto:[e-mail]>




From: [e-mail]<mailto:[e-mail]>
Date: 2025-10-02 23:12
To: Giuseppe Fioccola<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: cats<mailto:[e-mail]>; draft-ietf-cats-framework.all<mailto:[e-mail]>
Subject: Re: [Cats] draft-ietf-cats-framework-15 early Opsdir review
Hi Giuseppe

    Some thoughts to share. Hope they can help.

>From an OPSDIR point of view, I think it is good to have a section on
"Operational and Manageability Considerations", as also highlighted in
draft-opsarea-rfc5706bis.
[Zongpeng] Agree.

I understand that the specific means are out of
scope, but, since NETCONF and IPFIX are mentioned, I would also add the
references to RESTCONF and YANG Push, just for completeness.
[Zongpeng] OK. I think we can add some references about them.


Old1


   The above task can be enabled using a variety of means (NETCONF

   [RFC6241], IPFIX [RFC7011], etc.).  It is out of scope to discuss

   required CATS extension to these protocols.



5.2.  Deployment Considerations
New1

The above task can be enabled using a variety of means (NETCONF

   [RFC6241], IPFIX [RFC7011], RESTCONF [RFC8040], YANG-Push [RFC8639], etc.).  It is out of scope to discuss

   required CATS extension to these protocols.

[GF]: Ok.

Regarding the
possible deployment scenarios, I would add a pointer to
draft-ietf-cats-usecases-requirements, because it reports the CATS use cases.
[Zongpeng] OK. I think we can add a reference about it.



Old2


5.2.  Deployment Considerations



   This document does not make any assumption about how the various CATS

   functional elements are implemented and deployed.  Concretely,

   whether a CATS deployment follows a fully distributed design or

   relies upon a mix of centralized (e.g., a C-PS) and distributed CATS

   functions (e.g., CATS traffic classifiers) is deployment-specific and

   may reflect the preferences and policies of the (CATS) service

   provider.
New2

5.2.  Deployment Considerations



   This document does not make any assumption about how the various CATS

   functional elements are implemented and deployed.  Concretely,

   whether a CATS deployment follows a fully distributed design or

   relies upon a mix of centralized (e.g., a C-PS) and distributed CATS

   functions (e.g., CATS traffic classifiers) is deployment-specific *, which*

   may reflect the preferences and policies of the (CATS) service

   provider, and requirements of the usecases [draft-ietf-cats-usecases-requirements].

[GF]: Ok.

I suggest to clarify in the text whether the framework covers only the case of
single service provider. Otherwise, it would be better to provide some
deployment considerations about the case of multiple service providers.
[Zongpeng] Within my understanding, the draft is discussing under a single service provider scenario.
 The charter said that “The CATS WG will focus on single domain models.”
However, I think that it is a single service provider, but it can include multiple CATS services, and each of the CATS services can have a unique CATS Service ID.



Old3


5.3.  Implementation Consideration on Using CATS Metrics



   According to the metric definition in


New3

The framework covers only the case of a single service provider currently. Thus, the deployment considerations about the case of multiple service providers are not mentioned here.

5.3.  Implementation Consideration on Using CATS Metrics



   According to the metric definition in

[GF]: Maybe you can consider to clarify this point in the Introduction too, so it is clear from the beginning.
[[Zongpeng]]: Thanks for the proposal. Perhaps we can consider it in future.

I have additional suggestions for your consideration:
- The client is defined in Section 2 as an endpoint that connects to a service
provider network, but later in the text it is mentioned the case of the
multi-homed client. Therefore the definition should be reviewed.
[Zongpeng] I checked that in the Section 4.3., it says
      Note that multi-homed clients may be connected to multiple CATS
      infrastructures that may be operated by the same or distinct
      service providers.  This version of the framework does not cover
      multihoming specifics.
I wander whether we can delete the Note, so that we will not mention the case about the multi-homed client in the draft.



Old4


      Note that multi-homed clients may be connected to multiple CATS

      infrastructures that may be operated by the same or distinct

      service providers.  This version of the framework does not cover

      multihoming specifics.



4.4.  Service Contact Instance Affinity
New4

      Note that multi-homed clients may be connected to multiple CATS

      infrastructures that may be operated by the same or distinct

      service providers.  This version of the framework does not cover

      multihoming specifics.

[GF]: Ok.

- I would add
in Section 4 a flow chart to report the sequential steps. They might also be
deducted from the text but a diagram would definitely help the reader.
[Zongpeng] Thanks for the advice. I think we can prepare one for discussion.



Old5



4.  CATS Framework Workflow



   The following subsections provide an overview of a typical CATS

   workflow.  In order to enable CATS in a given domain, some

   provisioning is needed; see more details in Section 5.1.  Section 5.2

   describes several deployment options (distributed, centralized, and

   hybrid model) to accommodate a variety of contexts.
New5

4.  CATS Framework Workflow



   The following subsections provide an overview of a typical CATS

   workflow.  In order to enable CATS in a given domain, some

   provisioning is needed; see more details in Section 5.1.  Section 5.2

   describes several deployment options (distributed, centralized, and

   hybrid model) to accommodate a variety of contexts.



+-----------------------------------+

|         Service Announcement    |

+-----------------------------------+

             |

          V

+-----------------------------------+

|         Metrics Distribution    |

+-----------------------------------+

             |

          V

+-----------------------------------+

|       Service Access Processing  |

+-----------------------------------+

             |

          V

+-----------------------------------+

| Service Contact Instance Affinity |

+-----------------------------------+



Figure 3:   A Typical CATS Workflow

[GF]: I noticed the comment from Med on the PR about this figure. It seems there are cases where the steps are not sequential. Maybe, you can include it as just an example or revise the diagram in order to consider all the possibilities, e.g. using additional arrows or bidirectional arrows where applicable.
[[Zongpeng]]: Thanks for the proposal. We have some discussions here, and we have suggested not to include the Figure in the new version.
Comments from Med are copied here: The figure may be interpreted as if we assume a sequentiality in the various state, which may not be always true. For example service announcement can be updated/modified after metric are distributed.


- In Section 4.2, I would split the different metric distribution models
(distributed, centralized, hybrid) in separate subsections to improve
readability.
[Zongpeng] Thanks for the advice. We can modify accordingly.



Old6

4.2.  Metrics Distribution



   Figure 3 shows an example of how CATS metrics can be disseminated in

   the distributed model.



   If the CATS framework is implemented using a centralized model, the

   metric can be, e.g., distributed as illustrated in Figure 4.


   If the CATS framework is implemented in the hybrid model, the metric

   can be distributed, e.g., as illustrated in the Figure 5.
New6

4.2.  Metrics Distribution

4.2.1 Metrics Distribution in Distributed Model

   Figure 4 shows an example of how CATS metrics can be disseminated in

   the distributed model.

4.2.2 Metrics Distribution in Centralized Model



   If the CATS framework is implemented using a centralized model, the

   metric can be, e.g., distributed as illustrated in Figure 5.

4.2.3 Metrics Distribution in Hybrid Model


   If the CATS framework is implemented in the hybrid model, the metric

   can be distributed, e.g., as illustrated in the Figure 6.

[GF]: Ok.


- In Section 6 and 7, I would highlight the different security and
privacy implications if a single service provider or multiple service providers
are involved.
[Zongpeng] As talked before, I think we are under the case of single domain, so that it should be a single service provider from the network side. However, there could be multiple CATS services.


 Old7

6.  Security Considerations



   The computing resource information changes over time very frequently,

...

Also, C-SMA agents

   need to support a mechanism to authenticate the services for which

   they provide information to C-PS computation logics, among other CATS

   functions.





7.  Privacy Considerations



   CATS solutions must support preventing on-path nodes in the underlay

   infrastructure to fingerprint and track clients (e.g., determining

   which client accesses which service).



...

The specific encryption method may be applied at the

   network layer, transport layer, or at the application/protocol level

   depending on the implementation, so this is out of the scope of this

   document.



   For more discussion about privacy, refer to [RFC6462] and [RFC6973].



New7


6.  Security Considerations



   The computing resource information changes over time very frequently,

...

Also, C-SMA agents

   need to support a mechanism to authenticate the services for which

   they provide information to C-PS computation logics, among other CATS

   functions.



This version of the framework mainly focuses on the scenario of a single service provider. Hence, the security issues about the multiple service providers are not included currently.



7.  Privacy Considerations



   CATS solutions must support preventing on-path nodes in the underlay

   infrastructure to fingerprint and track clients (e.g., determining

   which client accesses which service).



...

The specific encryption method may be applied at the

   network layer, transport layer, or at the application/protocol level

   depending on the implementation, so this is out of the scope of this

   document.



This version of the framework mainly focuses on the scenario of a single service provider. Hence, the privacy issues about the multiple service providers are not included currently.



   For more discussion about privacy, refer to [RFC6462] and [RFC6973].

[GF]: Ok.

Best Regrards
Zongpeng Du

________________________________
[e-mail]<mailto:[e-mail]> & [e-mail]<mailto:[e-mail]>




From: Giuseppe Fioccola via Datatracker<mailto:[e-mail]>
Date: 2025-09-26 01:34
To: [e-mail]<mailto:[e-mail]>
CC: cats<mailto:[e-mail]>; draft-ietf-cats-framework.all<mailto:[e-mail]>
Subject: [Cats] draft-ietf-cats-framework-15 early Opsdir review
Document: draft-ietf-cats-framework
Title: A Framework for Computing-Aware Traffic Steering (CATS)
Reviewer: Giuseppe Fioccola
Review result: Has Nits

This document describes the Computing-Aware Traffic Steering (CATS) framework.
In particular, it defines the CATS components and the related procedures. I
think the document is generally clear and well written.

>From an OPSDIR point of view, I think it is good to have a section on
"Operational and Manageability Considerations", as also highlighted in
draft-opsarea-rfc5706bis. I understand that the specific means are out of
scope, but, since NETCONF and IPFIX are mentioned, I would also add the
references to RESTCONF and YANG Push, just for completeness. Regarding the
possible deployment scenarios, I would add a pointer to
draft-ietf-cats-usecases-requirements, because it reports the CATS use cases. I
suggest to clarify in the text whether the framework covers only the case of
single service provider. Otherwise, it would be better to provide some
deployment considerations about the case of multiple service providers.

I have additional suggestions for your consideration:
- The client is defined in Section 2 as an endpoint that connects to a service
provider network, but later in the text it is mentioned the case of the
multi-homed client. Therefore the definition should be reviewed. - I would add
in Section 4 a flow chart to report the sequential steps. They might also be
deducted from the text but a diagram would definitely help the reader. - In
Section 4.2, I would split the different metric distribution models
(distributed, centralized, hybrid) in separate subsections to improve
readability. - In Section 6 and 7, I would highlight the different security and
privacy implications if a single service provider or multiple service providers
are involved.



--
Cats mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>