 Okay, it's four after I think we can probably get started. So, thanks everybody for joining the senior working group meeting meet every Monday 1600 UTC. In case you missed it there's a link to the meeting minutes in the chat if you can just add your name. That would be great. And then before we get started is there anything that anyone would like to add the add to the agenda. I think I think we can probably jump right in then. Yeah, I'll just, can I add in a very small thing to agenda just a quick update on the network orchestration task force. Sure. Do you do you mind if I add it here do you want to have it at the beginning. Do you want to do it now or later. Not your choice. Okay, you can go first if you want. Okay, sure. So, some of you, maybe even all of you if I'm looking at the list here know but there's a, there's a new slack channel on CNCF called Tug networking orchestration. The discussions have been in the context of the tug, but it was clear that you know there's a lot of overlap both in things people work on and the people themselves. And I think after a fruitful conversation we decided that best place to start to work would be under the CNF working group with its governance. So yeah, I had a personal meeting with Taylor and we worked some stuff out and hopefully this week I'll have time to really flesh it out on the GitHub repo and we can start to work so not a lot to say today other than that. And maybe the next CNF work group I might have something more to add to the agenda and get into more details. But for now probably the best way to continue working is on slack. I know slack isn't accessible to absolutely everybody so if you if slack isn't great for you and you do want to be involved. Please let me know and I'll try to figure out some way to to include you. It has to be inclusive not exclusive. That's it. I'll go a little bit to that towel. And Bill, could I share my screen real quick. Absolutely. Let's see. All right. So the main thing that we were trying to work on was breaking down. What are all the different parts of what we want to accomplish across in the orchestration but then looking at all the different groups. As far as what you could do getting started we think the requirements definitions and gap analysis or in scope for the CNF working group. And we're talking about either current or new Kubernetes technology and past and current non Kubernetes so that would be thinking anything outside. We could say legacy but not all of it there's new stuff happening. And then specifically like presenting solutions. These could be maybe outside maybe inside of the CNF work group some of it could be the telecom user group. But the parts that we think we could get started immediately as far as the GitHub repo for CNF working group would be around requirements definitions and gap analysis. We broke a lot of this down. I'm not going to go through all of it. That'll be something I think you'll see as we move forward. But that's would be the main areas and towel and would you agree that kind of covers what the highlights at the top. Yeah, absolutely. The reason I didn't want to get into the details of this is that this could easily take the whole agenda so it's a starting point I'll I'll put something on the slack maybe hopefully this week more people can look at this provide feedback and maybe next work group meeting we could do something more productive. Yeah, this is this is I think a really great opening shot. And I think, you know, I treat these things as buckets of work where I think many different people in the group can contribute so I'm optimistic I think this could be a very productive endeavor. Absolutely. And that's the idea that we're trying to do with on the how the structuring specifically on CNF working group but ideally any of the different groups, wherever you're passionate about working. Hopefully you find a place, you can just focus, you will not just focus but you can focus on that and not think that you need to cover all the things. So the different buckets. I'm going to hand it back to you bill. Thanks Taylor and thanks tell. So, looking forward to the PR so they're going to be incoming and if you want to dive more into the networking orchestration task force, join the slack the link is here or reach out to tell directly. And I think his email is here. If you want to reach out to him. So, thank you. One is this pull request from Taylor, adding a code of conduct. So, essentially, this is just saying that the CNF working group will follow the CNCF code of conduct. In other words, unless anybody has any major objections to this I think we can probably merge this as everyone has agreed so far. Any last objections. Okay, great. So now we have a code of conduct. Perfect so thanks for that Taylor. The next one is from Ruben is he on the call today. I don't see him on the call today, but essentially, what this pull request is is in the charter also adding for operations of CNF, adding out the life cycle management component. So instead of just deploying and managing really looking at the whole life cycle management so deployment configuration management upgrade. So last week, I think there's quite a few approvals here unless there's any last objections on this call, also merge this to know three to one. Okay. Great so thanks everybody who took the time to review that to the next one I'd like to point out as Taylor said earlier there's multiple ways to get involved in the project. Beyond just some of the core stuff and so part of it is to create a contributing document and I know Taylor has started doing this but if there's anybody that's interested in working on this with him I mark this as a good first issue. So anybody wants to raise their hand on the call, or anything else you can do that now or look into it later so I'll just see if anybody's interested in adding the name now. You can also add your name later. So there, otherwise, I know Taylor is putting something together right now. So, okay. Last week, we talked a little bit, just like as a refresher is that we need to update the template around the user stories that the user stories should not be marked optional. I mean, if there's none you should start a GitHub discussion caveat shouldn't be optional and there's and it should be renamed to trade offs. And so, thanks to Watson he's made a pull request here, just giving these updates, essentially so the pull request is linked here. Just essentially. So, changing user stories from optional since that's going to be a category for us changing notes to trade off constraints and like caveats. Yeah, I think it's a pretty straightforward small pull request so if anybody. I know this is just committed three hours ago. So I'll leave it up for another week but if anybody wants to review it or wants me to add them now as a reviewer, I can do that. You can put my name there. Thanks and also Robbie said in the chat so thank you. Okay so I added both of you as reviewers and obviously anybody is free to review it. Thanks we'll leave that one open for now but I think we can probably get that merged easily next by next week it's pretty small change. The next one. Also I just want to take pauses anybody have any questions on what we've done so far. Then the next one is creating templates for use cases. So, just as a reminder last week we merged in the, the kind of, you can think of like the table of contents for the use cases document and one of the comments there is that we should have a template for use cases, and this is kind of the discussion out of there. What else is looking for a good first issue to jump in on is to create like a template for these use cases. If anybody wants to raise their hand right now in the meeting, I'm happy to assign you, or people can self assign after the meeting to build a book is speaking, I could take that one. Okay, what are use cases. Okay. Great thanks book. So, you have been assigned and looking forward to the forecast on that one. Unless, is there anything you want to discuss about it right now are you happy to go off and just kind of create an initial template and then have. I'll create initial draft template based on some ideas and practice. I use them in and will create a merge request to be reviewed and discussed. Okay. That's fine. Awesome. Thank you very much. I follow up on the template. If, if before we have a template decided on if you have a use a use case or a user story which is higher level. That you want to talk about then feel free to create a discussion. You don't have to wait for some having a bunch of content we can add a new discussion or add to the discussion list, just the idea. Yeah. And maybe that's a good time. I'll actually go a little bit out of order here is actually to go to the BGP use case, because this is one of the use case. So if is Ian on the call. I am yes. I'm not by the way terribly proud of this I wrote it in an hour this morning and got up especially early so it was ready for you but to. Yeah, I mean it's a beginning at least. So it was one example. I've seen this before. And the reason I've used this specific example is because it requires a second VRF on the network, which highlights a shortcoming that we run into. So it's just an example of how I might put a BGP speaker on and what I wanted to do is talk to my customers VPN network so a network that I have access to. But I don't want its manager to be on the customer network I want it to be managed independently. Tell us telling me off and not putting this in as a discussion and he's got a point, because it's as vague as anything and we don't have a use case template yet and I could probably have waited for that and done a better job of it. But the thing I was running into is it really did feel like it needed a document to discuss so that people could point to the document and say this is a thing I don't like very much about the way that this is put together. I'm quite happy to withdraw the call request if it turns out it's too early and it's the wrong thing to do, but for the time being I would at least give it once over and read it and see what you think. What I was trying to say with this as I say is here is a straightforward use case and again arguably not the right place for it here are set reasons why it's problematic as we stand where we find that we're getting into some difficulty, which again arguably isn't really correct for putting into a use case but I assume everybody that's seen it which probably about two people at this point appreciates that it's a reasonable problem description that it is a thing that does come up. Great, thank you for creating this. So, what do you mind if I, like, add you as a reviewer on here just that as they're going through and creating the template you can kind of see what you think is good what you think is missing and you I think you can kind of get a little bit on this kind of as a collaborate creating the template and actually having like a real use case. Yeah. So, it's a good to base it on some concrete content and then see what fits what doesn't fit. Yeah. Just to that concrete use case. I just want to mention, we have cases where we talk about seven VRFs to plump and so on so that's give a better example of this or a different example that comes from your perspective. I strongly encourage you to do that. I know for well we've got use cases where we want more than one VPN as well but they get more than one VRF, but they get complicated to explain so I thought I'd start with the simple one which points out a short coming. And then we can, you know, if we come up with a better, again, concrete example of it happening and why you would want to do it, then we can we can write another one as well. There's nothing wrong with one feature solving multiple use cases. I just wanted to mention that it is, it is reality and one aspect or one way to look at it is how can you resolve it on Kubernetes level. Another is what we are trying to do actually is how we can resolve it on data center fabric and integration of that fabric into into wide area network level. So that we offload everything to move everything from Kubernetes clusters into into the fabric as much as possible. But yeah, side comment only. No, I agree. Right. And again, well so that's that's where this document has a problem because one half of that is a use case and one half of that is implementation problems but I absolutely agree I see exactly the same short coming and it's a thing that I want to see fixed so anything that points in that direction is going to help us kind of flesh out what we would need to fix it. I think that's great. Ian, would you mind trying to add this as a discussion with your slide with the diagram as well we don't have to close the pull request out but just duplicate it. I'm interested in seeing what it would look like with the diagram embedded. That's an interesting question. Let's see what happens. That diagram by the way I did it in draw.io and it's an editable draw.io diagram. It's SVG I'm sure it would work with PNG as well just think of it as another experiment. And the discussion forum can also link or the discussion topic could link to the pull request and then once you know if we get it merged then it can link to the document but the discussion might be an area to have like larger conversations about that document but keep it in the get repo. Cool. So thanks Ian for putting this together and I'm looking forward to seeing kind of like this first use case kind of come together and sparking some discussion around there. Then. Yeah. I have a question. What is the expectation on the use case. I'm asking because I'm at this point to be lost. It's to where to start if I wanted to submit one and exactly how what to draw out of that use case. I might have missed that from earlier meetings but I appreciate if maybe can explain again. I'm just asking what a use case should contain or what is the purpose that we're for the scene of working group what like why are we trying to have the use cases. Yes, that one more. I mean I understand why we do use case based right before the scene of working groups so the it ties back to. And so that right now the practice the focus is to get towards best practices or techniques. How are you going to utilize if you're on a Kubernetes based platform. Then how can you take advantage of service capabilities how are you going to have apps networking apps that can utilize maybe other networking applications so what are best practices and Kubernetes. We had talked about for the scene of working group, but if you don't have some type of real world context then it makes it difficult to even talk about those. So the idea with a use case I'm going to make it even simpler one then thank you and for doing the BGP we've been talking about it for months. And even simpler one would be like a bump in the wall firewall bump in the wire so you have a firewall. CNF that's just sitting there and that one we could take and then break down what is the behavior and features it's small enough that we can talk about how we would expect it to act. If you're deploying it and break those features down to a point where we can say okay here's here's how we would expect to manage it from the life cycle management what are the different aspects. Here's how if you're a developer and doing developing a firewall that's going to just sit in the wire transparent firewall passing traffic. Then what are some things that you could do to make it easier to develop and deploy like thinking from a developer standpoint. So that if we have the use case then we can analyze it and then start saying what are the things that we could do in Kubernetes that would be helpful. Okay. Of course, anything these use cases I think are going to be useful outside of that focus. You know, there's some things that may go this should go to the tag or we should go talk to the network plumbing group and then Kubernetes or some other sig, or the multi cluster whatever it may be within the CNF working group that would be the focus. What would you recommend in order to discuss that we don't necessarily going fully in for a pull request. I mean you were saying best is to start by the discussions right. I'd say it's how sure are you on what if there's you know and put something out and arguably it could go either way. I'd say with the amount of content that he has and we don't have a template. If you there's let's see there's one of them networking use cases and user stories right there. So this one. This is just a long list. Essentially, this is whatever idea that you have if you don't have enough content but you're like we should take a look at this then feel free to add it here. And then we can get started and then if you say I have a little bit of content, but I don't feel like I have enough to fully define it then maybe start a new discussion. And that way we can start adding more and more to it. And of course we can come back and talk about reference. And then if you feel like you have enough content, some diagrams, and there's enough content that we can actually examine, then that would be create a pull request. But if you're not sure just go with one and then we can talk about it. Where, wherever you think. Thanks for gently taking my hand. No problem. It's all new for all of us this area. Now this is all work in progress. I think we're trying to figure it out at the same time. So, Okay, we've done everything also above. The next thing that is quite exciting is the governance PR. So this is the different roles of people, because obviously Taylor and I have helped set this up, but we'd really like this to be the community Latin government initiative going forwards. So just to kind of give people a preview what this PR is is setting up basically the different roles so the chair is the technical leads and everyone else. So basically lays out what the chair the technical leads and what other people do. Yeah, I'm going to open this up for conversation. I know there's quite a few approvals already but if anybody wants to make any last comments on this or has anything else they'd like to add like please feel free to say it now. Okay, hearing nothing. I think it's time to merge this also. I think we've added this here and we discussed it. Unless anybody has any objections like I'd be fine with also committing this, rather than making it a separate PR. Unless anybody has really strong objections to that. Ian's just adding Cisco as one of the interested parties. So this is, yeah, I mean, I know it could be another poll request it just didn't seem particularly necessary and the list of companies there clearly Jeff and Daniel got to this first and so there are two. But I think the other thing is if there's anybody else who wants adding to this speak now or for her all your piece and then we can just basically alter this right this second. Yeah, so this is just a reminder, since as we are trying to set up kind of more formalized governance and everything. We'd like to go to the like the TOC or other groups and say, these are all the interested parties and this is like our governance just that we're kind of like a formal body, kind of in line with what everybody else in the ecosystem is doing and this is just one part of it so your company is interested please feel free to. Um, maybe quick question about this. Going back to the networking orchestration task force. If it will be under the CNF working group umbrella. Should it be formalized in some way regarding membership here as a tech lead or for a specific topic. I'm just not sure what what the best way to handle it would be. Bill. If you'll click on the other view, the little for the answer the diff do the other view. Yeah. Okay, and then this everyone else members. Yeah, there we go. So, I'd say for right now. Let's just keep it under this area. So there's essentially on all members. We can create other roles that aren't part of the charter. I don't think that we need to create defined charter roles for the task force right now. But we can just say we're, we have a task force that's looking into this within the group. Anyone that wants to do that. We say, okay, well, you know, tal right now you're. Helping to lead this task force and whoever else won't step up, but I would put that under that all members and that specifically that second bullet point under all members. We can have other roles, and they're just not a defined role in the charter. Yeah, I guess, yeah, I wasn't suggesting that we need additional roles I was wondering how it would fit in the roles. So I, you know, I'll step up if it's needed to become a tech lead or something else but I'm absolutely fine if it could be just in everyone else category for now. I don't think we need to define that and the tech lead. I mean it could very well be under there but you know if the goal is here soon we're going to request again some nominate self nominations are going to happen but that's tech lead for all of the CNF working group. I see and then versus the task force. I think that's clear. Okay, and just since we will be doing salt self nominations, I'm just gonna like quickly like skim to the different roles that people like are familiar with them. So the chairs is going to be three chairs one from the Kubernetes community one from the service provider, and one from the CNF developer. And just to note, like the primary role of chairs is to run the operations and governance of the groups that's like things like setting and just agendas, managing the discussions starting the scheduling for proposals asking new things and working with the tech leads to establish the roadmap, whereas the tech lead is really kind of the people that are experts in networking tacos Kubernetes and want to provide like the technical leadership to produce the outputs of the CNF working group. So it's kind of the divide between the two roles. And so the tech leads are really deeply diving into like the project. But also, I guess, going to the conversation we just had is that membership is self declared there's no membership requirements to be part of it and it's open public open working group so if you want to contribute you can maybe be in one of these roles to contribute so you don't feel like if I don't get one of these roles, I, there's no place for me in the CNF working group it's absolutely open to everyone. And so, these are just a little providing a little bit structure but not, they're not the only ways that you can work within this group. So there's no further discussion on merge these and then what's going to happen after this is, we're going to come up with a voting PR just that there's a structure around how our voting and in the meantime will have a self nomination period. And so, this will be opened on the mailing list so anybody can nominate them there'll be a little bit of a structure saying like who you are, what you're nominating yourself for, and it'll be open until March 1. And then we'll probably have. Sorry, a voting period for two weeks after that so we expect to have our new governance team by mid March. Bill. Yes, what mailing list. The CNF working group mailing list. Taylor do you have a link to that off the top of your head. I'm just thinking if we have a mailing list, they probably ought to be at the top of this document just to make that it should be in the read me. Good catch. We will. I'll drop it at the top. Yeah, I think it is in the main read me you're right. It's right here, but also added in the meeting notes to sorry. Part of that I encourage you to join it. If you have any problems joining like please feel free to reach out to me. Obviously. Yeah, so that's kind of the rough timeline does anybody have any questions about that. Okay, so look forward to that PR and email coming in later this week. I have 23 minutes left. I just wanted to. I didn't have a ton of time to like prep but in case anybody wanted to dive into any of the discussions I see in. Thank you for adding the discussion so quickly. And Taylor I guess this is how it looks in the discussion in case you're wondering. Is there any discussion topics that somebody wanted to talk or is there anything that I missed on the agenda. Otherwise we can also end the meeting early. So actually, let me let me talk about that pull request because one thing did come up when I put it in. I mean discussion pull request doesn't really matter how you put it. We've got template. The template's not finished so it's not committed to the template but I think it did tell me a couple of things about how we should be putting it together if. Yeah, and I put a get ignoring because you know we need to get ignore but setting aside the one thing I found myself doing here and I don't know that's the right thing or not is the use case and this is a use case because it's not describing a function not a person's behavior. It basically highlights a bunch of shortcomings that I've expressed in terms of if I deployed Kubernetes out the box with the CNI. These are the things I would struggle to do. I don't know whether that's the right place to put it or not did anyone have any thoughts on how we might want to organize this seems like it's a good thing to put in, but it's not technically the use case. Anything if if you feel like it's additional reference material you could always add a section for additional context. Yeah. The thing is it seems like it's the thing you want in the main document in the sense of you really do want someone to basically read this as they're reading the document as well not just read the document go away happy. It's all going to work, but you know, and there's two parts to that one is it could potentially change over time if Kubernetes get better. The other is, if we're measuring this up against a platform definition of some variety, then if our platform definition changes if we say well our platform is not base Kubernetes obviously it's based Kubernetes plus these features, then that would change the change the results slightly. I don't know. I'm, I'm asking I don't have a great answer to this one but it's it's really a question on, you know, requirements design split so here's a use case and the use case raises a bunch of work items or a bunch of issues however you like to define it right well if no one's got comment then it will stay as it is for the time being and we will work on the assumption that that's the right thing to do. If anyone wants to pick on that then again there is both a discussion and a pull request. You can you can put your thoughts in there later and we'll decide how to how to react. So, thanks for that and obviously, as Ian said, there's the discussion on the pull request so add your thoughts. Is there anything anybody else wants to go over today. Otherwise, I think we can all have 20 minutes back. So, thanks everyone for joining today. Cheers. Cheers by everyone. Thanks everyone.