Hi Yi, Thanks for response. Let me provide some background on the question. Each port of the VM in openstack is part of a openstack tenant network. Each openstack installation has a configured encapsulation (VXLAN/GRE/VLAN/FLAT) method defined for tenant network. In your slide#7, all the VMs (VM1, VM2, SF1, SF2) have their ports part of single tenant network which uses VXLAN encapsulation. Now consider a case of non-SFC/non-NSH traffic between SF1 and SF2 (lets say simple ping). This will go via VXLAN tunnel between host1 and host2 as per openstack neutron networking path. But SFC/NSH traffic will follow different VXLAN-gpe encapsulation.
Architecturally speaking, SFC should create a overlay service plane based on top of underlay physical/virtual network. In this case (from VM perspective) underlay network is neutron tenant network to which all the ports belong. However, NSH traffic (when going across hosts) is not going through existing tenant network but instead orchestrating its own virtual overlay on top of physical network which is different than neutron tenant overlay. Now consider a case of multi-tenant environment where single host has VMs from different tenants and all or some of which are orchestrating the SFC. Since single VXLAN-gpe tunnel between the hosts will carry traffic from all these tenants, it may lead to un-desirable cases of IP/MAC conflicts as well as security concerns. Consider a case of application level networking connectivity monitoring scheme (gossip or some such many-to-many protocol) between all the VMs of given tenant. Such scheme may be used for high-availibility architecture. Since NSH traffic is flowing via different encapsulation method than regular tenant traffic, such monitoring will not be effective in deciding reachability. E.g. An TOR switch has been accidentally programmed to permit only GRE/VXLAN protocol and drop everything else. In such cases, SF1 continues to be accessible to SF2 via regular tenant networking, from SFC perspective SF1 and SF2 are disconnected. Coming back to existing implementation, I have specific question on steps given in slide#12. After packet is received from SF1 (SF1 OUT step), current implementation pops the ethernet header and then adds VXLAN-gpe (and IP/UDP/Eth) in subsequent steps. Instead of this, if the destination MAC is changed to that of SF2, can the packet not follow the existing tenant encapsulation scheme implemented for non-SFC traffic between SF1 and SF2 (VXLAN/GRE/VLAN etc)? What problems do you foresee? — Thanks, Aniruddha On 3/28/16, 8:35 PM, "Yang, Yi Y" <[email protected]<mailto:[email protected]>> wrote: Hi, Aniruddha Thank you for your question, SFC needs NSH to deliver SFC context information, currently VxLAN-gpe is only one available option, GRE/Geneve is also ok to do this, but currently they don’t support this in ovs implementation. I don’t know why underlay IP fabric can’t support VxLAN-gpe, VxLAN-gpe is almost same as VxLAN, VxLAN is very popular in data center, Openstack has used it as the default tunnel protocol between different compute nodes. Please let me know details if you have any user scenario which can’t support this. From: Aniruddha Atale [mailto:[email protected]] Sent: Tuesday, March 29, 2016 1:47 AM To: Yang, Yi Y <[email protected]<mailto:[email protected]>>; opendaylight sfc <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [ovsdb-dev] My presentation "Fix VxLAN issue in SFC integration by using Eth+NSH and VxLAN-gpe+NSH Hybrid Mode" in ONS 2016 Hi Yi, Could you please explain the reasoning behind VxLAN-gpe tunnel between two host using underlay networking directly as against running over tenant networking. It seems while non-SFC traffic between tenant vms (one two different hosts) would go via operator selected encapsulation technology (e.g. GRE/Geneve), the SFC traffic between them would use VxLAN-gpe encapsulation which may or may not be supported by underlay IP fabric. — Thanks, Aniruddha On 3/24/16, 11:43 PM, "[email protected]<mailto:[email protected]> on behalf of Yang, Yi Y" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: Hi, All I had a presentation “Fix VxLAN issue in SFC integration by using Eth+NSH and VxLAN-gpe+NSH Hybrid Mode<https://youtu.be/fu4s5MaURJQ>” in ONS 2016 to showcases our work in ovs, openflowplugin, ovsdb, gbp and sfc, you can get my presentation by http://events.linuxfoundation.org/sites/events/files/slides/Fix%20VxLAN%20issue%20in%20SFC%20integration%20by%20using%20Eth%2BNSH%20and%20VxLAN-gpe%2BNSH%20Hybrid%20Mode%20Final.pdf, here https://www.youtube.com/watch?v=fu4s5MaURJQ is video record, https://www.youtube.com/watch?v=3SlqKxZp9nY is demo’s HD video, you can watch it with 720P resolution. I hope I can reproduce this demo setup in netvirt+sfc integration and let it as test bed or landing zone for genius or Openflowplugin Flow Programmer, our openflow multi-writer issue or app coexistence issue will count on this setup :)
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
