Hey everyone, welcome back to Las Vegas. It's theCUBE live at AWS Koreanvent 2022. This is our fourth day of coverage. Lisa Martin here with Paul Gillin. Paul, we started Monday night. We filmed and streamed for about three hours. We have had jammed pack days, Tuesday, Wednesday, Thursday. What's your takeaway? We're routing final turn as we head into the home stretch. This is, as it has been since the beginning, this show with a lot of energy. I'm amazed for the fourth day of a conference of how many people are still here. I am too. And how active they are, how full the sessions are. Huge proud for the keynote this morning. You don't see that at most of the day four conferences. Everyone's on their way home. So people come here to learn and they're still learning. They are still learning and we're going to help continue that learning path. We have an alumni back with us. Tomas Sharon joins us. The CPO and co-founder of Dremio. Toma, it's great to have you back on the program. Yeah, thanks for having me here and thanks for keeping the best session for the fourth day. Yeah, you're right. I like that. That's good mojo to come into this interview with, Toma. So last year, last time I saw you was a year ago here in Vegas at re-invent 21. We talked about the growth of data lakes and the data lake houses. We talked about the need for open data architectures as opposed to data warehouses. And the headline of the Silicon Angles article on the interview we did with you was Dremio predicts 2022 will be the year open data architectures replace the data warehouse. We're almost done with 2022. Has that prediction come true? Yeah, I think we're seeing almost every company out there certainly in the enterprise adopting data lake, data lake house technology, embracing open source kind of file and table formats. And so I think that's definitely happening. Of course, nothing goes away. So, you know, data warehouses don't go away in a year and actually don't go away ever. We still have mainframes around, but certainly the trends are all pointing that direction. Describe the data lake house for anybody who may not be really familiar with that and what it really means for organizations. Yeah, I think you could think of the data lake house as the evolution of the data lake, right? And so, you know, for the last decade, we've had kind of these two options, data lakes and data warehouses. And, you know, warehouses, you know, having good SQL support and good performance, but you had to spend a lot of time and effort getting data into the warehouse. You got locked into them, very, very expensive. That's a big problem now. And data lakes, you know, more open, more scalable, but had all sorts of kind of limitations. And what we've done now as an industry with a lake house and especially with technologies like Apache Iceberg, is we've unlocked all the capabilities of the warehouse directly on object storage like S3. So you can insert and update and delete individual records. You can do transactions. You can do all the things you could do with a database directly in kind of open formats without getting locked in at a much lower cost. But you're still dealing with semi-structured data as opposed to structured data. And there's work that has to be done to get that into a usable form. That's where Dremio excels. What has been happening in that area that to make, I mean, is it formats like JSON that are enabling this to happen? How are we advancing the cause of making semi-structured data usable? Well, I think first of all, you know, I think that's all changed. I think that was maybe true for the original data lakes, but now with the lake house, our bread and butter is actually structured data. It's all tables with the schemas and you can create table, insert records. It's really everything you can do with a data warehouse you can now do in the lake house. Now, that's not to say that there aren't like very advanced capabilities when it comes to JSON and nested data and kind of sparse data. We excel in that as well. But we're really seeing kind of the lake house take over the bread and butter data warehouse use cases. You mentioned to open a minute ago. Talk about why it's why open is important and the value that it can deliver for customers. Yeah, well, I think if you look back in time and you see all the challenges that companies have had with kind of traditional data architectures, right? A lot of that comes from the problems with data warehouses, the fact that they are, you know, they're very expensive. The data is, you have to ingest it into the data warehouse in order to query it. And then it's almost impossible to get off of these systems, right? It takes an enormous effort, tremendous costs to get off of them and so you're kind of locked in. And that's a big problem, right? You also, you're dependent on that one data warehouse vendor, right? You can only do things with that data that the warehouse vendor supports. And if you contrast that to data lake houses and open architectures where the data is stored in entirely open format. So things like parquet files and Apache iceberg tables, that means you can use any engine on that data. You can use Dramio's SQL query engine. You can use Spark, you can use Flink. You know, there's a dozen different engines that you can use on that, both at the same time, but also in the future, if you ever wanted to try something new that comes out, some new open source innovation, some new startup, you just take and point out the same data. So the data is now at the core, at the center of the architecture, as opposed to some, you know, vendor's logo. Yeah. Amazon seems to be bought into the lake house concept. It has big announcements on day two about eliminating the ETL stage between RDS and Redshift. Do you see the cloud vendors is pushing this concept forward? Yeah, 100%. I mean, Amazon's a great partner of ours.  And, you know, their embracement of the lake house architecture, the fact that they adopted iceberg as their primary table format, I think that's exciting. As an industry, we're all coming together around standard ways to represent data so that at the end of the day, companies have this benefit of being able to, you know, have their own data in their own S3 account in open formats and be able to use all these different engines without losing any of the functionality that they need, right? The ability to do all these interactions with data that maybe in the past, you would have to move the data into a database or warehouse in order to do, you just don't have to do that anymore. Speaking of functionality, talk about what's new this year with Dremio since we've seen you last. Yeah, there's a lot of new things with Dremio. So, yeah, we now have full Apache iceberg support, you know, with DML commands, you can do inserts, updates, deletes, you know, copy into all that kind of stuff is now, you know, fully supported native part of the platform. We now offer kind of two flavors of Dremio. We have, you know, Dremio Cloud, which is our SaaS version, fully hosted.  And then Dremio Software, where you can self-host usually in the cloud, but even outside of the cloud. And then we're also very excited about this new idea of data as code. And so we've introduced a new product that's now in preview called Dremio Arctic. And the idea there is to bring the concepts of Git or GitHub to the world of data. So things like being able to create a branch and work in isolation.  You can do that in a branch. So all these ideas that, you know, we take for granted now in the world of source code and software development, we're bringing to the world of data with Dremio Arctic. And when you think about data mesh, a lot of people talking about data mesh now and wanting to kind of take advantage of those concepts and ideas, you know, thinking of data as a product. Well, when you think about data as a product, we think you have to manage it like code, right? You have to, and that's why we call it data as code, right? All those reasons that we use things like GitHub to build products, you know, if we want to think of data as a product, we need all those capabilities also with data. You know, also the ability to go back in time, the ability to undo mistakes, to see who changed my data and when did they change that table? All of those are part of this new catalog that we've created. You talk about data as a product, that's sort of intrinsic to the data mesh concept. Are you, what's your opinion of data mesh? Is the world ready for that radically different approach to data ownership? You know, we are now in dozens of our customers that are using Dremio to implement enterprise-wide kind of data mesh solutions. And at the end of the day, I think it's just, you know, what most people would consider common sense, right, in a large organization, it is very hard for a centralized single team to understand every piece of data, to manage all the data themselves, to, you know, make sure the quality is correct and make it accessible. And so what data mesh is first and foremost about is being able to kind of federate or distribute the ownership of data, the governance of the data. It still has to happen, right? And so that is, I think, at the heart of the data mesh, but thinking of data as kind of allowing different teams, different domains to own their own data, to really manage it like a product with all the best practices that we have with that, super important. So we're doing a lot with data mesh, you know, the way that Dremio Cloud has multiple projects and the way that Dremio Arctic allows you to have multiple catalogs and different groups can kind of interact and share data among each other. You know, the fact that we can connect to all these different data sources, even outside your data lake, you know, with Redshift, Oracle, SQL Server, you know, all the different databases that are out there, and join across different databases in addition to your data lake, that's all stuff that companies want with their data mesh. What are some of your favorite customer stories that where you've really helped them accelerate that data mesh and drive business value from it so that more people in the organization kind of access to data so they can really make those data driven decisions that everybody wants to make? I mean, there's so many of them, but you know, one of the largest tech companies in the world creating a data mesh where you have all the different departments in the company that, you know, they were a big data warehouse user, and it kind of hit the wall, right? The costs were so high and the ability for people to kind of use it for just experimentation, to try new things out, to collaborate, they couldn't do it because it was so prohibitively expensive and difficult to use. And so what they said, well, we need a platform that different people can, they can collaborate, they can experiment with the data, they can share data with others. And so at a big organization like that, their ability to kind of have a centralized platform but allow different groups to manage their own data. Several of the largest banks in the world are also doing data meshes with Dremio. One of them has over a dozen different business units that are using Dremio and that ability to have thousands of people on a platform and to be able to collaborate and share among each other, that's super important to these guys. Can you contrast your approach to the market, to Snowflakes? Because they have some of those same concepts. Snowflake's a very close system at the end of the day, right? Close and very expensive, right? I think they, if I remember seeing a quarter ago in one of their earnings reports that the average customer spends 70% more every year, right? Well, that's not sustainable. If you think about that in a decade, that's your cost is going to increase 200X. Most companies not going to be able to swallow that, right? So companies need, first of all, they need more cost efficient solutions that are just more approachable, right? And the second thing is, you know, Dremio, we talked about the open data architecture. I think most companies now realize that if you want to build a platform for the future, you need to have the data in open formats and not be locked into one vendor, right? And so that's kind of another important aspect. Beyond that, Dremio's ability to connect to all your data, even outside the lake, to your different databases, no SQL databases, relational databases. Dremio's semantic layer where we can accelerate queries. And so typically what happens with data warehouses and other data lake query engines is that because you can't get the performance that you want, you end up creating lots and lots of copies of data. For every use case, you're creating a pre-joined copy of that data, a pre-aggregated version of that data. And then you have to redirect all your data towards those individual things. Well, it's expensive. It's expensive, it's hard to secure that because permissions don't travel with the data. You have all sorts of problems with that, right? And so what we've done because of our semantic layer that makes it easy to kind of expose data in a logical way. And then our query acceleration technology, which we call Reflections, which transparently accelerates queries and gives you sub-second response times without data copies and also without extracts into the BI tools. Because if you start doing BI extracts or imports, again, you have lots of copies of data in the organization, all sorts of refresh problems, security problems, it's a nightmare, right? And that just collapsing all those copies and having a simple solution where data stored in open formats and we can give you fast access to any of that data, that's very different from what you get with like a Snowflake or any of these other companies. That's a great explanation. I want to ask you, early this year, you announced that your Dremio Cloud service would be free forever, the basic Dremio Cloud service. How has that offer gone over? What's been the uptake on that offer?  And thousands of people have signed up and I think it's a great service. It's very, very simple. People can go on the website, try it out. We now have a test drive as well. If you want to get started with just some sample, public sample data sets and like a tutorial, we've made that increasingly easy as well. But yeah, we continue to take that approach of making it easy, democratizing these kind of cloud data platforms and kind of lowering the barriers to adoption. How effective has it been in driving sales of the enterprise version? Yeah, a lot of business that we do, like when it comes to selling is folks that have educated themselves, right? They started off, they followed some tutorials. I think generally developers, they prefer the first interaction to be with a product, not with a sales person. And so that's basically the reason we did that. Before I ask you the last question, I want to just, can you give us a sneak peek into product roadmap as we enter 2023? What can you share with us that we should be paying attention to where Drumeo is concerned? Yeah, you know, actually a couple days ago here at the conference, we had a press release with all sorts of new capabilities that we just released and there's a lot more for the coming year. We'll shortly be releasing a variety of different performance enhancements. So we'll be in the next quarter or two, we'll be probably twice as fast just in terms of raw query speed. That's in addition to our reflections and our query acceleration. Support for all the major clouds is coming. Just a lot of capabilities in Drumeo that make it easier and easier to use the platform. Awesome. Tomer, thank you so much for joining us. My last question to you is, if you had a billboard in your desired location and it was going to really just feel like a mic drop about why customers should be looking at Drumeo, what would that billboard say? Well, Drumeo is the easy and open data lake house and open architectures is just a lot better, a lot more future proof, a lot easier and just a much safer choice for the future for companies. And so I'd argue with those people to take a look. Exactly. That wasn't the best billboard, so that's okay. I think it's a great billboard. Awesome. Tomer, thank you so much for joining Paul and me on the program and sharing with us what's new, what some of the exciting things that are coming down the pipe quite soon. We're going to be keeping our eye on Drumeo. Awesome, always happy to be here. Thank you. All right, for our guest and for Paul Gillan, I'm Lisa Martin. You're watching theCUBE, the leader in live and emerging tech coverage.


The Sheridan is the most versatile armored reconnaissance vehicle known. It is amphibious and air-droppable. It is fast, highly maneuverable, and mounts a weapon system that will destroy any known armor. The Sheridan mounts an M2 caliber 50 machine gun in its commander's power assist cupola and an M73 7.62 millimeter coax machine gun in its turret. Its 152 millimeter gun launcher fires conventional ammunition as well as facility guided missile. Driver, stop. Gunner, coax, troops, 800, up. Identified. Fire, driver, move out. On the way, sir, heat, bunker, 800. Identified. On the way. On the way. Cease fire. Gunner, heat, bunker, 1200. Identified. On the way. Lost. Over. Drop 100. Fire. On the way. Cease fire. Missile. Moving tank. Identified. On the way. The Sheridan can defeat a great variety of targets including the heaviest armor on the battlefield, but only if the skill of its crew matches the capability of their weapon system. What did each man do in those few crucial moments of combat to make a piece of fine hardware into a winning fighting unit? What did it take? Before the mission begins ammunition is loaded aboard the Sheridan. Unlike conventional ammunition the missiles are carried horizontally and loaded into the vehicle base first. Inside the Sheridan each missile is secured with care, the key pointing out to prevent damage. Similar care must be taken with the heat round. Its combustible cartridge case is fragile, highly inflammable, and must be protected by a moisture barrier bag and a nine-ply nylon ballistic baggie. It is carried like conventional ammunition and loaded into the vehicle with its nose pointed down. Care must be taken not to break the cartridge case. When the round is fired the cartridge case burns. No hot brass is ejected back into the turret. Before the Sheridan approaches its area of combat the gunner conducts a pre-fire test of the Shaleili missile system. This test is performed after any period of rough transport or inactivity. In action it is required at least once a day. It takes less than four minutes, but it can guarantee your missile system will work for you when you need it. With the fire control selector in the missile mode the test checkout panel can test the condition of every component of the Shaleili guidance and control system. The transmitter, the tracker, and a system self-test will terminate in 34 seconds with a red no-go light if a component is bad. If the system is functioning properly a green go light will illuminate. Turret power will be switched on when enemy contact is imminent as it takes 20 seconds for full power to be applied to the turret. Now you are ready for combat. Gunner, coax, troops, 800. Now wait a minute. Let's slow this down and see exactly what it takes for each man to do his job right. Gunner. At the command Gunner the Gunner immediately ensures that the turret power is switched on. This permits the vehicle commander to use his turret override to lay the gun launcher for direction. The command coax announces that the coax machine gun will be used. The Gunner switches to the coax mode. Then he switches the stabilizer switch on to permit the vehicle to fire accurately while on the move. At the same time the loader checks the loading of the coax machine gun. He switches the safety switch to the fire position. When the gun is ready to fire he steps back and announces troops, 800. This part of the fire command establishes the target and its approximate range. When the Gunner sees the target he announces identified. The commander then releases control of the turret to the Gunner and commands fire driver move out. The Gunner makes a final precise lay on the target using the Gunner's turret control announces on the way and squeezes the firing trigger. The loader checks the ammunition feed into the coax gun. The Gunner continues to fire in 20 to 25 round bursts until he receives the command target cease fire. Now let's see what happens when a main gun engagement is ordered firing a conventional round. Gunner, heat. The Gunner ensures that turret power is switched on. Then he switches to the conventional mode of operation. The 152 millimeter heat round is normally fired from a stationary position. When the loader hears the command heat, he selects a round of heat ammunition from its rack. He removes the nine-ply nylon baggy and the moisture barrier bag from the cartridge case and carefully loads the round into the gun launcher. He never slams a round of heat ammunition home as he could easily break the combustible cartridge case which is consumed when the round is fired. He ensures the eject lever is in the non-eject or up position. He switches the breach open-close switch to close and holds it in position until the breach closes and locks. He checks the safe to fire indicator. He checks that the path of recoil is clear. Then switches the safe ready switch to ready, checks for a gun ready light and announces In the meantime, the driver has found a level area with some cover and concealment and has stopped the vehicle. Bunker, 800. This part of the fire command identifies the target. When the Gunner finds the target in his telescope, he announces Identified. The commander releases control of the turret and the Gunner positions the target properly in the stadia reticle and ranges to the target. Fire. The Gunner makes a final precise lay on the target and announces On the way. He pauses one second to allow the crew to brace for the recoil. After the recoil, the Gunner observes the effect of his firing in the telescope. When he sees where the round burst, he applies the primary method of adjustment, burst on target. He places the point where he saw the burst over the center of vulnerability of the target. In the meantime, the loader has loaded another heat round. On the way. Gunner fails to see any effects of the round within his telescope field of view. He announces Lost. The alternate method of adjustment is used. The commander senses the round and directs the Gunner to his new aiming position. Over. Drop 100. Fire. The standard range correction for 1,200 meters and less is add or drop 100 meters. For ranges over 1,200 meters, the standard correction is add or drop 200 meters. On the way. How does the Sheridan engage the enemy with the caliber 50 machine gun? The commander alerts the crew by announcing Caliber 50. Then he brings his machine gun to bear by switching the cupola power on and using the traversing switches mounted on the machine gun handles. He opens fire when he is on target. He is finished. He announces the completion of the engagement. Cease fire. First stop. The Shaleili missile is reserved for tank or tank like targets at ranges greater than 800 meters. Gunner. Missile. Moving tank. The Gunner ensures turret power is on then switches to the missile mode. This automatically overrides the stabilizer if stab is on and illuminates the missile reticle in the Gunner's telescope. When the loader hears the command Gunner missile, he selects a missile and carefully keys the missile into the open launcher, taking care that the missile key aligns with the launcher keyway. He pushes the eject lever down into the eject position to ensure that the missile aft cap is ejected to the turret floor after firing. He closes the breach electrically, switching the open close switch to close. He checks the safe to fire indicator, ensures a free path of recoil for the launcher, switches the safe ready switch to ready, checks for a ready light and announces, Up! The Gunner searches in his telescope for the enemy tank. When it comes into view, the Gunner announces, Identify. The commander releases control of the turret to the Gunner and orders. Fire. The Gunner makes a final precise lay on the target, centering the crosshairs of his missile reticle on the center of vulnerability of the tank. He applies no lead element. When his aim is correct, he announces, On the way. And immediately squeezes the firing trigger. The missile is guided in flight by the vehicle's guidance and control system, directly to the point where the crosshairs are aimed. When a smoke screen is required, the commander announces, Grenade. Eight smoke grenade launchers are mounted four on each side of the turret. The commander aims the turret and fires the grenades using the grenade projector control box. He removes the master switch guard and switches the master switch on. The grenade launchers can be fired one at a time in white or left salvoes of four or in a full salvo of eight. A full salvo is selected. The pin is removed from the firing switch. The fire switch is activated. All weapons used. All weapons effective. The skill of the crew made them effective. The commander recognized the targets quickly. He gave his fire commands clearly and in time. Gunner, missile, moving tank. The gunner kept his weapons in firing condition. He sharpened his own skill to match their precision. The loader handled his ammunition and weapons swiftly and with care, knowing that their safety and speed of operation largely depended upon him. The driver maneuvered his vehicle in action, finding a level gun platform with cover and concealment when needed. Identified. Fire. On the way. By a crew that knows how to use their weapons, the Sheridan can defeat any known armor on the battlefield.


Hi folks, we're just getting another minute as people join and then we'll get started. All right, welcome everyone to today's LF networking webinar. Today's topic is dynamic network slicing and open source projects. Just a couple of housekeeping items before I introduce our panelists and get us started. Attendings will be muted during the presentation. However, if you have questions, feel free to use the Q&A function. There's a window at the bottom right of your screen. You can click that at any time and go ahead and type a question and we'll all see it. We are going to leave time at the end for live Q&A. But if you do, like I said, if you have questions during the presentation, feel free to type them in at any time. Recording of this will be available the next few days. All attendees will get that link emailed. So if you have to miss anything, don't worry, you can catch up on it later. All right, so today we've got speaking with us today, Shrini Adapali with Intel and Tushar Doshi with robin.io, both LF networking member companies. And without further ado, Shrini, I'm going to kick things over to you to get us started today. Next slide. Next slide. Okay. My name is Shrini. So I'm going to talk about, you know, first three items here, especially what is happening in a network slicing market. And then going to provide high level system architecture, and then I'll try to map to best of my knowledge, the open source projects that can be used to realize network slicing. So one thing I want to kind of indicate to everybody is that, you know, this is all learning process for us also. So please feel free to comment and also ask questions. Okay, and Tushar is going to talk about, you know, what is required for productization. And finally, we are going to open it for Q&A. Next slide. Okay, this is kind of, this slide talks about, you know, one view of, you know, various 3GPP, 5G network functions across multiple types of edges, right. So just one example here. And we believe that, you know, the starting point for providers is just to build upon what is happening in 4G, right. It's provide cellular access to mobile phones, data access to smartphones, laptops and, you know, whatever, you know, the devices that are that need access to internet, right. And, you know, you have cell towers, you have near cell tower, it just, that's where many times, you know, DU goes in and some provider applications that help in, you know, help in DU functionality. You know, you have 4CVHs where CU, UPC, UCP might go, and the regional data centers where you would have a distributed UPF, SMF, AMF, and possibly PCF and core data centers, you know, trust-of-the-control plane, 5G functions in addition to centralized UPF. Since there are multiple CNFs that need to be deployed across multiple types of edges, right, you tend to have some kind of a network service and app orchestrator as shown in the above across all these blocks. And then on top of it, you would have traditional OSSPSS. So with that description of the picture, we believe that the starting point is that no slicing, right. So one slice or no slice, whichever you want to call it, is mainly meant for the EMBP traffic that requires typically very high throughput. Next slide. And with this, with one slice, the way it is today, starting point-wise, but at the same time, people would like to, you know, deploy applications, enterprises would like to deploy applications closer to UPF, you know, to provide best user experience to their customers, right. And that is already happening, right. We see some press releases from operators and hyperscalers, you know, hyperscalers providing these enterprise slices near to UPF, right. And we believe that eventually even the telcos themselves would provide these services. Okay, that requires, you know, traffic redirection kind of functionality. Basically, when the user is trying to access a service in the cloud, but if that service is locally available near UPF, then you like that traffic to be redirected to local enterprise application, right. So that functionality is required. And from the perspective of orchestration perspective, in addition to providing network service and application, orchestration of provider applications, you also require multi-tenant way of onboarding applications and deploying them in multiple regional data centers as shown here. So I think that's the next step, we believe, and it's already kind of happening, at least from the thinking perspective, it's already happening. Next slide. Yeah, when you have applications, right, the natural question is that to who is going to do security, because before when the applications are in cloud, the security is taken care by companies like Cloudflare maybe are some security functions that deployed in the cloud itself. But in now that applicants are deployed at the edge locations, the expectation is that the security functions also available in the edge locations. So that's one more opportunity which we see for operators to provide security slices for enterprise applications that are deployed in the edge locations. Whenever you have these security functions, the critical requirement is service function chaining, right. Essentially, operators should be able to, based on the customer's request, should be able to deploy security functions coming from different vendors, and then steer them in a chain fashion, you know, such a way that traffic to going to applications from UPF go through set of security functions. So this is another opportunity we believe. Next slide. And then in phase two, our belief is that, you know, there would be multiple slices, but they're all static or genetic slices. So we talked about the EMBB traffic which required high throughput, and the industry for auto kind of interest, you know, segments require some ultra reliability low latency communication. So, so there is a need for another slice over there. And in case of IOT devices, massive, massive number of IOT devices they require the MTC kind of a traffic profile. So we have a traffic profile which is low throughput, but small messages and a very high number of messages possibly. So that's where we believe that the next phase of slicing would be a simpler slicing that is fixed number of slices provided by providers. And in this case, what you really require is very simple slicing orchestration. That's what's shown on the top there. So let's see what is dynamic network slicing. So far we talked about, you know, one slice or no slice to three or four slices which are specific to different traffic profiles.  And there are some evidence that, you know, some people might even like to see slice to be there for maybe hour or two. So it's really, really need to be on demand. Everything should be automated very well. And since there are multiple slices are going to be there, you do not want to dedicate the shared, you know, resources. You need to share resources and allocate resources on demand basis as and when slices are created. And the other important factor is that now that we are using shared infrastructure for multiple slices, and there would be a need to adjust, you know, resources based on the traffic that is happening there. And also based on the SLA that was agreed upon with that particular user slice user. So let's see who are the type of dynamic slice users. Next. Yeah. One is that enterprises that have, you know, highest security requirements. Basically, some people have data leaking concerns. If the same CNF is same CNF instance is shared among the slice users. There is always a concern that you know, there is a there could be some data leakage. There's one one kind of users. Next. Second kind of enterprises, you know, they require highest performance determinism, right today. CNFs, for example, may not be thinking about a way to provide very good performance isolation within a CNF instance. So either one may like to have different CNF instance for different slices to provide this performance determinism. Yeah, and some enterprises, right, especially maybe government organizations, they like to bring their own CNFs. Right. That's, don't know when that is going to happen, but that's something which we, which I keep hearing at least from few people that some people may some organization may like to bring their own, you know, security reach and as a kind of CNFs. Next. And of course, you know, mobile, virtual network operators. So they would take the services from MNOs and then provide, you know, services to the enterprises. So these are four kinds of users, the types of users we really require this dynamic network slicing. Next slide. So what does, how does it look right. I mean, in this is a little bit busy picture, but we talked about at the bottom of it, we have a genetic slices coming from very, you know, from provider itself. And then different organizations getting, you know, slices from provider. So in this case, we are showing organization one and organization N, they are getting three slices from provider. And then those organizations in turn provide services to the enterprises, enterprise app slices. Right. So in this complex environment, you really require the dynamic slicing orchestrator. And also you require service assurance to ensure that the SLAs of these slices are continue to be maintained in in the mini mini traffic scenarios. Okay. Next slide. Okay, so with all the, with all the evolution which we believe, right. So at this picture, what kind of showing what is the stack required to realize network slicing. So on the bottom of the picture you see, you know, telco edge clusters. And typically, these edge clusters would would be based on the Linux. And we know that covenants is becoming a choice for 5G in general. And we also know that covenants on top of it. And we also know that covenants, you know, by default, is not meant for telcos and CNFs, right, it's meant for applications. So that in the industry wise, there are any activity, many, many, many open source projects and initiatives that make covenants ready for telcos and edges so that many telco edge extensions. They're today. And then we believe that there are some slicing extensions required, more and beyond what is there today. Right. So the bottom, the bottom, that's what we are showing multiple edge locations at different location at different types. On the top, you know, use the network service orchestrator, it is meant to deploy today 5G CNFs and applications across multiple locations that you could basically define a network service with multiple CNFs. Then you could say that I want this CNF to be brought upon these type of locations and this CNF to be brought upon so many, so many applications at the intent. And thus, and then network service orchestrator will take care of deploying those CNFs of a network service across multiple locations and do connectivity required among them. Right, that is, that's already there. And on top we see that's that's where we are talking about dynamic slicing orchestrator in that blue color. Dynamic slicing orchestrator typically with the GBP defines right NSMF, which is a network slice management function, and then there are multiple other NSS MFs which we that is network slice subnet management functions, one for ran transport core, and we believe that you require even one NSS MF to open it is itself, and there will be a requirement for multiple NSS MFs to maintain the, you know, SLA and to maintain the QoS parameter QoS value. Okay, with this kind of a stat, let's see the functional expected. Next. Yeah, this is where DSO, which we believe it should take a slice LCM. And it, as I said, it has to be extensible to add more NSS MFs. And it needs to be multi tenant. Again, as I said, there would be multiple tenants getting different slices, and they may need to onboard the applications themselves so it has to be multi tenant anymore. Next. Then on the network slicing orchestrator, as I mentioned that many, a lot of functionality already available, but for slicing, you require some additional additional features we believe. One is that you know slice to cope on it is namespace automation. Right, and then in the, in the, in the translation of abstract SLS typically, you know, at the, if you look at a GST or any three GPP templates they talk about, you know, SLA with respect to latency through put and etc, etc. But what does it mean to actual resources that are needed to be dedicated. So that that translation is a complex one that is that is required in our view. Then other thing is that the security and performance isolations are very, very important for slicing to be successful. So we believe that there is a need for automating that aspect of it also. Okay, next. And the same thing on the on the on the edges, you require the security and, you know, performance isolation enhancements and confidential computing if somebody really wants their workload to be completely confidential from from even sophisticated attackers that have access to the edge location. And then local inferencing is very important if you want to have a dynamic SLA enforcement, you need to have inferencing also have to happen locally within each education. Next. The last one is service assurance. Yes. So, again, for SLA enforcement, you sometimes you need to have a predictive way of knowing stuff. And that's what we believe that MLDL framework is important over on top of existing service assurance platforms. Next. Okay, now that we talked about functionality, let's let's figure out what are the open source project that can, that can realize these things. Next. A dynamic slicing orchestrator own app as started, you know, work on network slicing a while ago. Almost now is one releases made and second releases are happening. So one app could be a good candidate over there, the network slicing part of one of the case. Next. From the network service orchestration perspective, we do have today M co openness M co that actually can deploy network functions, whether CNFs or BNFs across multiple edge locations, which are covenants based. And an own app has got some functions like CDS for two configuration. And it also has multiple components, external API, STC, so for defining, you know, for defining complex network services, based on the standards. And we also believe that the TSN switch automation is required, especially for your LLC kind of slices that time since the network is very, very pocket. I don't have any open source mapping there, but that's, that's the one important aspect, possibly own app is DNC could be a good candidate over there. On the platform side, you know, Linux foundation edge acryno defines multiple blueprints. And one of the blueprint is called ICN integrated cloud native platform, which is meant for covenants. And it, it, it has multiple telco edge extensions to make it really useful for telcos. Another cloud native observability tools that are available. And Istio on why is already there, but it may need to be enhanced for 5g core to implement the SCP functionality. So that's that's something which is, which is pending to be developed in my mind. Next. There is a student site, there are a lot of cloud native observability tools. The same 3dp for time series database elastic search for logs and traces storing spark and analytics zoo for AI ML training models, Minio for storing models in the graph on our Kiali and Kebana for visualization. And what, what is required is, you know, specific to slice, you know, there is some work going on in the own app and OSC communities to make, you know, slice away service assurance with non real time week. And also some, you know, whatever is required beyond the network that you know, as defined with 3dp. Okay, next, next slide. So let's see what is the status right in our mind. In a network slicing, what needs to be done in multiple projects, because it's a end to end big stack really, and efforts are started in multiple open source projects. And, and very good that the elephant one app did quite a bit of work, thanks to one of community, they did quite a bit of work on the slicing orchestration. Okay, but I believe that some key items need to be addressed in open source communities. One is security and performance isolation that they become very, very important for slicing. And end to end Qo is with the time series networking that is need to be taken care for the success of slicing in general. And SLA continuous enforcement is very key. And then ECM per slice provisioning this authentication where people might like to have their own SIM for that network slice, like so that ECM slice, you know, ECM provisioning becomes very, very important. I did not find at least myself in any, any, any open source project today, but that could be a good candidate. Another one is that cloud native 5G CNF configuration. This is for more than anything it is, it makes it simple for this orchestrator to automate the configuration of CNFs. And I said that, you know, putting together all these solutions, right, the multiple open source projects and of course, when, you know, when, in case of one app, when they are defining, when they are testing the network slicing, they do go with some, you know, simulated CNFs and simulated edges. That's good. But at the end of the day, there should be a, there is a need for, you know, combining multiple projects and showcasing end to end. You know, the things are working okay, and then it is, you know, has a good quality and optimize and secure it is important. I'm, I'm quite excited to know that, you know, there is the elephant started is something called 5G super appropriate. Okay, the intention is to exactly what I said, you know, showcasing end to end scenarios with including network slicing. So the link is given here. I'm sure you would be very interested in knowing about it and then. And an elephant would be happy to get your contributions and use it. Okay. With that, I will hand it over to Tushar. Okay, thanks, Srini. So I'm Tushar Doshi, and I'm part of the orchestration team at Robin.io. And some of you might know that Robin.io is a platform of choice for Rakutan 4G 5G deployment. And it includes the deployment from near-age to far-age to center data center. So today I'll be talking about learning that we had while building this overall ecosystem with the help of various open source projects including Kubernetes and the challenges. And you can extrapolate the challenges to when we are actually implementation of dynamic slicing on top of it. Next slide please. So these are the various challenges that we face. The first of it is desegregation. So we have seen various hardware vendors. So it includes Quanta or Dell or HPC. There could be various switches, routers, NIC cards, or FPGA devices, GPUs across various environments. So the platform which is used for deployment should be able to handle all these differences and the complexities provided by all these different types of devices. And it should give a consistent interface to the end user so that the applications getting onboarded should not see any differences when they are working for it. There could be multiple operating systems. So when you go to the far-age where you will have the VDU running and it would need the high-performance operating system and the platform of choice. There is the Red Hat at the kernel. And if you go to the central data center, then you will have your popular operating system like Red Hat Linux or CentOS. So and then you will have to handle the patching and upgrades and so on for these various environment. And anyways, the problem of scale also comes here, but your platform should be able to handle all these different challenges provided by different applications. And you will have the challenge of multiple heterogeneous sites. So there would be far-age locations for your DU, ER-age locations for CUM, FSM, etc. and the central data center for your ESS and OSS applications. And the platform has to behave differently when it's deployed, whether it's on the far-age or in the central data center. When you go to the far-age, the problem actually becomes of performance. So there you have to take as minimal resources as possible so that most of the resources are available for your actual RAN workloads. And then when you go to the central data center, the performance problem becomes less because you have resources that you can spare. But there the problem is with the scalability. With so many applications running with their different requirements, your platform needs to really scale while handling all these components. In central data center, you might get dedicated resources as well just for the platform, but the scalability is a challenge there. So the platform has to understand all these different flavors of your site deployments and need to handle it very well. The fourth point is most of these applications need new malware deployment. And this includes your new malware CPU, memory, FPGA, then any other GPUs and any other devices that the application might need. So one would say that it's being handled by Kubernetes today using topology manager, which has this fantastic CPU manager and other device plugins. But there are at least when we were looking at it, there are two things still missing. So one is there is no centralized scheduling for the NUMA aligned resource allocation in Kubernetes. So what happens is Kubernetes scheduler might decide a node where the pod might fit. But when actually pod gets scheduled, there might not be enough resources available in a single NUMA node as the application might require and the deployment might fail. And the second issue is there is no NUMA where memory alignment as of 1.20. There is that is a memory manager support is coming as alpha in 1.21. That's a great addition to what Kubernetes already is providing. But since we since the applications are ready to deploy, we have to find a solution for this memory, which is a centralized scheduling issues. Now the fifth point being the multi vendor CNF VNF applications. Now every you have to each CNF VNF is different and each come up with their own requirements. So you cannot have a single solution, which fits on. So some application might require see Mac VLAN CNI, whereas other might ask for obvious plugin and so on. And there would be requirement where they want multiple IPs on a single interface and so on. So that one should be able to handle it very well and it has to be very agile and provide support for what is needed when actually the development is happening. And even if we talk about 5G CNF, there are a lot of vendors still are using VNF and it will take time for shifting from VNF to CNF. So platform has to handle this very well and it has to should be able to handle the VNF and CNF in similar way and provide the similar functionality. So one of the example is say you have network policies in Kubernetes. Now if you if you apply those network policies in your cluster for CNF, similar network policies should also get applied to your VNF. So whatever support you add to container based workloads, you have to make sure that those are also available for the VM based workloads on Kubernetes as far as possible. Then with the multi vendors, there is another challenge of multi tenancy. The platform has 200 multi tenancy very well and here all the quotas and limits and limits come into picture. So say you have an application which auto scales depending on its load and another NF which also has auto scaling. So it might so happen that if you don't have limits that one application might grow more than what you wanted and another NF might not have any space to do auto scaling. So it is very important that you consider all this while designing a solution whether and this the same would be applicable even for dynamic network slicing where you have to you cannot do more than what is allocated to a particular NF. Otherwise it will just run over all your resources. The last point being the networking and the networking is is the one part where every vendor have its own view of things. So there are some common as there are common as per say multiple interfaces support where they will have some SRIOB interface or the Calico or the OBS interface. They will have different they will ask for different CNI support and and so on. And this complexity also occurs when we are talking about a distributed app deployment something like a ran where do you is running at bar age and see you is running somewhere in the middle. So you you have to handle that very well and when you go to the central data center also there are different requirements for each of these applications some applications require Kubernetes service to service communication. But some applications actually require part to part communication across different Kubernetes clusters so the platform should be able to provide those functionalities as needed by the by needed by the applications. And even if we call this as a network slicing it's not just about the network. So you have to at least the practical definition looks like that it means that slicing your compute storage as well as network so that you are predefined SLAs permit. Then why why does the storage come into picture all this right so there are some applications like CDN, which which need low latency but it also needs fast storage to achieve that low latency. So if you do not have a storage stack, which have those performance characteristics, your app will face issues, even when your network is blazingly fast so you will have to consider all of this while designing your network slicing solution. Next slide please. So that way, since there are all these network compute storage network, all of these are coming together. So the network slicing is more complex and it looks like it's more complex than what we have done as part of 5G deployment. And there could be more challenges because you have to consider the this this has to be dynamic and you will have to have a metrics and policy engine and all that achieve the actual dynamics. Next slide please. So here's giving a real life example for NF deployment. This is how it should generally look like the these parts, the NF parts that you see here, they can be part of the same application, or it can be part of different applications so with this model, if you consider the Farage you should be able to deploy different to use on the same physical host. So here you can see the blue CPUs in the middle that you see those are isolated non isolated CPUs which will be used for OS and Kubernetes and the platform, and yellow ones will be used for the application these are the isolated CPUs for the application. And if you see all the pods are getting CPU, memory, SRIOV devices, huge pages and so on from the same new manual. And when you go to new manual one the pods will be getting all the resources locally. Next slide please. And this, this is the ideal placement for your LLC application which cannot even take the additional latency introduced by cross NUMA communication. And this is, and this with this deployment you should be able to handle the scaling healing and so on. So some of the help chat some of the today with the multis and Kubernetes implementation. What happens is user will have to put the SRIOV interface names essentially are the device names in the request and limit section of the pod so when you do this, when say the node goes down or you have to move the resources across there may not be enough resources on the same interface name on the other node or it might happen that the interface naming is different. So with all these challenges the platform also should be able to handle the platform should able to handle that then things failover you should be dynamically adjust depending on the new nodes, new nodes availability what SRIOV devices are available there, what names are there and so on. So that is one of the challenges that we saw while deploying these solutions. So considering all these challenges that we have seen we concluded that the automation is really, really important piece of the, this whole ecosystem and it is also due to the fact that the scale of the 5G deployment is huge and we are talking about and then even the single cluster might have the nodes which are in three digits so considering that anything and everything in the environment should be automated even even a very small task. And this automation should include not just the NF deployment but it should include right from configuring the bare metal to NF management and the, and here the platform should augment what the open source technology is already whether it's Kubernetes, from Meteor, CSTO or any other open source technology and it should add value by integrating these various projects or adding various features which makes overall deployment usable for the user. With the experience that we have we should have the solution should be of a production quality and should be very agile because of the oncoming new requirement that are coming from different vendors. And this also is due to the fact that this 5G deployment overall is a new and there are some problems that we have never seen before due to introduction of Kubernetes and internalization in production and so on. And also if that is one problem there are so many clusters or deployments get impacted due to sheer scale that you will have to have a good quality solution because if you do not that is there is a huge impact when you actually hit some issue. And the next point is the platform should be extensible so that it can easily integrate with existing solutions out there including your BSS and OSS stack. And also everything in the platform should be API driven so that it becomes automatable. And that would mean that whatever you do can be automated by the platform or somebody else who is trying to automate the whole workflows. And it should work for all the common scenario so it should work it should the platform should behave same whether you are doing the RAN deployment on edge or CDN on Farage or CDN deployment at age or you're deploying OSS, BSS or some kind of a database applications in your central data center you should have a similar usability for the end user. And in this in these scenarios you will have to consider all kind of failure scenarios so your failure scenario should start from the it should consider each and every possibility that the disk could fail, your NIC card could fail, your physical host could fail, your rack could fail or your whole data center could go down. So you have to consider all this while designing the platform of your choice. And with all the building blocks in place it should be possible to do dynamic slicing which can be driven by policy engine and it will rely on various metrics coming from your infrastructure, your applications and so on. And this could come from different clusters, but first for implementing that you will have to have all your building blocks in place to reach there. Next slide please. So Robin has three solutions which try to solve these problems. So first solution being Robin MD cap. This is a workflow based automation system, which provides automation right from bare metal. Once the bare metal is racked and stacked whether it's in Farage near age or the central data center doesn't matter. It does the BIOS configuration, OS install, the Kubernetes install, and then it also gives you ability to deploy NF.  And it provides management of physical elements that include bare metal or switch or routers or it manages infrastructure elements like say Kubernetes cluster. Then also it provides a service management like deploying network service across these different Kubernetes clusters it gives you a end to end view and a central pane of glass across your world deployment. Then second product is the Robin CNP. So it is CNCF certified Kubernetes platform and it has all the bills and the results required for running production level telco and enterprise applications. And the more focus is on the high availability and disaster recovery for these applications. And the platform comes with MULTUS, SRIOV, GPU topology manager from ATSDCO all as part of the bundle. And the last but not the least is the CNS. So it's purpose built for application aware cloud native storage. It provides all standard functionality that any CSI compliant storage stack provides which includes replication, encryption, snapshot, grow, and so on.  So if you have a handshotted like just so what it will do is when you take a snapshot it just doesn't take a snapshot of your storage it also takes a snapshot of your Kubernetes objects. So if something wrong goes wrong in the cluster you can always restore from that backup. Or if you want to move your application from one Kubernetes cluster to other Kubernetes cluster, it will allow you to do so. So all these products can work independently, like MDCAF can orchestrate non Robin Kubernetes clusters or CNS can be deployed on any other Kubernetes to provide storage. But their goal is greater than some of its parts. So that way they interact well together. Next slide please. So, and this is what I had for my presentations. I think, I think you'll take over for these questions right. Yes, thank you both really appreciate the thorough overview there. So now we're going to move into the Q&A portion of the presentation. And thank you looks like we've got a good number of questions in the chat window so I'm going to go ahead and read some of these out and get us kicked off. So our first question came in earlier this morning is Kubernetes NSS MF equal to Kubernetes itself as NSS MF, or is it a separate NSS MF maintaining Kubernetes resources. I can take that. Yeah, when we say Kubernetes NSS MF, we really meant to what you said that I'm in the second part of your question right it is a separate NSS MF registered with NSMF. I don't know why we need this is that, you know, when the three GPP and they define the standards they assume, I mean, they don't, they did not, they assumed many scenarios including physical virtual and you know, containerized. So most of the specifications. The way I imagine that they assumed physical physical functions right, but since the CNS are being deployed on Kubernetes environments in the edge clusters on inches. It's also required to automate some configuration of Kubernetes on per slide spaces. For example, when you create a slice, you also want to automate maybe namespace creation among multiple edge clusters. You may also want to automate quota resource quota just to ensure that a given slice doesn't exceed some resources, you know, many more so we believe that that KS NSS MF is would be taking the role of automating all the stuff which I mentioned. Great, thank you for that. Next question, curious about the underlay I assume these tenancy separations could be maintained at the lower network devices if these are dynamic, are these handheld through VRFs etc. Next question, right. Again, as I was answering the previous question right it is very important to ensure that you maintain security and performance isolation. In case of Kubernetes. As you may know, when we create a pod, it actually creates a network namespace, which is nothing but the VRF from the net and networking perspective is VRF. So it does that already, but over on top of it, since you could have multiple parts for a given slice, you also require another construct which already is available by Kubernetes called namespaces. So, those namespaces can be configured with the quotas and things of that nature. So, yeah, absolutely. So, it's underlay, underlay configuration for resource management across multiple sizes is important, and Kubernetes is one of the underlays as per the slices consent, and we should leverage as much as possible, what Kubernetes offers to provide this kind of isolation. Wonderful. Thank you. Next question. Could you please talk about the parameters we have to pass from the orchestrator to core ran and transport for slicing. Yeah, and 3GPP defined all these things already, but predominantly, the things to be passed is that, you know, in case of core and ran, right, what network service to be brought up, right. I mean, the expectation is that the administrator or user would have already onboarded all the network slice specific CNFs or apps onto these domain orchestrators. And then, when the slices created by expectation is that the appropriate NSMF would invoke your orchestrator with the right network service that needs to be brought up.  Because at the end of the day, there is a function called NSMF, right, network slicing. Sorry, NSSF network slicing select selection function. So that needs to be configured. So that so that the information is your network service to be brought up. And what network slice ID to be configured in the NSSF and NSSF and some slice specific SLA parameters to enforce. So these are the typical parameters you need to pass from NSSMFs to orchestrators. Great. Thanks, Shrini. Here's another one for you. Where can we follow the progress of using Istio with 5GC? Two parts to two questions I guess in this one is, you know, the one is the deployment of 5G core functions, control plane functions at least with Istio service mesh. And I'm, you know, there is one, there's one demo was given by an LFN O&ES last year by a company called Lartner Networks. They used to free 5GC to deploy, you know, as a 5GC example. They haven't used Istio at the time, but my understanding is that they intend to use Istio. So hopefully this 5G super blueprint, which we are talking about, that would consider Istio for security and traffic management among the 5G control plane functions. And having said that, I also want to say that, you know, there is, I mean, Istio, you know, the traffic management it has kind of a conflicts with the traffic management that is required by 3GPP. 3GPP today defines, you know, its own mechanism of load balancing, figuring out the destination micro service instances based on NRF and its own 3GPP specific criteria. Whereas Istio has its own criteria to balance, you know, connections coming from client to CNF stores, server CNFs, like prominently round robin or weighted round robin kind of mechanisms. It's purely traffic based, but in case of 3GPP, it requires more, more parameters. So there is some work item, at least from Intel perspective, we are working on a service mesh, we are not working on it yet. We are thinking of enhancing on why sidecar and Istio to implement 3GPP SCP functionality. So I don't have the status or when we are going to start, but I'm, if you send an email and I'll be happy to update, keep up, keep up updating your guys on the status. Great, appreciate that. Here's a question for Tushar. Now OpenStack is being run on Kubernetes. Will this OpenStack use the cloud native storage instead of having to build stuff? Yeah, so I'm not sure why the progress of this project, but this looks like a orchestrator on top of orchestrator, right? So if the real use case here is running VNFs on Kubernetes, there are very nice projects which are Qvert and Worklet, which take care of deploying your VMs on top of Kubernetes. And yes, it does use cloud native storage instead of having to build stuff. So I'm not sure if the ask is for OpenStack on Kubernetes. Yes, it could very well use cloud native storage for the VMs rather than having to build stuff. Great, thank you. We have a question here about EdgeStack. So which EdgeStack projects, StarlingX, Acreno, Quart, et cetera, are more sustainable and easy to use network slicing for smart cities? Yeah, I guess it's very difficult to answer that question. So certainly, even in Acreno, right, there are many, many blueprints. So it is up to, I mean, the reason why there are so many blueprints are that there are so many use cases. You know, different use cases may require different capabilities and different functionalities. That's the reason you have so many blueprints in Acreno itself. In the smart cities perspective, I mean, I don't know about other blueprints, frankly, but the blueprint which we are at Intel and a few more community members are working on is called IC and blueprint family, integrated cloud native blueprint family. One of the smart cities, one of the smart city application is actually deployed using that blueprint. So I can only say up to that, but I'm sure there are many other blueprints and many projects are equally applicable and suitable for smart city applications. Okay, great. Yeah, that was a little bit of a tricky question. Here's another one for Tushar. Is Shri Av ready for prime time? Yeah, at least in the deployment that we have the Shri Av ready, Shri Av was the integral part of almost every real telco application, right, and this included whether it's a CDN application or if it's a DU, RU and other applications, but yeah, I think it's something that every render is using so and it is running in production without any issues. So I assume yeah, it is ready for prime time. Great. Here's another one for you Tushar. This is a follow up to an earlier question. In Kubernetes, the POD network is flat across namespaces. How do we ensure that the application traffic between apps that belong to different namescapes are isolated? That's a good question. So the answer is yes and no. So I mean it's not an objective question, but still. So it is possible to isolate the traffic and Kubernetes network policies help here where you can define a network policy which could essentially isolate a single POD or a particular namespace or even you can have a group of namespaces and carve out as a tenor namespaces and have them isolated together or it could very well be a level based as well. Even Istio provides you some kind of isolation there, but all of these things that only work and work on Calico as the primary interfaces. Now when you are talking about SRIOB based POD, you have the challenges where these Kubernetes rules don't apply because Kubernetes only supports a single interface and all the things that work on which will work only on the Calico based networks and the traffic and this is one of the challenges that still needs to be solved as far as I know and it's still being worked on. Yeah, just to add to that, there are, I mean, as Tushar mentioned, we have multiple network interfaces for the PODs and they're absolutely right. The networking is common across the PODs. At least from the primary network interfaces, people use Calico or any other things, Kubernetes already defined a concept called network policies. So you could ensure that you create policies such a way that, you know, across the namespaces, for example, as you asked, you could have policies across namespaces or even across PODs within a namespace. That's one facility that is available. But the question may be that, you know, in CNF, you could have secondary interfaces and secondary networks and who would take care of security among them. And that's where, that's where we believe that, you know, as Tushar mentioned, that's a going on at this time. That's kind of a work in progress. But in a Crino ICN project, as I mentioned, we have a secondary CNI called Woven for NFE. And using that Woven for NFE, a similar network policy concept that is provided for primary networks is available for secondary networks also. So you may want to check that out. Yeah. Thank you for the thorough response there. We now have a question coming in from Central America currently for a telco or CSP company. How would 4G LTE be integrated with dynamic slicing, dynamic slicing, would white box switches and bare metal services be used? Yeah, I don't know how to answer that question. But, you know, if you're looking at large number of slices, right, that dedicating the servers for physical resources for each slice is going to be a challenge, right? It's from the cost perspective and the manageability perspective and automation perspective. I still believe that whenever we talk about dynamic slicing, I'm assuming that it is on demand slicing. It's good to go with some kind of a virtualization platform or continuation of platform like Kubernetes on top of bare metal servers. That's my view. Great. Thank you. So we just have time for one more question. And before we jump into that, I just wanted to remind folks that yes, a recording of this webinar will be available in the next day or so. We'll be emailing that out to all of the attendees and it will be posted on the LF networking website. Okay, so last question is about a simulator. Do we have a simulator to test topologies with Kubernetes or containers? So if it's a question for me, I am not sure what this simulator is about. So Trini, is it along with the previous question that currently, how would 4G LTV integrated with dynamic slicing? Yeah, so certainly as in the dynamic slicing perspective, right, you know, that the community in OneApp does have a simulator, the CNFs, you know, because it's for testing purposes, right? So those are part of OneApp itself today. But in general, in general simulators are very common, right? For example, in a free 5G demo that was given in the last two or years, for example, they are using GNodeB simulators. So I don't know how to answer the question, but I guess on per project basis you might be finding simulators for testing purposes. Okay, that's all. Okay, great. Thank you. Well, we are at time. So I appreciate everyone's participation today and we'll see you on an upcoming webinar. Thank you so much. Yeah, thank you all. Thanks everyone. Bye.


What was the real reason why BTS got invited to the White House? Was it to solve Asian America's problems or are they political pawns? Welcome everybody to the hot pop boys. Global superstars BTS got invited to the White House to do a one on one sit down with President Joe Biden himself. Now, a lot of people are proud of them doing it and they're happy about it. But a lot of people are also kind of confused because they're like, wait, why did they go there representing Asian Americans if they're not American? I mean, I think you can look at this as simple as these are some global pop superstars meeting a president head of state. It happens all the time all the way to like, man, what are the implications for Asian America? And guess what? We're going to be talking about the implications for Asian America right now. So if you guys are excited about this video, hit that like button, check out other videos of the hot pop boys and please leave your comment down below. So we got five crazy takeaways, but here's the first one guys. Shout out to the BTS army overall. I thought it was a net positive. You know, RM, he is eloquent in English. I thought the things they said in Korean were nice. They're just like, we are different. We have different cultures, different histories. We can learn to respect each other. I thought that was important to acknowledge differences on the way to peace. Uh, Biden, strangely enough, Andrew also had a good bar. He said, you know, when good people talk about the bad things that are hidden, they tend to go down. All right. So let's be honest. I don't think any hard solutions came from that conversation. You know, it's not going to save anybody's life, but overall did shed a lot of light onto the issue. Was there a whole record number of reporters in the room where a whole other bunch of other politicians trying to get a seat in that room. So listen, it made people care about this talk, whether it was just based off a PR move using the star power of BTS or not. It can still be positive for Asian American, whether Biden knew they were pop stars, they were the Asian Beatles, or he actually thought they were in charge of some type of army or whether or not they're trying to maybe capture some votes from the BTS army demographic that can vote in America.  You know what I mean? Like they're very lesion in the suits. Yeah. They're very Asian. Listen, they embody Asian culture. So for them to be that famous and be on that stage, you know, whether or not you agree with it, it was a net positive in my opinion. I will say I was skeptical at first. I was like, wait, why are they at the White House? What is this going to do?  And anytime Tucker Carlson gets mad, it kind of goes to show you that the Democrats did score a big hit. Right. You know what I mean? Like I said, we're not picking sides. I'm just saying in terms of overall how it played, even though we were going to get into the controversy later, like it was a net positive. Moving on point number two, Andrew, it was confusing.  This is a H N P I, which is Asian American native Hawaiian Pacific Islander month and all this stuff's happening in America. Why is this pop group of these like gorgeous guys from that are raised in South Korea probably sheltered from a lot of these things? Why are they speaking out as our big dogs? Well, you know what's funny about them? They can actually kind of relate on some level because they experienced a lot of racism and discrimination from the global music industry. Right. Because even though they're from Asia, maybe they didn't grow up with racism for being Asian in Asia, right? But when they enter the global market, that's when they're they're at the high school with everybody else. I've noticed that a lot of VJs, whether it's from America, Canada, South America, Australia, not all of them occasionally, they'll try to downplay BTS's success because they'll be like, yeah, who are these like girly boys like singing and dancing on top of the charts? We like our own music. It's kind of nativist. Yeah. You know, so they're not maybe they're not on the streets of New York or Oakland experiencing all this stuff firsthand. But, you know, they have some context for it. Let's give them some credit. I think they care about their fan base, too, which is located in Western countries, probably going through it or at least seeing it online. And also doesn't make sense that it's from South Korea, which is has very close ties and positive ties with America versus, let's be honest, pop stars from China, which is definitely the geopolitical adversary right now. China would be viewed as some sort of anything from a rival to a arch nemesis right now, at least. And then South Korea would be viewed as like a good homie.   All right, guys, point number three. David, does this show that Asian-Americans, we just don't have that many stars to represent us that can draw this much attention? Yeah, I mean, I think if you would have assembled like the famous Asian-American Avengers of the past like six, seven years, you'd have like Michelle Yeoh, BTS, Rich Brian would show up. Maybe Henry Golding would be there and none of them would be American. Yeah, even Seymour, I think he has a Canadian passport. But you could have Jeremy Lin and Aquafina show up. But as far as like drawing the attention right now, I mean, yes, I think, and we're going to get into it in a later point, I think a lot of Asian-Americans are starting to realize that the global narrative is kind of our narrative. Yeah, I think that it's interesting. You can learn like almost like better American skills in an international school overseas sometimes than you can as an Asian-American. And it's so funny because Eileen Gu, who is a gold medalist of the Olympics, she won the gold for China and not America. So I don't think she'll be meeting with Biden. Oh, if Eileen Gu had won it for the US, I guarantee you she would have went to the White House by now, but I'm sure she's completely forever banned from the White House. All right. Point number four is that the Asian-American identity is becoming more and more complex and that we may have to accept a global narrative as our Asian-American narrative. What I mean by that is that there is so much talent, Asian talent coming from overseas, not just from Asia, but other Westernized countries. Even if that's Australia, UK or, you know, other Asian countries like Indonesia, and they're adding to the rise and the representation of Asians in media that we kind of end up accepting them as honorary Asian-Americans. But do we accept them or is it just like the game is the game? No, I feel like some Asian-Americans, they do accept them as Asian-American and some do not. As you can see on the internet, there's like a lot of debate. But with so many immigrants coming over at the age of five, 10, 15 or people growing up in international schools and they're representing Asians in media, it's almost like the lines are becoming so murky and blurry that you don't really know who's that American passport holder or not. And does it, I have a question. Leave it in the comments down below. Does it really matter as Asian-Americans? Are we just buying into this old school American? No, you know why they're not Asian-American? Let me finish. Let me finish as Asian-Americans. Are we just buying into this old school American exceptionalism by judging these Asians being like, you're not American like me. You didn't grow up exactly like me in, in Seattle. You didn't grow up in New York like me. You didn't grow up in Oakland, LA like me. No, man. You know why it is why it's because they didn't get picked on enough. Ah, they got, they got to grow up and be the elites and have all the systems where they're from. That's an assumption because if you're Asian and you grew up in a Western country, high-likeliness, you still got bullied in some respect. Yeah, but it might have not been in the American way. But like I said, BTS still went through discrimination, joining the global market of the music industry. So I'm not, I'm not saying they experienced it like Asian-Americans, but they're not the same roses from the concrete. I'm just kidding. I mean, I think it's up for a debate, guys. I don't really have a strong opinion on it. I will say this though, it is what it is to our final point. Listen, guys, whether you support BTS being like the big dogs of Asian- America or not, which I think there's valid arguments on both sides. Asian-America is just not at the point of development and we didn't put the work in and we didn't have the unity to gatekeep. So we got to take the help that we can get if our like older cousins or like second cousins from Asia want to come and represent us and they have that much more clout and power than us. We have to take it. So be it. You know what I mean?  We could say that. But at the end of the day, we got to be happy for BTS. But Bruce Lee is like the only sort of Asian-American. Right. He was still raised overseas. Yeah. So I think just accepting the fact that, you know what, guys? Like whoever can help Asian-Americans. That's Asian is almost Asian-American. Like at this point, if you have Asiatic blood flowing through your veins, if you got the Manga Lloyd features and you're doing something cool, you're talented and positive, we'll take you Asian-American. I don't know because it still has an impact. Because listen, also when we talk about Asians in America, that's not just including people whose English is their first language. That's actually just Asians living in America in this context. Anyways, guys, this could be a longer conversation. I want to leave it up to you to leave it in the comments down below. What you think? Those were our five takeaways. Like we said, overall, net positive, very interesting.  Hey, guys, so let us know in the comments down below. Please check out other episodes of the hot pop boys, David, Andrew. And until next time, we out. Peace.


Good day everybody. This is Dr. Sanjay Sanyal, Professor Department chair. I'm going to demonstrate a few salient clinical features about the humerus and its articulations.  So let's take a quick look at the parts of the humerus. This is the particular surface which forms the shoulder joint. So this is the head of the humerus and then like this is covered by halide cartilage. Only one-third of this surface is in contact with the glenoid fossa. I shall tell you about the joint a little later. Just behind that we can see one blue line. That is a small shallow groove and that is called an atypical neck of the humerus. And under that we can see two projections. One projection is this one, the other one is this one. This is the greater tubercle and this gives attachment to the rotator cuff muscles, supraspinitus, infraspinitus, teres minor. And then we have the lesser tubercle which gives attachment to the other rotator cuff muscle, namely the subscapularis. And in between we can see a shallow groove here. This is called the inter tubercular sulcus. In life this is bridged over by a ligament called the transverse humeral ligament. And therefore it is converted into a tunnel and through that tunnel passes the long end of the bicep tendon in its sine of your sheath. And attached to the floor of the inter tubercular sulcus is the latissimus dorsi. Attached to the lateral lip is the pectoralis major. And attached to the medial lip of the inter tubercular sulcus is the teres major. Under the greater tubercle and the lesser tubercle we have this portion where my finger is tracing that is called the surgical neck of humerus. And right adjacent to the surgical neck of humerus where my finger is located this is the location of the quadrangular space. Therefore we can see that the quadrangular space is located just under the head. And laterally it is bounded by the surgical neck of humerus. There are other structures which are bounding the quadrangular space. Through the quadrangular space passes the axillary nerve along with the posterior circumflex humoral artery. So therefore in surgical neck of humerus fracture or inferior dislocation of the shoulder joint it can impinge in the quadrangular space and can injure the axillary nerve with paralysis of the deltoid. The deltoid muscle is located here. The deltoid muscle gets inserted on a tuberosity on the lateral surface. This is the place and that's called the deltoid tuberosity. This is the next ray showing two views of the shoulder joint to show surgical neck of humerus fracture. This is the shaft of the humerus and if you look at the back of the shaft of the humerus you can see there's an oblique shallow line which runs like this. The way my finger is tracing from medial to lateral, oblique lead down. This is called the radial groove with a spiral groove. And we cannot see it very clearly here but its location is here. And through this radial groove the spiral groove runs the radial nerve and the profundal artery. Before that it is visible through the triangular interval. So therefore when we have a fracture of the shaft of the humerus we are allowed to injure the radial nerve. This is the next ray of the left arm to show fracture of the bit shaft of the humerus with the associated injury possibility. This shallow groove the radial groove demarcates the attachment of the two heads of the triceps. Namely above the radial groove a lateral to it is the lateral head of the triceps and below the radial groove and medial to that is the medial of the triceps. So therefore the radial groove is between the attachments of these two muscles. When the radial nerve is traveling through the radial groove it gives branch to the lateral head. The branch to the long head of the triceps and the medial of the triceps is given up before it enters the radial groove. So therefore if the radial nerve is injured in the radial groove the lateral head is paralyzed. The lateral head of the triceps is the powerful extensor against resistance. But the rest of the functions are performed by the medial head of the triceps which is the workhorse extensor. So that is not paralyzed in fracture of the shaft of the humerus. To continue down we see these two ridges one on the medial side and one on the lateral side. These are known as the supracondyler ridge medial and lateral. They give it as fit to a facial septum. The medial intramuscular septum and the lateral intramuscular septum which gets attached to the brachial fascia. And these two septa are the ones which divide the brachium into an anterior flexor compartment and a posterior extensor compartment. Pairing the medial intramuscular septum we have the ulnar nerve which pierces from the front and it goes behind. It runs behind the medial epicondyle of the humerus. Along with that is the superior ulnar collateral artery which also runs behind. Then brings me to this lower part of the humerus. We can see the lower part of the humerus is the one which articulates with the radius and the ulnar to form the humeral nerve joint and the radio-humeral joint. So let's take a look at the parts. This is called the capitulum.  This articulates with the head of the radius to form the radio-humeral joint. And this portion is called the trochlea. This is the one which articulates with the trochlear notch of the ulnar. And that is the one which forms the humeral ulnar joint. In front we can see a depression not one but two. Lateral depression is called the radial fossa. Because when the arm is fully flexed the head of the radius impinges here. And the medial depression is referred to as the coronoid fossa. The arm is fully flexed. The coronoid process of the ulnar fits here. Now I am going to turn this. We can see yet another depression. And we can see only the trochlea here. We don't see the capitulum here. This depression is referred to as the olecranon fossa. When the arm is fully extended the olecranon impinges here. This whole region is called the supracondyle. If you have a supracondylar fracture of the humerus, which is quite common in children when they fall on the outstretched hand. Or if they have anti-idusification of the elbow, which is also quite common in children. Then the upper fragment, the dislocated portion, can impinge on the cubital fossa. And it can injure the median nerve and or the brachial artery. So therefore whenever we see a child swelling in the cubital fossa, we should immediately feel for the radial pulsation. And if the hand is cold and the radial pulse is absent, then we should immediately take for surgical intervention to reduce the fracture, to reduce decompress the brachial artery. This is an extract of the elbow with a child to show anti-idusification of the elbow. Note the epiphysis of the olecranon process also. It is the fracture of the medial epicondyle. Then the ulnar nerve is at risk.  The radial nerve which I mentioned runs in the radial groove. After it runs, it comes to the front of the lateral epicondyle. So this is the lateral epicondyle. And here it is located under the brachial radialis. So this is the region of the cubital fossa. And the contents of the cubital fossa are from median to lateral. We have the median nerve, the brachial artery, the biceps tendon and the radial nerve. MBBR. Now let's take a quick look at the joints. I've held up the scapula here in front of me. And we can see this is the shoulder joint. And we can see that only approximately one-third of this articulates with the glenoid fossa. So we have the fibrous capsule of the shoulder joint. And of course we also have a series of ligaments called the glenohumeral ligament which extends from the glenoid margin to the humerus. Superior, middle and inferior gleno-humeral ligaments. If you take a look at the scapula here, this tubercle above the glenoid fossa is the supraglenoid tubercle. And this tubercle below the glenoid fossa is called the intraglenoid tubercle. The supraglenoid tubercle gives attachment to the long end of the biceps. It runs through the shoulder joint and then it runs in the inter tubercular sulcus in the tunnel made by the transverse superior ligament. This is the clinical picture of a patient that I happen to see who had ruptured of the tendon of the long head of the biceps on the right side. From the intraglenoid tubercle we have a long head of the triceps. Now I will show you how the lower end of the humerus forms the elbow joint. So this is articulated specimen that this is the ulna here. This is the trochlia nut of the ulna, which fits into the trochlia and this is the head of radius which fits into the capitula. So therefore when the arm is fully flexed, head of the radius fits into the radial fossa and the coronite process which is the anterior fits into the coronite fossa. When the arm is fully extended, olecranon process fits into the olecranon fossa. This is a lateral X-ray of the elbow to show how the trochlia of the humerus fits into the trochlia nut of the ulna. And this is an antrepressory X-ray to show how in a fully extended elbow the oligrenal process fits into the oligrenal fossa. If a child is pulled by the hand, sometimes the head of the radius can subluxate either subclinically or clinically or it can even dislocate and it can come out from the annular ligament in this region. In such a situation it can injure the radial nerve which is located right in front of the lateral epicondyle. So these are some of the points which I wanted to mention to you about the humerus and its articulations. Thank you very much for watching. If you have any questions or comments please put them in the comment section below. Have a nice day.