 Okay, I can actually see people now. And you can see me, that's usually half the problem. Okay, so I'm Margaret Kiyose, and as a lot of people know, I worked for a tier one carrier for a long time. And now I work for a vendor. So my goal is to actually go through some of it's always position of what we wanna see going forward, and then some of it's actually my personal opinion. But this talk actually was done in combination with a lot of people back in headquarters. A gentleman named Kailao, and another gentleman named Feng Hongwei. So they actually helped me create this. So that's actually, I think a talk we all feel comfortable with. Oh, how come it's not showing anything? Okay, why is it not showing anything? It worked before. You know, all I did was get out of screen mode for some reason. Okay. Okay. All right, so three areas. I wanna go through a network framework that we spend a lot of time actually back in headquarters to make sure we all agree. And we're on the same level. And then I wanna introduce the concept of identity and policy. Actually it was something that came up in a conversation with a certain vendor, another vendor. And within Huawei I wanted to sort of give you a feel for where we are. And just I think some areas, I'm actually sort of new to identity that areas of trends that are happening in the identity space that I think is that may impact the FIDO community pretty heavily if we're not watching. So this slide basically goes over, you know, it's very simple, right? I mean, people have seen this in a lot of variant ways where FIDO fits in. And FIDO's more on the data plane area, right? Over here. But there's all these other layers that interwork with it that are critical. So you have the application layer, you have an orchestration management layer, you have, of course, you have the network controllers, you have your operating system, and of course you have the hardware. So, I mean, I assume, since I haven't been involved in FIDO for a while, I assume everyone realizes that a lot of these pieces all interwork together with FIDO and that you can't do FIDO in its own little world. The interface with the rest of the ecosystem is pretty critical, because in the end data plane by itself is not sufficient, right? It's necessary, but not sufficient. So all these other pieces are necessary. So it is similar like the controller was not sufficient and you needed a data plane, right? In between the two, you're further along, but even then it's not really sufficient, especially when you start getting to virtualization. So management orchestration become pretty critical, okay? But I assume this is not controversial. So this is probably the key thing from a Huawei point of view of areas that we think need to stay open, if I call it that, or standardized in some sense. And how we do it, you know, it's in one place and maybe needs to evolve. So the one thing which is one of the reasons why the FIDO community got created is to come over the common, I call it the common overlay strategy for any type of environment, whether it's a virtualization, containers, bare metal, it shouldn't matter. And that's what the ones here stand for. I'm trying to show one here, the orchestrator, the different orchestrator and the one here, quote the different hypervisors or container environments so you can support multiple applications at the same time. But the key thing is we would like to have one overlay. This might be blasphemy because we're in open stack, but I don't think if you're a real network person in the middle of all the different networking, I don't know if we wanna go down the path that neutron has gone down. And the OVS and the OVDBs, I know they're changing, but they all started out in Ethernet, right? Layer two. And on the carrier side, Ethernet was just one out of many protocols that were used. And so you have a lot of Layer three protocols or services as well as like MPLS based services and you know, things of all. And I've been in the industry for almost 40 years. Actually I think this is gonna be my 40th year in the industry. And I started out in networking with async and bi-sync. So I have seen every single flavor of protocols ever thought of and when Ethernet finally came, I said, okay, I hope we're done. We don't have to do anymore. And then of course, no, that keeps evolving. So my only point is the network industry evolves has to be flexible for whatever the new applications are. And so because of that, we need, if you use OpenStack, we're in the OpenStack conference, if you get into the OpenStack neutron space, we need an environment that's actually flexible for all the different, you know, evolutions and so forth. So I see one of the Chris's cane. I don't know if you guys saw, there's a Chris talk and there's all these Chris's. Okay, so I'm sorry, I'm diverting. So, and I only probably have like 15 minutes. Okay, so that's the first space. The second is we need a common API for the data forwarding plane. Combination of, if I'm going the wrong way, there's really two types of control planes. There's a control forwarding plane and there's like a management plane. And right now, fine, today the control forwarding plane might be BGP, but as it evolves. And then management plane, okay, could be Yang, Ma might be Honeycomb helping and so forth. But even that might, will probably evolve. But the key thing is we wanna make sure these are open so that as we innovate in the forwarding plane and evolve, right, we gotta obviously interface well with our control planes, whether it's the management forwarding plane, which is more model driven or the, did I say management forwarding? I mean management plane and then the control forwarding plane, which is more around the routing, you know, and all the stitching and so forth and setting up paths and so forth. So that's pretty critical. The third area is a common API when you start getting to applications. And here I stick things like, I just sort of stuck things here, like policy identity. And whatever applications we create, we wanna make sure there's a common interface so that the data plane can take advantage of it. So as you can tell, I'm sort of taking things apart and I'm trying to show areas where we need to have commonalities open interfaces on. And on Huawei's side, we're very serious about it because our view is we need to do a lot more mixing and matching with a lot of evolution in these little, in these little, in these different modules in their own right and then we gotta make sure everything's more plug and play. I don't know if you've been familiar with all the OP NFV and the things that got involved with that. I'm really into this modularity and this plug and play, which of course is in a bigger sense, but even at this level, we have the same thing of a plug and play and there's different functional pieces, I would call it, that are actually important and that innovation happens in its own little ecosystem, but they all have to work together to really have a holistic system that works. And that's what this is trying to show for three on these two spaces. And then, let's see, four is down on the hardware level. So we have dbdk, we have odb, we have whatever might evolve going forward. But the key thing is we want choice and have a lot of different choices of hardware. On the carrier side, we wanted choice because the vision was you could, you might be able to classify anything that, well, when I was in the AT&T, anywhere AT&T existed. And so that included a hut, a cell tower and things like that. And the vision, I mean, not to insult anyone, but the vision is that one chip vendor can actually be best and brief for all those sizes, if I call it that, is probably a little bit to Nirvana. That's another session that's tomorrow. But, and so the vision was you could have a choice of all these different chips as they evolve, as they get optimized for whatever the different environments. And we don't want to keep reinventing the environment. We don't want to keep reinventing data plane. We don't want to keep reinventing this whole thing to make this work. So that's the whole vision of the DBDKs and the ODPs of the world. So currently today, you know, you've got the DBDK that has now been included or the ARM, Lanera folks are now participating more in DBDK. But I actually talked to Bob Monk on the other day, because I've been, as people know, I've been sort of out of this area for a while. I just wanted to get a sense of where were we? In fact, I joked around that I was gone for like six months or eight months and progress has not changed as drastically as I had hoped. Because the discussion we had yesterday or last week was the same discussion I had two years ago with him. And the point is, the vision is to have DBDK to be more of the generic interface for both, for all the different chips. And in the ARM space, the ODP is still probably a little bit better. It supports things like event handlers, which I think DBDK still is challenged on for whatever reason. And the performance, my understanding is on the ODP ARM side is still better than the DBDK side that interfaces the ARM. So I think it's really critical that the industry really works, I don't know if I call it fixed, but really tries to converge and get whatever the interface we have from the floating plane down to the different chips to make sure that we really do, we can use the best and breed other chips and we don't disadvantage one set of chips for another set of chips based on the interfaces. And I get the impression it's not a technical issue, really. It's still a community issue of really trying to work it for real. And then the different biases of why certain implementations are important and why they're not. I actually, my view is, forget about complaining about this implementation is better than the other, like is event needed or not. It's like if that set of chips need an event, just do it. Get it over with and get on with life instead of arguing. So that's part of the concerns I have at times. We try to optimize a little bit too much to the point that we really do disadvantage a different section of the industry. So that still needs to get worked. But I think it's critical for us because we do not want to have, I mean not, we're already going down that path. We have a VP over DBDK, we have a VP over ODP. And I think it's sort of wasteful energy if we don't converge. But if we have technical reasons to have it separate than fine, that's reality. But it's not clear, there are technical reasons for that still. And then finally, like I said, the identity is becoming more and more of a discussion and interest that's going on in the ecosystem and the policies that support it. And so now the issue is from a vital point of view, how does that fit in? Okay, so that's actually, I don't know, how many minutes do I have? Is there a clock anywhere? When am I supposed to be done? 9.30? Okay, 15 minutes. Okay, so I just go through parts of this a little bit more in depth. So this slide shows how a data plan can be in a lot of different scenarios. And of course we'd like FIDO to be that, the data plan. And so it just shows, right? You have a VM, so you have a FIDO here, you have container, you have a FIDO here. You have multiple VMs environment, so you want data plan forwarding, so you put it here. You might even have a smartNIC, right? With its own ecosystem. You know, as we went to, I joke around, as we went to NFE space, putting everything in a Linux environment, VMs and so forth, and all of a sudden you have these smartNICs coming and saying, hey, we can be our own little world too. So now we're going back into hardware, except hopefully easier, flexible hardware. And so there, you know, you might start needing data plan here because you're pulling in certain applications actually down here. It's getting pulled from up here to down here because throughput performance has become so critical and they're finding going through the whole operating system stack and so forth is not as efficient. And that there are certain applications, I would call it, that actually, whoops, that actually need a smartNIC and in the environment that it supports. So if we have that, then we would like a phyto in here. And then of course you have devices, same thing here. Okay, so I think this is sort of self-explanatory. Right? No questions? Okay, I feel like I'm talking, just talking, okay. So the other areas, you know, user space actually is critical. We want to move more and more of the data plan out of the kernel into the user because of the goal of, you know, high IO, high throughput, low latency. And the kernel wasn't quite meant to just focus on the space. So this is going through concepts of sockets, right? And I feel like I'm going back to decades ago when I knew Unix and so forth, but POSIX APIs and the key thing here is actually trying to have a stack pull. So it's more of, you know, shared memory and so forth, the moving things back and forth versus copying, right? Anytime you copy, that's a death, kiss of death from a latency and from a throughput point of view. So if we can move more and more memories and so forth and shared memories and pointers and so forth, that's probably the more efficient way. But the goal is to have a more unified compatible socket interface. Well, like I said, get out of the kernel stack and basically put more of the SLAs that are going to be required of us more and more as the industry starts moving toward, you know, VR, AR, right, types of things. You know, we're beyond video, right? Everyone's done data, video, right? Video's quote solved, which of course is not, but I mean, it's definitely further along and the next new applications I would say that's going to focus or stress performance or have more stringent performance requirements and higher throughput is actually the VR, AR space. So that's something we need to be sure we're ready for. Okay. Model driven of course is a big thing. In fact, we actually had all these other slides about going through all the ITS and so forth, but I think it's pretty obvious. At least for me, it's pretty obvious that model driven is the way to go, is the way to go. And in certain aspects, you know, Yang modeling of course is in the networking industry is an area where the industry has, you know, centered around and so forth. The problem is just like everything, there are a lot of models. There's a lot of SDOs, open source organizations that are all over the place actually in the spacing overlapping. And so we can have actually conflicting or non-compatible Yang models. And you can see there are Yang models in all these different layers, right? You have from customer service requests there are models being created there from an orchestration point of view there's models being driven here. And of course from a networking controller down to the forwarding plane, there are definitely different models, whether they're management, telemetry, types of models. And so the key thing is we need to continue to of course encourage in all these different models having standards models, but the biggest thing is we really need to have them more coordinated. So this is my personal opinion. So, AT&T with Google started this thing called open config. And the vision actually there was actually to have a central repository for all the different Yang models, period. And to then have tools to support Yang modeling are creating some Yang. So you have like Kevin DeSous's AT&T's Yang config tool, whatever, I don't even know what they call it, IDE. I don't even know what they call it anymore. Actually it's an own app now. They put in the design and creation part, but anyhow it's also in the open config. So that was like one proposal. And then maybe from there you can do all your reconciliations and all your tools and you have it in one place. So the key thing is you don't like stop all the creation of Yang models in the different open source SDOs. The real suggestion is can we at least have one repository of it. And then so at least as you're working in one arena you start seeing the tools and take advantage of maybe the tools that another arena might have created. You might even see of course all the other different Yang models that are creating the other SDOs and capitalize on and build upon and so forth. But I don't think we're, I think the industry has pretty much adopted that modeling is the way to go for faster creation, more flexibility on different pieces, whether it's services, all the way down to configuring elements. And now the issue is can we organize a little bit more efficiently through one organization, whatever that is. Okay. All right, so identity. So I said identity is an area that Huawei is actually getting more and more into. And in fact the industry is starting to get more into. It's like the next bleeding edge. And what is identity? Basically it's the who and the what of an element. So it's not tied to a physicality really per se. I mean it can be, but it's really tied to let's say a user, maybe with a combination of something physical, the combination of the user with the physical device is the identity of that quote person. Like I am an identity market on an iPad, which is a different identity of market on a cell phone. So those are unique identities versus just market as an identity. But even though let's say you have market as an identity, there are certain types of characteristics that I might want from my network and my services that doesn't matter whether I'm an iPad or I'm on a cell phone or whatever. And then there might be more details of what I might need if I'm on a mobile phone, which is different from if I'm on an iPad and things like that. And that's different from an identifier, right? An identifier is basically, that's usually tied to a physicality, a wire. And so the two combined are necessary I think to actually go into the space. Now why is identity important? Now on a carrier point of view, it's pretty obvious why it's important. When you have network failures, major network failures, it's actually pretty critical to know what customer you've impacted. And when you get onto cellular, right? When you have failures, it's important to understand what users, which might be actual cell phone number and so forth that's impacted, especially if let's say it's the president of the United States, right? You might want to know that instantaneously, right? So it's really useful to respond to customers for fault analysis, recovery, and just even trending SLAs to provide to that customer. This is an old term that was done in AT&T proactive predictive preventative. Basically having self fault isolation and recovery. And based on a customer, you might do it differently than another customer for whatever reason. But one of the values of identity is actually all the data collection that you get. If you collect a lot of data on your networks, whether it's the data plan, the control plan, and you tie it to a specific identity, there's a lot of great analytics you can do there for revenue generation. And that's actually the main reason I think why identity is important is the monetary things you can do with it once you identify traffic or control plan types of things for a specific customer. Because you can think about it, you can generalize it. You can say things like, okay, maybe for the automotive industry. Once you know the identities relate to the automotive industry. You know, these are trends that we want to do. Or you want to do it from, I don't know, all cellular traffic and so forth. You know, on and on and on. iPad traffic, whatever. So different markets, different platforms. Just a lot of different ways once you have the data and you've tied it to identity that you can actually analyze your heart's delight, actually, depending on what you're trying to do, okay? So where would you, if that's the vision to get into faster customer response for analysis and so forth, you know, big data analytics for revenue growth or even other analysis, you know, capacity, whatever, you know, all the life cycle of an environment. Where do you put it? So is it in a control plane? Is it in the data plane? Is it in both? And wherever it is, you know, that first framework slide I showed, that should impact FIDO, right? Especially if it's in the data plane. Then we have to work on, you know, how do you put it into the data plane? But if it's in the control plane, or it's the control plane with the data plane pieces, then all that has to get worked out. And I'm not telling you what the answer is. I'm just saying, if it needs to be in all these spaces, we just, as an organization, we just gotta make sure we have an interface that is open so that we can evolve and support and actually ride this next wave of, I would call it applications that are tied to identity. Is it centralized or is it distributed? Usually within, you know, your own domain, corporate domain, you can sometimes get away with centralization, but sometimes, of course, for scale, you need distributed, right? So it's probably gonna be a combination of both. I can't imagine it's all one or the other, even though the industry keeps trying to push one or the other, we're always finding cases where sometimes we need centralized and sometimes we need distributed. And so the same thing's gonna happen here. And then the key thing is, do you tie the ID, the identifier to the IP, or do you actually place the IP with the identifier? So there's actually a slide by the folks who are heavily into content, identifying things by content. And this is really more of their bias. And I thought it was fascinating when I saw it. So this is the progression. I mean, it starts a little bit in a world that wasn't quite captured in the industry, but you start with the open flow, you have IPSDN types of concepts. Then the next thing you start getting to virtualization, so you now have SDN and NFE together. And then now you start getting to identity, which is now trying to map the identity to content, right? And then the identity to IP. So you're now trying to get the network to be closely more tied to content. Well, there's a movement, whether it's successful is a different issue, is replacing IP and actually just replace it with these identifiers, which are tied to content. So I think a drastic that is, can you imagine if IP goes away and you really replace it with an identity instead? I mean, think about it. Our equipment has to change. So it's like a fascinating, I actually like this. I can see how IP can be dated and this is the way to go. Because I think when we started having our cell phones and all these different apps, it changed the network industry pretty drastically that people more and more relate to specific apps and relate to themselves and so forth. And so now the question is, is IP dated? And is content actually the better way of really looking at the world? And then the question is, do you go down, even down to the router and switch layer, instead of doing IP address and you do it based on content? And what does that really mean to what we do here? So I think it's a fascinating area and I'm hoping this organization is more open to the discussion. You know, I'm gonna make another snide remark because I've been around so long, but when SDN NFE started, I was in the MEF, I was involved in the MEF, and I got a lot of grief, a lot of grief about this was a bunch of crap. And I mean, the whole organization was in an uproar. Just went into the uproar and I kept arguing. I said, guys, you guys are thinking about today and the issue is you have to look at the future and sort of ignore reality and think of the future potential of why this is important and what it's trying to solve. I mean, whether the details of whatever's happening today, because at that time it's open-floor, right? Whether that's a valid or not, that's not the point. It's like the concept of what an SDN is, the concept of what a virtualization is, it's like what problems can you solve that are harder to solve now today with these ideas? And then look at where we are now, right? I mean, I got so much grief that I actually moved out of the MEF because this is the area I wanted to go into, the SDN NFE world and of course the rest is history and where we are now. And I actually think this is another area that's like that. It's another pivotal moment that can actually, that can actually influence the industry pretty tremendously. Now the issue is how do you do it? So in Huawei, there's definitely a faction that's more focused on mapping the identity to the IP address. So there's this whole thing called ideas. They proposed it or we proposed it with some other companies. I don't know if we've listed all the companies here, but you can go to the ITF. And you know, in Chicago, a few months ago, this was proposed and we want to form, I guess it's called a working group under ITF or whatever, to basically try to start fleshing the ideas out, fleshing how do you get content tied to the IP world? And then of course, provide the different types of services necessary when you get into content areas. So I know at a simple level as a former carrier, I can actually appreciate the value of content and the identity, the whole value of it, better than even the IP stack. Now the issue is how do you do it? Do you do it this way or do you do it this other way, which says, throw out IP, go to, throw out IP, go right to content, or do you map it to IP? I don't know what the answer is on that, but I just think it's an area that we really should look at more and more. Okay, and then policy, what do you mean by policy? I mean, a lot of people know what policy is, right? Set of conditions, which basically allow you to designate who is authorized to access certain resources. You know, what are the circumstances in which they can use those resources and you know, how can they use those resources? So this is basically a contract, right? Between the end user and the provider of a service is how I view policy. And then it shows here it could cover everything, you know, performance, usage, availability, cost, security, and so forth. But once you get into identity, policy becomes even more critical, right? Because you have different policies, like I was saying before, you might have policy for market in general for all the different equipment she's on and then you might have a more specific policy for the cell phone versus the policy for the iPad versus the policy for the television or the policy for even market in a car, right? So just think about how I can imagine myself going from, you know, there's me and then I'm in a car. So there's that type of networking that I might require versus all these other elements. And so you can actually then tie that all together. And then again, we're all of the, again, just like everything, right? We have policy being worked everywhere. So again, we have the challenge of trying to get everything converged. So we just got to make sure as we get into identity, right? The identity and the policy parts work together and we have to make sure in the final path that we have a more standard way of interfacing externally or externally in the final space. And then finally, my community one, let's work together. So basically on these five points I showed in the very first set of slides, common overlay, common API to the VPP for management control, forwarding planes, creating a common application interface for as we evolve to identity and policies, common API. So if we can get DPTK and ODP to converge better but to also still be able to support the diverse set of virtualized environments versus different chips, the NICS, the NPUs, the FPGA and of course work on applications like identity and policy, which I think is the next wave. And that's it. Okay, thank you. I guess no time for questions. Thank you, Margaret. I think we can take a question or two. Oh. Hi, Margaret, nice to see you here. So what do you summarize as content metadata driven policy enforcement on top of traffic flows, right? Through FDIO. If you, recently, not recently, but still recently, AT&T published the network 3.0 in Digo inside which implicitly referring this topology. So I don't remember, I don't represent AT&T, but okay. I know you're not, but that's the thing, right? NFE SDN driven by domain 2.0 and now we are going network 3.0 AT&T is kind of a little bit driving. Well the network 3.0, if I understand it correctly, is going after data analytics, right? Other metadata and so forth. Secure access to data through multi-party with the federation, which is pretty much implying this requirement and implementation of what you have presented to us in my humble opinion. Oh, okay, wow. Well, I mean, I always thought that the whole reason for all this stuff, SDN, NFE, even fight on self-worth is in the end, you wanna collect data. I mean, networking people have always had to collect data for survival, right? The network goes down, you have to know what to, you have to know where, who it's impacting and where it is and how to recover. So data, big data, data people have been doing forever. They didn't just call it, they didn't call it big data. And then this whole AI and data analytics come out. I mean, network people have had to do that. Or at least the carers had to do it because they had to survive. You had to keep everything up and running. So now we have the big buzzwords. Okay, fine, great. My only, I mean, maybe it looks so similar, but in the end, that's because in the end, this has always been the name of the game, right? I mean, you just don't put a bunch of boxes together, call it a service and it runs by itself. The heavy lifting is actually collecting the data, sorting the data, analyzing the data and figuring out what to do with that data and automating it because you can't get enough people to keep up with all the crap that happens when the network goes down and all the people that get impacted. So yeah, so if you look at H&T's, you know, domain two, domain three, or network three, whatever. So yeah, it's going to the networking, I mean, the data analytics, because in the end, that it was the end game, no matter what. It's just now a big buzzword now because the Googles and so forth of the world made it such a big deal. But actually the networking people have been doing it forever. So this is just trying to say content is becoming more and more critical because it's getting so intertwined to networking, right? It's not this separate stack. It's very much for the network to be responsive to it. And because things are so dynamic, you're being forced to it more and more. And so why? Do you want to call that three dot, oh, I don't know. I just can see that that's the next area to get into. Okay? All right, great. Thanks. I'm sure I don't fall off my chair.