Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers
I will be there for my lightning talk, and I think armax and kevin_benton will be there - it would be good to find some time for us to pow-wow, along with some teleconference so that carl_baldwin and mestery can join in... Ryan Moats (regXboi) Mike Dorman mdor...@godaddy.com wrote on 08/03/2015 10:07:23 PM: From: Mike Dorman mdor...@godaddy.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, OpenStack Operators openstack- operat...@lists.openstack.org Date: 08/03/2015 10:08 PM Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. Some of us from the large deployers group will be at the Ops Meetup. Will there be any representation from Neutron there that we could discuss with more? Thanks, Mike On 8/3/15, 12:27 PM, Carl Baldwin c...@ecbaldwin.net wrote: Kevin, sorry for the delay in response. Keeping up on this thread was getting difficult while on vacation. tl;dr: I think it is worth it to talk through the idea of inserting some sort of a subnet group thing in the model to which floating ips (and router external gateways) will associate. It has been on my mind for a long time now. I didn't pursue it because a few informal attempts to discuss it with others indicated to me that it would be a difficult heavy-lifting job that others may not appreciate or understand. Scroll to the bottom of this message for a little more on this. Carl On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton blak...@gmail.com wrote: Also, in my proposal, it is more the router that is the grouping mechanism. I can't reconcile this with all of the points you make in the rest of your email. You want the collection of subnets that a network represents, but you don't want any other properties of the network. This is closer to what I'm trying to say but isn't quite there. There are some subnets that should be associated with the segments themselves and there are some that should be associated with the collection of segments. I want floating IPs that are not tied the an L2 network. None of the alternate proposals that I'd heard addressed this. that the network object is currently the closest thing we have to representing the L3 part of the network. The L3 part of a network is the subnets. You can't have IP addresses without the subnets, you can't have floating IPs without the subnets, etc. You're right but in the current model you can't have IP addresses without the network either which is actually the point I'm trying to make. A Neutron network is an L2 construct that encapsulates L3 things. By encapsulating them it also provides an implicit grouping. The routed networks proposal basically wants that implicit grouping without the encapsulation or the L2 part. This sounds about right. I think it is wrong to assume that we need an L2 network to encapsulate L3 things. I'm feeling restricted by the model and the insistence that a neutron network is a purely L2 construct. We don't associate floating ips with a network because we want to arp for them. You're taking a consequence of the current model and its constraints and presenting that as the motivation for the model. We do so because there is no better L3 object to associate it to. Don't make assumptions about how people use floating IPs now just because it doesn't fit your use-case well. When an external network is implemented as a real Neutron network (leaving external_network_bridge blank like we suggest in the networking guide), normal ports can be attached and can co-exist/communicate with the floating IPs because it behaves as an L2 network exactly as implied by the API. The current model works quite well if your fabric can extend the external network everywhere it needs to be. Yes, when an external network is implemented as a real Neutron network all of this is true and my proposal doesn't change any of this. I'm wasn't making any such assumptions. I acknowledge that the current model works well in this case and didn't intend to change it for current use cases. It is precisely that because it does not fit my use case well that I'm pursuing this. Notice that a network marked only as external doesn't allow normal tenants to create ports. It must also be marked shared to allow it. Unless tenants are creating regular ports then they really don't care if arp or anything else L2 is involved because such an external network is meant to give access external to the cloud where L2 is really just an implementation detail. It is the deployer that cares because of whatever infrastructure (like a gateway router) needs to work with it. If the L2 is important, then the deployer will not attempt to use an L3 only
Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers
Can you also try to have some sort of remote option? I'd like to attend this, and I'd like Carl to try and attend as well. Thanks! On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats rmo...@us.ibm.com wrote: I will be there for my lightning talk, and I think armax and kevin_benton will be there - it would be good to find some time for us to pow-wow, along with some teleconference so that carl_baldwin and mestery can join in... Ryan Moats (regXboi) Mike Dorman mdor...@godaddy.com wrote on 08/03/2015 10:07:23 PM: From: Mike Dorman mdor...@godaddy.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, OpenStack Operators openstack- operat...@lists.openstack.org Date: 08/03/2015 10:08 PM Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. Some of us from the large deployers group will be at the Ops Meetup. Will there be any representation from Neutron there that we could discuss with more? Thanks, Mike On 8/3/15, 12:27 PM, Carl Baldwin c...@ecbaldwin.net wrote: Kevin, sorry for the delay in response. Keeping up on this thread was getting difficult while on vacation. tl;dr: I think it is worth it to talk through the idea of inserting some sort of a subnet group thing in the model to which floating ips (and router external gateways) will associate. It has been on my mind for a long time now. I didn't pursue it because a few informal attempts to discuss it with others indicated to me that it would be a difficult heavy-lifting job that others may not appreciate or understand. Scroll to the bottom of this message for a little more on this. Carl On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton blak...@gmail.com wrote: Also, in my proposal, it is more the router that is the grouping mechanism. I can't reconcile this with all of the points you make in the rest of your email. You want the collection of subnets that a network represents, but you don't want any other properties of the network. This is closer to what I'm trying to say but isn't quite there. There are some subnets that should be associated with the segments themselves and there are some that should be associated with the collection of segments. I want floating IPs that are not tied the an L2 network. None of the alternate proposals that I'd heard addressed this. that the network object is currently the closest thing we have to representing the L3 part of the network. The L3 part of a network is the subnets. You can't have IP addresses without the subnets, you can't have floating IPs without the subnets, etc. You're right but in the current model you can't have IP addresses without the network either which is actually the point I'm trying to make. A Neutron network is an L2 construct that encapsulates L3 things. By encapsulating them it also provides an implicit grouping. The routed networks proposal basically wants that implicit grouping without the encapsulation or the L2 part. This sounds about right. I think it is wrong to assume that we need an L2 network to encapsulate L3 things. I'm feeling restricted by the model and the insistence that a neutron network is a purely L2 construct. We don't associate floating ips with a network because we want to arp for them. You're taking a consequence of the current model and its constraints and presenting that as the motivation for the model. We do so because there is no better L3 object to associate it to. Don't make assumptions about how people use floating IPs now just because it doesn't fit your use-case well. When an external network is implemented as a real Neutron network (leaving external_network_bridge blank like we suggest in the networking guide), normal ports can be attached and can co-exist/communicate with the floating IPs because it behaves as an L2 network exactly as implied by the API. The current model works quite well if your fabric can extend the external network everywhere it needs to be. Yes, when an external network is implemented as a real Neutron network all of this is true and my proposal doesn't change any of this. I'm wasn't making any such assumptions. I acknowledge that the current model works well in this case and didn't intend to change it for current use cases. It is precisely that because it does not fit my use case well that I'm pursuing this. Notice that a network marked only as external doesn't allow normal tenants to create ports. It must also be marked shared to allow it. Unless tenants are creating regular ports then they really don't care if arp or anything else L2 is involved because
Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers
Ok, cool. We plan to discuss this during the LDT time slot at 1330-1500 Pacific on Tuesday 8/18. We can have this as the first agenda item so there’s a defined start time for those who are remote. I'll take ownership of setting up a hangout (or whatever.) Do people have a preference on what videoconference tool to us? Absent any opinions, I’ll just do a Google Hangout. Thanks! Mike From: Kyle Mestery Date: Tuesday, August 4, 2015 at 8:09 AM To: Ryan Moats Cc: Mike Dorman, OpenStack Development Mailing List (not for usage questions), OpenStack Operators Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers Can you also try to have some sort of remote option? I'd like to attend this, and I'd like Carl to try and attend as well. Thanks! On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats rmo...@us.ibm.commailto:rmo...@us.ibm.com wrote: I will be there for my lightning talk, and I think armax and kevin_benton will be there - it would be good to find some time for us to pow-wow, along with some teleconference so that carl_baldwin and mestery can join in... Ryan Moats (regXboi) Mike Dorman mdor...@godaddy.commailto:mdor...@godaddy.com wrote on 08/03/2015 10:07:23 PM: From: Mike Dorman mdor...@godaddy.commailto:mdor...@godaddy.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, OpenStack Operators openstack- operat...@lists.openstack.orgmailto:operat...@lists.openstack.org Date: 08/03/2015 10:08 PM Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. Some of us from the large deployers group will be at the Ops Meetup. Will there be any representation from Neutron there that we could discuss with more? Thanks, Mike On 8/3/15, 12:27 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: Kevin, sorry for the delay in response. Keeping up on this thread was getting difficult while on vacation. tl;dr: I think it is worth it to talk through the idea of inserting some sort of a subnet group thing in the model to which floating ips (and router external gateways) will associate. It has been on my mind for a long time now. I didn't pursue it because a few informal attempts to discuss it with others indicated to me that it would be a difficult heavy-lifting job that others may not appreciate or understand. Scroll to the bottom of this message for a little more on this. Carl On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton blak...@gmail.commailto:blak...@gmail.com wrote: Also, in my proposal, it is more the router that is the grouping mechanism. I can't reconcile this with all of the points you make in the rest of your email. You want the collection of subnets that a network represents, but you don't want any other properties of the network. This is closer to what I'm trying to say but isn't quite there. There are some subnets that should be associated with the segments themselves and there are some that should be associated with the collection of segments. I want floating IPs that are not tied the an L2 network. None of the alternate proposals that I'd heard addressed this. that the network object is currently the closest thing we have to representing the L3 part of the network. The L3 part of a network is the subnets. You can't have IP addresses without the subnets, you can't have floating IPs without the subnets, etc. You're right but in the current model you can't have IP addresses without the network either which is actually the point I'm trying to make. A Neutron network is an L2 construct that encapsulates L3 things. By encapsulating them it also provides an implicit grouping. The routed networks proposal basically wants that implicit grouping without the encapsulation or the L2 part. This sounds about right. I think it is wrong to assume that we need an L2 network to encapsulate L3 things. I'm feeling restricted by the model and the insistence that a neutron network is a purely L2 construct. We don't associate floating ips with a network because we want to arp for them. You're taking a consequence of the current model and its constraints and presenting that as the motivation for the model. We do so because there is no better L3 object to associate it to. Don't make assumptions about how people use floating IPs now just because it doesn't fit your use-case well. When an external network is implemented as a real Neutron network (leaving external_network_bridge blank like we suggest in the networking guide), normal ports can be attached and can co-exist/communicate with the floating IPs because it behaves as an L2
Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers
Google Hangout should work fine! And Carl and I will both be at Linuxcon and together, so we can dial in together. This time should work for us, so thanks for taking us into consideration Mike! Kyle On Tue, Aug 4, 2015 at 9:29 AM, Mike Dorman mdor...@godaddy.com wrote: Ok, cool. We plan to discuss this during the LDT time slot at 1330-1500 Pacific on Tuesday 8/18. We can have this as the first agenda item so there’s a defined start time for those who are remote. I'll take ownership of setting up a hangout (or whatever.) Do people have a preference on what videoconference tool to us? Absent any opinions, I’ll just do a Google Hangout. Thanks! Mike From: Kyle Mestery Date: Tuesday, August 4, 2015 at 8:09 AM To: Ryan Moats Cc: Mike Dorman, OpenStack Development Mailing List (not for usage questions), OpenStack Operators Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers Can you also try to have some sort of remote option? I'd like to attend this, and I'd like Carl to try and attend as well. Thanks! On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats rmo...@us.ibm.com wrote: I will be there for my lightning talk, and I think armax and kevin_benton will be there - it would be good to find some time for us to pow-wow, along with some teleconference so that carl_baldwin and mestery can join in... Ryan Moats (regXboi) Mike Dorman mdor...@godaddy.com wrote on 08/03/2015 10:07:23 PM: From: Mike Dorman mdor...@godaddy.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, OpenStack Operators openstack- operat...@lists.openstack.org Date: 08/03/2015 10:08 PM Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. Some of us from the large deployers group will be at the Ops Meetup. Will there be any representation from Neutron there that we could discuss with more? Thanks, Mike On 8/3/15, 12:27 PM, Carl Baldwin c...@ecbaldwin.net wrote: Kevin, sorry for the delay in response. Keeping up on this thread was getting difficult while on vacation. tl;dr: I think it is worth it to talk through the idea of inserting some sort of a subnet group thing in the model to which floating ips (and router external gateways) will associate. It has been on my mind for a long time now. I didn't pursue it because a few informal attempts to discuss it with others indicated to me that it would be a difficult heavy-lifting job that others may not appreciate or understand. Scroll to the bottom of this message for a little more on this. Carl On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton blak...@gmail.com wrote: Also, in my proposal, it is more the router that is the grouping mechanism. I can't reconcile this with all of the points you make in the rest of your email. You want the collection of subnets that a network represents, but you don't want any other properties of the network. This is closer to what I'm trying to say but isn't quite there. There are some subnets that should be associated with the segments themselves and there are some that should be associated with the collection of segments. I want floating IPs that are not tied the an L2 network. None of the alternate proposals that I'd heard addressed this. that the network object is currently the closest thing we have to representing the L3 part of the network. The L3 part of a network is the subnets. You can't have IP addresses without the subnets, you can't have floating IPs without the subnets, etc. You're right but in the current model you can't have IP addresses without the network either which is actually the point I'm trying to make. A Neutron network is an L2 construct that encapsulates L3 things. By encapsulating them it also provides an implicit grouping. The routed networks proposal basically wants that implicit grouping without the encapsulation or the L2 part. This sounds about right. I think it is wrong to assume that we need an L2 network to encapsulate L3 things. I'm feeling restricted by the model and the insistence that a neutron network is a purely L2 construct. We don't associate floating ips with a network because we want to arp for them. You're taking a consequence of the current model and its constraints and presenting that as the motivation for the model. We do so because there is no better L3 object to associate it to. Don't make assumptions about how people use floating IPs now just because it doesn't fit your use-case well. When an external network is implemented as a real Neutron network (leaving
Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers
I will be in China that week for the bug hackathon. I will be happy to dial in though assuming it's a reasonable time (e.g. morning PST). On Tue, Aug 4, 2015 at 10:39 AM, Kyle Mestery mest...@mestery.com wrote: Google Hangout should work fine! And Carl and I will both be at Linuxcon and together, so we can dial in together. This time should work for us, so thanks for taking us into consideration Mike! Kyle On Tue, Aug 4, 2015 at 9:29 AM, Mike Dorman mdor...@godaddy.com wrote: Ok, cool. We plan to discuss this during the LDT time slot at 1330-1500 Pacific on Tuesday 8/18. We can have this as the first agenda item so there’s a defined start time for those who are remote. I'll take ownership of setting up a hangout (or whatever.) Do people have a preference on what videoconference tool to us? Absent any opinions, I’ll just do a Google Hangout. Thanks! Mike From: Kyle Mestery Date: Tuesday, August 4, 2015 at 8:09 AM To: Ryan Moats Cc: Mike Dorman, OpenStack Development Mailing List (not for usage questions), OpenStack Operators Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers Can you also try to have some sort of remote option? I'd like to attend this, and I'd like Carl to try and attend as well. Thanks! On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats rmo...@us.ibm.com wrote: I will be there for my lightning talk, and I think armax and kevin_benton will be there - it would be good to find some time for us to pow-wow, along with some teleconference so that carl_baldwin and mestery can join in... Ryan Moats (regXboi) Mike Dorman mdor...@godaddy.com wrote on 08/03/2015 10:07:23 PM: From: Mike Dorman mdor...@godaddy.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, OpenStack Operators openstack- operat...@lists.openstack.org Date: 08/03/2015 10:08 PM Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. Some of us from the large deployers group will be at the Ops Meetup. Will there be any representation from Neutron there that we could discuss with more? Thanks, Mike On 8/3/15, 12:27 PM, Carl Baldwin c...@ecbaldwin.net wrote: Kevin, sorry for the delay in response. Keeping up on this thread was getting difficult while on vacation. tl;dr: I think it is worth it to talk through the idea of inserting some sort of a subnet group thing in the model to which floating ips (and router external gateways) will associate. It has been on my mind for a long time now. I didn't pursue it because a few informal attempts to discuss it with others indicated to me that it would be a difficult heavy-lifting job that others may not appreciate or understand. Scroll to the bottom of this message for a little more on this. Carl On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton blak...@gmail.com wrote: Also, in my proposal, it is more the router that is the grouping mechanism. I can't reconcile this with all of the points you make in the rest of your email. You want the collection of subnets that a network represents, but you don't want any other properties of the network. This is closer to what I'm trying to say but isn't quite there. There are some subnets that should be associated with the segments themselves and there are some that should be associated with the collection of segments. I want floating IPs that are not tied the an L2 network. None of the alternate proposals that I'd heard addressed this. that the network object is currently the closest thing we have to representing the L3 part of the network. The L3 part of a network is the subnets. You can't have IP addresses without the subnets, you can't have floating IPs without the subnets, etc. You're right but in the current model you can't have IP addresses without the network either which is actually the point I'm trying to make. A Neutron network is an L2 construct that encapsulates L3 things. By encapsulating them it also provides an implicit grouping. The routed networks proposal basically wants that implicit grouping without the encapsulation or the L2 part. This sounds about right. I think it is wrong to assume that we need an L2 network to encapsulate L3 things. I'm feeling restricted by the model and the insistence that a neutron network is a purely L2 construct. We don't associate floating ips with a network because we want to arp for them. You're taking a consequence of the current model and its constraints and presenting that as the motivation for the model. We do so because there is no better L3 object
