Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
Miguel, As a telco operator, who is active in the WG, I am absolutely an interested party for QoS. I’d be willing to hop between the two of them if absolutely necessary (it’s IRC, after all) but would prefer they not overlap if possible. Thanks! -Anthony On Apr 15, 2015, at 6:39 , Miguel Angel Ajo Pelayo mangel...@redhat.commailto:mangel...@redhat.com wrote: I saw Mathieu Rohon message on the mail list archive, but it didn’t reach my inbox for some reason: Hi, It will overlap with the Telco Working group weekly meeting [1]. It's too bad, since Qos is a big interest for Telco Cloud Operator! Mathieu [1]https://wiki.openstack.org/wiki/TelcoWorkingGroup#Meetings My intention was to set the meeting one hour earlier, but it seems that the DST time changes got to confuse me, I’m very sorry. I’m ok with moving the meeting 1 hour later (15:00 UTC) for future meetings, as long as it still works for other people interested in the QoS topic. Mathieu, I’m not sure if people from the telco meeting would be interested in participation on this meeting, but my participation on the TWG meeting would probably help getting everyone in sync. Best, Miguel Ángel On 14/4/2015, at 10:43, Miguel Angel Ajo Pelayo mangel...@redhat.commailto:mangel...@redhat.com wrote: Ok, after one week, looks like the most popular time slot is B, that is 14:00 UTC / Wednesdays. I’m proposing first meeting for Wednesday / Apr 22th 14:00 UTC / #openstack-meeting-2. Tomorrow (Apr 15th / 14:00 UTC) It’s a been early since the announcement, so I will join #openstack-meeting-2 while working on the agenda for next week, feel free to join if you want/have time. On 9/4/2015, at 22:43, Howard, Victor victor_how...@cable.comcast.commailto:victor_how...@cable.comcast.com wrote: I prefer Timeslot B, thanks for coordinating. I would be interested in helping out in any way with the design session let me know! From: Sandhya Dasu (sadasu) sad...@cisco.commailto:sad...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 12:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel, Both time slots work for me. Thanks for rekindling this effort. Thanks, Sandhya From: Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 1:45 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote: On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: On 7 April 2015 at 00:33, Armando M. arma...@gmail.commailto:arma...@gmail.com wrote: On 6 April 2015 at 08:56, Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] As you surely know, so far every attempt to achieve a consensus has failed in a pretty miserable way. This mostly because QoS can be interpreted in a lot of different ways, both from the conceptual and practical perspective. Yes, I’m fully aware of it, it was also a new feature, so it was out of scope for Kilo. It is important in my opinion to clearly define the goals first. For instance a simple extensions for bandwidth limiting could be a reasonable target for the Liberty release. I quite agree here, but IMHO, as you said it’s a quite open field (limiting, guaranteeing, marking, traffic shaping..), we should do our best in trying to define a model allowing us to build that up in the future without huge changes, on the API side I guess micro versioning is going to help in the API evolution. Also, at some point, we should/could need to involve the nova folks, for example, to define port flavors that can be associated to nova instance flavors, providing them 1) different types of network port speeds/guarantees/priorities, 2) being able to schedule instance/ports in coordination to be able to met specified guarantees. yes, complexity can sky rocket fast, Moving things such as ECN into future works is the right thing to do in my opinion. Attempting to define a
Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
On Apr 15, 2015, at 10:00 , Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Ok, 1) #openstack-meeting-2 doesn’t exist (-alt is it) 2) and not only that we’re colliding the TWG meeting, but all the meeting rooms starting at UTC 14:30 are busy. While not preferable, I don’t mind overlapping that meeting. I can be in both places. 3) If we move -30m (UTC 13:30) then we could use meeting room #openstack-meeting-3 before the neutron drivers meeting, and removing some overlap with the TGW meeting. But I know it’s an awful time (yet more) for anyone in the USA west coast. What do you think? This time is fine for me, but I’m EDT so it’s normal business hours here. #openstack-meeting-3 @ UTC 13:30 sounds good for everybody, or should we propose some other timeslot? What a wonderful meeting organizer I am… :/ You’re doing fine! It’s an international organization. It is by definition impossible to select a timeslot that’s perfect for everyone. Best, Miguel Ángel? Unless we’re able to live with 30min, we may need to move the meeting -Anthony __ 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] [QoS] QoS weekly meeting
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [QoS] QoS weekly meeting
On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo majop...@redhat.commailto:majop...@redhat.com wrote: Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, Yes, it’s been posted on github[1]. IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*, I’m sure there are lots of logic that we could reuse from the DSCP perspective, and even if API or internal implementation differs in the end, you’re going to get equivalent logic as soon as diffserv/DSCP is implemented. Absolutely. I’m by no means insinuating that what we have is the only way, or even the ‘right’ way. We had to do it for business requirements so we just got it done and are carrying patches. I’m definitely interested in Salvatore’s suggestion for starting with how to define things in the API first. Best regards, Miguel Ángel On 7/4/2015, at 15:07, Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [QoS] QoS weekly meeting
On Apr 7, 2015, at 11:05 , Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo majop...@redhat.commailto:majop...@redhat.com wrote: Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, Yes, it’s been posted on github[1]. The URL would have helped. [1] https://github.com/netoisstools/neutron/ IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*, I’m sure there are lots of logic that we could reuse from the DSCP perspective, and even if API or internal implementation differs in the end, you’re going to get equivalent logic as soon as diffserv/DSCP is implemented. Absolutely. I’m by no means insinuating that what we have is the only way, or even the ‘right’ way. We had to do it for business requirements so we just got it done and are carrying patches. I’m definitely interested in Salvatore’s suggestion for starting with how to define things in the API first. Best regards, Miguel Ángel On 7/4/2015, at 15:07, Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Telco][NFV][infra] Review process of TelcoWG use cases
On Feb 6, 2015, at 8:17 , Jeremy Stanley fu...@yuggoth.org wrote: On 2015-02-06 12:11:40 +0100 (+0100), Marc Koderer wrote: [...] Therefore I uploaded one of them (Session Border Controller) to the Gerrit system into the sandbox repo: https://review.openstack.org/#/c/152940/1 [...] This looks a lot like the beginnings of a specification which has implications for multiple OpenStack projects. Would proposing a cross-project spec in the openstack/openstack-specs repository be an appropriate alternative?\ It does look like that. However, the intent here is to allow non-developer members of a Telco provide the use cases they need to accomplish. This way the Telco WG can identify gaps and file a proper spec into each of the OpenStack projects. - we create a project under Stackforge called telcowg-usecases - we link blueprint related to this use case - we build a core team and approve/prioritize them I suppose this somewhat parallels how the API Working Group has decided to operate, so perhaps you just need a dedicated repository for Telco Working Group documents in general... some of which would percolate to cross-project specs (or maybe just related per-project specs) once sufficiently refined for a broader audience? We’re considering a proper repo. As Marc said, this is our first attempt at seeing if this can actually work. -- Jeremy Stanley __ 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 -Anthony __ 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] Lightning talks during the Design Summit!
I’ll +1 this. I think this is going to be relevant to quite a few things, including NFV and routing (if you want to establish an L2 neighbor for ISIS…). This seems like a useful feature. -Anthony Maruti's talk is, in fact, so interesting that we should probably get together and talk about this earlier in the week. I very much want to see virtual-physical programmatic bridging, and I know Kevin Benton is also interested. Arguably the MPLS VPN stuff also is similar in scope. Can I propose we have a meeting on cloud edge functionality? -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno
On 10/3/14, 14:58 , Henry Gessau ges...@cisco.com wrote: There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut. These bugs are quite important for IPv6 users and therefore I would like to lobby for getting them into a possible RC2 of Neutron Juno. These are low-risk fixes that would not jeopardize the stability of Neutron. 1. Network:dhcp port is not assigned EUI64 IPv6 address for SLAAC subnet Bug: https://bugs.launchpad.net/neutron/+bug/1330826 Fix: https://review.openstack.org/101433 2. Cannot set only one of IPv6 attributes while second is None Bug: https://bugs.launchpad.net/neutron/+bug/1363064 Fix: https://review.openstack.org/117799 The third one will probably not be allowed since it requires a string freeze exception, but I will mention it anyway ... 3. IPv6 slaac is broken when subnet is less than /64 Bug: https://bugs.launchpad.net/neutron/+bug/1357084 Fix: https://review.openstack.org/116525 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I¹ll second this notion. #2 is particularly important, as several modes like provider networking are going to be broken without this. -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota
Using the quota system would be a nice option to have. Can you clarify what you mean by cumulative bandwidth for the tenant? It would be possible to rate limit at the tenant router, but having a cumulative limit enforced inside of a tenant would be difficult. On Wed, Sep 10, 2014 at 1:03 AM, Giuseppe Cossu giuseppe.co...@create-net.orgmailto:giuseppe.co...@create-net.org wrote: Hello everyone, Looking at the QoS blueprint (proposed for incubation), I suggest to consider adding some parameters to Neutron Quotas. Let’s suppose using rate-limit for managing QoS. The quota parameters could be such as rate_limit (per port) and max_bandwidth (per tenant). In this way it is possible to set/manage QoS quotas from the admin side, and for instance set the maximum bandwidth allowed per tenant (cumulative). What do you think about it? I’m cautious about this. We’d either need to allow a “Number of DSCP settings” and set them outside the quota or leave it out altogether. Let’s not forget that there’s more than just rate limiting in QoS, and we need to make sure all the options are included. Otherwise, there’s going to be a lot of user and operator confusion as to what is and isn’t considered part of the quota. -Anthony Regards, Giuseppe Giuseppe Cossu CREATE-NET ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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][IPv6] Neighbor Discovery for HA
Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.commailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd now. The HA failover simply needs to start the proper radvd process on the secondary gateway and resume normal operation. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://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][IPv6] Neighbor Discovery for HA
Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.commailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd now. The HA failover simply needs to start the proper radvd process on the secondary gateway and resume normal operation. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Specs repository update and the way forward
+1 to this. It would be great to read the compiled spec and have it be searchable/filtered. -Anthony Thank you for the update, Kyle. I was sceptical about this move at first but hopefully I was wrong. The specs repository indeed eases a lot of the work from a submitter and reviewer point of view. Is there any web page where all approved blueprints are being published to? Jenkins builds such pages I’m looking for but they are linked to each patchset individually (e.g., http://docs-draft.openstack.org/77/92477/6/check/gate-neutron-specs-docs/f05cc1d/doc/build/html/). In addition, listing BPs currently under reviewing and linking to its review.o.o page could potentially draw more attention/awareness to what’s being proposed to Neutron (and other OpenStack projects). Thanks, Carlos Goncalves On 11 Jun 2014, at 18:25, Kyle Mestery mest...@noironetworks.commailto:mest...@noironetworks.com wrote: tl;dr: The specs repository has been great to work with. As a reviewer, it makes reviews easier. As PTL, it makes tracking easier as well. Since Juno-1 is about to close, I wanted to give everyone an update on Neutron's usage of the specs repository. These are observations from using this since a few weeks before the Summit. I thought it would be good to share with the broader community to see if other projects using spec repositories had similar thoughts, and I also wanted to share this info for BP submitters and reviewers. Overall, the spec repository has been great as a tool to consolidate where new ideas are documented and made into something we can merge and move forward with. Using gerrit for this has been great. We've merged a good amount of specs [1], and the process of hooking these to Launchpad for milestone tracking has been straightforward. As the PTL of Neutron, I've found the specs repository helps me out immensely, the workflow is great. One of the things I've noticed is that sometimes it's hard to get submitters to respond to feedback on the specs repository. If you look at our current queue of open BPs [2], we have a lot which are waiting for feedback from submitters. I don't know how to address this issue, any feedback appreciated here. Secondly, with so many open BPs, it's unlikely that all of these will make Juno. With what we already have approved and being worked, a lot of these will likely slide to the K release. At some point in the next few weeks, I may start going through some and marking them as such. So, to summarize, I'm very happy with the workflow from the specs repository. Thanks for reading! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z [2] https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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][IPv6] Privacy extension
I’ll take this one a step further. I think one of the methods for getting (non-NAT) floating IPs in IPv6 would be to push a new, extra address to the same port. Either by crafting an extra, unicast RA to the specific VM or providing multiple IA_NA fields in the DHCPv6 transaction. This would require multiple addresses to be allowed on a single MAC. -Anthony From: Martinx - ジェームズ thiagocmarti...@gmail.commailto:thiagocmarti...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 14:18 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension Hello! I agree that there is no need for Privacy Extensions in a Cloud environment, since MAC address are fake... No big deal... Nevertheless, I think that should be nice to allow 1 Instance to have more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, a VM with, for example, a range of IPv6s to it, can have a shared host environment when each website have its own IPv6 address (I prefer to use IP-Based virtualhosts on Apache, instead of Name-Based)... Cheers! Thiago On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: I was just about to respond to that in the session when we ran out of time. I would vote for simply insisting that VMs run without the privacy extension enabled, and only permitting the expected ipv6 address based on MAC. Its primary purpose is to conceal your MAC address so that your IP address can't be used to track you, as I understand it, and I don't think that's as relevant in a cloud environment and where the MAC addresses are basically fake. Someone interested in desktop virtualisation with Openstack may wish to contradict me... -- Ian. On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.commailto:sparkofwisdom.cl...@gmail.com wrote: Hi, guys: Nice to meet with all of you in the technical session and design session. I mentioned the challenge of privacy extension in the meeting, but would like to hear your opinions of how to address the problem. If you have any comments or suggestions, please let me know. I will create a BP for this problem. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Baremetal][Neutron] SDN Solution for Openstack Baremetal Driver
This is a discussion that warrants a broader audience, as others are likely to have a very similar need. It would be good to get something like this documented, and perhaps bolted on to the operators’ guide or somewhere similarly appropriate. -Anthony Hi Tim, NTT-docomo and VTJ developed network isolation in baremetal before they merging baremetal driver to upstream, and I also supported them by providing SDN(OpenFlow) controller plugin. I don't have good article to explain that for now, but I can have discussion if you are in the summit. Regards, Ryota ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit
Hi, The only issue I would see with the pod is that not all of us are ATCs, so we may or may not have access to that area (I am open to correction on that point - in fact I hope someone does ;) ) I’ll second this. I have an interest in attending and assisting here, but I don’t have ATC status yet (though I’m an active contributor technically, just not via code.) I could see it fitting in with our design session, but maybe if we meet on the Monday to do some initial hashing out as well, I think that would be good. I am around for the morning, and later on in the afternoon on Monday, if that suits. Graham On Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote: I have just updated my etherpad [1] with some proposed times. Not knowing much about the venue, I could only propose the pod area as a the location. I also updated the designate session etherpad [2] per your suggestion. If there is time during the Designate sessions to include this in the discussion then that may work out well. Thanks, Carl [1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate [2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride jmcbr...@rackspace.commailto:jmcbr...@rackspace.com wrote: On 4/29/14, 3:09 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote:I feel this is an important subject to discuss because the end resultwill be a better cloud user experience overall. The design summitcould be a great time to bring together interested parties fromNeutron, Nova, and Designate to discuss the integration that I proposein these blueprints. Do you have a time/location planned for these discussions? If not, we may have some time in one of the Designate sessions. The priorities and details for our design session will be pulled from https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you are interested in joining us, can you add your proposed blueprints in the format noted there? Thanks, joe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://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] Security Group logging
On Wed, 2014-04-09 at 00:02 +0100, Salvatore Orlando wrote: Auditing has been discussed for the firewall extension. However, it is reasonable to expect some form of auditing for security group rules as well. To the best of my knowledge there has never been an explicit decision to not support logging. However, my guess here is that we might be better off with an auditing service plugin integrating with security group and firewall agents rather than baking the logging feature in the security group extension. Please note that I'm just thinking aloud here. +1. A notification event should be sent across the typical notifier mechanisms when a security group rule is changed or applied. Throwing my hat in the ring for this as well. Preferably the message should include the UUID of the Group being changed, and also the UUID of the Instance if it¹s being applied. Best, -jay ___ 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][LBaaS] Mini-summit Interest?
On Thu, 2014-03-06 at 15:32 +, Jorge Miramontes wrote: I'd like to gauge everyone's interest in a possible mini-summit for Neturon LBaaS. If enough people are interested I'd be happy to try and set something up. The Designate team just had a productive mini-summit in Austin, TX and it was nice to have face-to-face conversations with people in the Openstack community. While most of us will meet in Atlanta in May, I feel that a focused mini-summit will be more productive since we won't have other Openstack distractions around us. Let me know what you all think! ++ ++ I think a few weeks after the design summit would be a good time. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Throwing my hat into the ring as well. I think this would be quite useful. -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Ensure that configured gateway is on subnet by default
This would break IPv6. The gateway address, according to RFC 4861[1] Section 4.2 regarding Router Advertisements: Source Address MUST be the link-local address assigned to the interface from which this message is sent. This means that if you configure a subnet with a Globally Unique Address scope, the gateway by definition cannot be in the configured subnet. Please don't force this option, as it will break work going on in the Neutron IPv6 sub-team. -Anthony [1] http://tools.ietf.org/html/rfc4861 Hi, Neutron permits to set a gateway IP outside of the subnet cidr by default. And, thanks to the garyk's patch [1], it's possible to change this default behavior with config flag 'force_gateway_on_subnet'. This flag was added to keep the backward compatibility for people who need to set the gateway outside of the subnet. I think this behavior does not reflect the classic usage of subnets. So I propose to update the default value of the flag 'force_gateway_on_subnet' to True. Any thought? [1] https://review.openstack.org/#/c/19048/ Regards, Édouard. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of NAT
Hello Stackers! It is very nice to watch the OpenStack evolution in IPv6! Great job guys!! Thanks! I have another idea: Floating IP for IPv6, or just Floating IPv6 With IPv4, as we know, OpenStack have a feature called Floating IP, which is basically a 1-to-1 NAT rule (within tenant's Namespace q-router). In IPv4 networks, we need this Floating IP attached to a Instance, to be able to reach it from the Internet (I don't like it). But, what is the use case for a Floating IP when you have no NAT* (as it is with IPv6)?! There are definitely cases for it, and we were planning to address it in a future release. At first, when with IPv6, I was planning to disable the Floating IP feature entirely, by removing it from Dashboard and from APIs (even for IPv4, if FWaaS can in somehow, be able to manage q-router IPv4 NAT rules, and not only the iptables filter table) and, I just had an idea! For IPv6, the Floating IP can still be used to allocate more (and more) IPs to a Instance BUT, instead of creating a NAT rule (like it is for IPv4), it will configure the DNSMasq (or something like it) to provide more IPv6 address per MAC / Instance. That way, we can virtually allocate unlimited IPs (v6) for each Instance! It will be pretty cool to see the attached Floating IPv6, literally floating around the tenant subnet, appearing inside the Instances itself (instead of inside the tenant's Namespace), so, we'll be able to see it (the Floating IPv6) with ip -6 address command within the attached Instance! The only problem I see with this is that, for IPv4, the allocated Floating IPs come from the External Network (neutron / --allocation-pool) and, for IPv6, it will come from the tenant's IPv6 subnet itself... I think... Right?! I think the real issue here is how neutron handles these from a network/port perspective. In the IPv4 case, the IPs are from and entirely separate block. I think that should probably stay the same for IPv6, since you have twofold problems: 1. You've already issued an RA on the network for a specific address scope. Another one, when an interface is already addressed, won't trigger adding a new address. 2. Routing. Which address should be the source address? If it's on the same network, the majority of distributions will ignore further routes and addresses for the purpose of sourcing packets. Because of the above, it would make sense for floats to end up on a floating IP subnet. However, we'd go back to earlier neutron issues about having multiple subnets on a network. So then, we end up with a new network, a new subnet and a new port. My personal vote is to go this route. --- Why I want tons of IPv6 within each Instance? A.: Because we can! I mean, we can go back to the days when we had 1 website per 1 public IP (i.e. using IP-Based Virtual Hosts with Apache - I prefer this approach). Also, we can try to turn the Floating IPv6, in some kind of Floating IPv6 Range, this way, we can for example, allocate millions of IPs per Instance, like this in DHCPv6: range6 2001:db8:1:1::1000 2001:db8:1:1000:1000;... I'd also argue for security/policy/reserved addressing reasons. Also, let's not get into the habit of assigning loads of addresses. Each network needs to be a /64, and going all out means you're back to the exhaustion issue we have in IPv4 ;) --- NOTE: I prefer multiple IPs per Instance, instead of 1 IP per Instance, when using VT, unless, of course, the Instances are based on Docker, so, with it, I can easily see millions of tiny instances, each of it with its own IPv6 address, without the overhead of virtualized environment. So, with Docker, this Floating IPv6 Range doesn't seems to be useful... * I know that there is NAT66 out there but, who is actually using it?! I'll never use this thing. Personally I dislike NAT very much, mostly because it breaks the end-to-end Internet connectivity, effectively kicking you out from the real Internet, and it is just a workaround created to deal with IPv4 exhaustion. As a long-time IPv6 engineer, I will advocate against NAT wherever I possibly can. +1 to this! BTW, please guys, let me know if this isn't the right place to post ideas for OpenStack / feature requests... I don't want to bloat this list with undesirable messages. It absolutely is! Also, you might want to join the discussions for the IPv6 sub-team: https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam Best Regards, Thiago Martins -Anthony Veiga ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Validating Addressing and Routing configuration
During last week's IRC meeting, we ran into a question about validating the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for IPv6 networks. This brought up a few issues, but after mulling it over for a while I think it breaks down into 2 distinct questions. Question 1) Should we allow the user to build a potentially broken network, knowing that there may be a use case we haven't covered? The example of this is a service VM or corner case where it's absolutely mandatory that an administrator use an external routing/addressing mechanism that doesn't fit under our configuration options. I was asked to put together a list of cases where a potentially invalid configuration for OpenStack is still valid when external entities are in use. One of these is setting ipv6_address_mode to stateful and ipv6_ra_mode to none. Normally, this means a neutron network would never have addressed clients as no RA means no address. However, a provider network with an external router would provide this. So having the addressing mode in any state without an RA is still valid. The opposite case would also be true, where an external source could be providing dhcpv6 information. In this case, addressing could be set to off, but RA could be set to stateful/stateless. The only case where I see a collision is where the two attributes are on but in entirely different modes. For example, RA set to SLAAC but addressing set to stateful. Question 2) How do we alert the user of either a potentially invalid configuration or a configuration that we have blocked? Something else that came up in a Review[2] was that we need to honor enable_dhcp and alert the user as well. Per ijw[3], we are supposed to treat enable_dhcp as an overriding flag. If it's set to false, we don't even check the other two attributes, because we should be disabling addressing for this network. I think the answer to #2 should apply here as well, but I wanted to point out that we should be treating enable_dhcp = False as a killswitch. [1] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [2] https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py [3] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014 -01-21-14.00.log.html timestamp 14:23:54 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
I vote address them (ipv6_). There's no guarantee of forward compatibility with a new protocol and this way it can't be confused with a (non-existant) selection method for IPv4, either. Also, future updates of other protocols would require a new attribute and break the API less. -Anthony OK - any suggestions for the names of API attributes? The PDF[0] shared does not specify the names of the attributes, so I had two ideas for the names of the two new attributes being added to the Subnet resource: Either prefix them with ipv6 * ipv6_ra_mode * ipv6_address_mode Or don't prefix them: * ra_mode * address_mode Thoughts? [0]: https://www.dropbox.com/s/rq8xmbruqthef38/IPv6%20Two%20Modes%20v2.0.pdf -- Sean M. Collins ___ 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][IPv6] A pair of mode keywords
An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. We were initially intending to treat enable_dhcp as an on-off flag for IPv6. If it's off, then we won't even bother with the other two attributes. Because of the issues already being discussed elsewhere in Neutron, you can't assign multiple scopes to a subnet so it's safe to assume that there won't be an IPv4 scope in an IPv6 subnet. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.commailto:sparkofwisdom.cl...@gmail.com wrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.commailto:sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Allow multiple subnets on gateway port for router
-- (rebroadcast to dev community from prior unicast discussion) -- Hi Nir Sorry if the description is misleading. Didn't want a large title, and hoped that the description would provide those additional details to clarify the real goal of what's included and what's not included. #1. Yes, it's only the gateway port. With that said, there are a series of BP that are being worked to support the dual-stack use case (although not necessarily dependent on each other) across Neutron, including internal ports facing the tenant. https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword https://blueprints.launchpad.net/neutron/+spec/neutronclient-support-dnsmasq-mode-keyword https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-relay-agent https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless I'd suggest popping into the ipv6-subteam's meetings [1] and having further discussions about this as well. We've been working on address allocation for the most part, but routing and service integration will need to be the next step. #2. Surely it's possible to have multiple v4 and v6 [global] addresses on the interface, but for the gateway port, I don't have a specific use case. To remain consistent with current feature capability (single v4 IP), I continue to restrict a single IP from each flavor. With that said, there's nothing technically preventing this. It can be done; however, the CLI and Horizon would likely need significant changes. Right now, the code is written such that it explicitly prevents it. As I mentioned before, I actually had to add code in to disallow multiple addresses of the same flavor and send back an error to the user. Of course, we can evolve it in the future if a use-case warrants it. The use case is for networks that rely on IP allocations for security. You may want a pair of separate routed blocks on the same network for, say, a public network for the web server to get through a policy to the Internet, but a separate address to get to an internal-only database cluster somewhere. I'm not saying it's the greatest way to do things, but I am sure there are people running networks this way. The alternative would be to spin up another port on another network and configure another gateway port as well. Thanks Randy On Thu, Jan 9, 2014 at 4:16 AM, Nir Yechiel nyech...@redhat.commailto:nyech...@redhat.com wrote: Hi Randy, I don't have a specific use case. I just wanted to understand the scope here as the name of this blueprint (allow multiple subnets on gateway port for router) could be a bit misleading. Two questions I have though: 1. Is this talking specifically about the gateway port to the provider's next-hop router or relevant for all ports in virtual routers as well? 2. There is a fundamental difference between v4 and v6 address assignment. With IPv4 I agree that one IP address per port is usually enough (there is the concept of secondary IP, but I am not sure it's really common). With IPv6 however you can sure have more then one (global) IPv6 on an interface. Shouldn't we support this? Thanks, Nir From: Randy Tuttle randy.m.tut...@gmail.commailto:randy.m.tut...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: rantu...@cisco.commailto:rantu...@cisco.com Sent: Tuesday, December 31, 2013 6:43:50 PM Subject: Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router Hi Nir Good question. There's absolutely no reason not to allow more than 2 subnets, or even 2 of the same IP versions on the gateway port. In fact, in our POC we allowed this (or, more specifically, we did not disallow it). However, for the gateway port to the provider's next-hop router, we did not have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron today, only a single subnet is allowed per interface (either v4 or v6). So all we are doing is opening up the gateway port to support what it does today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the gateway port (and same network/vlan). Our principle use case is to enable IPv6 in an existing IPv4 environment. Do you have a specific use case requiring 2 or more of the same IP-versioned subnets on a gateway port? Thanks Randy On Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel nyech...@redhat.commailto:nyech...@redhat.com wrote: Hi, With regards to https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port, can you please clarify this statement: We
Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting
-Original Message- From: Kyle Mestery mest...@siliconloons.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, December 10, 2013 10:48 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] Third party Neutron plugin testing meeting Last week I took an action item to organize a meeting for everyone who is doing third-party testing in Neutron for plugins, whether this is vendor or Open Source based. The idea is to share ideas around setups and any issues people hit. I'd like to set this meeting up for this week, Thursday at 1700UTC. I would also like to propose we make this a dial in meeting using the Infrastructure Conferencing bridges [1]. If this time works, I'll set something up and reply to this thread with the dial in information. +1 for the meeting time. Any particular reason for voice over IRC? Also, I've started a etherpad page [2] with information. It would be good for people to add information to this etherpad as well. I've coupled this pad with information around multi-node gate testing for Neutron as well, as I suspect most of the third-party testing will require multiple nodes as well. I'll start filling out our setup. I have some questions around Third-Party Testing in particular, and look forward to this discussion. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest ___ 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][IPv6] Provisioning Support
As part of the discussion around managing IPv6-addressed hosts both within neutron itself and other systems that require address information, Sean Collins and I had had a discussion about the types of addresses that could be supported. Since IPv6 has many modes of provisioning, we will need to provide support for each of them. However, there is a caveat when dealing with SLAAC provisioning. The only method of provisioning that is predictable from Neutron's point of view is EUI-64. Dazhao Yu has worked on a patch set to do this [1]. Privacy Extensions are in use and well documented by the IETF (RFC 4941), however it is not feasible for Neutron to predict these addresses. Thus it is my opinion that OpenStack should officially support using EUI-64 only for provisioning addresses via SLAAC. This does not preclude PE methods from functioning, but it will be impossible to provide the guest's IPv6 address to other systems such as FWaaS or LBaaS. Also, this is only for SLAAC provisioning mode. Stateful (DHCPv6) and static injection should not be impacted here. To this end, I'd like to propose that OpenStack officially support guests using EUI-64 when using SLAAC for provisioning. Note that I am NOT proposing anything regarding DHCPv6 or static provisioning, as I believe that should allow any of the existing allocation methods. [1] https://review.openstack.org/#/c/56184/ -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 sub-team?
As an IPv6 engineer interesting in helping Neutron get where it could be, I'd like to join in on this. I also like the Thursday 21:00 UTC slot. -Anthony -Original Message- From: Shixiong Shang sparkofwisdom.cl...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, November 12, 2013 10:01 To: Collins, Sean (Contractor) sean_colli...@cable.comcast.com Cc: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team? Thanks, Sean! I am on east coast, so Monday 20:00 UTC time and Thursday 21:00 UTC time work great for me. Hopefully we can find a timeslot working for everybody! Shixiong On Nov 11, 2013, at 1:23 PM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: On Mon, Nov 11, 2013 at 01:16:43PM -0500, Shixiong Shang wrote: +1. We have great interest to run OpenStack over IPv6 and would love to be a part of the discussion. Excellent - please see the thread I've made in OpenStack-Dev - we're tossing out times for the IRC meeting, that works for everyone interested. -- Sean M. Collins ___ 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
