Hi Ryan, > John->I've probably missed an orbit here, but in the ovn-northd > implementation, >I was expecting to find service chains in the egress and router pipelines >in addition to the ingress pipeline (see below for why I think a service >chain stage in the egress pipeline makes sense ...)
>Also, in the ovn-northd implementation, I'm a little disturbed to see the >ingress side of the service chain sending packets to output ports - II th >think that a more scalable (and more "ovs-like" approach) would be to >match the egress side of a port pair in the chaining stage of the >ingress pipeline, with an action that set the input port register. >Then the egress pipeline would have a chaining stage where the output >port register would be set based on the ingress port of the next port >pair in the chain and the packet being punted to the proper output port >in the last table. That should automagically build your function chain >and provide the basis for bucketizing multiple ingress ports for the >next port group to support hash based load balancing. Yes, that would work too. However, I like the current approach where we intercept packets in the ingress chainprior to the L2 lookup table, modify the packet for SFC (including hash based load-balancing)and then send it through the rest of the ingress and egress chains. The way I look at it is the service chaining overrides normal lookup. If we do chaining in the egress chain, it means we have (in the slow path) first done the normal L2 lookup on the packetin the ingress chain, and then in the output chain overriden the lookup results. There is also another reason IMHO for doing the chaining in the ingress chain.Ultimately, the whole point of SFC is for support service-aware VNFs.Service-aware VNFs will send a NSH header (when NSH support is available in OVS).A service-aware VNF can dynamically change the path of a service chain (E.ga DPI VNF could look in the packet and direct it to parental control instead of sendingit to a video-optimizer). Doing chaining for such packets in the ingress chainis far more convenient than first letting the packet go through a whole lot of inputfeatures only to check the NSP (NSH path) and redirect the packet in the egress chain. Regards,Farhad. Date: Mon, 23 May 2016 23:06:52 -0500 From: "Ryan Moats" <rmo...@us.ibm.com> To: John McDowall <jmcdow...@paloaltonetworks.com> Cc: OpenStack Development Mailing List <openstack-...@lists.openstack.org>, "discuss@openvswitch.org" <discuss@openvswitch.org> Subject: Re: [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC and OVN Message-ID: <20160524040659.271f3136...@b03ledav002.gho.boulder.ibm.com> Content-Type: text/plain; charset="utf-8" John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016 03:55:14 PM: > From: John McDowall <jmcdow...@paloaltonetworks.com> > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, "OpenStack > Development Mailing List" <openstack-...@lists.openstack.org> > Date: 05/18/2016 03:55 PM > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN > > Ryan, > > OK all three repos and now aligned with their masters. I have done > some simple level system tests and I can steer traffic to a single > VNF. Note: some additional changes to networking-sfc to catch-up > with their changes. > > https://github.com/doonhammer/networking-sfc > https://github.com/doonhammer/networking-ovn > https://github.com/doonhammer/ovs > > The next tasks I see are: > > 1. Decouple networking-sfc and networking-ovn. I am thinking that I > will pass a nested port-chain dictionary holding port-pairs/port- > pair-groups/flow-classifiers from networking-sfc to networking-ovn. > 2. Align the interface between networking-ovn and ovs/ovn to match > the nested dictionary in 1. > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain model. > 4. Add ability to support chain of port-pairs > 5. Think about flow-classifiers and how best to map them, today I > just map the logical-port and ignore everything else. > > Any other suggestions/feedback? > > Regards > > John John- (Sorry for sending this twice, but I forgot that text/html is not liked by the mailing lists ...) My apologies for not answering this sooner - I was giving a two day training on Tues/Wed last week and came back to my son graduating from HS the next day, so things have been a bit of a whirlwind here. Looking at the github repos, I like the idea of passing a dictionary from networking-sfc to networking-ovn. The flow classifiers should be relatively straightforward to map to ovs match rules (famous last words)... I've probably missed an orbit here, but in the ovn-northd implementation, I was expecting to find service chains in the egress and router pipelines in addition to the ingress pipeline (see below for why I think a service chain stage in the egress pipeline makes sense ...) Also, in the ovn-northd implementation, I'm a little disturbed to see the ingress side of the service chain sending packets to output ports - II th think that a more scalable (and more "ovs-like" approach) would be to match the egress side of a port pair in the chaining stage of the ingress pipeline, with an action that set the input port register. Then the egress pipeline would have a chaining stage where the output port register would be set based on the ingress port of the next port pair in the chain and the packet being punted to the proper output port in the last table. That should automagically build your function chain and provide the basis for bucketizing multiple ingress ports for the next port group to support hash based load balancing. Does that make sense? Ryan
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
