[ovs-dev] dev Digest, Vol 83, Issue 495

Ryan Moats rmoats at us.ibm.com
Tue Jun 28 03:45:07 UTC 2016


"dev" <dev-bounces at openvswitch.org> wrote on 06/27/2016 04:19:56 PM:

> From: Farhad Sunavala <fsbiz at yahoo.com>
> To: Farhad Sunavala <fsbiz at yahoo.com>, "dev at openvswitch.org"
> <dev at openvswitch.org>
> Date: 06/27/2016 04:20 PM
> Subject: Re: [ovs-dev] dev Digest, Vol 83, Issue 495
> Sent by: "dev" <dev-bounces at 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 <jmcdowall at paloaltonetworks.com>
> To: Ryan Moats <rmoats at us.ibm.com>
> Cc: "dev at openvswitch.org" <dev at openvswitch.org>
> Subject: Re: [ovs-dev] SFC summary?
> Message-ID: <D3968ED0.5C8C%jmcdowall at 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 at 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


More information about the dev mailing list