 Talk is about Not not just Cisco, but essentially we want to bring in our collaborators from academia and we want to talk about How our academic collaborators are deploying federated or at least thinking of deploying federated open stack on IPv6 backbones and you know their experiences and what we can do and I hope this will be an interactive session and Initially, we'll kick it off with May Wong from Cisco giving a short blurb about exactly who we are or this part of that that's related to the top and So a background about may may has more than 10 years of experience doing IPv6 at Cisco all the way when Steve Dearing And everybody else Did the seminal stuff on IPv6 and may Wong is right now a principal engineer and the head of Asia Pacific Research so she leads all research engagement So if you have if you're from an academic Organization and you want to plugged into get plugged into our research program, please come and talk to her Thank you for the introduction devil and yeah as devil mentioned this is a collaborate project is led by There are several parties involved. It's actually within Cisco is led by two groups our group Cisco research and devil's team, which is the CTO office of the cloud Devil and the loot occurs team So we work very closely and our collaborators in academia are three top universities from China And as the names here shown from Tsinghua University Professor Xing Li Cong Xiao Bao and I'm sorry Yeah, yeah, I just want to show the show the names but because they are at also Fred Baker Cisco fellow They have to be at IET at this week so they cannot be here but Professor students are going to do their presentation here and the highlighted names are the presenters for today and professors Liangcai and Qifei Zhang from Zhijian University and professor Yao Guijin and Xuan Luo from Shanghai Jiao Tong University so the goal of this collaboration is to Help solve the research problems we're seeing in the cloud environment especially Open stack based cloud environment and not only we want to address this problems We want to provide academia solutions We want to provide Algorithms, but we also want to bring in bigger impact via a large-scale deployment on the Academic campus network environment That's one of the key reasons we want to collaborate with these universities because all these three universities are Knows of CERNET, which is China Education and Research Network the largest In-run research network in China and CERNET2 is actually the largest pure IPv6 backbone in the whole world so we hope to Leverage this kind of platform and environment So there are lots of interesting research questions We want to look into but to begin with we want to really focus on IPv6 in data center As the due to the exhaustion of IPv4 addresses we are seeing increasing Deployment of IPv6 at the same time We also got lots of requests from our customers asking for a simpler and more scalable Network infrastructure and data center and we believe IPv6 is a key to provide this kind of platform solution So and we want to do this in like three steps The first one we want to analyze the existing IPv6 Implementation in OpenStack and that will be the key part of today's presentation We got some Tsinghua University got some very initial results. They like to present today and then after that We hope to work together with the community to design a native IPv6 infrastructure in data center with IPv6 in mind instead of having the IPv4 mindset and design the IPv6 infrastructure then after we have the prototype we have the code in OpenStack on top of this platform. There are lots of very interesting issues Questions we need to address for example the address allocation and management in IPv6 and the routing schemes for native IPv6 in data center and we believe overall this will provide a Better solution in terms of performance and scalability and because it's a simpler Network simpler infrastructure and we also hope it can reduce the overall cost so other than the IPv6 in data center, we are also seeing lots of very interesting research topics and so the the One part of today's presentation. We want to give you an example on some of the other research Questions we're looking into and that will be the presentation from Zhejiang University They have done some improvement on storage basically providing the effective file system that can handle large amount small file size and that supports IPv6 and that can be a service added to OpenStack so without further ado we'd like to invite the Speaker e-buy from Qinghua University to talk about the IPv6 analysis in Neutron and this is still based Grizzly release and we understand there's a new release Havana coming up and there's improvement on IPv6 implementation and Tsinghua is going to continue the work towards Havana release. Thank you And also because we're trying to squeeze in lots of content within a short amount of time So we'd like the presenters finish their talk and then we'll address all the questions together at the end and Good morning, everybody. I'm Yi Bai from Tsinghua University and I'm a graduate student and Today I'm very glad to be here representing our team to share some of our recent work with IPv6 in Neutron and give a brief Analysis about IPv6 support in Neutron So the first thing I'd like to talk about is the Motivation and as we know OpenStack cloud deployment needs huge amounts of IP addresses for the management or for the tenant network but But we also know that IPv4 address is Exhausting currently so the support for the IPv6 inside the cloud will be basic requirements in the future and Today we will focus on the two key problems in Neutron Neutron's tenant network The first one is IPv6 address automated Assignment and the second one is IPv6 routing mechanisms So the second thing I would like to talk about is the IPv6 backboard And that is sonnet 2 stands for the Chinese Education research net and it's a pure IPv6 environment which enable us to Simplify our examination with our work and it connects over 200 universities and Provides IPv6 services for more than three million users and our final goal is to deploy a federated OpenStack system between these three universities So here's a brief comparison between IPv4 and IPv6 Besides a larger address pool There are many new features in the IPv6 and some of these features is is not compatible with IPv4 and And we we know that Neutron is is now designing the philosophy of IPv4 So we should extend our extend Neutron to support IPv6 the first one is We know that Neutron uses NET to connect to build a connection between the internal and external network and Neutron uses also uses NET to to implement some function like floating IP but the net is depreciate in IPv6 so here will bring some challenges here and And some of the IPv6 some of the features in IPv4 is also updated like ARP is updated to a neighbor discovery and Private address is updated and renamed the unique local address also and Benefits from the larger address pool. There are many new address configuration Configuration mechanisms in IPv6 like the stateless automated assignment and its privacy extensions these These new mechanisms should be integrated into the Neutron so with with those differences differences and we think the IPv4 and IPv6 is not compatible with each other and there are several Several transitional transitional chess technologies are raised and one of them is called the translation technologies it can provide stateless translation between IPv4 and IPv6 to provide by directional initiated communication and it's defined in this ITF RFCs so We assume that the IPv4 only cloud and those existing clouds Will exist still exist for a very long time So we are working on deployed the translation technologies to provide the IPv6 internet accessible to the to those IPv4 existing cloud and Here is a brief a typical topology of tenant's network in IPv4 currently in Neutron and There are several key points here as the external network use uses the global adjusts and the private network or we call a internal network uses the private adjusts adjusts and and here in the guest A Neutron uses a Mechanisms called floating IP as a secondary IP adjusts for the guest to be accessible from the outside internet and floating IP is Implemented by by the IP aliasing and net so this These mechanisms work perfectly for IPv4 So we we decided not to move it in inside the cloud and we deploy a translator at the edge of cloud to make the IPv6 internet Accessible to the IPv4 cloud and here in the charges how it works You can see that adjusts is converted for several time both for the source adjusts and the destination adjusts and those those come the key key points to the those conversion conversion is that a global IPv6 adjusts is about it's bound to a Global I or private IPv4 adjusts inside the cloud then that is not in use so So in enabled IPv6 internet accessible to the IPv4 cloud and we deploy a Test bed for it and it's accessible from both IPv4 and IPv6 Size on the left is a native IPv4 assess assess and on the right You could you could see how the adjust is converted on visiting it and this is the This is the video service it could provide So for the next next phase we Wish you support for the IPv6 internally and and in OpenStack there are currently several blueprint talk about it and as I mentioned previously There are two key point Two key problems in support IPv6 internally the first one is adjusts assignments and And here is a comparison between IPv4 and IPv6 You can see that in IPv6. There are many more modes in adjusts assignments like the stateless Out to the allocation and its privacy extensions But the case is in IPv4 the new train generates an adjust for the instance and and tell the instance why Why a state static manually setting or or why the DHCP? But in IPv6, there are many modes that generates the adjust inside the instance like like slack so Neutron should be extend extend its function to generate the correct address as the instance generates and I mean the same send address with on the database and the instance for the further OpenStack management for example the security group and and When it comes to privacy extensions the case is more complicated for we know that Privacy extensions generates a random adjust every every several hours So it requires synchronization between the instance and the Neutron database to to to make it correct and as we know privacy extensions is almost used in the Operating systems like windows that is almost not open source. So we think the privacy extension should be left for the future work and the second key problem we In the second key problem is the layer 3 routing structure and as I mentioned earlier The IPv4 in Neutron uses the privacy adjust as as the internal network address By an IPv6 inside the cloud the internal network have Will have a larger adjust pool So we think we should use a subset of SNO network as the internal network adjusts To guarantee the chance the end-to-end transparency between the between the IPv6 inside IPv6 Internet, so it will be a pure hierarchical routing to implement this This new structure we could use two different technologies, which or which all have both have some advantage and Disadvantage I will mention later the first one is neighbor discovery proxy and the second one is pure routing protocol But before we get into the new structure, it will take some time for community to accept this new structure so and So here we choose the net 6 6 as a transitional choice the net 6 6 is is Deplicated, but the new Linux kernel support this this function since since 390 so we could we could extend Neutron very easily to To implement the net between the internal and external network in the in So the structure will will close will be closest to the to the current Neutron structure with the private network uses a unique local address and and use net and multiple adjust per instance to implement it we could create two to network and and bind the floating IP to the instance and as we have always doing in the in the IPv4 On the next step we think the neighbor discovery proxy will be will be a solution for the new structure and As the as the net 6 6 you can see neighbor discovery proxy requires no special configuration on the upstream router and So so you could and so it's all inside the cloud and the new Neutron on the on the Neutron's control But but the limitation of at neighbor discovery proxy is that the prefix of the external network It's limited to to the 64 due to the limitation of the neighbor discovery so the the prefix of the internal network as I mentioned should be a subset of the external network will be longer than 64 this Disable some some function like the slack or its privacy extension So we could only use some pure the HCP for this But we could also make it more flexible You as you can see that the neighbor discovery proxy limits the flexibility of the external network With the pure routing protocol we could build a more flexible adjust structure But it requires the open stack router and the physical router interacts with each other to to exchange the routing information here so so so one who Deploy the pure routing protocol should have the control over the upstream router which makes the Cloud structure more complete complicated So and no matter which way we deployed IPv6 there will be more and more IPv6 cloud There will be another problem that how IPv4 internet assess the IPv6 cloud as we know that if we provided The service in IPv6 if you if we lose the IPv4 Accessibility it will be a big problem So we could deploy another translator at the edge of the IPv6 cloud to make the IPv6 cloud Accessible from the IPv4 side and you could see the conversion of of adjust is much simpler than the than a previous translator so here we by manually settings the the IPv6 the IPv6 new structure and in the grizzly version we deploy an experimental test there for IPv6 and This is also accessible both from the IPv4 and IPv6 sites And you can see in the rise that there when you assess the This cloud in IPv6 sites no adjust translation or conversion has happened as as the old old new chain structure, so it's an end-to-end transparent cloud This is the this is the video if you're wise and Finally here's the remarks and the first list why Extended IPv4 and IPv6 states this translator the open stack can provide IPv6 service today but to support IPv6 internally and There are possible three approaches and the first one is the closest to the current IPv4 model in In open stack that is the net 6 6 and use the multiple adjust per instance And the letter one let letter two for the new end-to-end transparent Structure the first one is neighbor discovery proxy. It's all inside the cloud But the adjust structure will be not that flexible and for the latter is the pure routing protocol It's it follows the IETF model, but it's not But it requires the interaction between the open stack router and the upstream router and for the long term as IPv6 only cloud will As we deploy more and more IPv6 only cloud We can provide services to IPv4 only networks Whereas state list IPv4 and IPv6 translator so and We think that support the IPv6 inside the cloud in the tenant network there. These are our key points, but it's not not enough to just support a tenant's network and The wish you wrong some some amazing Application on the on the network. So Let's welcome dr. Qi Fei Zhang to given short Analysis about a highly straight scalable fire system for small fires Thank you, bye My name is Zhang Qi Fei from Zodiac University and so we can see from the PPT from by IPv6 Open stack is ready to run on IPv6 Network We think the other component should be ready for IPv6 too So we want to I want to introduce special file system named ZU DFS to ZU DFS to you ZU DFS is ZU DFS is designed designed to store small files and to store small files so People will ask why we why should we choose to store small files and Because it's Because it's necessary and Many research shows that most of the files are smaller than 64 megabytes and Nearly or half of the file are smaller than 64 kilobytes This data is from us Us National energy research scientific computer center This concrete is also come confirmed by the data from internet climates energy astronomy Biology and auto industry So how we to store these small files We have to face many changes the first changing It is the file is very file file is missing such as the Facebook Hashtag it is store 260 meaning picture and the average size is 800 800 kilobytes and more company the the file size is about the several kilobytes or several megabytes the second change is as the The request is huge and more rates than rights Once the data is right into disk They will be accessed by many times The third changing is a hotspot data. There are many snares Once the data generate Minutes of request the system how to deal with the minutes of request and during Within several hours or even several minutes, but after that They will be not accessed So we designed the UDFS UDFS The UDFS is a high-skinned file system for small files It has many features the first features We use two way to use two way to optimize those small file storage the first way is we use a multi-agent to Merge the band-wise the second way is to easy way Merge the small files on one version the two big files The second feature is status monitor based on this status the system can auto-balance when some laws join or decide and during the processing our auto-balance and some Some load some version of how to copy the data to others in order to simplify the Migration we use the state machine method to simplify the processing and to go further step We we can migrate the files on different virtual node in parallel That's not enough we want to do something more and we can see the UDFS is faithful to Store well images in Obstack and We also view as a small small file storage as a service in Obstack Also, we can we will make the UDFS to support IPv6 and We compare the UDFS with TFS TFS is Developed by Taobao Taobao is the biggest you can in business company in China This data we can see this data means at the pink pink is 70 megabytes per second with 65 straight and the network limits is 125 megabytes per second and we can see ZUDFS the performance of the UDFS is better than TFS in red and red Store put and the pink and And that's all I want to be introduced Thank you Now we like to invite all the speakers come up stage and we can address some questions If there are any questions Go ahead So the questions what kind of a limitation you see? Okay. Thank you Yes, that's good question and such as Taobao Facebook Facebook Has its own small file storage And she named named the hashtag It has stored stores about 260 billion pictures and I'll read it size is 800 Kilobytes There was a question here, right? Hi Yan And for metadata, we we know that is a is a tough problem, so for that just in in the IPv4 is is static there. So here we haven't haven't come up with a with a good Good good choice good or good solution for this for issue left for the future work and it's also so it's a Worldwide problem, I think thank you. We will consider it Thank you. Yes I think for SDN it can be on both IPv4 and IPv4 IPv6 So I think these are kind of the they don't conflict with each other so we can deploy SDN solutions at the existing IPv4 infrastructure and we can also provide native IPv6 Infrastructure and then deploy SDN on top of that more questions Yes The question is the benefits of implementing IPv6 in Utah And as we know IPv4 is exhausting and we we've been seeing many Many people deploying IPv4 OpenStack cloud using the internal network as the external External adjust to simulate the the function because they are lack of the IPv4 global address so and So So we think the larger adjust pool will benefit All all of the people who are lack of the IPv4 global address Yes, but but you could think about five years later or ten years later when the IPv4 coast more and more money to even to buy a small pool of address and I think then the IPv6 will be the solution So we we should support IPv6 from the very beginning to avoid Yeah Yeah, so actually About probably 20 years ago the whole network of community had already even though back then we still have plenty of IPv4 addresses But even back then people had already foreseen that they're going to be shortage of IPv4 addresses that's why IPv6 was designed and actually and And and actually the Cisco fellow Steve Dearing was trying to Invite people to adopt IPv6 But I that has been like many years effort But I until very recently people really start to see the Exhaustion of IPv4 addresses so actually more and more of customers are moving into IPv6 and lots of companies for for example Facebook and Google and lots of operator major operators are all moving into IPv6 because we're basically Running out of IPv4 addresses and there there there are no options We just have to move on to IPv6 and they're they're actually two main Benefits one is for IPv4 because of the shortage of IPF IPv4 addresses We have to do lots of like private address at public address. We have to do lots of address translation and lots of applications because of this whole addressing issue cannot With IPv4 cannot provide end-to-end Solution and that requires IPv6 to provide the end-to-end solution and then the second part is I we believe IPv6 can dramatically Simplify the network and because all these translations you have to do and all these Addressing schemes you have to do to conserve the consumption of IPv4 addresses and we cannot afford for each entity that we like to have a public routable IP addresses right now is just impossible in IPv4 so we have to do all these Intermediate steps that dramatically Complicate the the whole network Yeah, so we do see first of all the necessity the great need that we have to move to IPv6 and the secondly IPv6 is going to simplify the the network a lot Which which can reduce the cost the maintenance cost and everything? Actually the the Necessity to move on to IPv6 and the benefits of IPv6 it can be a whole another talk There are lots of information lots of materials on that and we've been actually working on Helping people move on to IPv6 for for many years. Yeah, and we can we can talk more about that Yes, thank you Thank you