Open Stack

Not quite. Two segments with different segmentation types can just co-exist
'for free' right now. There is no automated encapsulation translator thing
that connects them together at this time. There is of course the question
of whether or not that part will be merged anytime soon, but that's a
different discussion.

On Tue, Feb 24, 2015 at 1:47 AM, Salvatore Orlando <sorlando at nicira.com>
wrote:

> On 24 February 2015 at 10:36, Kevin Benton <blak111 at gmail.com> wrote:
>
>> Even ignoring integration with other VXLAN based drivers inside of a
>> segment, using ML2 can allow someone to run a network with a mix of
>> segments using different segmentation types. As long as the OVN driver
>> understands which ports it is capable of binding, it can coexist with other
>> drivers and allow heterogenous setups 'for free'.
>>
>
> It seems you're suggesting that ML2 is now able to integrate heterogenous
> segments even when the drivers interfacing with their respective backends
> ignore each other. In other words I can have a network with a segment
> speaking VLANs and managed by driver "A", another segment speaking VxLAN
> managed by driver "B", with ML2 providing you "for free" connectivity
> between these two segment, thus achieving the heterogenous setup you were
> mentioning.
>
> I was unaware that such support was now available in ML2. In that case any
> non-ML2 choice is probably a no brainer.
>
>
>>
>> On Tue, Feb 24, 2015 at 1:19 AM, Salvatore Orlando <sorlando at nicira.com>
>> wrote:
>>
>>> On 24 February 2015 at 01:34, Kyle Mestery <mestery at mestery.com> wrote:
>>>
>>>> Russel and I have already merged the initial ML2 skeleton driver [1].
>>>>
>>> The thinking is that we can always revert to a non-ML2 driver if needed.
>>>>
>>>
>>> If nothing else an authoritative decision on a design direction saves us
>>> the hassle of going through iterations and discussions.
>>> The integration through ML2 is definitely viable. My opinion however is
>>> that since OVN implements a full control plane, the control plane bits
>>> provided by ML2 are not necessary, and a plugin which provides only
>>> management layer capabilities might be the best solution. Note: this does
>>> not mean it has to be monolithic. We can still do L3 with a service plugin.
>>> However, since the same kind of approach has been adopted for ODL I
>>> guess this provides some sort of validation.
>>>
>>>
>>>> I'm not sure how useful having using OVN with other drivers will be,
>>>> and that was my initial concern with doing ML2 vs. full plugin. With the HW
>>>> VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
>>>> this is where we're at for now. Comments welcome, of course.
>>>>
>>>
>>> That was also kind of my point regarding the control plane bits provided
>>> by ML2 which OVN does not need. Still, the fact that we do not use a
>>> function does not make any harm.
>>> Also i'm not sure if OVN needs at all a type manager. If not, we can
>>> always implement a no-op type manager, I guess.
>>>
>>> Salvatore
>>>
>>>
>>>>
>>>> Thanks,
>>>> Kyle
>>>>
>>>> [1] https://github.com/stackforge/networking-ovn
>>>>
>>>> On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton <blak111 at gmail.com>
>>>> wrote:
>>>>
>>>>> I want to emphasize Salvatore's last two points a bit more. If you go
>>>>> with a monolithic plugin, you eliminate the possibility of heterogenous
>>>>> deployments.
>>>>>
>>>>> One example of this that is common now is having the current OVS
>>>>> driver responsible for setting up the vswitch and then having a ToR driver
>>>>> (e.g. Big Switch, Arista, etc) responsible for setting up the fabric.
>>>>> Additionally, there is a separate L3 plugin (e.g. the reference one,
>>>>> Vyatta, etc) for providing routing.
>>>>>
>>>>> I suppose with an overlay it's easier to take the route that you don't
>>>>> want to be compatible with other networking stuff at the Neutron layer
>>>>> (e.g. integration with the 3rd parties is orchestrated somewhere else). In
>>>>> that case, the above scenario wouldn't make much sense to support, but it's
>>>>> worth keeping in mind.
>>>>>
>>>>> On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando <
>>>>> sorlando at nicira.com> wrote:
>>>>>
>>>>>> I think there are a few factors which influence the ML2 driver vs
>>>>>> "monolithic" plugin debate, and they mostly depend on OVN rather than
>>>>>> Neutron.
>>>>>> From a Neutron perspective both plugins and drivers (as long at they
>>>>>> live in their own tree) will be supported in the foreseeable future. If a
>>>>>> ML2 mech driver is not the best option for OVN that would be ok - I don't
>>>>>> think the Neutron community advices development of a ML2 driver as the
>>>>>> preferred way for integrating with new backends.
>>>>>>
>>>>>> The ML2 framework provides a long list of benefits that mechanism
>>>>>> driver developer can leverage.
>>>>>> Among those:
>>>>>> - The ability of leveraging Type drivers which relieves driver
>>>>>> developers from dealing with network segment allocation
>>>>>> - Post-commit and (for most operations) pre-commit hooks for
>>>>>> performing operation on the backend
>>>>>> - The ability to leverage some of the features offered by Neutron's
>>>>>> built-in control-plane such as L2-population
>>>>>> - A flexible mechanism for enabling driver-specific API extensions
>>>>>> - Promotes modular development and integration with higher-layer
>>>>>> services, such as L3. For instance OVN could provide the L2 support for
>>>>>> Neutron's built-in L3 control plane
>>>>>> - The (potential afaict) ability of interacting with other mechanism
>>>>>> driver such as those operating on physical appliances on the data center
>>>>>> - <add your benefit here>
>>>>>>
>>>>>> In my opinion OVN developers should look at ML2 benefits, and check
>>>>>> which ones apply to this specific platform. I'd say that if there are 1 or
>>>>>> 2 checks in the above list, maybe it would be the case to look at
>>>>>> developing a ML2 mechanism driver, and perhaps a L3 service plugin.
>>>>>> It is worth nothing that ML2, thanks to its type and mechanism driver
>>>>>> provides also some control plane capabilities. If those capabilities are
>>>>>> however on OVN's roadmap it might be instead worth looking at a
>>>>>> "monolithic" plugin, which can also be easily implemented by inheriting
>>>>>> from neutron.db.db_base_plugin_v2.NeutronDbPluginV2, and then adding all
>>>>>> the python mixins for the extensions the plugin needs to support.
>>>>>>
>>>>>> Salvatore
>>>>>>
>>>>>>
>>>>>> On 23 February 2015 at 18:32, Ben Pfaff <blp at nicira.com> wrote:
>>>>>>
>>>>>>> [branching off a discussion on ovs-dev at this point:
>>>>>>> http://openvswitch.org/pipermail/dev/2015-February/051609.html]
>>>>>>>
>>>>>>> On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery <mestery at mestery.com>
>>>>>>> wrote:
>>>>>>> > One thing to keep in mind, this ties somewhat into my response to
>>>>>>> Russell
>>>>>>> > earlier on the decision around ML2 vs. core plugin. If we do ML2,
>>>>>>> there are
>>>>>>> > type drivers for VLAN, VXLAN, and GRE tunnels. There is no
>>>>>>> TypeDriver for
>>>>>>> > STT tunnels upstream now. It's just an item we need on the TODO
>>>>>>> list if we
>>>>>>> > go down the STT tunnel path.
>>>>>>>
>>>>>>> It was suggested to me off-list that this part of the discussion
>>>>>>> should be on
>>>>>>> openstack-dev, so here it is ;-)
>>>>>>>
>>>>>>>
>>>>>>> __________________________________________________________________________
>>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>>> Unsubscribe:
>>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Kevin Benton
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/65771e90/attachment.html>