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? 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 ? 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 5. SFC across subnets ? . Thanks, Farhad. >John | | | Gerrit Code Review | | | _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
