 Great, and Lucina, could you please paste the meeting notes into the chat window and everybody could you please put in your name and company in there? It looks like we do have some new folks on the call. So I would love to give folks a chance to introduce themselves and then my agenda I think would do a short update on the CNF test bed. We are putting together our plans for a demo at Mobile World Congress in Barcelona at the end of February. We hope that you and many of your colleagues will be able to come by and schedule time to meet with us. I also want to mention that if you make a note now on the Wednesday night and we'll be emailing this out to the the tug but it's Wednesday the 26th of February. We're going to have a reception at Mobile World Congress and I'll mention we did the same thing a year ago so and two years ago as well. And I would love to have you join there and be a chance for this group to meet each other. So my main agenda item is to talk about CNF conformance and I am working away on a proposal that I'm hoping to share with this team relatively quickly. But before I get to that I might ask I think Scott and Mark from AT&T are new if you guys could introduce yourselves and then if there's other folks as well please. Okay now that I found the double unmute. I'm Scott Steinberg I'm with AT&T. Recently doing some proxy work on OPNFV where Ben Hu was sitting in and I'm also engaging in CNT and now also tug related to some of the other community work that AT&T is doing. So I'm going to be leading for AT&T the work that's going on hopefully I'll bring it together more so than maybe was done in the past. So you'll be seeing my name more often thanks. And this is Mark Shostack I'm mainly focused on CNT and OPNFV as well so I'm kind of just monitoring what's going on here if it becomes more relevant in the CNF space. Great well I'm going to welcome I'm going to come back to both of you in a minute because the other related agenda item that I'd love to cover is to go through the your understanding of the plans in Prague as as closely as possible. I unfortunately am going to be in China that week and I know that Taylor and his team aren't going to be able to make it. But before we go into that can we have other folks who are new to the call introduce themselves please. I think Bill from Lutzi is this your first time joining. And a reminder if you're dialed in it's star six to unmute. Yeah so I'm Bill Mulligan from Lutzi and we have Kubernetes automation platform that's going into like the vendor space so Bill could you just remind Sebastian for me there might be others on the call who could help with this as well but in terms of the very cool demo that was done at KubeCon San Diego that Lutzi was part of we're still trying to get all the code that was used in that so that we could take a look at the CNFs and BNFs that were used for it. We're looking for some URLs please. Yeah I'll definitely help with Sebastian about that. Thanks. Anyone else new first time ever? Yeah hi this is Trevor Cooper from Intel I'm also involved with CNTT and have been working in OPNFE for some time on particularly focused on the on performance testing and compliance and test infrastructure so I'm pretty interested in the in the test bed and I'd like to learn more about that and that's that's the reason I'm joining. Great welcome. Anyone else? Yeah hey this is Igor Gengorosi I'm with Nokia on the mobile packet core team mostly spending my time on 5G packet core these days and just interested in following the work in the group. Did Gurgli abandon us? I'm sorry? Do you know Gurgli from Nokia? Yeah yeah I know him yeah but we've been on the calls in the past. Yeah we work in different teams he works more on the software Nokia software side I work more on the IPN optical which includes the packet core and transport. Great okay well you're very welcome. Any others? Okay well I guess I would ask for some of the folks who are going to be in Prague could you when somebody volunteered to take two or three minutes and walk through my understanding is with the RE2 work there that there are some initial proposals to move from a VNF certification in the OVP process to CNF certification but and I appreciate that that's being done by OVP by sorry OPNFV and by CNTT and that they have a GitHub repo but I haven't been able to find the work yet that shows how that CNF certification would work and I guess the discussions we've had in the past on the topic are around that the current VNF certification is mainly focused on TOSCA or heat compliance and so is sorry to ask for the new folks to jump in but would anybody be willing to step up and explain not necessarily speaking for CNTT or the OVP program but just explain your understanding of the process. So this is Mark Shostak I can add some color there probably the reason you can't find it is because we're really still working on the VNF side and even before that the baseline for the NFVI side so you know RE2 is being developed as an NFVI platform at this point but the reference certification or qualification hasn't really caught up to it you know the the various phases the reference we have the reference model we have the reference architectures which are all based on the reference model and then the reference implementation and then the reference certification so the development is kind of following that path as well so the certification or qualification portion lags the development of the the NFVI portion so to answer the first part of your question there so currently yeah that's very helpful and I appreciate that it's not just bad Google skills on my part no definitely not and let's see so and there's a based on what I've heard about the CNF you know there they're kind of some fundamental differences in the in the perspective our perspective in the test that is kind of a you know a standardized test regimen that that's executed against the the VNF or the NFVI under test and correct me if I'm wrong but my understanding about the CNF test bed and I guess based on what you said in the agenda maybe I'll learn more about this is that it's more of a you know proof of concept platform if you will or you know development level platform as opposed to a machine you know yeah that's absolutely the case and maybe I will call on Taylor to just do a five-minute overview of the test bed since we have several new folks but the key thing is that it's a test bed not a test harness or a test framework and so I definitely want to be clear of what it is and what's not yeah I think that's something that gets an important point because I think it confuses everyone but well that said I mean I'll go ahead and show my cards here in that the proposal that I'm putting together and I would emphasize very initial state is that this group I mean Tug and CNCF would create a CNF test framework or conformance framework that would help define a set of best practices around CNFs and then provide a set of open source tests to demonstrate that individual CNFs are following those best practices. But you know a ton of it would be trying to reference upstream software and leverage that but it absolutely would be a harness or a framework in terms of pulling together lots of different pieces but that's all relatively separate from the CNF test bed the only difference is that when you have a CNF and it passes this framework you could then also run it on the test bed if we wanted to try and do some performance pieces but before I get to that whole proposal I would maybe just ask a little bit more on the RA1 work because the OVP is live today right I can bring in a CNF to sorry a VNF to the University of New Hampshire and have them certify for me. OVP is live today and OVP actually has been live for quite a long time initially it was for certifying NFVI platforms and recently to your earlier point or question a VNF type certification capability has been added and it and is being you know enhanced there's a roadmap for it but what its intent is with regard to VNF testing is basically what you said you know it's focused primarily on the the heat and the TASCA artifacts and you know the the ability to onboard the VNF and instantiate the VNF as opposed to you know functional testing where you're trying to run let's say test traffic through it and ensure that whatever the function in the black box is is actually performing properly so you know most of these tests have no prior knowledge of what the VNF actually does so it would be difficult to validate its ability to do that whatever it might be okay yeah that's very helpful yeah if you could try and find that roadmap that you mentioned that talked about the and I do think it's really important to separate the NFVI certification the platform certification from the VNF certification the individual network functions on top but if you could find a link to that roadmap for the VNF certification where I understand that today it's mainly TOSCA or heat artifacts but if there's plans for adding more capabilities to it I'd love to see those so yeah so there's been a discussion about quote OVP 2.0 to help to meet the needs of cloud native slash CNF slash whatever and actually there's there's a meeting planned for the Prague face-to-face on Tuesday January the 14th at 1500 UTC so there's a kind of a an agenda being developed for that discussion to talk about meeting the about CVP CVC and CNCF and I can yeah I'm not sure we're gonna have CNCF representatives there we kind of found out about the meeting late at the very least I am have aiming to have a very rough document to share with that group that I'm talking about this CNF conformance concept but that's why I was just trying to get as much background on it as possible trouble and that kind of you know kind of give some insight to your question about Prague right I and Trevor you can give me your opinion but I don't think it's gonna go into a whole lot of detail of you know the actual testing in these sessions I think the focus initially is going to be what are the objectives yeah right agreed yeah so let me just go ahead and throw out there since some of you will be there to please feel free and by the way I mean our pit is going to be with me in in China so I know he can't make it but I will also have to have a conversation with Heather this week and say this to her directly but I do just want to communicate the relatively obvious point but I do think it's worth saying explicitly but my strong strong interest is not to have LF networking and Okina B and OVP and CNTT doing something different and incompatible from what CNCF is doing and so I think given the huge overlap in membership and in vendors and in operators and just the general alignment there it really would be in everyone's interest if we can align around a program and then you know all the details remain incredibly difficult that there actually is a ton of work that needs to be done and figuring out who is going to do that work and how some relatively difficult decisions will be made but I do just want to that out there that there's no sense in which CNCF is saying oh we're off on our own and and you know we understand telecoms perfectly so we'll just go do this without any input from all of these operators that are you know actually the end users of all this I don't think you need to excuse me I don't think you need to worry about that you know that that's already been a point of discussion and no one wants to reinvent the wheel or duplicate effort here so I think the well famous last words though I mean that has sort of there is a pretty bad precedent in our industry people who still come up with with multiple times yes exactly that is but I that is why I wanted to say it even though it could hopefully would go without saying so but it does sound like a lot of the focus in Prague is still going to be on the VNF certification and as I think Taylor pasted in that's why we're particularly interested in the VNF roadmap that we would like to understand how much of that would be applicable to a CNF roadmap so for search purposes you know CBC and OVP are the keys you want to search for there and I can send you some links if I can fish your email address out of someone or from somewhere to give you some pointers there but there is so there are requirements for VNF like they're fairly lengthy requirements for VNF testing in that context and then whatever state the roadmap for the CBC is currently in but and it's all on the web by the way so whatever state any of that's in you have visibility into it you know yeah and I do want to point out that that is already a huge difference in terms of the CNTT work compared to where we were a decade ago to have all of it on GitHub it is fantastic okay so I guess if I just went one level more detail here could you I guess give your view we had a conversation on the Asia call a couple weeks ago that I think everybody agreed that feet doesn't particularly make a lot of sense in a CNF context because it's so closely tied to OpenStack but could you share your perspective on TOSCA and how likely and again I'm not looking for the official ATT viewpoint here but maybe just sort of some color on previous conversations within OVP or elsewhere on how likely it is that TOSCA would become the basis of a CNF certification because I'll go ahead and throw out there and by the way there was a very good PowerPoint doc Taylor Lucina maybe you could paste a link to that into the chat or from into the the tug slack but it was looking at I think five or six different implementations that had been used in the past for CNF and so a couple of them were from Cloudify and there was TOSCA and then discussion of using Helm charts or others and part of the concept was just that none of them were a great fit right now so I guess I but I would love to ask that question in particular about your view on TOSCA and and CNF's. So with regard to you know TOSCA versus heat personally I haven't seen any you know or encountered any discussions on that yet so I can't really comment or if I did I'd just be making it up but since Scott's on here Scott do you have any more insight into that by chance you may be double or triple-emuted. I'm here I'm here I'm no not yet maybe by the next minute as I dig okay great so would anyone else want to maybe share an opinion on that Trevor or any of our our longtime folks I will keep an eye out for it yeah and for example there's a redhead engineer who did some interesting work on how you could adapt TOSCA to Kubernetes and create a custom compiler for it and such but it was all speculative work it wasn't a oh let's go everyone adopt this and it was really a year ago and I haven't seen any adoption of that approach. Yeah that was I think Tal Learon who had done that. Exactly. Yeah I don't think I don't think anything material like I think you put the ideas out but I don't think he he got the attention necessary in order to proceed with a this is my understanding I put Learon on. Yeah I actually got to chat with Tal in Antwerp at the Open Networking Summit and he confirmed that I mean it's still you know the idea is out there there's some slide decks and such on it but it's not something that he's actively pursuing. So I guess the most positive way of putting it is that the field is wide open here for exactly what CNF certification should CNF conformance I'm going to start with should look like. I mean the kind of high level concept that I want to get across here is as a concrete goal and I hope that we have agreement on this is that there is a strong desire from operators to be able to purchase or license CNFs from multiple different vendors have them all interoperate and work on a single NFEI or NC NFCI if you want to do it that way platform and so the the sort of end goal of saying I don't want to be locked into a single vendor solution I think is one that I there's probably pretty wide acceptance for but the exact details of how those CNFs would be demonstrate conformance and and what kind of interfaces they would be conforming to I think remain up in the air and so I have a proposal on this that is really meant as a starting point that I think is needs is going to need a huge amount of comments and feedback and then we'll but but hopefully is something that could could get the discussion going okay well that was actually exactly what I was hoping to cover in terms of my understanding of Prague and just giving a little bit of a preview of my thinking on the CNF conformance we're having a and I guess I will give one other insight into it where that the basis of the conformance work that I'm looking for is to have an open source test suite and you can really think of it as a suite as set of set of different tests where the model is the certified Kubernetes program that CMCF has been able to orchestrate for the last two and a half years and so the key thing is that that all of those tests are open source that anyone can download and and run them to certify that they're Kubernetes implementation is conformant and then because of that users can come along later and ensure that they're that the platform remains conformant and so I think that the combination of the kind of distributed crowd sourced validation of it that people can't just claim conformance and upload incorrect test results and then go operate in the market that at any point it can be validated whether they're actually performing or not that the test themselves are open source and then that because of their open source people can discuss and debate and improve them over time and then also that they that the tests are following the upstream projects are all really powerful aspects of that certification program or conformance program and then the certification on top of it is relatively lightweight it's all done via GitHub there's there's not an external testing center that you have to send your software to etc so that is the model that I'm basing it on and that I'm going to propose and the CMCF process has been pretty spectacularly successful where we have over a hundred certified vendors representing the entire cloud and enterprise software industry so but interestingly we've only ever certified the platforms of the equivalent of NFBI we haven't actually certified the applications which is the equivalent of the network functions here and that's largely because of a lack of demand for it and essentially we can that generally folks have found that containers tend to be interoperable on top of these different platforms which is really largely true of the Linux kernel API so that's the preview I do need to finish writing this up so that I can share it sorry Dan are you going to post that your proposal or how will we I will so you'll I'll be sending it to the mailing list and the GitHub and the CMCF Slack so you should see it certainly before the next call and I'm aiming to get it out before the PROG meeting but but maybe not much before and then my final so I would just sort of open it up if there's anyone would like to respond to any of that or have any comments or questions or concerns and then I might just ask Taylor to do five or ten minutes on the CMF testbed and some of the work that you're doing there with Michael and others to make some improvements to it and then again for the next call we can talk about what our plans are for the the Barcelona demo so any any comments anyone saying no that's CNS conformance idea sense crazy you should just certify the heat artifacts correct I think we'd be crazy to certify heat only so say it again I think we would be crazy to certify only the heat artifacts on like I do think that we need to look at the actual CNS themselves mm-hmm so you want to make sure the thing runs right and it doesn't just core or you know segfault or whatnot but you know the question is kind of how do you test function at you know arbitrary functionality that that hasn't been defined or declared in advance you know kind of like I think the closest idea I've had so far is to offer interconnections where you know the people supplying the BNS can also plum in their own you know data stimulus generators and data sinks so that they can validate its its functionality in the testbed but for us to do it it it's still a question yeah I mean that's that's effectively when on some of the interconnects that we do in in NSM we we have a set of tests that are defined around the specific type of code because we we came to the realization that like we can provide things like okay is this is going to provide some basic IP connectivity like we could easily provide some of some of that as a common basis but when it comes down to some more of the specific things it's like that some of nuances above a specific CNF it's also good for them to be able to inject their own behavior as well and not just rely on on solely commonly provided infrastructure and one of the reasons for this is that there's also edge cases that have to be taken that people have to take a look at and often the CNF or the NF provider is usually the best person or group rather to determine what those edge cases may be and especially when you look at it in the context of I want to perform enough a live upgrade or a live downgrade then it's like what do I need to make sure work so what I need to make sure what things are likely to break because of there's complexity there I think that makes sense and one of the real challenges with the found with the program is that it's pretty easy to come up with a bunch of tests that everybody agrees are good tests but to agree on specific criteria which set a sort of minimum bar for conformance to do certification is pretty challenging for many reasons one of some of them which you've just mentioned right you know so performance is kind of performance or scalability is kind of a step above being able to test just the functional capability well but even for even for functional capability because you even you get into specific when you ultimately when you actually do testing is versions right and support of versions and some vendors are ahead of the versions that are implemented in the reference and all these kind of problems yeah I'll give you a little bit of perspective on my side as well so I actually see upgrading and downgrading as a feature as opposed to a scalability or performance issue as well because it's something that needs to that's to be has written code you want to automate it you want to test it if it if it you can perform the upgrade from A to B as a feature you know that you know that works you know ignoring the performance or for scalability part and those have to be considered as well so what's one I think that's why specifically we call that specific thing out was from a from a performance perspective and we can help out on some perspective like we can say okay we installed your your our suite of tests and your suite of tests and we've installed your application and we see it working we perform an upgrade we see it working or we see it break or we see this packet loss and it's you know like there's there's things that we can we can do to to help along along those lines so I this is I think actually a really good segue into the CNF test bed and so I because what I've been talking about so far is a performance testing framework or test suite and I do think a performance test framework and also a installation conformance or installation testing upgrade testing are all quite valuable I mean at the end of the day of course it is really the operators who are going to say what's what's valuable to them or essential to them but the I do think that the CNF test bed is is potentially a pretty useful tool on this front because it's something where the entire test bed is open source and and publicly maintained and something that can be you know discussed and and optimized and such but then and the it and very likely the installers should also be open source but the actual CNFs themselves definitely don't need to be and it is something where someone could demonstrate on using the test bed and say okay here's some code where we've shown that we were able to install this and upgrade it and the performance continued running and here's the downtime itself so if Tara that's enough of a segue would you mind jumping in here and maybe just doing a five or ten minute overview on what we have built and what some of the initial goals were for it and then if you want to maybe extrapolate how it could be used in some of these use cases going forward sure thanks Dan and and I'll just mention that I'm gonna be in a noisy place soon so I'm still listening but you should go ahead and finish the call when you're done and and address any questions all right so we've I've kind of gone over I guess a lot of different parts of this on the CNF test bed so it's it's on github at CNCF in the CNCF org slash CNF test bed for folks who haven't seen it and I'm gonna drop a link into the zoom here so the I guess jumping back a little bit some of the initial ideas here came from that the long-term the long-term focus was how do we build something and and new stuff as well as take existing code and how would you run it on a new platform what would that look like and so looking at a lot of projects over a year ago now what was available so one of those was looking at on app there was a own app demo and we actually started with that and we've been doing a lot of other proof of concepts as well as ongoing work on packets so how would we take something that's focused on telecom and and get it up and make it where people can contribute as a group and and share everything so we started with that and got some of the this own app demo up to a point it was based on OpenSack and there was multiple levels of virtualization but it was kind of a good place to start and and then we ended up breaking things down into the components like the actual use cases the VCP use case and splitting those out and where could we go with this so we actually broke it down into the individual pieces the components some of those are VPP based network functions so all open source there and what we have now is the capability to build what would be maybe the NFEI platform as a base you can using cube spray so open source kubernetes production grade deployments we can deploy on to packet different machines types including some that have quad Intel NICs that we can put together for different use cases and you can build the whole thing including the now the networking aspects different the lands that you may want for segmentation and build all of that out so that's kind of the the platform and make that reusable this some somewhat some of it is I don't want to exactly say lowest common denominator but the focus was what's reusable so I want to compare this a little bit to the RE2 or maybe we'd say the OVP CNTT all that work that reference implementation there's some overlap there but as someone mentioned early on the focus is a little bit different and the collaboration and the proof of concept aspect I think it's the exploration so that's kind of idea here what would a cloud native platform and applications what would these cloud native applications that provide the functionality what would that look like so the lot of this is still being understood so as we move from physical to you know different platforms but virtual whatever else you're going to add new functionality or add new processes and you're going to drop some so what would that look like and I think that's part of the exploration exploration here so we've wanted to make sure that you can use plug-in and try out different things network service mesh Frederick was mentioning some of that a few minutes ago is one of them that we're using that's a add-on or extension to Kubernetes to expand the functionality so being able to show stuff like that and that's really been the focus in the kind of the last six months is making things a little bit more at pluggable for people to join and and have part of that so we've been talking about heat templates and Tosca and stuff on the conformance so on the Kubernetes side specifically because we did we do have open-stack software in the CNF testbed that you can use and run and see how some of the VNFs work as well but on the Kubernetes side it's using either Helm charts or Kubernetes YAML manifest files that you can describe what a use cases or what a deployment looks like and have those reusable between those different tests and making that more usable for someone to come in and add maybe a very simple test test the Intel device plug-in for Kubernetes and how would that work or a more extensive one that may use that and and do like SRV and as a full use case and those different parts so it's if someone is new to these things then it gives a way to step in at those different levels and then if you want to contribute so at the start of the call Dan mentioned I won't really go into this much but we're have been looking at a Mobile World Congress demo and specifically some of the things that we're looking at it would be relevant to bring up with how do we do different use cases right now we're not looking at the RAND side we're looking at packet core pieces and there's a few different implementations that we're looking at starting with some specific components within the packet core and showing how workloads would go across those and how we can manage connections in a dynamic way and that's the main focus on this and then expanding out to say again a proof of concept so we can discuss this how would you have a cloud native packet core how would you then connect that up with the different pieces outside and extend to have the full system and that's kind of the goals and we have some proof of concept code that's been going in over actually the holidays and we'll be tying more into that trying to not repeat things that we've already covered we plan on doing I guess a few other things roadmap wise we have some stuff with say multis and other other examples for accessing different devices SRV stuff we have some of those in there already there's IP sec examples in the test bed a lot of other use cases that I think would be common on the already on the VNF side including the I mentioned the demo we have different types that would be similar they're not exact exact as we've moved over so we're trying to move towards what we expect best practices and principles to be you'd follow this I think some of the things we want to add is topology showing like CPU topology separation of the resources and those type of things that are concerned some of the telecom and we have different I guess the different pieces and poor components and what we want to do is build out some of those use cases and ideally get some feedback from operators on what type of use cases would be interesting and workloads that you want to see from the side of a cloud native implementations like what what would we be talking about that are concerns or anything else you mean with the intent to do functional testing on those workloads or from what perspective and I would say there's if you're like for AT&T or any operator if you already have platforms that you're using and if you're looking any type of new technology or what it what is potentially I don't even say the technology but the changing to use some new principles on how it's architected or you're going to want to know what are the benefits and then what are the concerns so if there's anything specific you're looking at like we were right now the focus was a on the packet core and a specific part how would this work and still be dynamic how can you show that how being dynamic and and have the functionality for these devices to find each other but if there's anything specific that you're looking at like concerns how would we do this in the past we were looking at benchmarking for network performance and stuff and how does that look and we've been showing how you would be able to add different network paths and that's where network service mesh is one of the examples okay so potential challenges and challenges or we we'd really like to see either a specific use case or maybe it's even like specific examples of using Kubernetes or add-ons and extensions and a specific way that haven't seen something that meets the needs from an operator perspective but generally speaking at the application layer it could be application it could be I mean some of the they split up on the scene of testbed on like how the new structure is for the test we have split off what we think of as the platform and that can tie in with stuff like we expect the platform to have these SRV components and these other pieces like maybe network service mesh or whatever and how that would fit to provide functionality from a platform side so definitely interested in the platform as well either way really it depends on the concerns and questions well from the platform perspective ultimately you should be able to see at least one aggregate telco perspective in the CNTT documentation suite so at minimum you'll have that how that will transition to the or apply in the application space is kind of an open question at this point and this is Scott maintain team Taylor Dan I think we had inter introductions at KubeCon from my VP Ryan Benwick and I think as I come up speed in all the space as Ryan intended I'm probably providing some input from telco AT&T perspective to your point Taylor that would be I can't say right today but it will as I dig in to all all the stuff here in the year I'll definitely have perspective that I can share. Thanks Scott. Thanks Mark. So on the conformance testing side I think the thing would be making sure that the test but then run those different conformance tests and I think what Dan was saying is having all in the Kubernetes model where the tests are like an open suite and from the platform side that's potentially easier because you can say here are the different components that we expect to be available in the APIs and test that and we'd like to have something similar through the application and I know earlier on the call there's mention of besides it runs and it doesn't crash as a some type of workload we'd like to be able to have that as possible it may not be every every use case and test or example but potentially tagging a set of tests on the scene of test bed and say these are compliant and we can run those is definitely something that we want to make sure happens. Taylor hey this is one question in the context of a more generic adoption of the test bed and in particular in the context of the compliance tests we what are your plans regarding decoupling it further from the packet focus deployment scripting you currently have in place so I personally would love to deploy the same things also like an internal lab because that's just easier for me to get we have hardware available but it's incredibly hard to get funding to run it in some other place so I guess from a general adoption perspective it would be very helpful to have some some development in that direction what are your plans on that regard and totally open to supporting other platforms other I guess the physical under underlying platform that it runs on and it's if you or other folks would like to contribute on that that's really the main thing the components that build out the environment including deploying any CNS and connecting and everything else all of those are split up they're pretty pretty strongly split to they're composable but making making it where you can use different pieces so if so you have a you're already running Kubernetes then you should be able to deploy the different test where it's going to come into places stuff like if you're doing hardware acceleration or something then there are can be specific parts on that but you're really talking about what tests you're running some of the tests are more of a functionality that's not say a performance specific functionality then those should just run and you should be able to deploy them on any Kubernetes if it's something where you're running and doing SRV and the SRV plug-in that you're testing doesn't support the network card then that may not work stuff like VLANs and everything those are things that are fairly dynamic as far as how they're configured for what you're running but it's it would be tying it in to the underlying platform so if you have a way to maybe pass stuff like that in then it should be able to run but if this is definitely a place that we want to go and it's it's something where I know there's gaps there's there's parts there and we need kind of a driver for that and potentially you know collaboration on access we've talked about supporting stuff like AWS is bare metal and stuff but for sure labs within a you know that's vendor and operator side that would be great and the the Kubernetes itself or and I'll say the platform provisioning itself that is something where it's I would say it's fairly generic what we do right now as we talked to the packet API for the networking portion of the packet API for setting up the VLANs breaking say the default connections that are set up whenever you build out a machine and then reconnect them with however wanting like we want to support layer two and we're going to your own VLANs or we want it disconnected or direct connection and that's because they provide an API for their top of the rack switches and I doubt that anyone is using a hardware these days that doesn't have an API if you're using f5 or whatever you happen to be using there's some type of API so potentially even that sort of thing inside of a lab we could provide some type of integration and then you could target say a specific switch or router or whatever it is to do configuration at the platform level which I think would be awesome so totally up into that and if you want to follow up I'd love to hear from you okay thank you very much I think we're we're here at the top of the hour there's a telecom music group slack channel and CNCS slack tag there's also a CF testbed channel there's some dev channels please join the CNCS slack and there's conversations there that going every day on this and the next telecom music group meeting it's two weeks it'll be at the 7 p.m. China standard time and I think that's about it everybody my name is Brooke Frischmeyer from net number I had to jump in and jump out a couple times I got invited to this meeting via a colleague here at net number of Patrick and I just wanted to know who I can send an email to so I can be on the recurring meeting and jump in slack and other collateral and you can send an email to myself I posted the meeting the meeting notes here it's in the meeting notes for the tug and that's Taylor yeah this is Taylor sorry okay I see it there thank you okay we'll do thank you very much and there's a telecom music group you have you can find all the details there as well right nice to meet you all by the way thank you nice to meet everyone as well have a good one take care everybody cheers