On Tue, Nov 18, 2014 at 11:04 PM, henry hly <henry4...@gmail.com> wrote: > Is FWaas L2/3 or L4/7? >
Thats a good question, and what has been asked here in the context of VPNaaS as well. Hence the proposed definition below avoids characterizing the advanced services project purely as L4-7 because that would not be accurate (in the context of any of existing three services, or proposed new services). > On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam > <sumitnaiksa...@gmail.com> wrote: >> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif <mha...@brocade.com> wrote: >>> I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS >>> deals with L3 connectivity but belongs in advanced services. Where does >>> Edge-VPN work belong? We need a broader definition for advanced services >>> area. >>> >> >> So the following definition is being proposed to capture the broader >> context and complement Neutron's current mission statement: >> >> To implement services and associated libraries that provide >> abstractions for advanced network functions beyond basic L2/L3 >> connectivity and forwarding. >> >> What do people think? >> >>> Thanks, >>> —Hanif. >>> >>> From: "Paul Michali (pcm)" <p...@cisco.com> >>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >>> <openstack-dev@lists.openstack.org> >>> Date: Tuesday, November 18, 2014 at 4:08 PM >>> To: "OpenStack Development Mailing List (not for usage questions)" >>> <openstack-dev@lists.openstack.org> >>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into >>> separate repositories >>> >>> On Nov 18, 2014, at 6:36 PM, Armando M. <arma...@gmail.com> wrote: >>> >>> Mark, Kyle, >>> >>> What is the strategy for tracking the progress and all the details about >>> this initiative? Blueprint spec, wiki page, or something else? >>> >>> One thing I personally found useful about the spec approach adopted in [1], >>> was that we could quickly and effectively incorporate community feedback; >>> having said that I am not sure that the same approach makes sense here, >>> hence the question. >>> >>> Also, what happens for experimental efforts that are neither L2-3 nor L4-7 >>> (e.g. TaaS or NFV related ones?), but they may still benefit from this >>> decomposition (as it promotes better separation of responsibilities)? Where >>> would they live? I am not sure we made any particular progress of the >>> incubator project idea that was floated a while back. >>> >>> >>> Would it make sense to define the advanced services repo as being for >>> services that are beyond basic connectivity and routing? For example, VPN >>> can be L2 and L3. Seems like restricting to L4-L7 may cause some confusion >>> as to what’s in and what’s out. >>> >>> >>> Regards, >>> >>> PCM (Paul Michali) >>> >>> MAIL …..…. p...@cisco.com >>> IRC ……..… pc_m (irc.freenode.com) >>> TW ………... @pmichali >>> GPG Key … 4525ECC253E31A83 >>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 >>> >>> >>> >>> Cheers, >>> Armando >>> >>> [1] https://review.openstack.org/#/c/134680/ >>> >>> On 18 November 2014 15:32, Doug Wiegley <do...@a10networks.com> wrote: >>>> >>>> Hi, >>>> >>>> > so the specs repository would continue to be shared during the Kilo >>>> > cycle. >>>> >>>> One of the reasons to split is that these two teams have different >>>> priorities and velocities. Wouldn’t that be easier to track/manage as >>>> separate launchpad projects and specs repos, irrespective of who is >>>> approving them? >>>> >>>> Thanks, >>>> doug >>>> >>>> >>>> >>>> On Nov 18, 2014, at 10:31 PM, Mark McClain <m...@mcclain.xyz> wrote: >>>> >>>> All- >>>> >>>> Over the last several months, the members of the Networking Program have >>>> been discussing ways to improve the management of our program. When the >>>> Quantum project was initially launched, we envisioned a combined service >>>> that included all things network related. This vision served us well in >>>> the >>>> early days as the team mostly focused on building out layers 2 and 3; >>>> however, we’ve run into growth challenges as the project started building >>>> out layers 4 through 7. Initially, we thought that development would float >>>> across all layers of the networking stack, but the reality is that the >>>> development concentrates around either layer 2 and 3 or layers 4 through 7. >>>> In the last few cycles, we’ve also discovered that these concentrations >>>> have >>>> different velocities and a single core team forces one to match the other >>>> to >>>> the detriment of the one forced to slow down. >>>> >>>> Going forward we want to divide the Neutron repository into two separate >>>> repositories lead by a common Networking PTL. The current mission of the >>>> program will remain unchanged [1]. The split would be as follows: >>>> >>>> Neutron (Layer 2 and 3) >>>> - Provides REST service and technology agnostic abstractions for layer 2 >>>> and layer 3 services. >>>> >>>> Neutron Advanced Services Library (Layers 4 through 7) >>>> - A python library which is co-released with Neutron >>>> - The advance service library provides controllers that can be configured >>>> to manage the abstractions for layer 4 through 7 services. >>>> >>>> Mechanics of the split: >>>> - Both repositories are members of the same program, so the specs >>>> repository would continue to be shared during the Kilo cycle. The PTL and >>>> the drivers team will retain approval responsibilities they now share. >>>> - The split would occur around Kilo-1 (subject to coordination of the >>>> Infra and Networking teams). The timing is designed to enable the proposed >>>> REST changes to land around the time of the December development sprint. >>>> - The core team for each repository will be determined and proposed by >>>> Kyle Mestery for approval by the current core team. >>>> - The Neutron Server and the Neutron Adv Services Library would be >>>> co-gated to ensure that incompatibilities are not introduced. >>>> - The Advance Service Library would be an optional dependency of Neutron, >>>> so integrated cross-project checks would not be required to enable it >>>> during >>>> testing. >>>> - The split should not adversely impact operators and the Networking >>>> program should maintain standard OpenStack compatibility and deprecation >>>> cycles. >>>> >>>> This proposal to divide into two repositories achieved a strong consensus >>>> at the recent Paris Design Summit and it does not conflict with the current >>>> governance model or any proposals circulating as part of the ‘Big Tent’ >>>> discussion. >>>> >>>> Kyle and mark >>>> >>>> [1] >>>> https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev