Hi Arzhel,
now that our BGP thing is mostly working, I think we can move forward with IPv6 for codfw1dev, which was my original intention before doing anything related to BGP :-P
We would need to:
* allocate a small IPv6 prefix for the transport network (between cr-codfw and the neutron virtual router). I'm open to suggestion to the size of this subnet.
* allocate a big IPv6 prefix that we could use internally inside the cloud environment (for VMs). This should probably be a /48? I'm not sure yet if I would be doing subnetting of this big prefix and allocate smaller ones (/64) per project, or if we will be using the big one directly without sub-delegation. (Something to research anyway).
I will follow-up next week. For the record, doing this research and design is one my goals/OKRs for this quarter (3 week left!). My plan is to use this wikitech page as my deliverable:
https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhancemen...
regards.
Hi!
CCing Faidon if it's urgent as I'll be out next week.
A /64 for the transport network and a /48 per cloud environment (/site) sounds good to me. Exact prefixes TBD but it should be quick to assign. I don't know (yet) what's OpenStack best practices for v6 but I can probably do some research as well. Instinct tells me that splitting the /48 is more future-proof. About OKRs, please let me know in advance so I can prioritize accordingly :) Related, I still have to create a Google doc to strawman/discuss dedicated hardware (switches, routers).
Cheers.
On Fri, Mar 6, 2020 at 1:57 PM Arturo Borrero Gonzalez < aborrero@wikimedia.org> wrote:
Hi Arzhel,
now that our BGP thing is mostly working, I think we can move forward with IPv6 for codfw1dev, which was my original intention before doing anything related to BGP :-P
We would need to:
- allocate a small IPv6 prefix for the transport network (between cr-codfw
and the neutron virtual router). I'm open to suggestion to the size of this subnet.
- allocate a big IPv6 prefix that we could use internally inside the cloud
environment (for VMs). This should probably be a /48? I'm not sure yet if I would be doing subnetting of this big prefix and allocate smaller ones (/64) per project, or if we will be using the big one directly without sub-delegation. (Something to research anyway).
I will follow-up next week. For the record, doing this research and design is one my goals/OKRs for this quarter (3 week left!). My plan is to use this wikitech page as my deliverable:
https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhancemen...
regards.
-- Arturo Borrero Gonzalez SRE / Wikimedia Cloud Services Wikimedia Foundation
On 3/6/20 5:18 PM, Arzhel Younsi wrote:
Hi!
CCing Faidon if it's urgent as I'll be out next week.
A /64 for the transport network and a /48 per cloud environment (/site) sounds good to me. Exact prefixes TBD but it should be quick to assign. I don't know (yet) what's OpenStack best practices for v6 but I can probably do some research as well. Instinct tells me that splitting the /48 is more future-proof.
At this early point, I really don't have a strong opinion about prefix length. Whatever works for you, works for me!
You can find some notes on Openstack IPv6 here:
https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhancemen...
(includes a link to upstream docs)
At first it doesn't look like a big deal. We will probably use SLAAC internally. The big deal is to answer this question:
Would it be possible to replace/reduce the IPv4 NAT mechanism to the bare minimum by using IPv6?
That's why I would really like to start playing with this ASAP.
About OKRs, please let me know in advance so I can prioritize accordingly :)
OK. I asked for the allocation of the IPv6 range couple of times already. I honestly didn't expect that the BGP thing would be a blocker (took almost a month!). My expectation is to advance as much as I can in research and design this Q.
regards.
cloud-admin@lists.wikimedia.org