"dev" <dev-boun...@openvswitch.org> wrote on 06/27/2016 04:19:56 PM:
> From: Farhad Sunavala <fs...@yahoo.com> > To: Farhad Sunavala <fs...@yahoo.com>, "dev@openvswitch.org" > <dev@openvswitch.org> > Date: 06/27/2016 04:20 PM > Subject: Re: [ovs-dev] dev Digest, Vol 83, Issue 495 > Sent by: "dev" <dev-boun...@openvswitch.org> > > Hi John and Ryan, > Thanks for taking the initiative on this.Please see inline for FS: > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jun 2016 15:21:47 +0000 > From: John McDowall <jmcdow...@paloaltonetworks.com> > To: Ryan Moats <rmo...@us.ibm.com> > Cc: "dev@openvswitch.org" <dev@openvswitch.org> > Subject: Re: [ovs-dev] SFC summary? > Message-ID: <d3968ed0.5c8c%jmcdow...@paloaltonetworks.com> > Content-Type: text/plain; charset="Windows-1252" > > >Ryan, > >Getting clearer. Let me try to parse out a few more items. > >When you talk about M-T are you talking about have a VNF instance > handle M-T or talking about the OVS/OVN service chaining infra- > structure handling M-T? >Just want to make sure we are talking about > the same problem. > >I have the multi-stage ppg coded, I just need to bring up another > VNF to test it, I think it I will work as you suggested. ‘ > >BTW: I am testing currently without Openstack – just ovs/ovn so the > UUID’s do not have the Openstack naming conventions for the UUIDs. > > >My current table structure is: > > > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_L2, 0, "ls_in_port_sec_l2") \ > > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_IP, 1, "ls_in_port_sec_ip") \ > > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_ND, 2, "ls_in_port_sec_nd") \ > > PIPELINE_STAGE(SWITCH, IN, PRE_ACL, 3, "ls_in_pre_acl") \ > > PIPELINE_STAGE(SWITCH, IN, ACL, 4, "ls_in_acl") \ > > PIPELINE_STAGE(SWITCH, IN, ARP_RSP, 5, "ls_in_arp_rsp") \ > > PIPELINE_STAGE(SWITCH, IN, CHAIN, 6, "ls_in_chain") \ > > PIPELINE_STAGE(SWITCH, IN, L2_LKUP, 7, "ls_in_l2_lkup") \ > > FS: This table structure looks good. We can do everything in > the ingress chain as I had earlier suggested. > > >I thing you are suggesting that the FC rules go into the ACL table > and we create a new action that sends the flows into the >ls-in- > chain table, I am a little fuzzy on how that would work. > > >I would like to try and focus on the following items first ( not > that L2/L3 and load balancing are not important), I just have > >trouble juggling too many items at the same time :-). > > > 1. Agree on basic pipeline model/architecture > > 2. Resolve how to implement the FC/ACL model and implement > > 3. Resolve the M-T/S-T design > > >Thoughts? > > Some general comments and something to think about. > While focusing on delivering a BITW SFC for OVN is fine for now, we > need to make sure we do not lose sight > of the bigger picture for SFC support on OVN. General areas include > > > 1. Support for NSH (or any other tagging mechanism be it MPLS tags, etc.). > Thoughts on where these would be processed and/or handled? > How about the schema requirements for NSH? NSH can add a lot of metadata. > Will all this be put in the OVN NB DB, then sent to the OVN SB DB > and finally to the local OVN controllers? > I don't see how it can be avoided but wondering if anyone has better ideas. > > 2. In addition to BITW, L2, and L3 VNFs, we also need to accomodate > NSH aware and NSH unaware service functions. > Will the current model support all these combinations? E.g. L2 and > NSH-aware or L3 and NSH unaware. > For NSH-aware service functions, is it necessary to add support for > SFC in the egress chain or can it be handled in the > ingress chain also? Honestly, I'm not going to worry about NSH at this point. I want to get something that works that isn't NSH aware and then those that are interested can figure out what is needed to add NSH as a later patch set. > 3. Support for physical appliances connected to L2GW? How will > these be handled? > The HW VTEP switch will have a DI but the appliances connected to > the HW VTEP switch will not have a logical DI. > How about return traffic from physical appliances connected to L2GW ? This is an excellent question and one that I'd also like to address with a follow-on patch. > 4. I assume the goal is to deliver SFC with OVN (stand-alone) and > SFC with OVN and Openstack integration. > Is this assumption correct? If yes, networking-sfc defines the > neutron CLI and it is very comprehensive. Will > SFC on OVN support all the necessary CLI ? If yes, would it make > sense to add all the CLI to the SFC OVN drive > so they can be reviewed? > > https://review.openstack.org/#/c/333172/1/doc/source/sfc_ovn_driver.rst I believe that's a question for a different context and a different audience, since you are asking about the interface between n-sfc and n-ovn, I'd take that question to the dev@openstack list and tag it appropriately. > 5. SFC across subnets ? If you are talking about SFC at the boundaries between networks, I've not seen anything about that and that is what leads to my side comments about Logical_Routers and Logical_Router_Ports. If you are talking about something else, I'm not sure what you mean... Ryan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
