Subject: [sfc] What if the SF consumes all the packets?

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Tue, 24 May 2016 17:22:42 +0000

Hello everyone,

So far most of the service functions in the SFC framework forward packets back to the SFF.  There is another set of SFs that receives packets but does not forward them out.  Analytic functions and IDS are a few examples.  They are "packet sinks" or “receive-only” SFs.

Some challenges for those SFs to operate in SFC:

- Being part of an SFP - They are managed as SF for simple and consistent SFC policy, but they do not egress traffic
- Packet replication - those SFs need to take a copy of the packets so that the original ones continue on the path
- Service index decrementing - packets “passing” such an SF need to have their SI decremented before reaching the next SF

We published a draft attempting to address the need for supporting this set of SFs, as a complementary to the SFC framework today.
https://tools.ietf.org/html/draft-wang-sfc-receive-only-00

Would appreciate your feedback.

Regards,
-Eric

---

From: "Duarte Cardoso, Igor" <[email-masked]>
Date: Tue, 31 May 2016 18:02:11 +0000

Hi Eric, Kent,

This draft has captured my attention since it's about a subject that I've also given a little bit of thought. Here goes my review, please excuse any possible misinterpretation, and point out if there's any.

It seems like RO SFs are being treated as outside functions not really part of the SFC domain, like non-SFC-aware SFs that require the SFC proxy as the gate to the SFC domain, and a new kind of logical SF being introduced to replace them, the Extended SFC Proxy, when the SFC architecture could be slightly "exploited" to address the use case of mirroring packets and still end up supporting RO SFs.

About RO ESs, my view is split between thinking that it is slightly out of scope versus that it actually goes into what I was thinking too (for the SFF scenario only).

Disclaimer: For the individual comments about specific lines, I hadn't read anything after the point about which I was commenting.

From RFC 7665:
>   4.8.  Reclassification and Branching
>   The SFC architecture supports reclassification (or non-initial
>   classification) as well.  As packets traverse an SFP,
>   reclassification may occur -- typically performed by a classification
>   function co-resident with a service function.  Reclassification may
>   result in the selection of a new SFP, an update of the associated
>   metadata, or both.  This is referred to as "branching".

Review:

Page 3:
>    RO ES:  A Receive-Only External Service not participating in SFC.
>    Specifically, an RO ES is not an SF.  It is not allocated with a
>    Service Index (SI) in the Service Function Path (SFP).  However,
>    it receives packets from the SFF or an SF.
If it is not inside the SFC domain, then why does it interact with an SFF or an SF?

Page 4:
>   examined by a chain of services before they reach the server.  The
>   three service functions, DDoS, IDS and Firewall, compose an SFC.
I agree, they compose an SFC.

>   Each SF including the IDS SF is allocated with a Service Index (SI)
>   in the SFP.  The IDS SF is a fundamental part of the service chain
This is where I would like to debate - should the 3 of them really be in the same SFP?
I ask this because there are essentially 2 "paths" being taken by the packets (even though only one is used to output). The first (main) one includes function DDoS and Firewall, while the second is an "RO path" composed by functions DDoS and IDS. So this is a branching SFC after DDoS. However, it has one major difference in that it's not really branching, but replicating.

>   Extending the SFC framework to RO SF enables a unified SFC policy
>  model for SFC administrators.  The administrator only needs to manage
I think that rather than overloading SFPs with RO and non-RO SFs, perhaps we should use the flexibility of SFC Encapsulation and SFPs to our advantage. Please check when I mention a Classifier replicating traffic.

>   threat analysis.  When doing so, it is desired that the construction
>   of the SFP is not affected.  That is, the Service Path ID (SPID) and
>   SI for each of the SFs in the SFP remain unchanged.
I agree.

Page 5:
>   An RO ES still requires support from SFC elements including SFF and
>   SF for receiving packets.  Because an RO ES does not send back
>   packets, it must receive replication of the packets.  Depending on
Partially agree since I would expect the same statement to be made about a normal RO SF. Also, the SFF may not be the best place to execute the replication. On one hand the SFF could do it, meaning that an existing SFP would always be reused. On the other hand, the Classifier could do it since it's the entity that in practice does branching depending on different criteria but, although not mandatory, it should have a different SFP because a different action was taken by the Classifier and thus a different path taken by the packets - and also helps on tracing and monitoring.

Page 7:
>   that packet back to the SFF.  This capability is an extension to the
>   current SFC Proxy as defined in ([RFC7665]).
The SFC Proxy is meant to be the "translator" for non-SFC-aware SFs, and the Extended SFC Proxy seems to have no relationship with the former in that regard. However, from the chain's point of view, it's definitely an SFC Proxy.

Page 9:
>   analysis, packet data replication may be conducted by an SF capable
>   of identifying file boundary in the packet stream.  The RO ES would
>   be associated with the SF and receives packet data from the SF
Is this still in the scope of the draft? It seems to be something up to the SF to execute, and there's an infinite amount of things that could be done by an SF.

>   Alternatively, for use cases such as generic packet capture for
>   troubleshooting, the SFF may carry out the packet replication and
>   forwarding work.  Higher performance may be achieved with hardware
>   based SFF.
See what I was envisioning at the end of my review.

Page 11:
Where the scenario that made use of an Extended SFC Proxy was perfectly achievable (because the base SFC abstraction was kept untouched - as it essentially reuses the existing SFC Proxy concept but does something different behind it), the other scenario (where an SFF is used to replicate traffic) cannot yet be supported, even taking into account draft-ietf-sfc-nsh-05, since a single next-hop must be selected by the SFF.

Page 16:
Drafts draft-ietf-sfc-nsh-05 and draft-ietf-sfc-control-plane-06 are out.

Let me share the solution I had mind. I'll appreciate feedback on this:
                - Actions in the Classifier (besides updating metadata, SFP information and sending, it could also support replication);
                - Alternatively, support sets of NHs when forwarding instead of single NHs in the SFF forwarding table (to be used in parallel);
                - Update control plane to accommodate either the sets of NHs or the new kind of action for the Classifier;
                - No need to overload the model with an Extended SFC Proxy.

My main concerns about the proposed solution in draft-wang-sfc-receive-only-00:
                - Potential additional delays and performance loss introduced by linearly inserting the Extended SFC Proxy function for the sake of parallelizing traffic;
                - RO SFs are being treated as outside functions not really part of the SFC domain, like non-SFC-aware SFs that require the SFC proxy as the gate to the SFC domain, and a new kind of logical SF being introduced to replace them;
                - Specifically at the SFF-based replication scenario, there is the need to formally extend the original definitions of SFF and SFF mapping table (essentially supporting the "Copy" field in the SFF forwarding table presented);
                - What happens if you need to replicate traffic to more than a single additional function?

My main concerns about the solution I had in mind:
                - Potential performance loss in SFF or Classifier if any of them are responsible for the replication action;
                - If the SFF is chosen for replication, there is the need to formally extend the original definitions of SFF and SFF [NSH] mapping table.

Best regards,
Igor.

From: sfc [mailto:[email-masked]] On Behalf Of Eric Wang (ejwang)
Sent: Tuesday, May 24, 2016 6:23 PM
To: [email-masked]
Cc: Kent Leung (kleung) <[email-masked]>
Subject: [sfc] What if the SF consumes all the packets?

Hello everyone,

Regards,
-Eric