Re: [openstack-dev] [neutron][l2-gateway] Added Ricardo Noriega to the core team

[Emilien Macchi]

On Wed, Jul 19, 2017 at 9:15 AM, Alex Schultz  wrote:

>
>
> On Wed, Jul 19, 2017 at 9:58 AM, Ricardo Noriega De Soto <
> rnori...@redhat.com> wrote:
>
>> Thanks Gary for the opportunity! We'll keep fighting! :-)
>>
>>
> Congrats. Your efforts in the puppet openstack repos to also get this
> properly supported and tested have also been very appreciated.
>

ditto in tripleo :-)


> Thanks,
> -Alex
>
>
>> On Wed, Jul 19, 2017 at 8:52 AM, Gary Kotton  wrote:
>>
>>> Hi,
>>>
>>> Over the last few months Ricardo Noriega has been making many
>>> contributions to the project and has actually helped get it to the stage
>>> where it’s a lot healthier than before ☺. I am adding him to the core
>>> team.
>>>
>>> Congratulations!
>>>
>>> A luta continua
>>>
>>> Gary
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Ricardo Noriega
>>
>> Senior Software Engineer - NFV Partner Engineer | Office of Technology
>>  | Red Hat
>> irc: rnoriega @freenode
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][l2-gateway] Added Ricardo Noriega to the core team

[Alex Schultz]

On Wed, Jul 19, 2017 at 9:58 AM, Ricardo Noriega De Soto <
rnori...@redhat.com> wrote:

> Thanks Gary for the opportunity! We'll keep fighting! :-)
>
>
Congrats. Your efforts in the puppet openstack repos to also get this
properly supported and tested have also been very appreciated.

Thanks,
-Alex


> On Wed, Jul 19, 2017 at 8:52 AM, Gary Kotton  wrote:
>
>> Hi,
>>
>> Over the last few months Ricardo Noriega has been making many
>> contributions to the project and has actually helped get it to the stage
>> where it’s a lot healthier than before ☺. I am adding him to the core
>> team.
>>
>> Congratulations!
>>
>> A luta continua
>>
>> Gary
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][l2-gateway] Added Ricardo Noriega to the core team

[Ricardo Noriega De Soto]

Thanks Gary for the opportunity! We'll keep fighting! :-)

On Wed, Jul 19, 2017 at 8:52 AM, Gary Kotton  wrote:

> Hi,
>
> Over the last few months Ricardo Noriega has been making many
> contributions to the project and has actually helped get it to the stage
> where it’s a lot healthier than before ☺. I am adding him to the core
> team.
>
> Congratulations!
>
> A luta continua
>
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][l2-gateway] Added Ricardo Noriega to the core team

[Gary Kotton]

Hi,
Over the last few months Ricardo Noriega has been making many contributions to 
the project and has actually helped get it to the stage where it’s a lot 
healthier than before ☺. I am adding him to the core team.
Congratulations!
A luta continua
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][L2 Gateway] No meeting on July 4th

[Sukhdev Kapur]

Folks,

Due the US holiday on 4th of July, there will be no meeting for L2 Gateway.

The channel will be available for anybody to use, should you need to
discuss anything during the meeting's time slot.

Happy 4th..

-Sukhdev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][L2 Gateway]

[Sukhdev Kapur]

Folks,

Due to holiday on Monday in USA, there will be no L2 Gateway meeting on
February 15.

Feel free to use the channel for any discussions that you would want to
carry during that hour.

Thanks
-Sukhdev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][l2-gateway] Kindly ask for review for this RFE

[joehuang]

Hello,

This RFE[1] “extend l2gw api to support multi-site connectivity” needs review 
after it’s registered several weeks ago.

There are several projects looking forward for the feature of extending L2 
network across Neutron, or say, across sites.
For example: OPNFV multisite[2]: VNF(Telecom Application) high availability 
across OpenStack ( VIM in NFV terms). Another way of implementation is proposed 
in Neutron[3], but Neutron suggested to move this to L2GW sub-project. 
Tricircle also has expectation on the cross OpenStack networking via VxLAN [4]

[1] RFE: https://bugs.launchpad.net/networking-l2gw/+bug/1529863
[2] OPNFV multisite requirement  
https://git.opnfv.org/cgit/multisite/tree/docs/requirements/VNF_high_availability_across_VIM.rst
[3] RFE in Neutron https://bugs.launchpad.net/neutron/+bug/1484005
[4] Tricircle requirement: 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g

Best Regards
Chaoyi Huang ( Joe Huang )

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Thursday, January 14, 2016 3:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive



From: "Armando M." mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 12, 2016 at 8:57 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive



On 12 January 2016 at 09:21, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Here is an example of a patch that was posted 5 weeks ago. - 
https://review.openstack.org/#/c/254816/
That is a pretty long time for something that is trivial

5 weeks is bad but not the end of the world. We all have patches sitting idle 
in the queues of various projects.

[Gary] I have patches in other project for over 10 months … Thanks for 
addressing the concerns and reviewing the patches


From: "Vasudevan, Swaminathan (PNB Roseville)" 
mailto:swaminathan.vasude...@hpe.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 12, 2016 at 6:11 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Hi Gary,
I think it is still active.
What are your concerns, I can talk to the team.
Thanks
Swami

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, January 12, 2016 6:14 AM
To: OpenStack List
Subject: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Its like a desert out here trying to get a review…

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

[Gary Kotton]

From: "Armando M." mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 12, 2016 at 8:57 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive



On 12 January 2016 at 09:21, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Here is an example of a patch that was posted 5 weeks ago. - 
https://review.openstack.org/#/c/254816/
That is a pretty long time for something that is trivial

5 weeks is bad but not the end of the world. We all have patches sitting idle 
in the queues of various projects.

[Gary] I have patches in other project for over 10 months … Thanks for 
addressing the concerns and reviewing the patches


From: "Vasudevan, Swaminathan (PNB Roseville)" 
mailto:swaminathan.vasude...@hpe.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 12, 2016 at 6:11 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Hi Gary,
I think it is still active.
What are your concerns, I can talk to the team.
Thanks
Swami

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, January 12, 2016 6:14 AM
To: OpenStack List
Subject: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Its like a desert out here trying to get a review…

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

[Armando M.]

On 12 January 2016 at 09:21, Gary Kotton  wrote:

> Here is an example of a patch that was posted 5 weeks ago. -
> https://review.openstack.org/#/c/254816/
> That is a pretty long time for something that is trivial
>

5 weeks is bad but not the end of the world. We all have patches sitting
idle in the queues of various projects.


>
> From: "Vasudevan, Swaminathan (PNB Roseville)" <
> swaminathan.vasude...@hpe.com>
> Reply-To: OpenStack List 
> Date: Tuesday, January 12, 2016 at 6:11 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive
>
> Hi Gary,
>
> I think it is still active.
>
> What are your concerns, I can talk to the team.
>
> Thanks
>
> Swami
>
>
>
> *From:* Gary Kotton [mailto:gkot...@vmware.com ]
> *Sent:* Tuesday, January 12, 2016 6:14 AM
> *To:* OpenStack List
> *Subject:* [openstack-dev] [Neutron]{l2-gateway] is this project alive
>
>
>
> Its like a desert out here trying to get a review…
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

[Gary Kotton]

Here is an example of a patch that was posted 5 weeks ago. - 
https://review.openstack.org/#/c/254816/
That is a pretty long time for something that is trivial

From: "Vasudevan, Swaminathan (PNB Roseville)" 
mailto:swaminathan.vasude...@hpe.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 12, 2016 at 6:11 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Hi Gary,
I think it is still active.
What are your concerns, I can talk to the team.
Thanks
Swami

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, January 12, 2016 6:14 AM
To: OpenStack List
Subject: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Its like a desert out here trying to get a review...
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

[Armando M.]

On 12 January 2016 at 06:14, Gary Kotton  wrote:

> Its like a desert out here trying to get a review…
>

There was a patch that was meant to unwedge a few things. I wouldn't say
it's a desert, things are still slow after the holidays.


>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Gary,
I think it is still active.
What are your concerns, I can talk to the team.
Thanks
Swami

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, January 12, 2016 6:14 AM
To: OpenStack List
Subject: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Its like a desert out here trying to get a review…
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron]{l2-gateway] is this project alive

[Gary Kotton]

Its like a desert out here trying to get a review…
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 gateway project

[Sukhdev Kapur]

Hey Kyle,

We are down to couple of patches that are awaiting approval/merge. As soon
as it is done, I will let you know.

Thanks
-Sukhdev


On Fri, Oct 9, 2015 at 9:39 AM, Kyle Mestery  wrote:

> On Fri, Oct 9, 2015 at 10:13 AM, Gary Kotton  wrote:
>
>> Hi,
>> Who will be creating the stable/liberty branch?
>> Thanks
>> Gary
>>
>>
> I'll be doing this once someone from the L2GW team lets me know a commit
> SHA to create it from.
>
> Thanks,
> Kyle
>
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 gateway project

[Kyle Mestery]

On Fri, Oct 9, 2015 at 10:13 AM, Gary Kotton  wrote:

> Hi,
> Who will be creating the stable/liberty branch?
> Thanks
> Gary
>
>
I'll be doing this once someone from the L2GW team lets me know a commit
SHA to create it from.

Thanks,
Kyle


> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] L2 gateway project

[Gary Kotton]

Hi,
Who will be creating the stable/liberty branch?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] L2 Gateway API released

[Sukhdev Kapur]

Folks,

L2 Gateway team is pleased to announce the release of L2 Gateway API. This
API can be downloaded from [1]

If you plan on attending OpenStack summit in Vancouver next week, please
attend presentation [2] to find more details about this feature.
If you are not able to attend the summit, be sure to watch the recording
this presentation on openstack.org after the summit.

Be sure check out the L2 Gateway wiki [3] for more information. L2 Gateway
can be deployed by using devstack. Please follow steps described at [4] to
install L2 Gateway using devstack.

L2 Gateway team meets on alternate mondays at 1700 UTC at
#openstack-meeting-4. If you would like to contribute or want to join us to
understand the details, The next meeting is scheduled on June 8th. The
meeting agenda and details are available at [5].

Thanks
-Sukhdev


[1] https://pypi.python.org/pypi/networking-l2gw/2015.1.1
[2]
https://openstacksummitmay2015vancouver.sched.org/event/7ed8f0119a9ad52ae50e32c752bbf9ed#.VVWSX9pVhHw
[3] https://wiki.openstack.org/wiki/Neutron/L2-GW
[4]
https://wiki.openstack.org/wiki/Neutron/L2-GW#L2_gateway_setup_using_devstack
[5] https://wiki.openstack.org/wiki/Meetings/L2Gateway
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][L2-Gateway] l2-gateway-connection-create problems

[Daniel Depaoli]

Hi all.
I'm interesting in L2 gateway project.
For a testing purpose I've installed a devstack in a VirtualBox
environment. My objective is to use L2 gateway to connect a virtual machine
in openstack with a virtual machine in Virtualbox.
I created a virtual gateway with "neutron-l2gw l2-gateway-create gw1
--device name='7aec3b21ea4b,interface_names=port1;port2'" where
7aec3b21ea4b is the datapath id of br-ex bridge.
Then creating a new connection with command "neutron-l2gw
l2-gateway-connection-create gw1 private --default-segmentation-id=100". I
obtained this error: "L2 Gateway Device 7aec3b21ea4b could not be
found."
I tried then many others configuration, without success and with the same
error. The problem is that I don't understand what is the correct settings
for --device option.

Should you explain me what I have to set for device for my case?

Thanks

-- 

Daniel Depaoli
CREATE-NET Research Center
Smart Infrastructures Area
Junior Research Engineer

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron[[L2-Gateway] No meeting this week due to USA holiday

[Sukhdev Kapur]

Folks,

We are canceling the meeting on Monday (2/16/2015) due to USA holiday. The
meeting will take place the following week Monday (2/23/2015).
The agenda for next week's meeting will be posted at -
https://wiki.openstack.org/wiki/Meetings/L2Gateway


Thanks
-Sukhdev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2-Gateway] Meetings announcement

[Sukhdev Kapur]

Hi Ian,

I do not have one definition per se for the L2 gateway. Every use case
tends to define it in differently :-).  The desire (and goal) is to come up
with "an" API within Kilo cycle, upon which folks can start to build their
use cases, and (hopefully) iteratively come up with an API which covers
most, if not all, use cases.

For past few cycles (going all the way back to Hong Kong summit), we have
been discussing about this API, but, have not been able to converge.

During Paris summit (in the pods), a reasonable number of vendors
participated in the discussion to build upon the proposal made my Maruti
(from HP) to come up with the a "starting point" for this API. Maruti and
Armando (along with others) have been iterating over the spec proposed by
Maruti ( I posted the link on the wiki).

We felt, it is about time that we get together in a regular meeting form to
discuss as to what we have have so far and see how we can make it reality
for Kilo cycle. I realize that this may not fill all the bills. Once we
have a working version, we can alway build upon it and bring in more and
more use case as we move forward.

Please join us on IRC on this Monday and share your wisdom with other
members.

-Sukhdev


On Jan 4, 2015 2:08 AM, "Kevin Benton"  wrote:

> Weasels
>
> On Sat, Jan 3, 2015 at 2:57 PM, Ian Wells  wrote:
>
>> Sukhdev,
>>
>> Since the term is quite broad and has meant many things in the past, can
>> you define what you're thinking of when you say 'L2 gateway'?
>>
>> Cheers,
>> --
>> Ian.
>>
>> On 2 January 2015 at 18:28, Sukhdev Kapur  wrote:
>>
>>> Hi all,
>>>
>>> HAPPY NEW YEAR.
>>>
>>> Starting Monday (Jan 5th, 2015) we will be kicking of bi-weekly meetings
>>> for L2 Gateway discussions.
>>>
>>> We are hoping to come up with an initial version of L2 Gateway API in
>>> Kilo cycle. The intent of these bi-weekly meetings is to discuss issues
>>> related to L2 Gateway API.
>>>
>>> Anybody interested in this topic is invited to join us in these meetings
>>> and share your wisdom with the similar minded members.
>>>
>>> Here is the details of these meetings:
>>>
>>> https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting
>>>
>>> I have put together a wiki for this project. Next week is the initial
>>> meeting and the agenda is pretty much open. We will give introduction of
>>> the members of the team as well the progress made so far on this topic. If
>>> you would like to add anything to the agenda, feel free to update the
>>> agenda at the following wiki:
>>>
>>> https://wiki.openstack.org/wiki/Meetings/L2Gateway
>>>
>>> Look forward to on the IRC.
>>>
>>> -Sukhdev
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> ___
> 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

Re: [openstack-dev] [Neutron][L2-Gateway] Meetings announcement

[Kevin Benton]

Weasels

On Sat, Jan 3, 2015 at 2:57 PM, Ian Wells  wrote:

> Sukhdev,
>
> Since the term is quite broad and has meant many things in the past, can
> you define what you're thinking of when you say 'L2 gateway'?
>
> Cheers,
> --
> Ian.
>
> On 2 January 2015 at 18:28, Sukhdev Kapur  wrote:
>
>> Hi all,
>>
>> HAPPY NEW YEAR.
>>
>> Starting Monday (Jan 5th, 2015) we will be kicking of bi-weekly meetings
>> for L2 Gateway discussions.
>>
>> We are hoping to come up with an initial version of L2 Gateway API in
>> Kilo cycle. The intent of these bi-weekly meetings is to discuss issues
>> related to L2 Gateway API.
>>
>> Anybody interested in this topic is invited to join us in these meetings
>> and share your wisdom with the similar minded members.
>>
>> Here is the details of these meetings:
>>
>> https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting
>>
>> I have put together a wiki for this project. Next week is the initial
>> meeting and the agenda is pretty much open. We will give introduction of
>> the members of the team as well the progress made so far on this topic. If
>> you would like to add anything to the agenda, feel free to update the
>> agenda at the following wiki:
>>
>> https://wiki.openstack.org/wiki/Meetings/L2Gateway
>>
>> Look forward to on the IRC.
>>
>> -Sukhdev
>>
>>
>>
>> ___
>> 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
>
>


-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L2-Gateway] Meetings announcement

[Ian Wells]

Sukhdev,

Since the term is quite broad and has meant many things in the past, can
you define what you're thinking of when you say 'L2 gateway'?

Cheers,
-- 
Ian.

On 2 January 2015 at 18:28, Sukhdev Kapur  wrote:

> Hi all,
>
> HAPPY NEW YEAR.
>
> Starting Monday (Jan 5th, 2015) we will be kicking of bi-weekly meetings
> for L2 Gateway discussions.
>
> We are hoping to come up with an initial version of L2 Gateway API in Kilo
> cycle. The intent of these bi-weekly meetings is to discuss issues related
> to L2 Gateway API.
>
> Anybody interested in this topic is invited to join us in these meetings
> and share your wisdom with the similar minded members.
>
> Here is the details of these meetings:
>
> https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting
>
> I have put together a wiki for this project. Next week is the initial
> meeting and the agenda is pretty much open. We will give introduction of
> the members of the team as well the progress made so far on this topic. If
> you would like to add anything to the agenda, feel free to update the
> agenda at the following wiki:
>
> https://wiki.openstack.org/wiki/Meetings/L2Gateway
>
> Look forward to on the IRC.
>
> -Sukhdev
>
>
>
> ___
> 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] [Neutron][L2-Gateway] Meetings announcement

[Sukhdev Kapur]

Hi all,

HAPPY NEW YEAR.

Starting Monday (Jan 5th, 2015) we will be kicking of bi-weekly meetings
for L2 Gateway discussions.

We are hoping to come up with an initial version of L2 Gateway API in Kilo
cycle. The intent of these bi-weekly meetings is to discuss issues related
to L2 Gateway API.

Anybody interested in this topic is invited to join us in these meetings
and share your wisdom with the similar minded members.

Here is the details of these meetings:

https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting

I have put together a wiki for this project. Next week is the initial
meeting and the agenda is pretty much open. We will give introduction of
the members of the team as well the progress made so far on this topic. If
you would like to add anything to the agenda, feel free to update the
agenda at the following wiki:

https://wiki.openstack.org/wiki/Meetings/L2Gateway

Look forward to on the IRC.

-Sukhdev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] L2 gateway as a service

[Armando M.]

On 20 November 2014 02:08, Salvatore Orlando  wrote:

>
>
> On 20 November 2014 02:19, Sukhdev Kapur  wrote:
>
>> Folks,
>>
>> Like Ian, I am jumping in this very late as well - as I decided to travel
>> Europe after the summit, just returned back and  catching up :-):-)
>>
>> I have noticed that this thread has gotten fairly convoluted and painful
>> to read.
>>
>> I think Armando summed it up well in the beginning of the thread. There
>> are basically three written proposals (listed in Armando's email - I pasted
>> them again here).
>>
>> [1] https://review.openstack.org/#/c/134179/
>> [2] https://review.openstack.org/#/c/100278/
>> [3] https://review.openstack.org/#/c/93613/
>>
>>
> In this thread I have seen other specs being mentioned as "related".
> Namely:
> 1) https://review.openstack.org/#/c/93329/ (BGP VPN)
> 2) https://review.openstack.org/#/c/101043/ (MPLS vpn)
> 3) https://review.openstack.org/#/c/87825/ (external device integration)
> Note that I am not saying they should be put as well in the mix. I'm only
> listing them here as a "recap".
> There are probably other "ideas" not yet put in the form of a concrete
> specification. In order to avoid further confusion, I would just blindly
> ignore proposals which do not exist in the form a specification.
>

Ah, I know what you're trying to do here...I am not gonna fall into your
trap :)


>
>
>
>> On this thread I see that the authors of first two proposals have already
>> agreed to consolidate and work together. This leaves with two proposals.
>> Both Ian and I were involved with the third proposal [3] and have
>> reasonable idea about it. IMO, the use cases addressed by the third
>> proposal are very similar to use cases addressed by proposal [1] and [2]. I
>> can volunteer to  follow up with Racha and Stephen from Ericsson to see if
>> their use case will be covered with the new combined proposal. If yes, we
>> have one converged proposal. If no, then we modify the proposal to
>> accommodate their use case as well. Regardless, I will ask them to review
>> and post their comments on [1].
>>
>
> One thing that I've noticed in the past is that contributors are led to
> think that the owner of the specification will also be the lead for the
> subsequent work. There nothing farther from truth. Sometimes I write specs
> with the exact intent of having somebody else lead the implementation. So
> don't feel bad to abandon a spec if you realize your use cases can be
> completely included in another specification.
>

Stating the obvious, but yes point taken!


>
>
>>
>> Having said that, this covers what we discussed during the morning
>> session on Friday in Paris. Now, comes the second part which Ian brought up
>> in the afternoon session on Friday.
>> My initial reaction was, when heard his use case, that this new
>> proposal/API should cover that use case as well (I am being bit optimistic
>> here :-)). If not, rather than going into the nitty gritty details of the
>> use case, let's see what modification is required to the proposed API to
>> accommodate Ian's use case and adjust it accordingly.
>>
>
> Unfortunately I did not attend that discussion. Possibly 90% of the people
> reading this thread did not attend it. It would be nice if Ian or somebody
> else posted a write-up, adding more details to what has already been shared
> in this thread. If you've already done so please share a link as my
> google-fu is not that good these days.
>
>
>>
>> Now, the last point (already brought up by Salvatore as well as Armando)
>> - the abstraction of the API, so that it meets the Neutron API criteria. I
>> think this is the critical piece. I also believe the API proposed by [1] is
>> very close. We should clean it up and take out references to ToR's or
>> physical vs virtual devices. The API should work at an abstract level so
>> that it can deal with both physical as well virtual devices. If we can
>> agree to that, I believe we can have a solid solution.
>>
>
>> Having said that I would like to request the community to review the
>> proposal submitted by Maruti in [1] and post comments on the spec with the
>> intent to get a closure on the API. I see lots of good comments already on
>> the spec. Lets get this done so that we can have a workable (even if not
>> perfect) version of API in Kilo cycle. Something which we can all start to
>> play with. We can always iterate over it, and make change as we get more
>> and more use cases covered.
>>
>
> "Iterate" is the key here I believe. As long as we pretend to achieve the
> perfect API at the first attempt we'll just keep having this discussion. I
> think the first time a L2 GW API was proposed, it was for Grizzly.
> For instance, it might relatively easy to define an API which can handle
> both physical and virtual devices. The user workflow for a ToR terminated
> L2 GW is different from the workflow for a virtual appliance owned by
> tenant, and this will obviously reflected in the API. On the other hand, a

Re: [openstack-dev] [neutron] L2 gateway as a service

[Armando M.]

Hi Sukhdev,

Hope you enjoyed Europe ;)

On 19 November 2014 17:19, Sukhdev Kapur  wrote:

> Folks,
>
> Like Ian, I am jumping in this very late as well - as I decided to travel
> Europe after the summit, just returned back and  catching up :-):-)
>
> I have noticed that this thread has gotten fairly convoluted and painful
> to read.
>
> I think Armando summed it up well in the beginning of the thread. There
> are basically three written proposals (listed in Armando's email - I pasted
> them again here).
>
> [1] https://review.openstack.org/#/c/134179/
> [2] https://review.openstack.org/#/c/100278/
> [3] https://review.openstack.org/#/c/93613/
>
> On this thread I see that the authors of first two proposals have already
> agreed to consolidate and work together. This leaves with two proposals.
> Both Ian and I were involved with the third proposal [3] and have
> reasonable idea about it. IMO, the use cases addressed by the third
> proposal are very similar to use cases addressed by proposal [1] and [2]. I
> can volunteer to  follow up with Racha and Stephen from Ericsson to see if
> their use case will be covered with the new combined proposal. If yes, we
> have one converged proposal. If no, then we modify the proposal to
> accommodate their use case as well. Regardless, I will ask them to review
> and post their comments on [1].
>
> Having said that, this covers what we discussed during the morning session
> on Friday in Paris. Now, comes the second part which Ian brought up in the
> afternoon session on Friday.
> My initial reaction was, when heard his use case, that this new
> proposal/API should cover that use case as well (I am being bit optimistic
> here :-)). If not, rather than going into the nitty gritty details of the
> use case, let's see what modification is required to the proposed API to
> accommodate Ian's use case and adjust it accordingly.
>
> Now, the last point (already brought up by Salvatore as well as Armando) -
> the abstraction of the API, so that it meets the Neutron API criteria. I
> think this is the critical piece. I also believe the API proposed by [1] is
> very close. We should clean it up and take out references to ToR's or
> physical vs virtual devices. The API should work at an abstract level so
> that it can deal with both physical as well virtual devices. If we can
> agree to that, I believe we can have a solid solution.
>

Yes, I do think that the same API can target both: a 100% software solution
for L2GW as well as one that may want to rely on hardware support, in the
same spirit of any other Neutron API. I made the same point on spec [1].


>
>
> Having said that I would like to request the community to review the
> proposal submitted by Maruti in [1] and post comments on the spec with the
> intent to get a closure on the API. I see lots of good comments already on
> the spec. Lets get this done so that we can have a workable (even if not
> perfect) version of API in Kilo cycle. Something which we can all start to
> play with. We can always iterate over it, and make change as we get more
> and more use cases covered.
>

So far it seems like proposal [1] that has the most momentum. I'd like to
consider [3] as one potential software implementation of the proposed API.
As I mentioned earlier, I'd rather start with a well defined problem, free
of any potential confusion or open to subjective interpretation; a loose
API suffers from both pitfalls, hence my suggestion to go with API proposed
in [1].


>
> Make sense?
>
> cheers..
> -Sukhdev
>
>
> On Tue, Nov 18, 2014 at 6:44 PM, Armando M.  wrote:
>
>> Hi,
>>
>> On 18 November 2014 16:22, Ian Wells  wrote:
>>
>>> Sorry I'm a bit late to this, but that's what you get from being on
>>> holiday...  (Which is also why there are no new MTU and VLAN specs yet, but
>>> I swear I'll get to them.)
>>>
>>
>> Ah! I hope it was good at least :)
>>
>>
>>>
>>> On 17 November 2014 01:13, Mathieu Rohon 
>>> wrote:
>>>
 Hi

 On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
 > Last Friday I recall we had two discussions around this topic. One in
 the
 > morning, which I think led to Maruti to push [1]. The way I
 understood [1]
 > was that it is an attempt at unifying [2] and [3], by choosing the API
 > approach of one and the architectural approach of the other.
 >
 > [1] https://review.openstack.org/#/c/134179/
 > [2] https://review.openstack.org/#/c/100278/
 > [3] https://review.openstack.org/#/c/93613/
 >
 > Then there was another discussion in the afternoon, but I am not 100%
 of the
 > outcome.

 Me neither, that's why I'd like ian, who led this discussion, to sum
 up the outcome from its point of view.

>>>
>>> So, the gist of what I said is that we have three, independent, use
>>> cases:
>>>
>>> - connecting two VMs that like to tag packets to each other (VLAN clean
>>> networks)
>>> - connecting many networks to a single VM (trunking ports)
>>> -

Re: [openstack-dev] [neutron] L2 gateway as a service

[Ian Wells]

On 19 November 2014 17:19, Sukhdev Kapur  wrote:

> Folks,
>
> Like Ian, I am jumping in this very late as well - as I decided to travel
> Europe after the summit, just returned back and  catching up :-):-)
>
> I have noticed that this thread has gotten fairly convoluted and painful
> to read.
>
> I think Armando summed it up well in the beginning of the thread. There
> are basically three written proposals (listed in Armando's email - I pasted
> them again here).
>
> [1] https://review.openstack.org/#/c/134179/
> [2] https://review.openstack.org/#/c/100278/
> [3] https://review.openstack.org/#/c/93613/
>
> On this thread I see that the authors of first two proposals have already
> agreed to consolidate and work together. This leaves with two proposals.
> Both Ian and I were involved with the third proposal [3] and have
> reasonable idea about it. IMO, the use cases addressed by the third
> proposal are very similar to use cases addressed by proposal [1] and [2]. I
> can volunteer to  follow up with Racha and Stephen from Ericsson to see if
> their use case will be covered with the new combined proposal. If yes, we
> have one converged proposal. If no, then we modify the proposal to
> accommodate their use case as well. Regardless, I will ask them to review
> and post their comments on [1].
>
> Having said that, this covers what we discussed during the morning session
> on Friday in Paris. Now, comes the second part which Ian brought up in the
> afternoon session on Friday.
> My initial reaction was, when heard his use case, that this new
> proposal/API should cover that use case as well (I am being bit optimistic
> here :-)). If not, rather than going into the nitty gritty details of the
> use case, let's see what modification is required to the proposed API to
> accommodate Ian's use case and adjust it accordingly.
>

As far as I can see, the question of whether you mark a network as 'edge'
and therefore bridged to something you don't know about (my proposal) or
whether you attach a block to it that, behinds the scenes, bridges to
something you don't know about (Maruti's, if you take out all of the
details of *what* is being attached to from the API) are basically as good
as each other.

My API parallels the way that provider networks are used, because that's
what I had in mind at the time; Maruti's uses a block rather than marking
the network, and the only real difference that makes is that (a) you can
attach many networks to one block (which doesn't really seem to bring
anything special) and (b) uses a port to connect to the network (which is
not massively helpful because there's nothing sensible you can put on the
port; there may be many things behind the gateway).  At this point it
becomes a completely religious argument about which is better.  I still
prefer mine, from gut feel, but they are almost exactly equivalent at this
point.

Taking your statement above of 'let's take out the switch port stuff' then
Maruti's use case would need to explain where that data goes. The point I
made is that it becomes a Sisyphean task (endless and not useful) to
introduce a data model and API to introduce this into Neutron via an API
and that's what I didn't want to do.  Can we address that question?

-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] L2 gateway as a service

[Salvatore Orlando]

On 20 November 2014 02:19, Sukhdev Kapur  wrote:

> Folks,
>
> Like Ian, I am jumping in this very late as well - as I decided to travel
> Europe after the summit, just returned back and  catching up :-):-)
>
> I have noticed that this thread has gotten fairly convoluted and painful
> to read.
>
> I think Armando summed it up well in the beginning of the thread. There
> are basically three written proposals (listed in Armando's email - I pasted
> them again here).
>
> [1] https://review.openstack.org/#/c/134179/
> [2] https://review.openstack.org/#/c/100278/
> [3] https://review.openstack.org/#/c/93613/
>
>
In this thread I have seen other specs being mentioned as "related".
Namely:
1) https://review.openstack.org/#/c/93329/ (BGP VPN)
2) https://review.openstack.org/#/c/101043/ (MPLS vpn)
3) https://review.openstack.org/#/c/87825/ (external device integration)
Note that I am not saying they should be put as well in the mix. I'm only
listing them here as a "recap".
There are probably other "ideas" not yet put in the form of a concrete
specification. In order to avoid further confusion, I would just blindly
ignore proposals which do not exist in the form a specification.



> On this thread I see that the authors of first two proposals have already
> agreed to consolidate and work together. This leaves with two proposals.
> Both Ian and I were involved with the third proposal [3] and have
> reasonable idea about it. IMO, the use cases addressed by the third
> proposal are very similar to use cases addressed by proposal [1] and [2]. I
> can volunteer to  follow up with Racha and Stephen from Ericsson to see if
> their use case will be covered with the new combined proposal. If yes, we
> have one converged proposal. If no, then we modify the proposal to
> accommodate their use case as well. Regardless, I will ask them to review
> and post their comments on [1].
>

One thing that I've noticed in the past is that contributors are led to
think that the owner of the specification will also be the lead for the
subsequent work. There nothing farther from truth. Sometimes I write specs
with the exact intent of having somebody else lead the implementation. So
don't feel bad to abandon a spec if you realize your use cases can be
completely included in another specification.


>
> Having said that, this covers what we discussed during the morning session
> on Friday in Paris. Now, comes the second part which Ian brought up in the
> afternoon session on Friday.
> My initial reaction was, when heard his use case, that this new
> proposal/API should cover that use case as well (I am being bit optimistic
> here :-)). If not, rather than going into the nitty gritty details of the
> use case, let's see what modification is required to the proposed API to
> accommodate Ian's use case and adjust it accordingly.
>

Unfortunately I did not attend that discussion. Possibly 90% of the people
reading this thread did not attend it. It would be nice if Ian or somebody
else posted a write-up, adding more details to what has already been shared
in this thread. If you've already done so please share a link as my
google-fu is not that good these days.


>
> Now, the last point (already brought up by Salvatore as well as Armando) -
> the abstraction of the API, so that it meets the Neutron API criteria. I
> think this is the critical piece. I also believe the API proposed by [1] is
> very close. We should clean it up and take out references to ToR's or
> physical vs virtual devices. The API should work at an abstract level so
> that it can deal with both physical as well virtual devices. If we can
> agree to that, I believe we can have a solid solution.
>

> Having said that I would like to request the community to review the
> proposal submitted by Maruti in [1] and post comments on the spec with the
> intent to get a closure on the API. I see lots of good comments already on
> the spec. Lets get this done so that we can have a workable (even if not
> perfect) version of API in Kilo cycle. Something which we can all start to
> play with. We can always iterate over it, and make change as we get more
> and more use cases covered.
>

"Iterate" is the key here I believe. As long as we pretend to achieve the
perfect API at the first attempt we'll just keep having this discussion. I
think the first time a L2 GW API was proposed, it was for Grizzly.
For instance, it might relatively easy to define an API which can handle
both physical and virtual devices. The user workflow for a ToR terminated
L2 GW is different from the workflow for a virtual appliance owned by
tenant, and this will obviously reflected in the API. On the other hand, a
BGP VPN might be a completely different use case, and therefore have a
completely different set of APIs.

Beyond APIs there are two more things to mention.
First, we need some sort of open source reference implementation for every
use case. For hardware VTEP obviously this won't be possible, but perhaps
[1] can be

Re: [openstack-dev] [neutron] L2 gateway as a service

[Sukhdev Kapur]

Folks,

Like Ian, I am jumping in this very late as well - as I decided to travel
Europe after the summit, just returned back and  catching up :-):-)

I have noticed that this thread has gotten fairly convoluted and painful to
read.

I think Armando summed it up well in the beginning of the thread. There are
basically three written proposals (listed in Armando's email - I pasted
them again here).

[1] https://review.openstack.org/#/c/134179/
[2] https://review.openstack.org/#/c/100278/
[3] https://review.openstack.org/#/c/93613/

On this thread I see that the authors of first two proposals have already
agreed to consolidate and work together. This leaves with two proposals.
Both Ian and I were involved with the third proposal [3] and have
reasonable idea about it. IMO, the use cases addressed by the third
proposal are very similar to use cases addressed by proposal [1] and [2]. I
can volunteer to  follow up with Racha and Stephen from Ericsson to see if
their use case will be covered with the new combined proposal. If yes, we
have one converged proposal. If no, then we modify the proposal to
accommodate their use case as well. Regardless, I will ask them to review
and post their comments on [1].

Having said that, this covers what we discussed during the morning session
on Friday in Paris. Now, comes the second part which Ian brought up in the
afternoon session on Friday.
My initial reaction was, when heard his use case, that this new
proposal/API should cover that use case as well (I am being bit optimistic
here :-)). If not, rather than going into the nitty gritty details of the
use case, let's see what modification is required to the proposed API to
accommodate Ian's use case and adjust it accordingly.

Now, the last point (already brought up by Salvatore as well as Armando) -
the abstraction of the API, so that it meets the Neutron API criteria. I
think this is the critical piece. I also believe the API proposed by [1] is
very close. We should clean it up and take out references to ToR's or
physical vs virtual devices. The API should work at an abstract level so
that it can deal with both physical as well virtual devices. If we can
agree to that, I believe we can have a solid solution.

Having said that I would like to request the community to review the
proposal submitted by Maruti in [1] and post comments on the spec with the
intent to get a closure on the API. I see lots of good comments already on
the spec. Lets get this done so that we can have a workable (even if not
perfect) version of API in Kilo cycle. Something which we can all start to
play with. We can always iterate over it, and make change as we get more
and more use cases covered.

Make sense?

cheers..
-Sukhdev


On Tue, Nov 18, 2014 at 6:44 PM, Armando M.  wrote:

> Hi,
>
> On 18 November 2014 16:22, Ian Wells  wrote:
>
>> Sorry I'm a bit late to this, but that's what you get from being on
>> holiday...  (Which is also why there are no new MTU and VLAN specs yet, but
>> I swear I'll get to them.)
>>
>
> Ah! I hope it was good at least :)
>
>
>>
>> On 17 November 2014 01:13, Mathieu Rohon  wrote:
>>
>>> Hi
>>>
>>> On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
>>> > Last Friday I recall we had two discussions around this topic. One in
>>> the
>>> > morning, which I think led to Maruti to push [1]. The way I understood
>>> [1]
>>> > was that it is an attempt at unifying [2] and [3], by choosing the API
>>> > approach of one and the architectural approach of the other.
>>> >
>>> > [1] https://review.openstack.org/#/c/134179/
>>> > [2] https://review.openstack.org/#/c/100278/
>>> > [3] https://review.openstack.org/#/c/93613/
>>> >
>>> > Then there was another discussion in the afternoon, but I am not 100%
>>> of the
>>> > outcome.
>>>
>>> Me neither, that's why I'd like ian, who led this discussion, to sum
>>> up the outcome from its point of view.
>>>
>>
>> So, the gist of what I said is that we have three, independent, use cases:
>>
>> - connecting two VMs that like to tag packets to each other (VLAN clean
>> networks)
>> - connecting many networks to a single VM (trunking ports)
>> - connecting the outside world to a set of virtual networks
>>
>> We're discussing that last use case here.  The point I was made was that:
>>
>> - there are more encaps in the world than just VLANs
>> - they can all be solved in the same way using an edge API
>>
>
> No disagreement all the way up to this point, assumed that I don't worry
> about what this edge API really is.
>
>
>> - if they are solved using an edge API, the job of describing the network
>> you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or
>> l2tpv3 endpoint data) is best kept outside of Neutron's API, because
>> Neutron can't usefully do anything with it other than validate it and hand
>> it off to whatever network control code is being used.  (Note that most
>> encaps will likely *not* be implemented in Neutron's inbuilt control code.)
>>
>
> This is where the

Re: [openstack-dev] [neutron] L2 gateway as a service

[Armando M.]

Hi,

On 18 November 2014 16:22, Ian Wells  wrote:

> Sorry I'm a bit late to this, but that's what you get from being on
> holiday...  (Which is also why there are no new MTU and VLAN specs yet, but
> I swear I'll get to them.)
>

Ah! I hope it was good at least :)


>
> On 17 November 2014 01:13, Mathieu Rohon  wrote:
>
>> Hi
>>
>> On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
>> > Last Friday I recall we had two discussions around this topic. One in
>> the
>> > morning, which I think led to Maruti to push [1]. The way I understood
>> [1]
>> > was that it is an attempt at unifying [2] and [3], by choosing the API
>> > approach of one and the architectural approach of the other.
>> >
>> > [1] https://review.openstack.org/#/c/134179/
>> > [2] https://review.openstack.org/#/c/100278/
>> > [3] https://review.openstack.org/#/c/93613/
>> >
>> > Then there was another discussion in the afternoon, but I am not 100%
>> of the
>> > outcome.
>>
>> Me neither, that's why I'd like ian, who led this discussion, to sum
>> up the outcome from its point of view.
>>
>
> So, the gist of what I said is that we have three, independent, use cases:
>
> - connecting two VMs that like to tag packets to each other (VLAN clean
> networks)
> - connecting many networks to a single VM (trunking ports)
> - connecting the outside world to a set of virtual networks
>
> We're discussing that last use case here.  The point I was made was that:
>
> - there are more encaps in the world than just VLANs
> - they can all be solved in the same way using an edge API
>

No disagreement all the way up to this point, assumed that I don't worry
about what this edge API really is.


> - if they are solved using an edge API, the job of describing the network
> you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or
> l2tpv3 endpoint data) is best kept outside of Neutron's API, because
> Neutron can't usefully do anything with it other than validate it and hand
> it off to whatever network control code is being used.  (Note that most
> encaps will likely *not* be implemented in Neutron's inbuilt control code.)
>

This is where the disagreement begins, as far as I am concerned; in fact we
already have a well defined way of describing what a network entity in
Neutron is, namely an L2 broadcast domain abstraction. An L2 gateway API
that is well defined and well scoped should just express how one can be
connected to another, nothing more, at least as a starting point.


>
> Now, the above argument says that we should keep this out of Neutron.  The
> problem with that is that people are using the OVS mechanism driver and
> would like a solution that works with that, implying something that's
> *inside* Neutron.  For that case, it's certainly valid to consider another
> means of implementation, but it wouldn't be my personal choice.  (For what
> it's worth I'm looking at ODL based controller implementations, so this
> isn't an issue for me personally.)
>
> If one were to implement the code in the Neutron API, even as an
> extension, I would question whether it's a sensible thing to attempt before
> the RPC server/REST server split is done, since it also extends the API
> between them.
>
> > All this churn makes me believe that we probably just need to stop
>> > pretending we can achieve any sort of consensus on the approach and let
>> the
>> > different alternatives develop independently, assumed they can all
>> develop
>> > independently, and then let natural evolution take its course :)
>>
>> I tend to agree, but I think that one of the reason why we are looking
>> for a consensus, is because API evolutions proposed through
>> Neutron-spec are rejected by core-dev, because they rely on external
>> components (sdn controller, proprietary hardware...) or they are not a
>> high priority for neutron core-dev.
>> By finding a consensus, we show that several players are interested in
>> such an API, and it helps to convince core-dev that this use-case, and
>> its API, is missing in neutron.
>>
>
> There are lots of players interested in an API, that much is clear, and
> all the more so if you consider that this feature has strong analogies with
> use cases such as switch port exposure and MPLS.  The problem is that it's
> clearly a fairly complex API with some variety of ways to implement it, and
> both of these things work against its acceptance.  Additionally, per the
> above discussion, I would say it's not essential for it to be core Neutron
> functionality.
>

> Now, if there is room for easily propose new API in Neutron, It make
>> sense to leave new API appear and evolve, and then " let natural
>> evolution take its course ", as you said.
>>
>
> Natural selection works poorly on APIs because once they exist they're
> hard to change and/or retire, due to backward compatibility requirements.
>

Well, that is true assumed that someone can or is willing to use them :)


>
>
>> To me, this is in the scope of the "advanced services" proj

Re: [openstack-dev] [neutron] L2 gateway as a service

[Ian Wells]

Sorry I'm a bit late to this, but that's what you get from being on
holiday...  (Which is also why there are no new MTU and VLAN specs yet, but
I swear I'll get to them.)

On 17 November 2014 01:13, Mathieu Rohon  wrote:

> Hi
>
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
> > Last Friday I recall we had two discussions around this topic. One in the
> > morning, which I think led to Maruti to push [1]. The way I understood
> [1]
> > was that it is an attempt at unifying [2] and [3], by choosing the API
> > approach of one and the architectural approach of the other.
> >
> > [1] https://review.openstack.org/#/c/134179/
> > [2] https://review.openstack.org/#/c/100278/
> > [3] https://review.openstack.org/#/c/93613/
> >
> > Then there was another discussion in the afternoon, but I am not 100% of
> the
> > outcome.
>
> Me neither, that's why I'd like ian, who led this discussion, to sum
> up the outcome from its point of view.
>

So, the gist of what I said is that we have three, independent, use cases:

- connecting two VMs that like to tag packets to each other (VLAN clean
networks)
- connecting many networks to a single VM (trunking ports)
- connecting the outside world to a set of virtual networks

We're discussing that last use case here.  The point I was made was that:

- there are more encaps in the world than just VLANs
- they can all be solved in the same way using an edge API
- if they are solved using an edge API, the job of describing the network
you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or
l2tpv3 endpoint data) is best kept outside of Neutron's API, because
Neutron can't usefully do anything with it other than validate it and hand
it off to whatever network control code is being used.  (Note that most
encaps will likely *not* be implemented in Neutron's inbuilt control code.)

Now, the above argument says that we should keep this out of Neutron.  The
problem with that is that people are using the OVS mechanism driver and
would like a solution that works with that, implying something that's
*inside* Neutron.  For that case, it's certainly valid to consider another
means of implementation, but it wouldn't be my personal choice.  (For what
it's worth I'm looking at ODL based controller implementations, so this
isn't an issue for me personally.)

If one were to implement the code in the Neutron API, even as an extension,
I would question whether it's a sensible thing to attempt before the RPC
server/REST server split is done, since it also extends the API between
them.

> All this churn makes me believe that we probably just need to stop
> > pretending we can achieve any sort of consensus on the approach and let
> the
> > different alternatives develop independently, assumed they can all
> develop
> > independently, and then let natural evolution take its course :)
>
> I tend to agree, but I think that one of the reason why we are looking
> for a consensus, is because API evolutions proposed through
> Neutron-spec are rejected by core-dev, because they rely on external
> components (sdn controller, proprietary hardware...) or they are not a
> high priority for neutron core-dev.
> By finding a consensus, we show that several players are interested in
> such an API, and it helps to convince core-dev that this use-case, and
> its API, is missing in neutron.
>

There are lots of players interested in an API, that much is clear, and all
the more so if you consider that this feature has strong analogies with use
cases such as switch port exposure and MPLS.  The problem is that it's
clearly a fairly complex API with some variety of ways to implement it, and
both of these things work against its acceptance.  Additionally, per the
above discussion, I would say it's not essential for it to be core Neutron
functionality.

Now, if there is room for easily propose new API in Neutron, It make
> sense to leave new API appear and evolve, and then " let natural
> evolution take its course ", as you said.
>

Natural selection works poorly on APIs because once they exist they're hard
to change and/or retire, due to backward compatibility requirements.


> To me, this is in the scope of the "advanced services" project.
>

Advanced services or no, the point I was making is that this is not
something that should fit under the Neutron API endpoint.  Since it's not
really related to any of the other advanced services it's not particularly
necessary that it fit under the Advanced Services API endpoint either,
although it could.  My Unix design leanings say to me that if things are
not related they shouldn't be combined, though - the simplest thing that
does the job is the right answer.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] L2 gateway as a service

[Armando M.]

On 17 November 2014 01:13, Mathieu Rohon  wrote:

> Hi
>
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
> > Last Friday I recall we had two discussions around this topic. One in the
> > morning, which I think led to Maruti to push [1]. The way I understood
> [1]
> > was that it is an attempt at unifying [2] and [3], by choosing the API
> > approach of one and the architectural approach of the other.
> >
> > [1] https://review.openstack.org/#/c/134179/
> > [2] https://review.openstack.org/#/c/100278/
> > [3] https://review.openstack.org/#/c/93613/
> >
> > Then there was another discussion in the afternoon, but I am not 100% of
> the
> > outcome.
>
> Me neither, that's why I'd like ian, who led this discussion, to sum
> up the outcome from its point of view.
>
> > All this churn makes me believe that we probably just need to stop
> > pretending we can achieve any sort of consensus on the approach and let
> the
> > different alternatives develop independently, assumed they can all
> develop
> > independently, and then let natural evolution take its course :)
>
> I tend to agree, but I think that one of the reason why we are looking
> for a consensus, is because API evolutions proposed through
> Neutron-spec are rejected by core-dev, because they rely on external
> components (sdn controller, proprietary hardware...) or they are not a
> high priority for neutron core-dev.
>

I am not sure I agree with this statement. I am not aware of any proposal
here being dependent on external components as you suggested, but even if
it were, an API can be implemented in multiple ways, just like the (core)
Neutron API can be implemented using a fully open source solution or an
external party like an SDN controller.


> By finding a consensus, we show that several players are interested in
> such an API, and it helps to convince core-dev that this use-case, and
> its API, is missing in neutron.
>

Right, but it seems we are struggling to find this consensus. In this
particular instance, where we are trying to address the use case of L2
Gateway (i.e. allow Neutron logical networks to be extended with physical
ones), it seems that everyone has a different opinion as to what
abstraction we should adopt in order to express and configure the L2
gateway entity, and at the same time I see no convergence in sight.

Now if the specific L2 Gateway case were to be considered part of the core
Neutron API, then such a consensus would be mandatory IMO, but if it isn't,
is there any value in striving for that consensus at all costs? Perhaps
not, and we can have multiple attempts experiment and innovate
independently.

So far, all my data points seem to imply that such an abstraction need not
be part of the core API.


> Now, if there is room for easily propose new API in Neutron, It make
> sense to leave new API appear and evolve, and then " let natural
> evolution take its course ", as you said.
> To me, this is in the scope of the "advanced services" project.
>

Advanced Services may be a misnomer, but an incubation feature, sure why
not?


>
> > Ultimately the biggest debate is on what the API model needs to be for
> these
> > abstractions. We can judge on which one is the best API of all, but
> > sometimes this ends up being a religious fight. A good API for me might
> not
> > be a good API for you, even though I strongly believe that a good API is
> one
> > that can:
> >
> > - be hard to use incorrectly
> > - clear to understand
> > - does one thing, and one thing well
> >
> > So far I have been unable to be convinced why we'd need to cram more than
> > one abstraction in one single API, as it does violate the above mentioned
> > principles. Ultimately I like the L2 GW API proposed by 1 and 2 because
> it's
> > in line with those principles. I'd rather start from there and iterate.
> >
> > My 2c,
> > Armando
> >
> > On 14 November 2014 08:47, Salvatore Orlando 
> wrote:
> >>
> >> Thanks guys.
> >>
> >> I think you've answered my initial question. Probably not in the way I
> was
> >> hoping it to be answered, but it's ok.
> >>
> >> So now we have potentially 4 different blueprint describing more or less
> >> overlapping use cases that we need to reconcile into one?
> >> If the above is correct, then I suggest we go back to the use case and
> >> make an effort to abstract a bit from thinking about how those use cases
> >> should be implemented.
> >>
> >> Salvatore
> >>
> >> On 14 November 2014 15:42, Igor Cardoso  wrote:
> >>>
> >>> Hello all,
> >>> Also, what about Kevin's https://review.openstack.org/#/c/87825/? One
> of
> >>> its use cases is exactly the L2 gateway. These proposals could
> probably be
> >>> inserted in a more generic work for moving existing datacenter L2
> resources
> >>> to Neutron.
> >>> Cheers,
> >>>
> >>> On 14 November 2014 15:28, Mathieu Rohon 
> wrote:
> 
>  Hi,
> 
>  As far as I understood last friday afternoon dicussions during the
>  design summit, this use case is in the scope o

Re: [openstack-dev] [neutron] L2 gateway as a service

[Igor Cardoso]

What would be the best meeting to discuss these works and any
others related? Maybe, collectively, a very flexible solution for all
related use cases could be found.

I also want to go forward with some work I've developed a couple months
ago, part of "methods to connect x to a neutron l2 segment", which aims at
any "x", be it a 10-year old cheap home gateway wireless access point
located at the other side of the planet, or a datacenter's hardware switch
VLAN.

Cheers,

On 17 November 2014 12:29, Doug Wiegley  wrote:

>  Sorry, it's early, I was being imprecise and using trunk to mean,
> "methods to connect x to a neutron (l2 segment".
>
> Doug
>
> On Nov 17, 2014, at 10:35 AM, Salvatore Orlando 
> wrote:
>
>   I think this thread is about the L2 gateway service... how's that
> related with the notion of trunk port?
>
>  I know that the spec under review adds a component which is tantamount
> to a L2 gateway, but while the functionality is similar, the use case, and
> therefore the API exposed, are rather different.
> Am I missing something here?
>
>  Salvatore
>
> On 17 November 2014 10:40, Doug Wiegley  wrote:
>
>>
>> > On Nov 17, 2014, at 9:13 AM, Mathieu Rohon 
>> wrote:
>> >
>> > Hi
>> >
>> > On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
>> >> Last Friday I recall we had two discussions around this topic. One in
>> the
>> >> morning, which I think led to Maruti to push [1]. The way I understood
>> [1]
>> >> was that it is an attempt at unifying [2] and [3], by choosing the API
>> >> approach of one and the architectural approach of the other.
>> >>
>> >> [1] https://review.openstack.org/#/c/134179/
>> >> [2] https://review.openstack.org/#/c/100278/
>> >> [3] https://review.openstack.org/#/c/93613/
>> >>
>> >> Then there was another discussion in the afternoon, but I am not 100%
>> of the
>> >> outcome.
>> >
>> > Me neither, that's why I'd like ian, who led this discussion, to sum
>> > up the outcome from its point of view.
>> >
>> >> All this churn makes me believe that we probably just need to stop
>> >> pretending we can achieve any sort of consensus on the approach and
>> let the
>> >> different alternatives develop independently, assumed they can all
>> develop
>> >> independently, and then let natural evolution take its course :)
>> >
>> > I tend to agree, but I think that one of the reason why we are looking
>> > for a consensus, is because API evolutions proposed through
>> > Neutron-spec are rejected by core-dev, because they rely on external
>> > components (sdn controller, proprietary hardware...) or they are not a
>> > high priority for neutron core-dev.
>> > By finding a consensus, we show that several players are interested in
>> > such an API, and it helps to convince core-dev that this use-case, and
>> > its API, is missing in neutron.
>> >
>> > Now, if there is room for easily propose new API in Neutron, It make
>> > sense to leave new API appear and evolve, and then " let natural
>> > evolution take its course ", as you said.
>> > To me, this is in the scope of the "advanced services" project.
>>
>>  I think we need to be careful of the natural tendency to view the new
>> project as a place to put everything that is "moving too slowly" in
>> neutron.  Certainly advanced services is one of the most obvious use cases
>> of this functionality, but that doesn't mean that the notion of an SDN
>> trunk port should live anywhere but neutron, IMO.
>>
>> Thanks,
>> doug
>>
>> >
>> >> Ultimately the biggest debate is on what the API model needs to be for
>> these
>> >> abstractions. We can judge on which one is the best API of all, but
>> >> sometimes this ends up being a religious fight. A good API for me
>> might not
>> >> be a good API for you, even though I strongly believe that a good API
>> is one
>> >> that can:
>> >>
>> >> - be hard to use incorrectly
>> >> - clear to understand
>> >> - does one thing, and one thing well
>> >>
>> >> So far I have been unable to be convinced why we'd need to cram more
>> than
>> >> one abstraction in one single API, as it does violate the above
>> mentioned
>> >> principles. Ultimately I like the L2 GW API proposed by 1 and 2
>> because it's
>> >> in line with those principles. I'd rather start from there and iterate.
>> >>
>> >> My 2c,
>> >> Armando
>> >>
>> >> On 14 November 2014 08:47, Salvatore Orlando 
>> wrote:
>> >>>
>> >>> Thanks guys.
>> >>>
>> >>> I think you've answered my initial question. Probably not in the way
>> I was
>> >>> hoping it to be answered, but it's ok.
>> >>>
>> >>> So now we have potentially 4 different blueprint describing more or
>> less
>> >>> overlapping use cases that we need to reconcile into one?
>> >>> If the above is correct, then I suggest we go back to the use case and
>> >>> make an effort to abstract a bit from thinking about how those use
>> cases
>> >>> should be implemented.
>> >>>
>> >>> Salvatore
>> >>>
>> >>> On 14 November 2014 15:42, Igor Cardoso  wrote:
>> 
>>  Hello all,
>>  Also, what 

Re: [openstack-dev] [neutron] L2 gateway as a service

[Doug Wiegley]

Sorry, it's early, I was being imprecise and using trunk to mean, "methods to 
connect x to a neutron (l2 segment".

Doug

On Nov 17, 2014, at 10:35 AM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:

I think this thread is about the L2 gateway service... how's that related with 
the notion of trunk port?

I know that the spec under review adds a component which is tantamount to a L2 
gateway, but while the functionality is similar, the use case, and therefore 
the API exposed, are rather different.
Am I missing something here?

Salvatore

On 17 November 2014 10:40, Doug Wiegley 
mailto:do...@a10networks.com>> wrote:

> On Nov 17, 2014, at 9:13 AM, Mathieu Rohon 
> mailto:mathieu.ro...@gmail.com>> wrote:
>
> Hi
>
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. 
> mailto:arma...@gmail.com>> wrote:
>> Last Friday I recall we had two discussions around this topic. One in the
>> morning, which I think led to Maruti to push [1]. The way I understood [1]
>> was that it is an attempt at unifying [2] and [3], by choosing the API
>> approach of one and the architectural approach of the other.
>>
>> [1] https://review.openstack.org/#/c/134179/
>> [2] https://review.openstack.org/#/c/100278/
>> [3] https://review.openstack.org/#/c/93613/
>>
>> Then there was another discussion in the afternoon, but I am not 100% of the
>> outcome.
>
> Me neither, that's why I'd like ian, who led this discussion, to sum
> up the outcome from its point of view.
>
>> All this churn makes me believe that we probably just need to stop
>> pretending we can achieve any sort of consensus on the approach and let the
>> different alternatives develop independently, assumed they can all develop
>> independently, and then let natural evolution take its course :)
>
> I tend to agree, but I think that one of the reason why we are looking
> for a consensus, is because API evolutions proposed through
> Neutron-spec are rejected by core-dev, because they rely on external
> components (sdn controller, proprietary hardware...) or they are not a
> high priority for neutron core-dev.
> By finding a consensus, we show that several players are interested in
> such an API, and it helps to convince core-dev that this use-case, and
> its API, is missing in neutron.
>
> Now, if there is room for easily propose new API in Neutron, It make
> sense to leave new API appear and evolve, and then " let natural
> evolution take its course ", as you said.
> To me, this is in the scope of the "advanced services" project.

I think we need to be careful of the natural tendency to view the new project 
as a place to put everything that is "moving too slowly" in neutron.  Certainly 
advanced services is one of the most obvious use cases of this functionality, 
but that doesn't mean that the notion of an SDN trunk port should live anywhere 
but neutron, IMO.

Thanks,
doug

>
>> Ultimately the biggest debate is on what the API model needs to be for these
>> abstractions. We can judge on which one is the best API of all, but
>> sometimes this ends up being a religious fight. A good API for me might not
>> be a good API for you, even though I strongly believe that a good API is one
>> that can:
>>
>> - be hard to use incorrectly
>> - clear to understand
>> - does one thing, and one thing well
>>
>> So far I have been unable to be convinced why we'd need to cram more than
>> one abstraction in one single API, as it does violate the above mentioned
>> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's
>> in line with those principles. I'd rather start from there and iterate.
>>
>> My 2c,
>> Armando
>>
>> On 14 November 2014 08:47, Salvatore Orlando 
>> mailto:sorla...@nicira.com>> wrote:
>>>
>>> Thanks guys.
>>>
>>> I think you've answered my initial question. Probably not in the way I was
>>> hoping it to be answered, but it's ok.
>>>
>>> So now we have potentially 4 different blueprint describing more or less
>>> overlapping use cases that we need to reconcile into one?
>>> If the above is correct, then I suggest we go back to the use case and
>>> make an effort to abstract a bit from thinking about how those use cases
>>> should be implemented.
>>>
>>> Salvatore
>>>
>>> On 14 November 2014 15:42, Igor Cardoso 
>>> mailto:igordc...@gmail.com>> wrote:

 Hello all,
 Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
 its use cases is exactly the L2 gateway. These proposals could probably be
 inserted in a more generic work for moving existing datacenter L2 resources
 to Neutron.
 Cheers,

 On 14 November 2014 15:28, Mathieu Rohon 
 mailto:mathieu.ro...@gmail.com>> wrote:
>
> Hi,
>
> As far as I understood last friday afternoon dicussions during the
> design summit, this use case is in the scope of another umbrella spec
> which would define external connectivity for neutron networks. Details
> of those connectivity would be defined through service plugin API.
>

Re: [openstack-dev] [neutron] L2 gateway as a service

[Isaku Yamahata]

On Mon, Nov 17, 2014 at 10:13:50AM +0100,
Mathieu Rohon  wrote:

> Hi

Hi.


> On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
> > Last Friday I recall we had two discussions around this topic. One in the
> > morning, which I think led to Maruti to push [1]. The way I understood [1]
> > was that it is an attempt at unifying [2] and [3], by choosing the API
> > approach of one and the architectural approach of the other.
> >
> > [1] https://review.openstack.org/#/c/134179/
> > [2] https://review.openstack.org/#/c/100278/
> > [3] https://review.openstack.org/#/c/93613/
> >
> > Then there was another discussion in the afternoon, but I am not 100% of the
> > outcome.
> 
> Me neither, that's why I'd like ian, who led this discussion, to sum
> up the outcome from its point of view.

I, Isaku, talked with Maruti and has agreed to pursue [1] with a hope to
unify [2] and we will see the outcome in kilo cycle.
I'm willing to review/help [1] (and corresponding patches).

thanks,

> > All this churn makes me believe that we probably just need to stop
> > pretending we can achieve any sort of consensus on the approach and let the
> > different alternatives develop independently, assumed they can all develop
> > independently, and then let natural evolution take its course :)
> 
> I tend to agree, but I think that one of the reason why we are looking
> for a consensus, is because API evolutions proposed through
> Neutron-spec are rejected by core-dev, because they rely on external
> components (sdn controller, proprietary hardware...) or they are not a
> high priority for neutron core-dev.
> By finding a consensus, we show that several players are interested in
> such an API, and it helps to convince core-dev that this use-case, and
> its API, is missing in neutron.
> 
> Now, if there is room for easily propose new API in Neutron, It make
> sense to leave new API appear and evolve, and then " let natural
> evolution take its course ", as you said.
> To me, this is in the scope of the "advanced services" project.
> 
> > Ultimately the biggest debate is on what the API model needs to be for these
> > abstractions. We can judge on which one is the best API of all, but
> > sometimes this ends up being a religious fight. A good API for me might not
> > be a good API for you, even though I strongly believe that a good API is one
> > that can:
> >
> > - be hard to use incorrectly
> > - clear to understand
> > - does one thing, and one thing well
> >
> > So far I have been unable to be convinced why we'd need to cram more than
> > one abstraction in one single API, as it does violate the above mentioned
> > principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's
> > in line with those principles. I'd rather start from there and iterate.
> >
> > My 2c,
> > Armando
> >
> > On 14 November 2014 08:47, Salvatore Orlando  wrote:
> >>
> >> Thanks guys.
> >>
> >> I think you've answered my initial question. Probably not in the way I was
> >> hoping it to be answered, but it's ok.
> >>
> >> So now we have potentially 4 different blueprint describing more or less
> >> overlapping use cases that we need to reconcile into one?
> >> If the above is correct, then I suggest we go back to the use case and
> >> make an effort to abstract a bit from thinking about how those use cases
> >> should be implemented.
> >>
> >> Salvatore
> >>
> >> On 14 November 2014 15:42, Igor Cardoso  wrote:
> >>>
> >>> Hello all,
> >>> Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
> >>> its use cases is exactly the L2 gateway. These proposals could probably be
> >>> inserted in a more generic work for moving existing datacenter L2 
> >>> resources
> >>> to Neutron.
> >>> Cheers,
> >>>
> >>> On 14 November 2014 15:28, Mathieu Rohon  wrote:
> 
>  Hi,
> 
>  As far as I understood last friday afternoon dicussions during the
>  design summit, this use case is in the scope of another umbrella spec
>  which would define external connectivity for neutron networks. Details
>  of those connectivity would be defined through service plugin API.
> 
>  Ian do you plan to define such an umbrella spec? or at least, could
>  you sum up the agreement of the design summit discussion in the ML?
> 
>  I see at least 3 specs which would be under such an umbrella spec :
>  https://review.openstack.org/#/c/93329/ (BGPVPN)
>  https://review.openstack.org/#/c/101043/ (Inter DC connectivity with
>  VPN)
>  https://review.openstack.org/#/c/134179/ (l2 gw aas)
> 
> 
>  On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
>  wrote:
>  > Thanks Maruti,
>  >
>  > I have some comments and questions which I've posted on gerrit.
>  > There are two things I would like to discuss on the mailing list
>  > concerning
>  > this effort.
>  >
>  > 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
>  > https://review.opens

Re: [openstack-dev] [neutron] L2 gateway as a service

[Salvatore Orlando]

I think this thread is about the L2 gateway service... how's that related
with the notion of trunk port?

I know that the spec under review adds a component which is tantamount to a
L2 gateway, but while the functionality is similar, the use case, and
therefore the API exposed, are rather different.
Am I missing something here?

Salvatore

On 17 November 2014 10:40, Doug Wiegley  wrote:

>
> > On Nov 17, 2014, at 9:13 AM, Mathieu Rohon 
> wrote:
> >
> > Hi
> >
> > On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
> >> Last Friday I recall we had two discussions around this topic. One in
> the
> >> morning, which I think led to Maruti to push [1]. The way I understood
> [1]
> >> was that it is an attempt at unifying [2] and [3], by choosing the API
> >> approach of one and the architectural approach of the other.
> >>
> >> [1] https://review.openstack.org/#/c/134179/
> >> [2] https://review.openstack.org/#/c/100278/
> >> [3] https://review.openstack.org/#/c/93613/
> >>
> >> Then there was another discussion in the afternoon, but I am not 100%
> of the
> >> outcome.
> >
> > Me neither, that's why I'd like ian, who led this discussion, to sum
> > up the outcome from its point of view.
> >
> >> All this churn makes me believe that we probably just need to stop
> >> pretending we can achieve any sort of consensus on the approach and let
> the
> >> different alternatives develop independently, assumed they can all
> develop
> >> independently, and then let natural evolution take its course :)
> >
> > I tend to agree, but I think that one of the reason why we are looking
> > for a consensus, is because API evolutions proposed through
> > Neutron-spec are rejected by core-dev, because they rely on external
> > components (sdn controller, proprietary hardware...) or they are not a
> > high priority for neutron core-dev.
> > By finding a consensus, we show that several players are interested in
> > such an API, and it helps to convince core-dev that this use-case, and
> > its API, is missing in neutron.
> >
> > Now, if there is room for easily propose new API in Neutron, It make
> > sense to leave new API appear and evolve, and then " let natural
> > evolution take its course ", as you said.
> > To me, this is in the scope of the "advanced services" project.
>
> I think we need to be careful of the natural tendency to view the new
> project as a place to put everything that is "moving too slowly" in
> neutron.  Certainly advanced services is one of the most obvious use cases
> of this functionality, but that doesn't mean that the notion of an SDN
> trunk port should live anywhere but neutron, IMO.
>
> Thanks,
> doug
>
> >
> >> Ultimately the biggest debate is on what the API model needs to be for
> these
> >> abstractions. We can judge on which one is the best API of all, but
> >> sometimes this ends up being a religious fight. A good API for me might
> not
> >> be a good API for you, even though I strongly believe that a good API
> is one
> >> that can:
> >>
> >> - be hard to use incorrectly
> >> - clear to understand
> >> - does one thing, and one thing well
> >>
> >> So far I have been unable to be convinced why we'd need to cram more
> than
> >> one abstraction in one single API, as it does violate the above
> mentioned
> >> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because
> it's
> >> in line with those principles. I'd rather start from there and iterate.
> >>
> >> My 2c,
> >> Armando
> >>
> >> On 14 November 2014 08:47, Salvatore Orlando 
> wrote:
> >>>
> >>> Thanks guys.
> >>>
> >>> I think you've answered my initial question. Probably not in the way I
> was
> >>> hoping it to be answered, but it's ok.
> >>>
> >>> So now we have potentially 4 different blueprint describing more or
> less
> >>> overlapping use cases that we need to reconcile into one?
> >>> If the above is correct, then I suggest we go back to the use case and
> >>> make an effort to abstract a bit from thinking about how those use
> cases
> >>> should be implemented.
> >>>
> >>> Salvatore
> >>>
> >>> On 14 November 2014 15:42, Igor Cardoso  wrote:
> 
>  Hello all,
>  Also, what about Kevin's https://review.openstack.org/#/c/87825/?
> One of
>  its use cases is exactly the L2 gateway. These proposals could
> probably be
>  inserted in a more generic work for moving existing datacenter L2
> resources
>  to Neutron.
>  Cheers,
> 
>  On 14 November 2014 15:28, Mathieu Rohon 
> wrote:
> >
> > Hi,
> >
> > As far as I understood last friday afternoon dicussions during the
> > design summit, this use case is in the scope of another umbrella spec
> > which would define external connectivity for neutron networks.
> Details
> > of those connectivity would be defined through service plugin API.
> >
> > Ian do you plan to define such an umbrella spec? or at least, could
> > you sum up the agreement of the design summit discussion in the ML?
> >
> > 

Re: [openstack-dev] [neutron] L2 gateway as a service

[Doug Wiegley]

> On Nov 17, 2014, at 9:13 AM, Mathieu Rohon  wrote:
> 
> Hi
> 
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
>> Last Friday I recall we had two discussions around this topic. One in the
>> morning, which I think led to Maruti to push [1]. The way I understood [1]
>> was that it is an attempt at unifying [2] and [3], by choosing the API
>> approach of one and the architectural approach of the other.
>> 
>> [1] https://review.openstack.org/#/c/134179/
>> [2] https://review.openstack.org/#/c/100278/
>> [3] https://review.openstack.org/#/c/93613/
>> 
>> Then there was another discussion in the afternoon, but I am not 100% of the
>> outcome.
> 
> Me neither, that's why I'd like ian, who led this discussion, to sum
> up the outcome from its point of view.
> 
>> All this churn makes me believe that we probably just need to stop
>> pretending we can achieve any sort of consensus on the approach and let the
>> different alternatives develop independently, assumed they can all develop
>> independently, and then let natural evolution take its course :)
> 
> I tend to agree, but I think that one of the reason why we are looking
> for a consensus, is because API evolutions proposed through
> Neutron-spec are rejected by core-dev, because they rely on external
> components (sdn controller, proprietary hardware...) or they are not a
> high priority for neutron core-dev.
> By finding a consensus, we show that several players are interested in
> such an API, and it helps to convince core-dev that this use-case, and
> its API, is missing in neutron.
> 
> Now, if there is room for easily propose new API in Neutron, It make
> sense to leave new API appear and evolve, and then " let natural
> evolution take its course ", as you said.
> To me, this is in the scope of the "advanced services" project.

I think we need to be careful of the natural tendency to view the new project 
as a place to put everything that is "moving too slowly" in neutron.  Certainly 
advanced services is one of the most obvious use cases of this functionality, 
but that doesn't mean that the notion of an SDN trunk port should live anywhere 
but neutron, IMO.

Thanks,
doug

> 
>> Ultimately the biggest debate is on what the API model needs to be for these
>> abstractions. We can judge on which one is the best API of all, but
>> sometimes this ends up being a religious fight. A good API for me might not
>> be a good API for you, even though I strongly believe that a good API is one
>> that can:
>> 
>> - be hard to use incorrectly
>> - clear to understand
>> - does one thing, and one thing well
>> 
>> So far I have been unable to be convinced why we'd need to cram more than
>> one abstraction in one single API, as it does violate the above mentioned
>> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's
>> in line with those principles. I'd rather start from there and iterate.
>> 
>> My 2c,
>> Armando
>> 
>> On 14 November 2014 08:47, Salvatore Orlando  wrote:
>>> 
>>> Thanks guys.
>>> 
>>> I think you've answered my initial question. Probably not in the way I was
>>> hoping it to be answered, but it's ok.
>>> 
>>> So now we have potentially 4 different blueprint describing more or less
>>> overlapping use cases that we need to reconcile into one?
>>> If the above is correct, then I suggest we go back to the use case and
>>> make an effort to abstract a bit from thinking about how those use cases
>>> should be implemented.
>>> 
>>> Salvatore
>>> 
>>> On 14 November 2014 15:42, Igor Cardoso  wrote:
 
 Hello all,
 Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
 its use cases is exactly the L2 gateway. These proposals could probably be
 inserted in a more generic work for moving existing datacenter L2 resources
 to Neutron.
 Cheers,
 
 On 14 November 2014 15:28, Mathieu Rohon  wrote:
> 
> Hi,
> 
> As far as I understood last friday afternoon dicussions during the
> design summit, this use case is in the scope of another umbrella spec
> which would define external connectivity for neutron networks. Details
> of those connectivity would be defined through service plugin API.
> 
> Ian do you plan to define such an umbrella spec? or at least, could
> you sum up the agreement of the design summit discussion in the ML?
> 
> I see at least 3 specs which would be under such an umbrella spec :
> https://review.openstack.org/#/c/93329/ (BGPVPN)
> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with
> VPN)
> https://review.openstack.org/#/c/134179/ (l2 gw aas)
> 
> 
> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
> wrote:
>> Thanks Maruti,
>> 
>> I have some comments and questions which I've posted on gerrit.
>> There are two things I would like to discuss on the mailing list
>> concerning
>> this effort.
>> 
>> 1) Is this spec replacing  https

Re: [openstack-dev] [neutron] L2 gateway as a service

[Mathieu Rohon]

Hi

On Fri, Nov 14, 2014 at 6:26 PM, Armando M.  wrote:
> Last Friday I recall we had two discussions around this topic. One in the
> morning, which I think led to Maruti to push [1]. The way I understood [1]
> was that it is an attempt at unifying [2] and [3], by choosing the API
> approach of one and the architectural approach of the other.
>
> [1] https://review.openstack.org/#/c/134179/
> [2] https://review.openstack.org/#/c/100278/
> [3] https://review.openstack.org/#/c/93613/
>
> Then there was another discussion in the afternoon, but I am not 100% of the
> outcome.

Me neither, that's why I'd like ian, who led this discussion, to sum
up the outcome from its point of view.

> All this churn makes me believe that we probably just need to stop
> pretending we can achieve any sort of consensus on the approach and let the
> different alternatives develop independently, assumed they can all develop
> independently, and then let natural evolution take its course :)

I tend to agree, but I think that one of the reason why we are looking
for a consensus, is because API evolutions proposed through
Neutron-spec are rejected by core-dev, because they rely on external
components (sdn controller, proprietary hardware...) or they are not a
high priority for neutron core-dev.
By finding a consensus, we show that several players are interested in
such an API, and it helps to convince core-dev that this use-case, and
its API, is missing in neutron.

Now, if there is room for easily propose new API in Neutron, It make
sense to leave new API appear and evolve, and then " let natural
evolution take its course ", as you said.
To me, this is in the scope of the "advanced services" project.

> Ultimately the biggest debate is on what the API model needs to be for these
> abstractions. We can judge on which one is the best API of all, but
> sometimes this ends up being a religious fight. A good API for me might not
> be a good API for you, even though I strongly believe that a good API is one
> that can:
>
> - be hard to use incorrectly
> - clear to understand
> - does one thing, and one thing well
>
> So far I have been unable to be convinced why we'd need to cram more than
> one abstraction in one single API, as it does violate the above mentioned
> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's
> in line with those principles. I'd rather start from there and iterate.
>
> My 2c,
> Armando
>
> On 14 November 2014 08:47, Salvatore Orlando  wrote:
>>
>> Thanks guys.
>>
>> I think you've answered my initial question. Probably not in the way I was
>> hoping it to be answered, but it's ok.
>>
>> So now we have potentially 4 different blueprint describing more or less
>> overlapping use cases that we need to reconcile into one?
>> If the above is correct, then I suggest we go back to the use case and
>> make an effort to abstract a bit from thinking about how those use cases
>> should be implemented.
>>
>> Salvatore
>>
>> On 14 November 2014 15:42, Igor Cardoso  wrote:
>>>
>>> Hello all,
>>> Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
>>> its use cases is exactly the L2 gateway. These proposals could probably be
>>> inserted in a more generic work for moving existing datacenter L2 resources
>>> to Neutron.
>>> Cheers,
>>>
>>> On 14 November 2014 15:28, Mathieu Rohon  wrote:

 Hi,

 As far as I understood last friday afternoon dicussions during the
 design summit, this use case is in the scope of another umbrella spec
 which would define external connectivity for neutron networks. Details
 of those connectivity would be defined through service plugin API.

 Ian do you plan to define such an umbrella spec? or at least, could
 you sum up the agreement of the design summit discussion in the ML?

 I see at least 3 specs which would be under such an umbrella spec :
 https://review.openstack.org/#/c/93329/ (BGPVPN)
 https://review.openstack.org/#/c/101043/ (Inter DC connectivity with
 VPN)
 https://review.openstack.org/#/c/134179/ (l2 gw aas)


 On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
 wrote:
 > Thanks Maruti,
 >
 > I have some comments and questions which I've posted on gerrit.
 > There are two things I would like to discuss on the mailing list
 > concerning
 > this effort.
 >
 > 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
 > https://review.openstack.org/#/c/93613 - I hope so, otherwise this
 > just adds
 > even more complexity.
 >
 > 2) It sounds like you should be able to implement this service plugin
 > in
 > either a feature branch or a repository distinct from neutron. Can you
 > confirm that?
 >
 > Salvatore
 >
 > On 13 November 2014 13:26, Kamat, Maruti Haridas 
 > wrote:
 >>
 >> Hi Friends,
 >>
 >>  As discussed during the summit, I have uploaded the

Re: [openstack-dev] [neutron] L2 gateway as a service

[Armando M.]

Last Friday I recall we had two discussions around this topic. One in the
morning, which I think led to Maruti to push [1]. The way I understood [1]
was that it is an attempt at unifying [2] and [3], by choosing the API
approach of one and the architectural approach of the other.

[1] https://review.openstack.org/#/c/134179/
[2] https://review.openstack.org/#/c/100278/
[3] https://review.openstack.org/#/c/93613/

Then there was another discussion in the afternoon, but I am not 100% of
the outcome.

All this churn makes me believe that we probably just need to stop
pretending we can achieve any sort of consensus on the approach and let the
different alternatives develop independently, assumed they can all develop
independently, and then let natural evolution take its course :)

Ultimately the biggest debate is on what the API model needs to be for
these abstractions. We can judge on which one is the best API of all, but
sometimes this ends up being a religious fight. A good API for me might not
be a good API for you, even though I strongly believe that a good API is
one that can:

- be hard to use incorrectly
- clear to understand
- does one thing, and one thing well

So far I have been unable to be convinced why we'd need to cram more than
one abstraction in one single API, as it does violate the above mentioned
principles. Ultimately I like the L2 GW API proposed by 1 and 2 because
it's in line with those principles. I'd rather start from there and iterate.

My 2c,
Armando

On 14 November 2014 08:47, Salvatore Orlando  wrote:

> Thanks guys.
>
> I think you've answered my initial question. Probably not in the way I was
> hoping it to be answered, but it's ok.
>
> So now we have potentially 4 different blueprint describing more or less
> overlapping use cases that we need to reconcile into one?
> If the above is correct, then I suggest we go back to the use case and
> make an effort to abstract a bit from thinking about how those use cases
> should be implemented.
>
> Salvatore
>
> On 14 November 2014 15:42, Igor Cardoso  wrote:
>
>> Hello all,
>> Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
>> its use cases is exactly the L2 gateway. These proposals could probably be
>> inserted in a more generic work for moving existing datacenter L2 resources
>> to Neutron.
>> Cheers,
>>
>> On 14 November 2014 15:28, Mathieu Rohon  wrote:
>>
>>> Hi,
>>>
>>> As far as I understood last friday afternoon dicussions during the
>>> design summit, this use case is in the scope of another umbrella spec
>>> which would define external connectivity for neutron networks. Details
>>> of those connectivity would be defined through service plugin API.
>>>
>>> Ian do you plan to define such an umbrella spec? or at least, could
>>> you sum up the agreement of the design summit discussion in the ML?
>>>
>>> I see at least 3 specs which would be under such an umbrella spec :
>>> https://review.openstack.org/#/c/93329/ (BGPVPN)
>>> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with
>>> VPN)
>>> https://review.openstack.org/#/c/134179/ (l2 gw aas)
>>>
>>>
>>> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
>>> wrote:
>>> > Thanks Maruti,
>>> >
>>> > I have some comments and questions which I've posted on gerrit.
>>> > There are two things I would like to discuss on the mailing list
>>> concerning
>>> > this effort.
>>> >
>>> > 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
>>> > https://review.openstack.org/#/c/93613 - I hope so, otherwise this
>>> just adds
>>> > even more complexity.
>>> >
>>> > 2) It sounds like you should be able to implement this service plugin
>>> in
>>> > either a feature branch or a repository distinct from neutron. Can you
>>> > confirm that?
>>> >
>>> > Salvatore
>>> >
>>> > On 13 November 2014 13:26, Kamat, Maruti Haridas 
>>> > wrote:
>>> >>
>>> >> Hi Friends,
>>> >>
>>> >>  As discussed during the summit, I have uploaded the spec for
>>> review
>>> >> at https://review.openstack.org/#/c/134179/
>>> >>
>>> >> Thanks,
>>> >> Maruti
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> ___
>>> >> 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
>>>
>>
>>
>>
>> --
>> Igor Duarte Cardoso.
>> http://igordcard.com
>> @igordcard 
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bi

Re: [openstack-dev] [neutron] L2 gateway as a service

[Narasimhan, Vivekanandan]

Hi Salvatore,



Thanks for the review comments on the BP.



Yes, Maruti’s BP supersedes the review https://review.openstack.org/#/c/100278 
posted by Isaku, and we

discussed with  Isaku during the summit to embrace his BP.



For the review https://review.openstack.org/#/c/93613 by Racha , we were not 
able to see how that

idea maps to implementation angle driven in Maruti’s BP.



And Kevin’s idea of giving neutron representation of external-attachment-points 
(good idea),  can be

used in the  implementation of Maruti’s BP  where in the attachment-points can 
be fed to ‘net-gateway-create’

command, instead of giving physical-network switch names/ports.



So we request Kevin , Racha and others, to peruse Maruti’s BP and post 
comments/questions

on the same, more specifically from the resource representation perspective 
(REST APIs and CLIs).



--

Thanks,



Vivek





From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Friday, November 14, 2014 10:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] L2 gateway as a service



Thanks guys.



I think you've answered my initial question. Probably not in the way I was 
hoping it to be answered, but it's ok.



So now we have potentially 4 different blueprint describing more or less 
overlapping use cases that we need to reconcile into one?

If the above is correct, then I suggest we go back to the use case and make an 
effort to abstract a bit from thinking about how those use cases should be 
implemented.



Salvatore



On 14 November 2014 15:42, Igor Cardoso 
mailto:igordc...@gmail.com>> wrote:

Hello all,

Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its 
use cases is exactly the L2 gateway. These proposals could probably be inserted 
in a more generic work for moving existing datacenter L2 resources to Neutron.

Cheers,



On 14 November 2014 15:28, Mathieu Rohon 
mailto:mathieu.ro...@gmail.com>> wrote:

Hi,

As far as I understood last friday afternoon dicussions during the
design summit, this use case is in the scope of another umbrella spec
which would define external connectivity for neutron networks. Details
of those connectivity would be defined through service plugin API.

Ian do you plan to define such an umbrella spec? or at least, could
you sum up the agreement of the design summit discussion in the ML?

I see at least 3 specs which would be under such an umbrella spec :
https://review.openstack.org/#/c/93329/ (BGPVPN)
https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN)
https://review.openstack.org/#/c/134179/ (l2 gw aas)



On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:
> Thanks Maruti,
>
> I have some comments and questions which I've posted on gerrit.
> There are two things I would like to discuss on the mailing list concerning
> this effort.
>
> 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
> https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds
> even more complexity.
>
> 2) It sounds like you should be able to implement this service plugin in
> either a feature branch or a repository distinct from neutron. Can you
> confirm that?
>
> Salvatore
>
> On 13 November 2014 13:26, Kamat, Maruti Haridas 
> mailto:maruti.ka...@hp.com>>
> wrote:
>>
>> Hi Friends,
>>
>>  As discussed during the summit, I have uploaded the spec for review
>> at https://review.openstack.org/#/c/134179/
>>
>> Thanks,
>> Maruti
>>
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







--

Igor Duarte Cardoso.

http://igordcard.com

@igordcard<https://twitter.com/igordcard>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [neutron] L2 gateway as a service

[Salvatore Orlando]

Thanks guys.

I think you've answered my initial question. Probably not in the way I was
hoping it to be answered, but it's ok.

So now we have potentially 4 different blueprint describing more or less
overlapping use cases that we need to reconcile into one?
If the above is correct, then I suggest we go back to the use case and make
an effort to abstract a bit from thinking about how those use cases should
be implemented.

Salvatore

On 14 November 2014 15:42, Igor Cardoso  wrote:

> Hello all,
> Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
> its use cases is exactly the L2 gateway. These proposals could probably be
> inserted in a more generic work for moving existing datacenter L2 resources
> to Neutron.
> Cheers,
>
> On 14 November 2014 15:28, Mathieu Rohon  wrote:
>
>> Hi,
>>
>> As far as I understood last friday afternoon dicussions during the
>> design summit, this use case is in the scope of another umbrella spec
>> which would define external connectivity for neutron networks. Details
>> of those connectivity would be defined through service plugin API.
>>
>> Ian do you plan to define such an umbrella spec? or at least, could
>> you sum up the agreement of the design summit discussion in the ML?
>>
>> I see at least 3 specs which would be under such an umbrella spec :
>> https://review.openstack.org/#/c/93329/ (BGPVPN)
>> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN)
>> https://review.openstack.org/#/c/134179/ (l2 gw aas)
>>
>>
>> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
>> wrote:
>> > Thanks Maruti,
>> >
>> > I have some comments and questions which I've posted on gerrit.
>> > There are two things I would like to discuss on the mailing list
>> concerning
>> > this effort.
>> >
>> > 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
>> > https://review.openstack.org/#/c/93613 - I hope so, otherwise this
>> just adds
>> > even more complexity.
>> >
>> > 2) It sounds like you should be able to implement this service plugin in
>> > either a feature branch or a repository distinct from neutron. Can you
>> > confirm that?
>> >
>> > Salvatore
>> >
>> > On 13 November 2014 13:26, Kamat, Maruti Haridas 
>> > wrote:
>> >>
>> >> Hi Friends,
>> >>
>> >>  As discussed during the summit, I have uploaded the spec for
>> review
>> >> at https://review.openstack.org/#/c/134179/
>> >>
>> >> Thanks,
>> >> Maruti
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> 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
>>
>
>
>
> --
> Igor Duarte Cardoso.
> http://igordcard.com
> @igordcard 
>
> ___
> 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

Re: [openstack-dev] [neutron] L2 gateway as a service

[Igor Cardoso]

Hello all,
Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of
its use cases is exactly the L2 gateway. These proposals could probably be
inserted in a more generic work for moving existing datacenter L2 resources
to Neutron.
Cheers,

On 14 November 2014 15:28, Mathieu Rohon  wrote:

> Hi,
>
> As far as I understood last friday afternoon dicussions during the
> design summit, this use case is in the scope of another umbrella spec
> which would define external connectivity for neutron networks. Details
> of those connectivity would be defined through service plugin API.
>
> Ian do you plan to define such an umbrella spec? or at least, could
> you sum up the agreement of the design summit discussion in the ML?
>
> I see at least 3 specs which would be under such an umbrella spec :
> https://review.openstack.org/#/c/93329/ (BGPVPN)
> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN)
> https://review.openstack.org/#/c/134179/ (l2 gw aas)
>
>
> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando 
> wrote:
> > Thanks Maruti,
> >
> > I have some comments and questions which I've posted on gerrit.
> > There are two things I would like to discuss on the mailing list
> concerning
> > this effort.
> >
> > 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
> > https://review.openstack.org/#/c/93613 - I hope so, otherwise this just
> adds
> > even more complexity.
> >
> > 2) It sounds like you should be able to implement this service plugin in
> > either a feature branch or a repository distinct from neutron. Can you
> > confirm that?
> >
> > Salvatore
> >
> > On 13 November 2014 13:26, Kamat, Maruti Haridas 
> > wrote:
> >>
> >> Hi Friends,
> >>
> >>  As discussed during the summit, I have uploaded the spec for review
> >> at https://review.openstack.org/#/c/134179/
> >>
> >> Thanks,
> >> Maruti
> >>
> >>
> >>
> >>
> >> ___
> >> 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
>



-- 
Igor Duarte Cardoso.
http://igordcard.com
@igordcard 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] L2 gateway as a service

[Mathieu Rohon]

Hi,

As far as I understood last friday afternoon dicussions during the
design summit, this use case is in the scope of another umbrella spec
which would define external connectivity for neutron networks. Details
of those connectivity would be defined through service plugin API.

Ian do you plan to define such an umbrella spec? or at least, could
you sum up the agreement of the design summit discussion in the ML?

I see at least 3 specs which would be under such an umbrella spec :
https://review.openstack.org/#/c/93329/ (BGPVPN)
https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN)
https://review.openstack.org/#/c/134179/ (l2 gw aas)


On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando  wrote:
> Thanks Maruti,
>
> I have some comments and questions which I've posted on gerrit.
> There are two things I would like to discuss on the mailing list concerning
> this effort.
>
> 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
> https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds
> even more complexity.
>
> 2) It sounds like you should be able to implement this service plugin in
> either a feature branch or a repository distinct from neutron. Can you
> confirm that?
>
> Salvatore
>
> On 13 November 2014 13:26, Kamat, Maruti Haridas 
> wrote:
>>
>> Hi Friends,
>>
>>  As discussed during the summit, I have uploaded the spec for review
>> at https://review.openstack.org/#/c/134179/
>>
>> Thanks,
>> Maruti
>>
>>
>>
>>
>> ___
>> 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

Re: [openstack-dev] [neutron] L2 gateway as a service

[Salvatore Orlando]

Thanks Maruti,

I have some comments and questions which I've posted on gerrit.
There are two things I would like to discuss on the mailing list concerning
this effort.

1) Is this spec replacing  https://review.openstack.org/#/c/100278 and
https://review.openstack.org/#/c/93613 - I hope so, otherwise this just
adds even more complexity.

2) It sounds like you should be able to implement this service plugin in
either a feature branch or a repository distinct from neutron. Can you
confirm that?

Salvatore

On 13 November 2014 13:26, Kamat, Maruti Haridas 
wrote:

>  Hi Friends,
>
>  As discussed during the summit, I have uploaded the spec for review
> at *https://review.openstack.org/#/c/134179/*
> 
>
> Thanks,
> Maruti
>
>
>
>
> ___
> 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] [neutron] L2 gateway as a service

[Kamat, Maruti Haridas]

Hi Friends,

 As discussed during the summit, I have uploaded the spec for review at 
https://review.openstack.org/#/c/134179/

Thanks,
Maruti



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[joehuang]

Hi,



Why not use already defined multi-segements (or multi-provider-network) API 
interface, and hide the L2GW explicit manipulation?



Best Regards



Chaoyi Huang ( joehuang )


From: Sukhdev Kapur [sukhdevka...@gmail.com]
Sent: 06 November 2014 19:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] L2 Gateway discussion

resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur 
mailto:sukhdevka...@gmail.com>> wrote:
Folks,

After Maruti's lighting talk on L2 Gateway, bunch of people/vendors expressed 
interest in coming up with an API for this service. The goal is to come up with 
a basic set of API which can be implemented in Kilo time frame and build upon 
it over time in the future.
Armando, Akihiro, and others present in this small discussion decided to get 
together tomorrow morning (Friday) in the Pods area (outside Degas Room) at 
9:30am.

If anybody has any interest in this discussion or can add value to this 
discussion, this will be a great opportunity to stop by.

Thanks
Sukhdev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Igor Cardoso]

I was at Maruti's presentation and it was very interesting. I have
developed a similar PoC so I got even more interested.

The main difference between them, from my understanding during the
presentation, is that my PoC tries to encompass very heteogeneous kinds of
networking equipment. Say, making use of an old old switch from some
vendor, or a different equipment that doesn't even use VLANs.

This is possible due to a pluggable architecture that makes it possible to
develop complete drivers to deal with any network switch/router and
L2-extend their physical/legacy networks towards Neutron (and vice-versa).
One of the drivers I have developed is for OpenWrt, which also allows
instantiating wireless SSIDs remotely (via Neutron) and map them to
specific Neutron networks.

I would like to join you tomorrow. Unfortunately, by that time, I will be
heading back to my home country. Nevertheless, I will be staying on par, as
soon as I get reconnected.

Cheers,

On 6 November 2014 15:54, Kamat, Maruti Haridas  wrote:

>  + Christian
>
>
>
> Hi Everyone,
>
>
>
> The slide-deck is placed at:
> https://drive.google.com/file/d/0B6wARyYJHf0ZRDJvdkJYVjVLVzQ/view?usp=sharing
>
>  References:
>
> https://review.openstack.org/#/c/93613/
>
> https://review.openstack.org/#/c/100278/
>
> https://review.openstack.org/#/ c/87825
> 
>
>
>
> Thanks,
>
> Maruti
>
>
>
> *From:* Sukhdev Kapur [mailto:sukh...@arista.com]
> *Sent:* Thursday, November 06, 2014 2:59 PM
> *To:* Armando M.
> *Cc:* Shiv Haris; Akihiro Motoki; Sukhdev Kapur; rmada...@brocade.com;
> Kamat, Maruti Haridas; isaku yamahata
> *Subject:* Re: L2 gateway spinout
>
>
>
> Folks,
>
>
>
> FYI...
>
> There were more people in the circle discussing this.
>
>
>
> I had sent the same message on dev list to ensure that everybody has
> opportunity to participate - see here
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-November/049907.html
>
>
>
> Please reply to that email than this - so that wider audience gets the
> exposure to this discussion.
>
>
>
> regards..
>
> -Sukhdev
>
>
>
>
>
>
>
>
>
> On Nov 6, 2014 1:42 PM, "Armando M."  wrote:
>
> Hi Shiv,
>
>
>
> Thanks for starting this up.
>
>
>
> Can we put together all the references that might be relevant to this
> effort on this mail thread? This is what I got so far:
>
>
>
> https://review.openstack.org/#/c/93613/
>
> https://review.openstack.org/#/c/100278/
>
>
>
> Cheers,
>
> Armando
>
>
>
> On 6 November 2014 13:26, Shiv Haris  wrote:
>
>
>
> After the L2 lightening talk some folks got interested in getting together
> for a spinout of this project.
>
>
>
> We will be meeting on Friday at 9:30 am outside the Neutron Session area.
>
>
>
> See you there if you are interested in participating in this.
>
>
>
> Please forward this email to all interested.
>
>
>
> Thanks,
>
>
>
> Shiv Haris
>
> irc: shivharis
>
>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Igor Duarte Cardoso.
http://igordcard.com
@igordcard 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] L2 Gateway discussion

[Kamat, Maruti Haridas]

+ Christian

Hi Everyone,

The slide-deck is placed at: 
https://drive.google.com/file/d/0B6wARyYJHf0ZRDJvdkJYVjVLVzQ/view?usp=sharing
References:
https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/
https://review.openstack.org/#/c/87825

Thanks,
Maruti

From: Sukhdev Kapur [mailto:sukh...@arista.com]
Sent: Thursday, November 06, 2014 2:59 PM
To: Armando M.
Cc: Shiv Haris; Akihiro Motoki; Sukhdev Kapur; rmada...@brocade.com; Kamat, 
Maruti Haridas; isaku yamahata
Subject: Re: L2 gateway spinout

Folks,

FYI...
There were more people in the circle discussing this.

I had sent the same message on dev list to ensure that everybody has 
opportunity to participate - see here
http://lists.openstack.org/pipermail/openstack-dev/2014-November/049907.html

Please reply to that email than this - so that wider audience gets the exposure 
to this discussion.

regards..
-Sukhdev




On Nov 6, 2014 1:42 PM, "Armando M." 
mailto:arma...@gmail.com>> wrote:
Hi Shiv,

Thanks for starting this up.

Can we put together all the references that might be relevant to this effort on 
this mail thread? This is what I got so far:

https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/

Cheers,
Armando

On 6 November 2014 13:26, Shiv Haris 
mailto:shivha...@gmail.com>> wrote:

After the L2 lightening talk some folks got interested in getting together for 
a spinout of this project.

We will be meeting on Friday at 9:30 am outside the Neutron Session area.

See you there if you are interested in participating in this.

Please forward this email to all interested.

Thanks,

Shiv Haris
irc: shivharis



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Sukhdev Kapur]

Can we put together all the references that might be relevant to this
effort on this mail thread? This is what I got so far:

https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/

Cheers,
Armando
resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur 
wrote:

> Folks,
>
> After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
> expressed interest in coming up with an API for this service. The goal is
> to come up with a basic set of API which can be implemented in Kilo time
> frame and build upon it over time in the future.
> Armando, Akihiro, and others present in this small discussion decided to
> get together tomorrow morning (Friday) in the Pods area (outside Degas
> Room) at 9:30am.
>
> If anybody has any interest in this discussion or can add value to this
> discussion, this will be a great opportunity to stop by.
>
> Thanks
> Sukhdev
>
>
> ___
> 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

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Sukhdev Kapur]

resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur 
wrote:

> Folks,
>
> After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
> expressed interest in coming up with an API for this service. The goal is
> to come up with a basic set of API which can be implemented in Kilo time
> frame and build upon it over time in the future.
> Armando, Akihiro, and others present in this small discussion decided to
> get together tomorrow morning (Friday) in the Pods area (outside Degas
> Room) at 9:30am.
>
> If anybody has any interest in this discussion or can add value to this
> discussion, this will be a great opportunity to stop by.
>
> Thanks
> Sukhdev
>
>
> ___
> 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