 Hi folks, welcome to today's webinar. We'll just give another minute or so for more as more people join Okay, we're gonna go ahead and get started Welcome everybody to today's LF networking webinar today's topic is cloud infrastructure telco task force or CNTT for short We're gonna be giving an update. What's new what's coming up? so Before I introduce our panelists just a couple of housekeeping items All attendees are going to be muted throughout the duration of the webinar However, we do encourage Q&A throughout the session. There is a Q&A window You're welcome to type in your question at any time We do have a few minutes designated at the end of the presentation to go over those questions So feel free to to post them in the window as they come up. All right, so I'm gonna go ahead and kick off Welcome our today's presenters. We have Bob Monkman He's director of open-source strategist at Intel Corporation and we've got Robbie Abdel He's a network cloud principal architect and senior manager at Vodafone group and both of these gentlemen have been involved in CNTT for quite some time All right, so without further ado, I'm gonna kick things over to Bob Thank you Jill. I greatly appreciate it so let's get started by Reexamining the problem statement that CNTT has set out to achieve You know, it's been several years since we began to see the deployments of virtualized network infrastructure that was Originally envisioned at the launch of network function virtualization, you know way back in the fall of 2012 and To be sure a great progress has been made but the progress on network transformation Has not been I mean frankly, it's not been as smooth nor as far along as we had originally hoped for by this time and you know what we have seen is Over 60 NFEI implementations and in most cases a fair amount of dependencies in the V&Fs on those underlying platforms effectively Creating virtual appliances You have to the vendors have to go through a onboarding and verification compatibility, you know process with each with each NFEI platform and V&F vendor combination and we end up with a lot of siloed deployments and You know these interoperability issues have led frankly to the onboarding time stretching to weeks and months and Really higher operational complexity higher costs and You know less ability to get out more new functions for new services, which was the whole point of service agility, right? And so what we aim to achieve in CNT Through a highly collaborative and very focused effort is to realize a more focused and finite set of common cloud infrastructure specifications and configurations greatly expanded verification protocols that result that the combination of which will result in a lot a lot clear expectations and verification and conformance of the combination of the network functions on the cloud infrastructure platform and You know obviously what we hope to achieve then is greater agility and deploying an onboarding new network functions reduced complexity and the operation and the cost of Executing those new network functions Better consistent operating model scalability easier route to automation and better better Expectations of we know what the verifications and conformance is Is defined as and how it's achieved you can pre verify and in the end we get to you know quicker onboarding and More network functions deployed in a given period of time Next slide brand So just from a semantic standpoint what it what is the cloud infrastructure telco task force all about so again Primarily, we're looking to reduce the number of cloud infrastructure configurations on which you know the vnfs and the cnfs have deployed Across the operators. So that's you know, that's sort of one of the key efforts here, right is to really define, you know, different, you know Config configurations for that are very well defined and the way that vnfs and cnfs should be expected to be onboarded are very clear and very well defined You know, it's really focused on the telco communications infrastructure network operators, right And they started this, you know back in early 2019 And got together and announced the initiative at on s North America in San Jose in April but then quickly opened it up after some level setting and some some Agreement on the fundamental goals and the ways of working They started bringing all the the vendors from the supply chain on board to participate And it's grown as you'll see in a coming slide. It's grown to you know, nearly 40 kind of participants and We are meeting weekly in a number of work streams. Robbie is going to go over the details of all the different work streams the different specifications we're creating, etc But the the goal here is really it's a very focused collaborative task force the entire supply chain working in collaboration with gsma gsma is going to ultimately hold and and And archive the artifacts the specifications a lot of the implementation of testing protocols and reference infrastructures to To help flush out those testing protocols are going to be done in the opn fe Under the linux foundation networking umbrella. So very close alignment between all these various industry bodies the stakeholders in the supply chain who are going to work together to improve the situation and accelerate network transformation. That's that's what we're all about here Next slide, please so You know at the outset we We when we when we got fairly fairly well into the process here, we spent some time talking to the decision makers some of the executives at both operators and suppliers to the operators in this in this community effort And we wanted to ensure that we had a really solid understanding of what the business value was to all involved And how we could convey that message right and And this is really key. And so some of the highlights of that is we are submitting that cntt will effectively dramatically reduce the vnf and cnf onboarding time From weeks to months down to hours and days. That is a Very crisp goal of this initiative that we intend to achieve in an iterative process We're going to ensure that it is possible to deploy multiple network functions from different vendors without having to create unique cloud infrastructure platforms for each one of those and effectively Getting rid of the virtual appliance, you know, effective situation that we have today and we're going to foster a Very well understood and very well communicated conformance and badging program That will be executed in in under the linux foundation in the ovp Program that you may not be familiar with from before but it's being expanded So that the you know, all of the infrastructure vendors and the network function vendors have a very Very clear and consistent path to greater assurance in deploying these things together and ultimately What that's going to result in we believe is far lower cost spent on and time on onboarding and testing The the these vnfs and cnfs on the cloud infrastructure platform lower operational complexity lower expenses and faster time to volume and revenue, which is what it's all about, right? So we think it's going to greatly expand the whole 5g ecosystem encouraging new innovation New players to enter the marketplace We think it's going to you know, if we can do this faster We can realize that vision of service agility new, you know New network functions and new services can be deployed in a given year That's shorter time to volume and greater revenue for everybody involved, right? So And again, if we do our job, right? And we've got very clear very well defined verification protocols That can be you know done pre pre validated in advance Then there's fewer surprises when they get into the lab at the operators site So it lowers uncertainty lowers the the pain and suffering of getting these things validated and deployed Ultimately what cntt Will do is to dramatically improve The efficiency and the predictability of onboarding and deploying, you know The new network functions and accelerating network transfers transformation in the process And lowering the total cost of ownership. That's that's what it's all about Next slide, please So here's just a quick view of you know, I mentioned that you know, we've got nearly, you know, roughly in the order of 40 participants now In this initiative and growing and so it's a really good cross section of network operators ISVs labs silicon players Telecom equipment manufacturers Operating system vendors and you know management orchestration vendors Etc. Right. So we've really got a good good cross section Of companies here and participation from those companies Is growing we as I as I mentioned earlier We have weekly meetings in numerous work streams and focus groups Robbie's going to go over the details of that But this this initiative is getting a lot of good participation great collaboration And we're moving forward pretty rapidly Next slide So here's where I'm going to turn it over to Robbie And he's going to go into the details of how we're realizing this acceleration of network transformation These new specifications, etc. Yeah, so Robbie take it away Thank you, Bob. And thanks everybody for joining our webinar today And to comment what Bob started in terms of the problem statement This is a little bit go deeper into the details of how do we expect CNTT to improve the VNF-CNF onboarding in a typical telco environment The left hand side of the slide that you can see in front of you Is really showing the current VNF-CNF onboarding process within our network As you can see there are two areas and two parallel tracks that has to happen in order to any For any service to be deployed in our infrastructure So we do have the VNF vendor the application vendor who's delivering the service That we need to deploy in our infrastructure But we also have the VNF vendor who are really providing the platform of which those applications will have to run off And traditionally more or less what's happening right now We have to go through different procurement process to board and procure those VNF vendors as well as the VNF vendors But what happened really when we tried to deploy those applications into the choosing infrastructure We realized there's a lot of design and implementation dependencies of the workload Against the infrastructure What that really means to have to successfully deploy any application in our choosing infrastructure There is certain level of testing and verification that have to happen in-house Before we really successfully being able to deploy the application in our network And if we think about automation, how do you really make that possible? It becomes even more challenging to bring this automation Why we you have this dependency between the workload and the underlying infrastructure with the cntt We expect the cntt to bring in the right hand side of the diagram as you can see some level of standardization If which both vnf as well as and the vi conform to what that really means the vnf vendors when we when they bring their application Or the cnf vendor when they write their container workloads They write against a will will specify the standard that will determine What capabilities the underlying infrastructure will provide to the application level? And similarly when we go and onboard and and the vi solution or a cloud platform Into our network we make sure that the capabilities and the feature set The infrastructure is providing is the same of what the vnf for the workload is actually Expecting but that really mean also that we could rely on industry driven verification program Such as lf and ovp to do the certification on our behalf In essence the vnf vendor or the cnf vendor will go and certify their application in the industry At the same time when we buy an nna vi solution We make sure it's actually certified in the community And that will really reduce the risk that we will end up having to integrate and having challenges in integrating the vnf and the vi Next So this is more on to going into a little bit detail into the the scope and how the cntt Specification is being really structured. So as as we explained earlier There is the vnf side of things, but there's also the infrastructure side of things There's the workload that actually we are trying to deploy in our infrastructure And that workload is expected to understand in details What kind of infrastructure capabilities or metrics it need to have in order to allow it to understand What it has to do in order to deliver the level of kpi and performance We expect to to get from that workload and the reference model is exactly doing that It specifies in details. What kind of resources the infrastructure is exposing to the workload And what kind of feature set and metrics and performance numbers you expect to get from the underlying Infrastructure additional to that the reference model will contain some exceptions to allow the workload without it is a vnf Or a cnf to migrate and transition to be cntt Conformance, so we don't really expect the workload and the application to be cntt Conformance from day one the expectation really is to work together and trying to understand what that transition plan Look like and we're doing that in cntt through introducing the concept of exceptions in our Implement in our specifications that we have in cntt Of course additional to that there will be guidelines to the application vendors to assess them to understand How they expect it to consume their standard and build their application according to that Now the reference model as boob mentioned the expectation is really for it to to migrate and move To gsma, so gsma will keep maintaining their specification In the long run now once we define the reference model and what the workload should expect from the underlying Infrastructure the question becomes how do I deliver this infrastructure? That has the right level of capabilities and feature set which the workload is expecting to have And we this is why we do have two tracks in cntt trying to come up with a cloud platform Based on open stack technology as well as capabilities and containers Technology now for the open stack one. We do have the reference architecture based on open stack That will specify in details what kind of api What kind of functionalities what kind of feature set the cloud platform has to have and that also includes some level of hardware Expectation that we expect to see in the underlying infrastructure To to make sure that we guarantee any level of performance We set and define in the reference model now once the reference architecture is really defined Then the question becomes do we have a reference implementation? Using an open source components and elements that we can Define to realize an Implementation or an instance of the reference architecture that we can use as the basis of the certification conformance program the industry is trying to lead to and this is when we talk about the reference conformance A reference conformance is a set of these cases and these tools that allow any And the vi implementation to be certified against cntt Specification and of course the reference implementation in that case Will be a reference that we can relate any certification activities of vendor implementation Against the reference implementation So that will be like the threshold of what we expect all vendor implementation confirming to cntt to live by And similarly in the Kubernetes and container word, we do have the same kind of setup We do have a reference architecture that will determine in details what kind of components plugins that we expect to see in the in the in the cloud platform that are targeting towards container But also we define what kind of api and interfaces we expect to expose to the workload in that sense And that will be complemented by having a reference implementation using an upstream open source components to define and design an implementation for the containerization reference architecture And finally that will be complemented by the reference conformance Which is again a list of these cases and tools that will allow us to test any cloud platform container based against the reference implementation that we created in cntt And as you can see from this the slide Both of those tracks will be complemented by the lf and Verification program that will allow either the cloud platform Or the workload to be badged and certified against the cntt specifications And across the horizon across the different specification We have in cntt. We do have the network in focus group Which is looking at what kind of feature set from network in perspective We would like to support in different specifications And that's looking into the physical layer But also trying to look at how those resources from network in perspective will be exposed and consumed by the workload And finally we have an edge Wextene that will look at specific requirements that are targeting more the edge use cases For example the open ran is one of the use cases that we are trying to address And look at to support in cntt Next slide Now this is really looking at it from an architectural point of view Of course, there's always a question around Orchestration automation. What are we doing around those topics? And this is really to clarify that when it comes to cntt These are the areas that we consider on the in the scope of cntt So if we start from the reference model, which is the blue Blue shape we see in the screen This is really defining the abstraction model that we set into Into cntt that will expect that we expect the workload to design against And this is basically all the capabilities and resources We expose to the workload the workload in this case can be either a vnf paste vm paste Or also it can be a containerized base But the reference model is a common between both vnf's world and the cnf world Now moving up moving down the stack We do have the cloud infrastructure the software layer And this is really in the in the open stack one is the ra one and that as I explained earlier Defining how the cloud infrastructure from software perspective Will be designed and architected to to fulfill the expectation we set in the reference model And similarly for the container platform the ra2 the extreme ra2 that we have in cntt Will set how the cluster the cabinet cluster will be designed and architected to deliver the capabilities and feature set That we expose to the cnf from the reference model And moving down the stack to the the cloud infrastructure the physical layer We expect this layer to span across different specifications So it will address and touch the reference model. It will also touch the ra1 and also ra2 in that sense And finally we do have the cast manager Which is really the life cycle management of the cloud platform container base And we expect the ri2 to make a choice of what class manager what cast manager We will will be using but that not going to be anything we standardize in cntt So although in cntt we are going to select and determine what cast manager we are going to use for the reference implementation To which is the container base We're not really standardizing how that should look like and what's the behavior of that cast manager need to be And we expect the vendor themselves will bring their own cast manager further on cloud platform But we are using that cast manager for ri2 as the basis of any conformance testing We have to do against the cloud platform and the same story apply in the open stack world for ra1 We expect to choose and select a cloud infrastructure manager That we'll be using as the basis for the reference implementation By again, we expect the vendors who are delivering open stack cloud platform to bring their own life cycle managers That will come with their own product and we're not really standardizing how that should look like and what's the behavior of that That cloud infrastructure manager Should be and finally when it comes to the conformance As you can see from the screen, we do have two system under test in this scenario We do have the cloud infrastructure itself is really the under test that we would like to perform This thing against and that's the rc1 that is targeting against open stack And that would be complimented by the lf and ovp Phase one badging program But also we do have the system under test which will be the cluster itself for the container paste And we expect the ovp phase two to be the program delivering the badging for those kind of platform additional to that those conformance program we design and develop in cntt will also touch some aspect From the workload So we expect the rc1 which is open stack base Also to have some these cases to test how the workload is really consuming The infrastructure in the way that is conformant to cntt specification Similarly when it comes to the cnf we expect to have some kind of testing that will guarantee that the cnf when it is When it is deployed against the infrastructure it will conform the cntt specifications Next slide So this is kind of trying to clarify How cntt is really related to the it's cnfv initiative So if we think about it's cnfv and as you can see it's cnfv is mainly focusing into the management and orchestration There's various different sport of which it's cnfv is really Specifying and focusing on and what we're really doing in cntt We're trying to add this the point of which it's cnfv are not mainly targeting So the things that around the infrastructure and how the infrastructure are exposed to the workload This is something that the it's cnfv are not really addressing at the moment And this is what the scope of cntt is is trying to fill the gaps to avoid having a situation Where you do have multiple variants on the infrastructure That's that's trying to be conformant to it's cnfv But because it's cnfv is not really standardizing in those So we risk the option of having multiple of these variants Existing any given Deployments and this is where cntt trying to step up and trying to define the standard for those components That's not being standardized by cnfv Next And this is trying to also Clarify the relationship that we see Between what cntt are doing and what open a v and ovp are doing of course when it comes to cntt It's all about requirements. What do we expect the infrastructure to contain? What what kind of interfaces and apis we need to see from the from the underlying infrastructure And this is where the cntt in the various specification We we design and develop will feed in many requirements that will go into open a v Specifically if we look at the reference implementation when we really need to have that kind of realization of the infrastructure Based on open source components. We specify in details in the ri What kind of infrastructure requirements? We expect to see that we expect any installer to kind of deliver And this is where we feed those requirements into the open a v and that will determine what kind of hardware We expect the community labs in open a v to contain addition to that when it comes to things like airship We really set requirements into airship to specify What is the state expected from the underlying infrastructure that would like airship to install for us that we can use as the basis for the certification activity additional to that when we come up with With a reference implementation We expect the reference implementation to have the kind of pop book That will determine to the readers of the our specification What kind of instruction in details The any audience of that specification will have to go through in order to allow it to have An instantiation of that reference implementation in their own lab And that really will help and assist Workload vendors such as vnl vendor or cnl vendor to assist them to do to deploy The reference implementation in their own lab and allow them to test their own workload on top of the cnt t conformant a reference implementation and finally as open a v provide a lot of testing tooling and projects that will be Important to test the capabilities of the underlying infrastructure Whether it is a functionality testing or performance testing or benchmarking The expectation is really for cnt t to provide open a v with these cases to determine to open a v What kind of metrics we would like to test against and what kind of functionalities We would like to see those open a v project are actually testing And the result of those testing that open a v is doing will be feeding into Things like dovetail in open in lf and ovp program that will allow The the the governance in the cvc to review the results submitted by the vendors and go through approval process And that will allow And the vi as well as vnl vendor to go through the certification program and get their platform As well as their workload certified against cntt the next Of course, besides open a v and ovp There are many Industry bodies that we actively collaborate with and just to name a few here We have the lf edge and we have a close collaboration trying to look at requirements They have in the agrano project and feeding those requirements into our edge work stream Other shop to that gsma has their own Edge initiatives that we're trying to keep close alignment to As well as on ab when they look at the vnl requirements specifically And what kind of orchestration capabilities that we expect to see because of things that we define in cntt So of course, although we expect the the impact of what we do in cntt To on ab to be minimum We're trying to coordinate on things like security and things like resource provisioning and making sure that The definition we had in cntt are kind of orchestrated from the onab perspective And of course open stack we're trying to identify if there are any gaps We we we see in the industry when we develop our standard in cntt We're trying to be more proactive and interact more closely with with the open stack To proactively address those challenges that we see in the industry And again when it comes to things like open network foundation And we're trying to collaborate in the network and focus a group and come up with a consistent network model that we deploy for cntt tungsten fabric is another example of the projects that we are planning to To support in our reference implementation for open stack And here's the collaboration between us and tungsten fabric is to make sure that we do have the support In the reference implementation addition to that open daylight One of the projects that we're trying to bring more SDN capabilities into our specification And we see that the collaboration is important to make sure we are kept aligned Between the initiatives we do in both sides and again and finally the black tests here Which is done by it's nv Bob is gonna talk a little bit more about in later this slide But we're trying to keep engaged in the community and participate in the event Hosted by it's nv for the testing and verification purposes and the next slide. I'm going to Talk more about cntcf and the tip in particular And the collaboration we're doing with them So for the cntcf As you can imagine, we do have a strong collaboration with the cntcf silk user group tug And the the main collaboration we have is to make sure that as the tug group defines The cloud native principles We need to make sure that those principles and those specifications sit in tug are actually aligned with what we specify In our container based Reference architecture addition to that the cntcf has really great programs around the cnf conformance test And at a close collaboration we have with the team there to make sure that this case is of interest to cntc Actually being implemented in the cnf conformance test So this way we avoid having to duplicate the effort And we're trying to leverage as much as we can of what is happening in the industry And finally the cnf this bit and and because also they have the labs and they have the reference their own reference Inventation we're trying to bring an influence The reference invitation in those projects to be more aligned with cntt Also, we're trying to get some learning back into the cntt from the experience that the cnf this bit is really having within the cncf community And finally for the tip with there are different collaboration with different projects that are going with the tip specifically around the open core And to work in the project Open core networking project are using the cntt Ra2 as the de facto for their own cloud architecture for the ocn workload that we're trying to deploy In terms of continental internalization Workload for the 5g core and the labs and the reference invitation. They are creating They are aligning the specification of their own reference invitation With the cntt and this is again an opportunity to get the learning back from the tip and feed those requirements back into cntt And similarly with the open run project that's happening in within the tip We are trying to we collaborating with the with the with the project in in tip with the open run Trying to get the requirement feeding into the cntt Each work stream so make sure our specifications whether it is rm or ra2 Are actually aligned with the requirement they have and make sure we do have the right feature set and the right capabilities To make sure that the any open run workload is actually can run in cntt conformant implementations Next slide I'm just quickly going to the roadmap. This is the roadmap that we we do have in cntt As you can see we did release a baldy two weeks ago Which is really past an open stack mainly Release at the moment and that is that comes with a complete reference conformance A suite that comes with this tooling and these cases that will allow an Infrastructure to be certified against cntt moving into barracue We expect to have the ovp program in lfn Reflecting a cntt requirement. So hopefully after a barracue release in september And the vi vendor can go and certify their The infrastructure Against cntt a specification. Of course, there is something called bundle and cntt Which really determines what kind of specification relates to each other So bundle three the one we released in baldy will have all the All the specifications and documentation that will be related to each other Moving to barracue. We expect to start seeing a new feature set Added to the reference model such as hardware acceleration But we also expect to have complete story for bundle three that will take us through all the life cycle from the Implementation of the workload all the way to the conformance of those first weapons Next slide And by this I hand over back to to bob Thanks, robby. So let's talk a little bit about, you know, where we're going with some, you know, some testing and some verification Right now we're planning to in the over the course of the next few weeks in june We're going to do some some what we call field trials and you could consider these to be Alpha testing let's say for the reference conformance specifically reference conformance one like the open stack track The the reference conformance two will follow on a little bit later So the idea here is to, you know, we want to validate the efficacy and the adoptability of the specifications, you know, can we Do we are our specifications tight enough clearly to find enough and are the testing protocols the verification programs Built upon what you know, we were building upon by the way what we had in opn fe in the past, but there's a lot more required now So we want to make sure that we've got the right the right specification details The right gaps failed and the right testing protocols, right? And we expect this to be a an iterative process. So the first set of field trials are going to be In starting next week and running through june and we have some trials consisting of with three telcos and two nfei suppliers And we're going to have a virtual conference in the third week of june We'll talk about that on one of the On the next slide or so on some links to some of these events There's a virtual conference that we will have and we'll publish You know some findings from that and we expect to derive some learnings Go back to to the process the work streams and improve the testing fill any gaps that we have And just go through that, you know, sort of alpha beta production You know sort of roll out an versioning of the reference conformance So we'll start here with this first one coming up in the next month. We're pretty excited about that We're also having some conversations with some of the participants in the etsy plug test which is Later on in june as well There's there's for example, there's a number of vnf vendors that are participating in that in that plug test and so we hope to Get some testing done either in this field trial or in a separate session with some of the vnf vendors on Some of the participant of the nvi suppliers or reference implementations that we've done here and again our our goal is to iterate on and You know continuously improve the quality of our specifications and the effectiveness of our conformance test protocols Next slide please So how do you get involved? How do you contribute? So first of all, I want to make it pretty clear that there's really not a formal membership To this task force. This is a participant organization. There are some rules. There are some IP, you know considerations that are always present and so forth and so on but there's no, you know, you don't join or sign up or necessarily you come and you participate and you contribute and you learn right and so Here on this slide you're seeing a lot where a lot of the The specifications for cntt are found on the github location for for cntt So the reference model there's there's some general ones here. There's documentation up in the right hand corner. There's You know other specifications listed here and very specifically for the reference model the reference architecture the reference implementation and the reference conformance You're seeing here the links to those very specific. So you can go there Find the documentation read the chapters And and see all what we've got so far and again, these are all Evolving and versioning over time as rubby pointed out in the roadmap. So you are encouraged to come in Join find out you'll find out about meetings and meeting times on the cntt wiki, right? And that'll that'll excuse me That'll allow you to find out where went in the meeting for the ra1 Workstream or the ra2 work stream and join in that meeting and hear what's going on and contribute, right? So we've got really good participation But we we really need and want and welcome more eyes more participants helping us move this effort forward Let's go to the next slide And here we're going to see a lot of new Collateral artifacts that we've created for the baldy release. So we've got an updated white paper that we just posted here Go check that out. We've got a blog post about the details of the baldy release Here as well I might want to make particular mention here of the cntt wiki on linux found under linux foundation networking Right, so this is where you're going to find a lot of meeting minutes and a lot other information including the onboarding guide That's a really important one if you are interested in actually participating In cntt and you want to understand what are the steps? Go to the onboarding guide and it will walk you through four to five steps that you will need to take to Participate and it's very very helpful very clear Sign up for the mailing list. There's various mailing lists ones that you may be interested in and and at one point that I want to really make here is This is not just about learning and understanding what we're doing but We're Welcoming and welcoming and actively looking for participants if you have expertise or experience Or a passion for solving some of the problems that we're talking about Then we would like you to come in and join this effort and and help us realize it and help us make it happen And again on the previous slide. I mentioned that some of the testing results will be Published at the next developer and testing forum So this is a virtual linux foundation networking forum happening the week of june 22nd There's going to be several tracks and some of you may be familiar We have opina fee tracks and onap tracks and and other tracks From lfn projects But cntt also has attracted and there's some joint sessions and so we can't we don't have the the pleasure of meeting face to face and Talking over coffee breaks and in networking events, but we can still meet we can still have sidebar chat rooms There are joint sessions. There are plenary sessions. So lots of good information. So please go to this link Register the event and during that Several day event you will get lots of information on the latest and greatest on what's happening with cntt as well as other lfn projects So with that, I think we're going to go into q&a jill. All right, great. Thank you bob. Thank you, robby Really great presentation And thanks to those who have submitted questions We have answered some of them via typed response, but we do have a few minutes left to go through Some questions live here. Um, so I think one of our first questions to uh to respond to is Are there plans for vnf vendors to participate in the field trial? And if so, how does someone get involved? Yeah, so I could take that when I I kind I briefly touched on that So we're still working on that but there there's absolutely I mean we want vnf vendors, right? And so we've started with some nfei and and cloud infrastructure vendors for testing against ra1, but and we want some vnf vendors As well. And so we have been actually reaching out to some vnf vendors On the side people that we know are participating as I said in the etsy plug test But we haven't you know, we haven't gotten to everybody yet. Um, and so we're a little bit behind on that but Absolutely, we if you are from a vnf company and you would like to set up some some testing on some of the Representative participating cloud infrastructure platforms By all means get ahold of us On the wiki join one of the meetings and uh, we'll we would love to hear from you Great. Thank you. Um, so here's a question for robbie. Um, how are we planning to achieve? Cloud nfei agnostic infrastructure as some vendors might be using open stack based appointments to spawn vm containers Some could be using kubernetes docker some from cloud providers like aws gcp azure, etc Are we planning uh to make a common generic api for lcm and orchestration, etc? Uh, good question. So the lcm and orchestration piece is not in the scope of uh, of cntt Project like onab have a multi cloud project that will Try to standardize the way you Interact with the different cloud But from cntt perspective If we look at ra1, which is the open stack based it is infrastructure as a service layer Now when we look about look at containers workload The ra2, which is uh, the component as a cluster will be not dependent on any infrastructure as a service layer So that ra2 architecture can be deployed either in bare metal in open stack in cloud in public Wherever the the infrastructure as a service layer has been choosing to be so there's less dependency There's not a tendency between the component is cluster specification We create in cntt and underlying a physical infrastructure for that matter Great, thank you. Um, there's another question for you robbie as per my understanding cntt is leveraging opnf for rc1 But except opnf e is there anything cnt? Are there any cntt specific workloads available? There is no such a thing as cntt specific workload So of course cntt specification can apply to any kind of workload That would like to be designed conformant to cntt specification So for example, if we define a certain storage apis That will be supported by the infrastructure, which is conformant to cntt The expectation of our any workload that would like to to run against the cntt conformant infrastructure Will have to be designed and built to leverage that existing interface now For cntt any workload that's into working focus will be cntt conformance if it was designed to follow the cntt specifications Okay, great. Um, we've got another question. Um This one is is for anyone and I do want to note that we also have heather curxie on the line With she's with the linux foundation. She's heavily involved in cntt and might be able to answer some of these questions as well So is there any volunteer work required? For cntt opnf e like func test yardstick test cases And if so, what is the procedure to contribute to opnf e related tests? Oh, great. The simple answer is yes, please more now And I saw that this was a question from an anonymous attendee. Um But yeah, so participating in opnf e is like the rest of the lfm projects. There is an open repo. There are Regular email discussions and irc discussions with respect to func test If you're interested in getting involved, it might be useful to introduce you To some of the folks in opnf v who work on func test and testing in general So some folks like al mortin rtsc chair and cedric olivier. Who is the ptl for func test Bob, do you know? Yeah in addition in addition. Yes. So there are On the wiki the lf networking wiki for cntt We had a link on the the previous slide before the q&a and you'll get that copies published You will there that you'll find the the work streams In minutes of the rc the reference conformance Workstream right and so you can end on the cntt The wiki you'll find the meeting times For all of the work stream. So if you join the rc work stream meetings, that would be helpful as well Great. Just a few more questions here. Um, this one is for rabbi. Do we see hcps like azure gcp at aws? Aligning with cntt in the future if they're not conforming to cntt then telcos may not choose hcps So, yeah, the idea is for even public cloud specifically for the offering towards network and the vn function virtualization Is to have also alignment with cntt certainly When the ra2 and the component is specifications comes out of cntt We will be working closely with public cloud vendors and providers to make sure that Any workload that's written against cntt will still run in the same way against public cloud As if it runs in on a premises. So the short answer is yes, that's the plan wonderful um How has opnfv changed since it's been collaborating with cntt? I can I could take a crack at that one. So, you know, it's really important to note that I mean, I think many people are you know are probably aware that that opnfv's original You know, one of the deliverables out of opnfv was a particular reference implementation NFV stack, right? and we did two releases a year for four years or so and then we paused on that last year and so we're no longer producing reference Implementation stacks and that's one of the big Points of the sort of the pivot and the shift, right? So we're we're leveraging all the goodness that we created the tools the testing um lab setups and so forth from opnfv and we actually Changed the mission statement of opnfv. So we're really we're really aligned with the goals of cntt And opnfv if you want to call it opnfv 2.0, right is really focused on a new mission to To effectively align with the the task force goals and really improve really that reference implementations, right? And those reference implementations are not the same. They're not like releases As was done in opnfv 1.0. They're really meant to strengthen and fill gaps and and and On the specifications and the test suites, right to improve the test suite so we want to implement against the specs and Use that ri to create better and better rc Verification frameworks, right and so the rc Frameworks the tests and the utilities and so forth Those are what opnfv is going to be focused on in the near term here on delivering, right? And so that and then there's also the ovp program that branches off of that and so These are the big big deliverables now the big changes to opnfv. So you know, opnfv is changing and it's revitalized and We are welcoming members to come in and help us Accelerate network transformation with this new mission Yeah, what one of the really exciting things I think is seeing a renewed excitement between the developers and opnfv With a lot of direct feedback from from the operators So that everyone you know feels very confident that the work that we're producing Will actually attain these goals of you know, accelerating network transformation and service agility and you know reduced opx. So it's it's definitely been a pretty exciting several months In opnfv world Excellent So it looks like we just have one more question It sounds like there's some overlap between cntc's charter and onap can someone elaborate on that I don't think so. No, I don't really see the overlap. I mean, you know onap is really focused on the life cycle management the service orchestration and all and lots of auxiliary functions around that Really on the automation and that's completely out of scope It still is we our work is still Is really focused on on improving that that nfei cloud infrastructure platform interoperability with the network functions um and and uh And the closest we get is our of course our interactions with the the open stack implementations out there the vims and the kubernetes Interaction on with the with the rc2 and ri2s and so forth. So Not i'll let robby, you know comment as well, but uh, it's it's really Separate domains. We're not going to get into the life cycle management or the automation area But we're hoping that our work will make life easier for those tools to Sit on top of and uh and do their particular functions Yeah, certainly, uh, cntc is minor agnostic. So we don't really Have any say on how the workload is being orchestrated, which is mainly What the onap is doing now as we specify what cloud infrastructure Looks like and what kind of feature set and resources Exposed by the cloud To the workload We see areas where for example, if we look at the vnf requirement project in onap Where you ask the vnf to specify what kind of resources it needs from the underlying infrastructure Those are the only areas that we see might be some Impact but impact us only in the information model not in the life cycle management Of the workload or the way that the the onap is actually Many Interacting with the infrastructure to spawn new virtual machines or doing any management for the workload It's only going to impact how the vnf descriptor potentially look like because now there's more Information model reflecting the cntv specification, but nothing beyond that Good point robby All right. Well, I think I think that wraps up today's webinar Thank you to our Our panelists our participants and all of the attendees. We've enjoyed having you with us today As a reminder the slides And an on-demand recording will be available tomorrow Everyone who's registered to attend will receive a link via email To those both of those resources and they'll also be posted on the lf networking website All right, we hope to see you all on a future webinar. Have a great day Thank you