[ovs-discuss] [ovn4nfv]

[Russell Bryant]

I won't be at the OpenStack Summit this time around.

I'm happy to jump on the phone sometime for quick clarifications if needed,
but in general I think it's best if we keep discussion in public as much as
possible.  I want to make sure we include whoever else is interested.  I
certainly don't have all the answers.  :-)

I feel like we have a lot of good ideas, and our instincts are saying we
can do this, but I know we have some details missing.  I'd also like to
feel reasonably confident that the solution we come up with more generally
supports other uses of the networking-sfc API.

What I'd like to see as a next step is a detailed end-to-end design for a
simple use case that shows:

1) A sample use of the networking-sfc API

2) How we would reflect that in the OVN_Northbound database

3) An explanation of the logical flows we would generate to implement what
was specified in OVN_Northbound

4) Docs on the "Life Cycle of a Packet through a Service Chain".  In
ovn-architecture(7), there are several very detailed "Life Cycle"
sections.  I feel this functionality could really benefit from a detailed
walkthrough.

I feel like I had a pretty good idea of how this could work if all the
ports were on the same logical switch.  I never figured out allowing ports
in the chain to exist on separate logical switches.  It'd be nice to
include that in the sample.  Or is that limitation a reasonable one to
accept as a first cut?  If so, we might be able to move quickly on a first
iteration based on the work I had done before.

-- 
Russell Bryant


On Wed, Mar 30, 2016 at 1:13 PM, John McDowall <
jmcdowall at paloaltonetworks.com> wrote:

> Russell,
>
> Let me try and answer your questions:
>
>    1. I looked at the networking-sfc API (
>    http://docs.openstack.org/developer/networking-sfc/api.html#rest-api)
>    and I think we can fit into it pretty easily. I would use the neutron
>    port-pair-create and use the service-function-parameters option to pass in
>    a type indicating service insertion and the application-id that the service
>    would be inserted to. Port-pair-groups could be used to do simple chain – I
>    think but needs more investigation.
>    2. Yes, also interested in service insertion outside of Openstack, I
>    implemented a set of ovn-nbctl commands to enable insertion outside of
>    openstack. I have really used Openstack as the centralized management plane.
>    3. As a “legacy” vendor :-), we would rather remain unaware of the NSH
>    headers, though we would change if we can see good use cases that require
>    the VNF to participate in the service chain.
>
> I assume you will be at the Openstack Summit in Austin perhaps we could do
> a f2f there.
>
> Would like to ask everyone on the list about potential use cases so we can
> make sure we can address the widest audience.
>
> Regards
>
> John
>
> From: Russell Bryant <russell at ovn.org>
> Date: Tuesday, March 29, 2016 at 6:06 AM
> To: John McDowall <jmcdowall at paloaltonetworks.com>
> Cc: Ben Pfaff <blp at ovn.org>, "discuss at openvswitch.org" <
> discuss at openvswitch.org>
> Subject: Re: [ovs-discuss] [ovn4nfv]
>
> On Mon, Mar 28, 2016 at 6:56 PM, John McDowall <
> jmcdowall at paloaltonetworks.com> wrote:
>
>> Russell,
>>
>> Thanks of taking the time to provide a detailed response. Let me try and
>> answer your questions, and ask a few on my own.
>>
>>    1. Yes, I want to continue working through this as we see it really
>>    important to enable easy service insertion at scale. Think of the problem
>>    of how to deploy hundreds of VNF’s that can be scaled up/down with no
>>    manual intervention.
>>
>>
> Fantastic.  :-)
>
>>
>>    1. The Neutron API I created was done for much the same reason as
>>    your prototype - seeing how hard it was and making sure I could get
>>    something to work. Creating and supporting yet another API is rarely a good
>>    idea and so aligning with the networking-sfc API is the right thing to do.
>>    I have had a few off-line conversations with that team and will continue to
>>    try and fit this under that umbrella as it evolves.
>>
>> Great!  Do you have specific issues with their API?  I'd be interested to
> hear about what changes you think should be made.
>
>>
>>    1. I agree with you idea of a separate table, once again I just took
>>    what I could see was the shortest path to get something working for a
>>    prototype. I will take a look at your code and see how to implement an
>>    extra table.
>>
>> I totally understand.  A prototype of something working is a great way to
> get the conversation going!
>
>
>>
>>    1. The issue with routing between subnets to chain VNF’s could be
>>    looked at in three ways, 1) If each subnet has one or more VNF’s the
>>    problem  is easy; 2) If the application being protected is communicating
>>    with applications/hosts on a different subnet then the traffic is, I
>>    assume, forwarded the default router; 3) The hardest case is if the
>>    topology is such that all the VNF’s are placed in a shared subnet, then we
>>    would need to add additional information in the API  to direct traffic to
>>    that subnet, or OVN could look up the subnet based on logical port? - have
>>    not thought about it a lot but seems doable.
>>
>> IP addresses are stored in the logical port "addresses" column.
>
>>
>>    1. The toughest question here is what is a VNF and does it operate at
>>    L3, L2, or as a transparent bump in the wire. The related question is how
>>    complex is the service chain of these virtual functions. I would disagree a
>>    little here with Russell and suggest that the approach is not for “legacy”
>>    VNF’s but transparent VNF’s that act as a “bump in the wire" from a
>>    networking POV. The issue becomes what are the specific use cases we want
>>    to design for with ovn4nfv.
>>
>> I meant no harm by using the term "legacy".  :-)  I just needed a term to
> differentiate from the service chaining aware VNFs that expect some
> additional metadata.  RFC 7665 calls it a "SFC-unaware Service Function".
>
> I think your "bump in the wire" use case makes sense.
>
> I honestly don't have that strong of an opinion on what use cases to
> support.  I just want to support whatever it is actual users want.
>
> Let me try to start to separate/segment some of the approaches:
>>
>> I think there are several segments of the market for VNF’s and NFV. The
>> two I see most are:
>>
>>    1. Carrier networks where they are focused on virtual
>>    provider/customer edge routers (vCPE, vPE), border network gateways (BNG) ,
>>    for wired to wireless networks, and SD-WAN, which is related to vCPE/PE
>>    2. Public/private cloud data centers and virtual enterprises, where
>>    the use cases are centered around virtual load balancing/scaling and
>>    security.
>>
>> The needs of both are different (IMHO), the need for the carriers is to
>> enable the creation of large scale distributed virtual routers, leveraging
>> MPLS and/or BGP as the core transport protocol. The goal for the carriers
>> is to be able to customize their core routing infrastructure without
>> waiting for a new release from their hardware vendors which can take years
>> to get into production. Here the architecture of networking-sfc has it core
>> strengths; with its focus on dynamic routing; as it acts similarly to the
>> ingress/egress forwarding paths of a classical router. This enables
>> carriers to build large scale dynamic distributed virtual routing
>> infrastructure from virtual functions.
>>
>> The needs in private/public cloud (and enterprises) are simpler as the
>> requirements are to insert either a load-balancer or security VNF to scale
>> up/down applications or secure applications. Here change can be rapid and
>> the need is to deploy and scale up/down in minutes if not seconds in many
>> instances.  I have been focusing on the use cases for the second segment as
>> it is where we are seeing a need for simplicity and speed.
>>
>> A typical use case we see a lot of is protecting east-west traffic, when
>> an application is deployed, security is deployed with it to protect it, and
>> when the application is removed, security is removed. The goal here is to
>> deploy a “zero trust” security model. We have deployed a similar
>> architecture very successfully with VMWare’s NSX product, we would now like
>> to figure out how to do it in the open source environment.
>>
>> We would prefer to be transparent to networking “bump in the wire” as
>> this simplifies the interaction between the controller (OVN) and the VNF.
>> The only information that is shared is the logical in and out ports for the
>> VNF. Hence configuration requires less interactions between the networking
>> infrastructure and the VNF/Controller, moving the VNF or application also
>> becomes easier. It becomes a simple API interaction with minimal shared
>> state between OVN and the VNF.
>>
>> Does this make sense, it is just my rough attempt at breaking down the
>> use cases into a more specific set of cases we can solve?
>>
>
> That's a nice breakdown.  I like the focus on the simpler case.  I always
> like when a feature can be broken down into smaller useful iterations.
>
> From an OpenStack POV, I always come back to "what API are we
> implementing?".  You mention that networking-sfc is built in support of
> #1.  Do you think it can also support #2, or do you think another API is
> more appropriate?  If networking-sfc works, are there some reasonable
> limitations we can put in place to get a first version out?
>
> Do you have interest in this functionality in OVN outside of OpenStack?
>
>
>> Also what other use cases should we consider?
>>
>
> There seems to be some industry interest in NSH based SFC.  It's not
> supported by OVS yet, but it should be on our radar.  I suppose it just
> comes back to eventually wanting to support SFC-aware VNFs that expect some
> metadata.
>
> --
> Russell Bryant
>



-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160330/91031f61/attachment-0002.html>