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?

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)

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

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?


Ashish Varma

discuss mailing list

Reply via email to