[ovs-discuss] NSH related questions

Tue Apr 24 20:58:07 UTC 2018

Regarding question #4 below, using conntrack to remember state is an interesting possible solution which we can think more on.
You are right about SFC Proxy being a difficult entity to implement in a generic way, and would need to be a bit customized based on network / use case.

Answers for #1 and #2 are also very useful.

We would be coming back to this thread for more information or questions and any more comments to the questions are more than welcome.
Thanks Jan for your answers and input!

-Ashish

From: Jan Scheurich <jan.scheurich at ericsson.com>
Date: Friday, April 20, 2018 at 5:09 PM
To: Ashish Varma <avarma at vmware.com>, "ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>, "yi.y.yang at intel.com" <yi.y.yang at intel.com>
Cc: Justin Pettit <jpettit at vmware.com>, Pierluigi Rolando <prolando at vmware.com>, Raju Koganty <rkoganty at vmware.com>, Kantesh Mundaragi <kmundaragi at vmware.com>, Niaz Khan <niazkhan at vmware.com>
Subject: RE: NSH related questions

Hi Ashish,

You are asking relevant and interesting questions that have been bothering us for quite some time. Please find some partial answers/thoughts below.

Best regards, Jan

From: Ashish Varma [mailto:avarma at vmware.com]
Sent: Monday, 16 April, 2018 21:28
To: ovs-discuss at openvswitch.org; Jan Scheurich <jan.scheurich at ericsson.com>; yi.y.yang at intel.com
Cc: Justin Pettit <jpettit at vmware.com>; Pierluigi Rolando <prolando at vmware.com>; Raju Koganty <rkoganty at vmware.com>; Kantesh Mundaragi <kmundaragi at vmware.com>; Niaz Khan <niazkhan at vmware.com>
Subject: NSH related questions

Hi Jan / Yi Yang,

We, at VMware, are working on integrating partner services on NSX using NSH support on OVS. It would be very helpful to understand the current NSH/SFC adaptation trend and deployment scenarios happening in the industry.
Regarding this, we have few questions and it would be very helpful to get any insight on these:

1. When the classifier classifies a packet (stream) to follow a particular Service Function Path, the path may consist of going to multiple Service Function Forwarders (e.g. to cover all the Service Functions which may be spread across the network or data center) The last SFF could be far from the classifier (assuming there is only one in this SFP) where the NSH header was added to the original packet.
How do packets generally go back on its original path? Are they sent back to the original classifier or there are cases where you see last SFF intelligent enough to know the next hop of the packet outside the SFC overlay?

[Jan] As you observe, there are two fundamental approaches to this problem:
a) Forward the packet back to the Classifier (i.e. close the SFP to a ring), or
b) The Classifier encodes the forwarding context (e.g. L2 domain or L3 VRF) in the NSH context data, so that the last SFF knows into which context to inject the decapsulated packet for forwarding to its final destination. This can only work if both ends of the SFP have a footprint in that L2/L3 domain and agree on some identification.

2. In your experience, have you seen SFC being deployed on an existing overlay network. e.g SFC on top of OVN where now there is an SFC overlay network over tunnel based OVN overlay network. Have you encountered any challenges with this? (e.g. increase in packet size)

[Jan] As far as I know the SFC project in ODL is/was working on a model of a distributed virtual SFF covering an entire cloud (e.g. OpenStack region). In this model the mesh of OVS switches realizing the vSFF would be using VXLAN-GPE transport tunnels to carry the NSH payload. I don’t see strong challenges except the usual MTU size considerations with that approach.

3. Are there any third party Virtual Network Functions which are NSH/SFC compliant?

[Jan] I have no insight into that. Yi hinted at having some collaborations.

4. SFC proxy is supposed to de-capsulate the NSH header when sending the packet to Service Function and encapsulate NSH header back when sending back to SFF. The NSH header information (SPI/SI, context headers etc.) needs to be put back on the packet when going back to SFF. If this is to be done using OVS flows (without sending the packets to Controller which can remember the information), we will have to come up with some kind of ‘learn’ flow to dynamically put the header back.
What are your thoughts on this?

[Jan] I think a general SFC Proxy is extremely hard to implement even without any of the constraints imposed by OVS and OpenFlow. Re-attaching the stripped NSH header can only work in simple cases when the SF does not modify any parts of the packet needed by the Proxy to re-identify it. I fear many true value-add services do manipulate the packet stream (modify/drop/insert packets). I am therefore very sceptic of the Proxy SFC concept.

To me NSH makes sense most when the header can be maintained through the entire SFP. Where it cannot, it might be simpler to split the SFP into to segments and re-classify the packet coming back from a non-NSH service function.

Having said that, I think that one could implement a simple stateful SFC Proxy with OVS, recognizing packet flows by their 5-tuples. This might be a new use case for conntrack. The challenge would be how to store the entire NSH header as data in the conntrack entry. Even the fixed size NSH MD1 header has 6x32 = 196 bits and exceeds the 128 bits available in ct_label today. Could that be extended? Using learn actions to create flow entries with NSH header info stored in set-field actions might be an alternative.

Thanks,

Ashish Varma

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180424/286d42cc/attachment-0001.html>