[Cats] Re: Call for adoption: draft-fu-cats-oam-fw-07 (Ends 2026-07-06)

[Adrian Farrel <[e-mail]>]

Thanks for the confirmation, Cheng.

The I-D was successfully adopted.

Further reviews and comments are encouraged from everyone.

 

Adrian

 

 

From: Cheng Li <c.l=[e-mail]> 
Sent: 19 August 2026 07:58
To: [e-mail]; [e-mail]; zengguanming <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Cats] Re: Call for adoption: draft-fu-cats-oam-fw-07 (Ends 2026-07-06)

 

Hi Quan,

 

Sorry for my delay.

I reviewed the update quickly, and it seems that my comments are addressed, so I am ok for now.

 

Thank you for your work.

 

Cheers,

Cheng

 

 

From: [e-mail] <[e-mail]> 
Sent: Friday, July 10, 2026 3:04 PM
To: Cheng Li <[e-mail]>; [e-mail]; zengguanming <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Call for adoption: draft-fu-cats-oam-fw-07 (Ends 2026-07-06)

 

Hi Cheng, Guanming and Peng, 

 

Thank you for the valuable suggestions and comments during our adoption call!

The authors have revised the document and attached an updated version to fully address all your concerns.

We sincerely look forward to your further feedback before the formal submission. Thank you again for your time!

 

Best Regards,

Quan

 

 

 

 

Original

From: ChengLi <[e-mail] <mailto:[e-mail]> >  

To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >;cats <[e-mail] <mailto:[e-mail]> >;  

Cc: cats-chairs <[e-mail] <mailto:[e-mail]> >;[e-mail] <[e-mail] <mailto:[e-mail]> >;

Date: 2026年07月02日 17:33  

Subject: RE: Call for adoption: draft-fu-cats-oam-fw-07 (Ends 2026-07-06)  

Hi authors,

Thank you for your work on CATS OAM. I have read the draft, it looks good with VERY correct/nearly perfect grammar, and some high-end words, more like a paper  writing instead of an IETF I-D.

A simple question, no mean to offense, I may wonder that whether you used the LLM to translate the text or modify the text :)

Some comments below.

 

Thanks,

Cheng

 

 

Main issues

1. Question: OAM framework, is it a framework? or a tool set?

1. this should be an informational draft instead of a stand track document. Because I did not find new technique is defined but only concepts  and requirements without IANA allocation requirement. In this case, it should be an Informational draft?

2.for section 4:

Incommensurability of Heterogeneous Metrics: Since network metrics (e.g., one-way delay, jitter, packet loss) and computing metrics (e.g., instructions per second,  memory watermark) characterize distinct dimensions of service delivery, they are often collected via disjoint protocols and lack unified correlation mechanisms, such as high-precision synchronized timestamps. Without a consolidated OAM framework to harmonize  these data points, the CATS Path Selector (C-PS) cannot accurately calculate the composite cost, defined as C{total} = f(C{network}, C_{computing}), thereby undermining the deterministic nature of path computation  and steering efficiency.

[Cheng] I may not agree with this point. In the cats metric document, we can see that we can use the normalized metric, and for the C-PS node, it is a local problem for it to  select the best path, it can be done without OAM framework. C{total} = f(C{network}, C_{computing}) seems not a OAM function neither.

3.section 6.1:

3.1.The operational layer, please define the operational layer before use.  I do not understad what is the operational layer.

3.2.regarding the requirements of operation, they seem quite general, I  am not sure that are specific Operational requirements or not.

like 

1. O-REQ-1: Multi-Dimensional Status Awareness. The system MUST support the collection of both network metrics (latency, jitter, packet loss) and computing metrics ( e.g., processing capacity, load, and availability) defined in [ <https://datatracker.ietf.org/doc/html/draft-ietf-cats-metric-definition-08> I-D.ietf-cats-metric-definition].  To balance precision and control plane overhead, the system SHOULD support both periodic and threshold-triggered reporting.

This has been defined in the CATS metric draft or CATS framework? it looks like a commen requirement, not a OAM requirement.

 

 

 

Minor issues

1.[I-D.ietf-teas-rfc3272bis <https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-27> ]  has been published as RFC9522, please update.

2.Internet Control Message Protocol(ICMP) [ <https://www.rfc-editor.org/rfc/rfc4443> RFC4443])  verify the liveness of the routing path and the node's IP interface. They lack the granularity to detect the health of the service instance hosted on that node.

Question: a service node can process the ICMP packets? We might not limit  the ICMP to be used between routers/switches?

3.I might not be a professional english reader. The wording of the below  text seems too complicated to me. translated by some LLM tools? Suggest to use some simple and clear words to help readers to under stand the content easier.

3.1. Reachability without Serviceability: serviceability seems not clear

3.2. Temporal Staleness of Computing Metrics:Temporal  Staleness ?

3.3. Lack of Cross-Layer Fault Demarcation: Demarcation? suggest to use another simple word.

3.4. Incommensurability of Heterogeneous Metrics:

Incommensurability? suggest to use other words to help readers understand  it easily.

4.IEEE 802.3ah,

seems this is for Mac reachability? not for IP? if yes, suggest to delete  this in this document.

5.Monitoring mechanisms MUST support flexible  implementation modes, including a "Push" mode, where computing nodes report dynamic load status in real-time, and a "Pull" mode, where the egress CATS-Forwarder proactively retrieves computing metrics by extending the existing OAM mechanisms.

5.1.suggest to use must instead of MUST here. 

5.2.Are you trying to define Push and Pull mode here? if yes, you might need to add them into the terms section. Suggest to delete the modes, this it not the essential  part of this draft.

6.Service OAM: This layer provides either end-to-end or segmented visibility  into the connectivity and performance between the Ingress CATS-Forwarder and the target Service Instance (SI), as defined in the CATS framework [ <https://datatracker.ietf.org/doc/html/draft-ietf-cats-framework-24> I-D.ietf-cats-framework].

[Cheng] segmented as well? it should be an E2E visibility?

7.SVC-OAM: please define what is SVC and SVC-OAM

8.In the figure 1, it looks like the Service OAM is for e2e from the ingress  CATS forwarder to the serivce instance. So it is not for segmented?

9.in the figure 1, instance OAM, seems started from the Egress CATS forwarder,  why?

10.Link OAM and Path OAM are already supported by existing mechanisms.  Accordingly, this document proposes two new sets of components corresponding to the remaining two layers, namely, Instance OAM and Service OAM.

looks like instance OAM and Service OAM also can be supported by the existing  tools, do we define any new OAM methods in this document?

11.As specified in Section 5.1, Instance OAM supports both Push mode and Pull mode. When inconsistencies are detected  between the values obtained via the two modes, the system MUST be capable of detecting such inconsistency. This document does not mandate a single conflict resolution strategy, as the optimal approach depends on deployment scenarios.

suggest to define Push and Pull mode, or remove the mode but keeping the function.

12.s/MUST/must

 

 

Nits

1.suggest to use another word to replace ‘encompasses’

2.Section 8.1: The text mentions "Service OAM、Instance  OAM". The顿号 (、)  is a Chinese punctuation mark. It should be replaced with a comma (,) for an English-language RFC: "Service OAM, Instance OAM".

 

 

 

 

 

 

 

 

From: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, June 22, 2026 9:52 AM
To: cats <[e-mail] <mailto:[e-mail]> >
Cc: cats-chairs <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: Call for adoption: draft-fu-cats-oam-fw-07 (Ends 2026-07-06)

 

Hi, All:

 

This email begins a 2-week adoption poll for: https://datatracker.ietf.org/doc/draft-fu-cats-oam-fw/ , 

which may be one of the good candidates for CATS additional groundwork in the charter. 

Please review this document, send email to the list whether you support or not with comments/suggestions by Monday 06th July 2026. 

 

IPR status:

There are 1 IPR statement: https://datatracker.ietf.org/ipr/7356/. 

Considering the latest version has some change of the text and the co authors, please make sure if there is any potential IPR status change,

and the new co author should also reply to the IPR call at least.

 

Preliminary comments: 

Please notice that the CATS system can only collect the metrics but can't *monitor* the instance or service status positively.

So, in the text, maybe *trace* would be more appropriate to prevent people from thinking CATS can 'control' the computing resource.

 

Regards,

Peng and Adrian

  _____  

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