By principle, SFC definition is in orchestration, devOps and SDN controller domain, but it requires support at networking requirements, which is relevant to Anuket RA2 forum.

SFC can be visualized as Service function plane (consists of SFF, SFC, SF, SF proxy) over Service function overlay network, which is realized over Overlay /underlay network.
In Overlay network, packets are routed based on networking principles as destination ip, next hop.
However, in service overlay network, packets are routed based on policies unlike overlay network, again defined at Orchestrator level. This requires specific support at CNI in CNF environment to provide such specific routing mechanism.
It means, we need to define or capture items, which will help realize SFC at CNF environment, are

1. SFC aware interfaces available to Pod as plugins at CNI level.
2. CNI need to route packets based on policy, along with networking routing principles.
   For example,
   CNI enables SFC by assigning a port/interface to Container (SFC identifier, or SFCID, to each SF and sequencing these service SFCIDs in a ordered list. A service SFCID may be of local significance or directly reachable from anywhere in the routing domain.
   Once packets destined to undergo SFP, CNI will be getting the information encapsulated in packet to enable this forwarding to Container (SF). This information will be encoded by SFC and forwarded to CNI to act as SFF.(out of scope for RA2)

SFC Architecture
Functional Components:- SFC can be visualized as made of these components which makes SFC possible.

1. DevOps components of SF/SFC Orchestrator, CNF MANO–, which are responsible for as SF LCM. For example cloudify, K8S, Ansible, etc.
2. SFC components for traffic steering in Service Plane. SFF, SF , SF proxy.
3. SFC port Agent/ Renderer – creates and wires port for SF data path. CNI agent to wire Policy rules for SFC. It can deploy different techniques to stitch the wiring but provide the same functionality, for example l2xconn, srv6 , Segment routing etc.
   

Call flow-
A possible use case to create the SFC in container system shown as below. After creation of container ( or existing container ), SFC interface(s) is(are) created, identified by interface Id(s) and attached with the container.
These interface IDs ae used to render SFP for given SFC.
Once packets received on these SFP, policy driven packet steering performed to route packets to SF for processing.

A Service Function Path consists of:
• a set of container interface ports, to define the sequence of service functions
• a set of flow classifiers, to specify the classified traffic flows to enter the chain (– out of scope of RA2)
If a service function has a pair of ports, the first port in the port-pair is the ingress port of the service function, and the second port is the egress port of the service function. The first port of the first port-pair is the head of the service chain. The second port of the last port-pair is the tail of the service chain. A bidirectional service chain would be composed of two unidirectional Port Chains.

For example, [{p1: p2}, {p3: p4}, {p5: p6}] represents:

In addition, SFP represented in CNF environment as -

Summary to RA2 relevance:-
Relevance to RA2-

1. Attaching SFC supporting Interfaces at Pod using multi plugin
2. Architecture support for SDN controller interfaces at CNI
3. Configuring policy driven routes to steer traffic between these Interfaces via SDN controller .

Out of scope of RA2 :-
Note:- these are not exhaustive list.

1. How CNI will support SFC using SRv6, mpls, NSH ?
2. How SDN controller will interact with CNI for SFC policy?
3. How packets are classified for SFC?
4. How SFP is created from SFC design?

• if this is going to be in scope of RA2, it should be an optional feature
• it is worth to identify what workloads (eg UPF) and use cases would leverage this functionality

Updating better diagrams -

Architecture-

Call Flow

SFP illustration

SFP Data Model