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

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Wed, 1 Jun 2016 19:09:37 +0000

Hi Igor,

Thank you for your detailed comments.

"Reclassification and branching" is an important function with good use cases.  In fact we described in detail its use in draft-wang-sfc-ns-use-cases (see 4.1.3 & 4.1.4).  I’m open to exploring it for RO SFs.  If adopting it can simplify the model it would be a good alternative to "extended SFC proxy".

Just as you quoted below, reclassification is "typically performed by a classification function co-resident with a service function”.  There are a few issues I’d like to bring up for discussion when utilizing it for RO SF.

1. Trigger of reclassification.  Normally SFC classifier is invoked at the entry point of the SFC.  Once the packet is classified with a proper path, it is forwarded by SFF without going through the classier each time.  A possible trigger for reclassification is “new data” which is typically obtained by an SF. If the SF deems necessary it may invoke the classification function based on the new information (such as discovering an encrypted stream and sending the packets to the path with decryption capability).

If the Classifier is used here for packet replication and diverting to the RO SF SFP, how to know reclassification needs to occur, and when?  It would be inefficient to invoke classifier at each stage of SFF forwarding; other regular SFs may not be aware of the RO SF hence won’t help with the reclassification.

2. Parallel vs. linear insertion.  Reclassification is typically much heavier than simple SFF forwarding.  If the Classifier is inserted to perform reclassification, packet replication, and forwarding of the original packet back to SFF, would it be the same “linear” insertion?  Please let me know if I misunderstood your point.

3. I’d like to explore the “set of NHs" option, if that is an alternative to reclassification in the middle of the path.  In other words, is it pre-determined “two-path” at the ingress, or a true “reclassification and branching”?

Regarding the efficiency part of “extended SFC proxy”, it is only an extension to the SFC framework to accommodate both hardware and software, but not mandating the implementation.  In practice, a software SFF implementation could embed the “extended SFC proxy” function so that packet replication and forwarding can be done in parallel (including SI decrement which is "non-standard" in SFF).  On the other hand, a hardware/ASIC SFF implementation does not have to change to support RO SF.  Either way, the control plane model and communications would be consistent with the introduction of “extended SFC proxy”.

Please see some other responses inline… [EW]

On May 31, 2016, at 11:02 AM, Duarte Cardoso, Igor <[email-masked]<mailto:[email-masked]>> wrote:

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.

[EW] It’s a good summary.  I would argue the RO SF is still part of the SFC domain because the SFC contains the RO SF as a hop (instead of the Extended SFC Proxy that serves the RO SF).  RO SF understands NSH and complies with the SFC framework, with the only exception of passing on traffic. From this perspective RO SF is not quite like non-SFC-aware SFs.  To the end, the reason for extended SFC proxy is to provide a consistent model (especially in control plane) for various implementations, from very purpose specific hardware/ASIC SFF to sophisticate software implementation.

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).

[EW]  My view is the same. The reason it is discussed in the draft is because the SFF replication scenario.

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?

[EW] Only for the SFF packet replication part.  Hope it is clear from the subsequent discussions.

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.

[EW] Agreed.  The scope of “proxy” has to be extended.  We are also considering several other extensions of the “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.

[EW] That’s not in the scope when it deals with SF’s behavior.  I can make it clear in the text.

>   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.

[EW] That’s right. The replication function needs to be part of the SFF to support RO ES.  However it does not require data plane protocol change.  It would need control plane support and implementation in the SFF.

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

[EW] Thanks. Will update.

Best regards,
-Eric

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]<mailto:[email-masked]>
Cc: Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] What if the SF consumes all the packets?

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

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Duarte Cardoso, Igor" <[email-masked]>
Date: Wed, 8 Jun 2016 12:59:59 +0000

Hi Eric, thanks for the responses,

"Reclassification and branching" is an important function with good use cases.  In fact we described in detail its use in draft-wang-sfc-ns-use-cases (see 4.1.3 & 4.1.4).  I’m open to exploring it for RO SFs.  If adopting it can simplify the model it would be a good alternative to "extended SFC proxy".
[IDC] Thanks for the quick pointer to real-world branching use cases! I’ll have a full read at it.

“Normally SFC classifier is invoked at the entry point of the SFC.  Once the packet is classified with a proper path, it is forwarded by SFF without going through the classier each time.”
[IDC] Correct. However, you can set up your SFF in such a way that the last hop of your SFP-A is a classifier function, which can then switch to SFP-B.

“If the SF deems necessary it may invoke the classification function based on the new information (such as discovering an encrypted stream and sending the packets to the path with decryption capability).”
[IDC] In which case the classifier would be co-resident with the SF right?

“If the Classifier is used here for packet replication and diverting to the RO SF SFP, how to know reclassification needs to occur, and when?  It would be inefficient to invoke classifier at each stage of SFF forwarding; other regular SFs may not be aware of the RO SF hence won’t help with the reclassification.”
[IDC] The classifier would only be “called” before potential branching or replication points. So, it would be inefficient for scenarios where you keep replicating or branching, but not so much as you have more and more guaranteed linearity.

“2. Parallel vs. linear insertion.  Reclassification is typically much heavier than simple SFF forwarding.  If the Classifier is inserted to perform reclassification, packet replication, and forwarding of the original packet back to SFF, would it be the same “linear” insertion?  Please let me know if I misunderstood your point.”
[IDC] If you use the Classifier for replicating traffic, it may be the case that there are other actions the classifier can take as well. An academic scenario that I see is: needing to have different paths for TCP and UDP traffic, while replicating all TCP:

1.       With replication function: classify once to separate TCP and UDP and then have the replication function split traffic in the TCP path (to another or the same path);

2.       With only the classifier function: classify once to either send 2 TCP flows down a path (or down 2 paths) or to send UDP flows to the other path.
Also, at the physical layer you could have your SFF co-resident with the Classifier, so no need to actually linearize traffic. But then, the extended proxy can also be co-resident with the SFF as you later say in the email.

“3. I’d like to explore the “set of NHs" option, if that is an alternative to reclassification in the middle of the path.  In other words, is it pre-determined “two-path” at the ingress, or a true “reclassification and branching”?”
[IDC] True reclassification and branching needs to be done at the Classifier. The set of NHs would be something like this:
SPI/SI |   NH
1/1    |   {A}
1/2    |   {B}
1/3    |  {C,D}
Where traffic would be sent to both C and D when SPI/SI=1/3, and no changes would be made to that header. Either C or D would be a RO function so only a single 1/4  flow would be received back in the SFF (or not, depending on the objective and what C and D are). So, essentially, different RSPs going on here, but still using the same SFP (1).

“I would argue the RO SF is still part of the SFC domain because the SFC contains the RO SF as a hop”
[IDC] This is what I read in the draft: “SFF looks up in its forwarding table and finds Extended SFC Proxy for SF-2 to be the next hop.  SFF sends the packet to SF-2's Proxy.”

“The reason it is discussed in the draft is because the SFF replication scenario.”
[IDC] Is this SFF replication scenario something mentioned in other drafts/RFCs or, if this question doesn’t make sense, what are you referring to as being “discussed in the draft”?

“That’s not in the scope when it deals with SF’s behavior.  I can make it clear in the text.”
[IDC] Okay, thanks.

“That’s right. The replication function needs to be part of the SFF to support RO ES.  However it does not require data plane protocol change.  It would need control plane support and implementation in the SFF.”
[IDC] Agreed.

Best regards,
Igor.

From: sfc [mailto:[email-masked]] On Behalf Of Eric Wang (ejwang)
Sent: Wednesday, June 1, 2016 8:10 PM
To: Duarte Cardoso, Igor <[email-masked]>
Cc: Kent Leung (kleung) <[email-masked]>; [email-masked]
Subject: Re: [sfc] What if the SF consumes all the packets?

Hi Igor,

Hi Eric, Kent,

Review:

I agree.

Page 11:

Page 16:

Best regards,
-Eric

Best regards,
Igor.

Hello everyone,

Regards,
-Eric