Re: [Cats] Start to address the issues of framework draft #

["Shihang(Vincent)" <[e-mail]>]

The bigger question is whether SF is a form of computing. Normally, an SF such as FW and IPS involves some form of computing in addition to forward the packet. Then the same SF can be deployed in multiple places/cloud. In this case, CATS can be used to select the best SF instance. Please see https://datatracker.ietf.org/doc/html/draft-zhang-cats-computing-aware-sfc-usecase

How to chain multiple different SFs together is clearly in the scope of SFC(the Chain part).

Thanks,
Hang
From: Cats <[e-mail]> On Behalf Of Cheng Li
Sent: Friday, December 8, 2023 6:24 PM
To: Yao Kehan <[e-mail]>; Joel M. Halpern <[e-mail]>
Cc: cats <[e-mail]>; Dirk Trossen <[e-mail]>; Peng Liu <[e-mail]>
Subject: Re: [Cats] Start to address the issues of framework draft #

Well. Regarding SFC and CATS, I think there is a case that a SFC is represented as a service ID. It works in CATS actually.
Because when a client is requesting for a service, and it may not care about how this service is constructed. It may be constructed by a single service instance, or a serial service instances like SFC.
But apparently, how the service is constructed is out of the scope of CATS, therefore we have some related text in the framework draft as below.

======

Which and how these resources are solicited is part of the service logic which is internal to the provider. For example, these resources may be:¶<https://datatracker.ietf.org/doc/html/draft-ldbc-cats-framework-03#section-2-2.12.1>

· Exposed by one or multiple processes (a.k.a. Service Functions (SFs) [RFC7665<https://www.rfc-editor.org/rfc/rfc7665>]).¶<https://datatracker.ietf.org/doc/html/draft-ldbc-cats-framework-03#section-2-2.12.2.1>

=======
Furthermore, a CATS packets may go through an overlay path that consists of several SFs, making it as a SFC path, that is OK.
But this is simple combining SFC and CATS, making a SFC as a path selection result of CATS, just like a SR path can be the selected path of CAST. However, we might also call it as Computing-aware SFC?
Some simple text can explain the combination.

Regarding your Q2, I learned that in NSH, we have SPI and SI, where SPI represents the path ID, and the SI represents the service index in the chain. Multiple service instances may be associated with a single SI attaching to a SFF? I guess the problem comes from here. If it is what I am saying, then it comes back to the question of flow affinity, and we will come back to the discussion with Dirk. It is a flow based/service-request based forwarding.

We have some text in section 4.5 https://datatracker.ietf.org/doc/html/draft-ldbc-cats-framework-03#name-service-contact-instance-af
We can enhance this part in the future revisions.

Thanks,
Cheng


From: Yao Kehan <[e-mail]<mailto:[e-mail]>>
Sent: Friday, December 8, 2023 3:48 AM
To: Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: cats <[e-mail]<mailto:[e-mail]>>; Dirk Trossen <[e-mail]<mailto:[e-mail]>>; Peng Liu <[e-mail]<mailto:[e-mail]>>
Subject: Re:Re: [Cats] Start to address the issues of framework draft #


Hi Joel, Cheng, all,



Let me clarify a little bit on the discussion between Dirk and me. I think there are two questions.


Q1: The scope. Many thanks for the clarification from Joel, very clear. CATS and SFC are two different tools to solve two different problems. And of course, this part is very helpful for the gap analysis.

Q2: The mapping issues between service ID and service instances in SFC and CATS, similarity and the difference. This question is what Dirk and me were focused on.



In previous emails, I quoted the comments from Jim and Adrian in IETF 118. They mentioned that there had been some discussions on the mapping issues between service ID and service instances in SFC. So I raised my personal curiosity that what's the necessity for the mapping in SFC and what's the background. Personally I think these information make a lot sense in promoting the discussion on mapping issues in CATS.




BR,
Kehan


----邮件原文----
发件人：Peng Liu <[e-mail]<mailto:[e-mail]>>
收件人："c.l " <[e-mail]<mailto:[e-mail]>>,"Joel M. Halpern" <[e-mail]<mailto:[e-mail]>>,"dirk.trossen " <[e-mail]<mailto:[e-mail]>>,yaokehan  <[e-mail]<mailto:[e-mail]>>
抄　送: cats  <[e-mail]<mailto:[e-mail]>>
发送时间：2023-12-08 10:29:34
主题：Re: [Cats] Start to address the issues of framework draft #
Yes, thanks, it's clear. This might also be helpful to the gap analysis, the co authors may consider to add a new paragragh based on Joel's reply.

Regards,
Peng
________________________________
[e-mail]<mailto:[e-mail]>

From: Cheng Li<mailto:c.l=[e-mail]>
Date: 2023-12-08 03:10
To: Joel Halpern<mailto:[e-mail]>; Dirk Trossen<mailto:[e-mail]>; Yao Kehan<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>
Subject: Re: [Cats] Start to address the issues of framework draft #
Agree with your understanding of CATS and SFC. Very clear, and I think this is what we discussed before.

Respect,
Cheng


From: Joel Halpern <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, December 7, 2023 7:53 PM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>; Dirk Trossen <[e-mail]<mailto:[e-mail]>>; Yao Kehan <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Cats] Start to address the issues of framework draft #


I missed some of the discussion, and am having trouble parsing the various in line components.  So I am going to top-post how I understand CATS vs SFC.

They are two very ddifferent things that solve very different problems.

CATS is concerned with directing a packet from a subscriber to the most suitable instance of the service to which the packet is addressed.

SFC is concerned with directing the packet from a subscriber to the correct sequence of transparent services beign provided by the operator.  These services are not identified by the address the subscriber puts in the destination address  of the packet.

To meet its objectives without overloading the routing system, the CATS edge router will use some form of tunnel to direct the subscriber packet to the selected egress / service instance.  That tunnel is not part of the CATS work, but  is presumably any one of a number of technologies (We have specified I believe that the way edge rotuers in CATS select service instances and deliver the packets is local matter.)  It is certainly possible ot use SFC as part of the tunneling technology, and  deliver internal services using SFC.  But the SFC NSH (or MPLS or SRv6) mapping is internal, and its job is to direct the packet to the correct egress / addressed service instance.  THe service addressed by the subscriber is not an SF (much less an SFF) in  the terms used for SFC.

In my understanding, it will help us be able to make use of our tools well if we keep the concepts separate.

Yours,

Joel, M. Halpern
On 12/7/2023 1:43 PM, Cheng Li wrote:
Hi Dirk, Kehan, all,

Please see my reply inline.

Thanks,
Cheng


From: Dirk Trossen <[e-mail]><mailto:[e-mail]>
Sent: Thursday, December 7, 2023 10:58 AM
To: Yao Kehan <[e-mail]><mailto:[e-mail]>; Cheng Li <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Re:RE: [Cats] Start to address the issues of framework draft #

Hi Kehan, all,

Please see inline.

Best,

Dirk

From: Yao Kehan <[e-mail]<mailto:[e-mail]>>
Sent: 07 December 2023 10:47
To: Dirk Trossen <[e-mail]<mailto:[e-mail]>>; Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re:RE: [Cats] Start to address the issues of framework draft #


Hi Dirk, All,



    I've added some personal thoughts. Please see inline.



BR,

Kehan


----邮件原文----
发件人：Dirk Trossen  <[e-mail]<mailto:[e-mail]>>
收件人："姚柯翰" <[e-mail]<mailto:[e-mail]>>,Cheng Li <[e-mail]<mailto:[e-mail]>>
抄　送: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
发送时间：2023-12-06 18:11:39
主题：RE: [Cats] Start to address the issues of framework draft #


All,

Please see inline.

Best,

Dirk

From: Cats <[e-mail]<mailto:[e-mail]>> On Behalf Of ???
Sent: 06 December 2023 10:09
To: Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Cats] Start to address the issues of framework draft #


Hi Cheng,

                In IETF 118, there is a comment from Jim on the requirement draft. Here is the quote from the group meeting minutes:



    [Jim Guichard as individual] From the  WG pespective,  we do have some high level discussion of compute metrics and deciding which service instance to use, but we do not have some specific discussion of service identifiers. For example, how to map the service ID to a specific service instance in  the real network,  and what’s the excat metrics for this service. We had some discussions in SFC WG but haven’t solved it yet.

[DOT] Indeed, I understood that SFC focusses on the data plane but not the selection of the service function path (which is control plane) – maybe I misunderstand. But  isn’t the question on how to map the service  ID to a specific instance (or contact point, more correctly) the very essence of what CATS is about?

[KY] I think it's about how SF-ID can be mapped to SF instance, and it has not much relation with SFP-ID. And I'm curious about the backgroud of the discussions  on SF-ID mapping issues in SFC WG, what's the necessity for the mapping?

[DOT] In SFC, you will need to ‘fix’ the service path in order for the packet to traverse the network. This mapping to the specific SFP needs to be distributed to all SFF along the possible path from  endpoint to service instance. Now you can argue that if you choose some compute-aware ‘fixing of the SFP’ strategy, you do compute-aware traffic steering, too, can’t you?

And SFC is policy based, shouldn't the mapping be configured at the very beginning?

[DOT] indeed, it may become a question on how dynamic we see those mappings to happen. In my understanding of SFC (and Jim, Joel, and others are much better suited to comment here), the suitable SFP information  would need distribution to the SFF every time, in addition to the decision making itself. In the CATS framework, the choices (for service contact points to map a service ID to) are longer lived (albeit announced when joining new to the network), while the  metric distribution to the CATS ingress point will drive the selection of which service contact point is meant to be used (based on whatever objective function is being executed atop the metric information). So this sounds to me like a simpler approach.

I haven't found the evidence from RFC 7665, maybe I missed that.

[DOT] AFAIK, the control plane is not in scope of RFC7665 but, again, others may have more accurate views on that.

In CATS, I think the necessity is reflected in the migration of service to different service instances based on compute info, what's it for SFC?

[DOT] See above. I can see SFC being used for compute-aware traffic steering but would require to distribute the result of the SFP selection to the SFFs in the network. But as far as I understand, the  actual SFP choices may not be subject to many changes, as long as the network policy on how the traffic may traverse the network does not change. But which endpoint to use with which SFP is subject to metric-driven change.

Understanding about the background maybe good to promote the discussion in CATS.

[Cheng]Well, the core work of CATS is finding out the best service instance among instances associated with a service ID. This is true. I think we do have some text in the framework draft to explain that the computing-metrics are included  in the selecting/mapping algorithm. Also we should be aware that the algorithm is out of the scope of standardization of CATS. So we may show https://datatracker.ietf.org/doc/html/draft-ldbc-cats-framework-03#section-4.4 to Jim?



              [Adrian] Yes. The problem is even worse for CATS. For CATS little clusters of packets go to a specific service instance, but in  SFC all packets in a flow will be forwarded to the same service instance., but in CATS,  they might be forwarded to different service instances. Problem should be solved.

[DOT] I am confused by this answer. Service/flow affinity would demand that a flow will continue to be sent to a previously chosen instance (contact point), so instance change ONLY happens  when new flows (or transactions) are started. We have that  in the requirements, don’t we (apologies for the rhetoric question – we do have if you look at Section 5.5 of the requirements draft)? So we did outline that within a single flow, all packets must  go to a previously chosen instance – that assumes that the  flow is the boundary of a transaction, which is a big IF. Problem is mainly that the ingress tunnel endpoint has to perform some form of guesswork, based for instance on the assumption that flow boundary  means transaction boundary – but that is the problem  with making such decision in the network rather than the endpoint (I won’t dig up the whole E2E discussion here but one may see where this is pointing to).

[KY] If flow is the boundary for traffic steering to service instances, what's the difference between SFC and CATS on the issue of service ID  mapping?

[DOT] That was my main point. Adhering to the choice of service instance (or contact point) along the boundaries of a transaction is something I would see apply to SFC and CATS alike.  But the decision mechanism is indeed different IMO. Given that that decision in SFC could also use some compute metric to make a decision makes SFC a possible CATS mechanism.

is the decision maker the major difference(let's just leave alone whether it's based on compute status of the instance)?



            I think the mapping issue between service ID and instance ID is also very important for framework draft, and it may impact the requirements,  hope  we can continue the discussion on the list.

[DOT] Again, Jim’s question is the very heart of CATS; it is about this mapping in the ingress tunnel endpoint that CATS is about. So it is obvious to me that this issue is not just important  for the framework draft but it is its very essence!

[KY] Thanks for the emphasis.

[Cheng] Agree with this is the core task of CATS. Also, I think Dirk’s point is correct, the assumption is that the selection is per-flow/service request based solution. But we do need to specify it more clear in the draft. Currently,  this is described in https://datatracker.ietf.org/doc/html/draft-ldbc-cats-framework-03#section-4.5.

Personally, I would like to postpone the update of this part, and update it after the WG adoption. Because many people may have their POVs, and we need the inputs from the WG. But some detailed text can be added before WG adoption. However,  we may not be able to address this in the next revision which may be posted in the following days. Let’s do it step by step.



BR,

Kehan


----邮件原文----
发件人：Cheng Li  <c.l=[e-mail]<mailto:c.l=[e-mail]>>
收件人：Cheng Li  <c.l=[e-mail]<mailto:c.l=[e-mail]>>,"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
抄　送: (无)
发送时间：2023-11-28 03:18:22
主题：Re: [Cats] Start to address the issues of framework draft #


Hi Zongpeng,

Here[1] is the update to address your comments, is it ok for you?
We might try to address as many comments as possible in a single update, and you can read the link to check before submitting the new revision.

Thanks for Med’s editing.

Thanks,
Cheng

[1]. https://github.com/boucadair/CATS-framework/commit/e2f2ff887bf07f93db35c5505f5a3dbde1bbc6c6



From: Cats <[e-mail]<mailto:[e-mail]>> On Behalf Of Cheng Li
Sent: Thursday, November 23, 2023 5:32 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Xipengxiao <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Cats] Start to address the issues of framework draft

[Fixed syntax error: s/is/are]

Hi CATS,

The authors of framework draft are planning to address the issues of the framework draft[1] from today.
Med has addressed the first issue: Renamed the name of Github repository and updated it in the datatracker. Many thanks to Med [cid:image001.jpg@01DA2A8F.014D8B40] Good start!

Currently, we have 16 open issues to be addressed[2]. I also recorded two more comments from Zongpeng.
We will try our best to move the discussion to our mailing list, and update the draft ASAP. We will also use Github to merge text.
If you have any comments, you are welcome to share it in the mailing list.

Thanks,
Cheng

[1]. https://datatracker.ietf.org/doc/draft-ldbc-cats-framework/
[2]. https://github.com/boucadair/CATS-framework/issues


From: Cheng Li
Sent: Thursday, November 23, 2023 5:29 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Xipengxiao <[e-mail]<mailto:[e-mail]>>
Subject: Start to address the issues of framework draft

Hi CATS,

The authors of framework draft is planning to address the issues of the framework draft[1] from today.
Med has addressed the first issue: Renamed the name of Github repository and updated it in the datatracker. Many thanks to Med [cid:image001.jpg@01DA2A8F.014D8B40] Good start!

Currently, we have 16 open issues to be addressed[2]. I also recorded two more comments from Zongpeng.
We will try our best to move the discussion to our mailing list, and update the draft ASAP. We will also use Github to merge text.
If you have any comments, you are welcome to share it in the mailing list.

Thanks,
Cheng

[1]. https://datatracker.ietf.org/doc/draft-ldbc-cats-framework/
[2]. https://github.com/boucadair/CATS-framework/issues