
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I like the definition.<div><br></div><div><br><div apple-content-edited="true">

<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div>PCM (Paul Michali)</div><div><br></div><div>MAIL Е..Е. <a href="mailto:pcm@cisco.com">pcm@cisco.com</a></div><div>IRC ЕЕ..Е pc_m (<a href="http://irc.freenode.com">irc.freenode.com</a>)</div><div>TW ЕЕЕ... @pmichali</div><div>GPG Key Е 4525ECC253E31A83</div><div>Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83</div></div><div><br></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">

</div>

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