**Session Date/Time:** 23 Jul 2026 12:00

[00:00:05] **Mahesh Jethanandani**: No. Like here, ask them to

[00:00:09] **Ian Farrer**: Oh, okay.

[00:00:10] **Mahesh Jethanandani**: And that gives the control over the blue work.

[00:00:13] **Ian Farrer**: Now Okay.

[00:00:15] **Luis Miguel Contreras**: And, by the way,

[00:00:16] **Mahesh Jethanandani**: it resets it after every slide deck.

[00:00:19] **Ian Farrer**: Yeah. And Mithin Mithin's gonna drive this. So we have 02:00, and it's time for the first work group session at IETF 120. My name is Ian Farrer, and my co-chair there is Med Boucadair, who is gonna be attending remotely from, I think, the West Coast.

[00:00:49] **Med Boucadair**: Hello, everyone. Good to see you all. Excited to start working with you all.

[00:00:56] **Ian Farrer**: So we'll start as ever with the note well. Please take a minute to have a look over it. And can you please make sure that you're logged in via Meetecho to show your attendance in the room? There's a QA QR code on the mic there, or you can do it through the website on the agenda. Some links there. And we've got a two hour slot today, and we've got a hell of a lot to get through. This is a very, very packed agenda. So we're gonna have to be pretty tight on the timings. And, yeah, if we have to ask you to move on, if you're not finished, then please bear with us. We'll take things to the list, but we have got a lot that we need to get through to today. Queuing. And if you wanna participate, then please use meter code to get into the queue. I think you will know the drill for that. But, yeah, that's how it works. Okay. As ever, we've had a number of contributions, and I think we're doing quite well at the moment. But please, yeah, remember, the mailing list is the place where work and decisions actually get made. We don't have any draft drafts for review yet, but this this will come up. Yeah. We will ask for your participation and your support in that area. And, yeah, we're a way away from Document Shepherds at this stage, but, yeah, one day. Okay. I think we've covered work group reviews, document reviews. So let us start with why we are here today. The New Onsen work group, it's been a long time coming, I think. But here, we finally are. I can't even say the word, I'm afraid. That's what we call it Onsen for short. But, yeah, we're focused on abstracted modeling and service modeling over the top kind of stuff, layered abstractions. How do we get here? There's a lot of work that's been going on for many, many years now that many of you will have been involved with, certainly you'll have read, into service network models and the abstracted models. These are things that, you know, we're we're trying to do so that we can implement, manage things at scale, intent based provisioning, and, you know, how we can speed up provisioning in really complex and diverse environments. The problem is the take up has not been what it might have we might have hoped for. And and the question behind that then got raised, well well, why? What's what is the problem here? Back at the end of twenty twenty four, the IAB ran the workshop, which was meant to review how really we've progressed in the last twenty years. We now have NetConf and Yang and, you know, a bunch of additional models, I mean, hundreds of models literally that have been authored around here. But maybe we haven't got as far as implement implementing these things as we hoped we would have been. So this is why we're here. This is what Onsen is going to try and find out and resolve to make it possible to use these things to understand how we can actually implement stuff and and get stuff into service. So with that said, let us get started. A little view of the estates that we have inherited here. It's by no means the full list, but what we tried to break out here was the the key models that that we're focused on. So we've got service models, l two, l three. There's also some attachment service stuff that lives up there. We've got the network models, which are focused by around the common VPN model, but also the l two and l three VPN model. The whole attachment circuits architecture. I think there's four RFCs that define those with the associated models. And then down here, some associated work that is also under our remit. So this is by no means an exhaustive list, but this is kind of where we're focusing. And I I think the the left pane is where we'll be first looking at. So how do we get started on all this? Clearly, we have a problem or we have a number of problems. Otherwise, we wouldn't be sitting in the room today. We wouldn't have a work group to talk about these things. And there's a number of things that are being raised via neemops via various different efforts to gather things together. And so the first thing that we need to do is get a clear view of what the problems are that we believe are in the remit of the work group, what what things we need to address, you know, where we have inconsistence, when we have emissions, and and all of those kind of things. I think also we will have to address problems that are not just this model doesn't work properly or, you know, that bit's missing. Around, you know, deploying these things, there's organizational things, there's technical things, there's educational elements, there's so many other things that we need to consider here around saying, okay. How do you actually, you know, help people to get stuff into service? And on that basis, you know, we may have to apply a bit more creativity to how we go about addressing these problems. And, you know, it's it may not be just a case of saying, here's another architectural RFC. We then take that information, and we need to look at what the foundations that underpin all of these models because, you know, it's just extending and and adding more containers and leaves onto shaky foundations is not gonna help anyone. You know, a lot of the problems that we'll be talking about are maybe a bit more fundamental than just, you know, we don't have enough nodes on the on the trees. So that's will be the next step that we have to look at is to say, okay. How do we get our foundation dried so that we have, you know, the the right building blocks to go forward with? Okay. Let's get started with our agenda. So we've given a rather meaty slot to the problem statement because, obviously, this is the first and most all important thing that we need to look at. Samir is gonna be running that for us. What we then have done is kind of tried to create the different drafts that have already been submitted. Given the timing, you know, given this is the first meeting, there's a a bunch of work that people have already submitted, and we've tried to sort of arrange this in order of what the relevance is to the problems that we already know about, give the authors a chance to, you know, describe what they've got in there and and use that as a basis to screw up for discussion about how and we we proceed with each of those pieces of work. So we have, I think, a total of was it seven? Yeah. Seven slots. And, we're then like, we should have a couple of minutes left at the end for an open mic. Can I hand over to Sameer for the first presentation then, please?

[00:08:30] **Samir Varghese**: Hello? Can you hear me?

[00:08:33] **Chris Bowers**: Yes.

[00:08:34] **Samir Varghese**: Perfect. Can you share the slides, or should I share

[00:08:49] **Chris Bowers**: it?

[00:08:49] **Ian Farrer**: I I think

[00:08:50] **Dhruv Dhody**: You have lunch here

[00:08:51] **Oscar Gonzalez de Dios**: before share.

[00:08:52] **Med Boucadair**: Yeah. I'm actually trying to

[00:08:54] **Ian Farrer**: I bet you can. Yeah.

[00:09:01] **Med Boucadair**: We should have it.

[00:09:05] **Samir Varghese**: Yeah. Perfect. Good afternoon, everyone. My name is Samir Varghese. I'm presenting this on behalf of my coauthors, but I also want to remember that this is nothing new. This is something that I'm just recollecting all the information and discussions that we have on the past on the mailing list, and I just try to put everything together. So I encourage you also to to give all the feedback and all the comments or all the possible comments that you have to the the current draft. The session goals that we have for today is initially present each of the problems that we have documented so far in the draft. Ideally, we are going to discuss each problem. We have a limited time frame, so the idea is to reduce the the discussions to a specific amount of time that I will share later. But the idea is to cover if it is in a scope, if it's correctly framing, if you detect that something is missing, we are open here to well, we are open to hear any of your comments and and feedback. And we have also, at the end, a final MIGO option. So if something is missing or any of the eight problems that we have documented in the in the draft do not cover your expectations. We are also open well, some time to to discuss it. Let's copy reminder. This document do not propose any solution or protocol or data model. The goal is to agree on what are the problems that the onsen charter is going to solve and try to put it here as an action actional actionable items. And finally, I want to make send a special thanks to all the charter proposal, all the mailing lead discussions, and all the contributors to the draft. I'm just someone that put everything together, but this work is the result of all the discussions that we have in the past. So what is onsen? I believe the our chairs already present that, but the goal is to make IT of service and network instructions easier to implement and use. The idea is to improve how network automation increase operational efficiency and interoperability between vendors and in in different network scenarios. And the core activities is basically the common use cases, scope, and priorities. This is the purpose of this draft, updating some of the young data models or key young data models that we saw in the previous slides and defining obstruction and service layers for OSS and VSS integration and increasing interoperability. It's clear they do not define new protocol or extend external frameworks. So the background of this draft, and and and you can see it on on the document, is the RFC eight eighty nine six nine. So, basically, here, we define what is a service model, a network model, and a device model, which is the scope of each of these layers and what is the life cycle management. So what we expect or how we define service instantiation, monitoring, modification, decommissioning, and closed loop automation. So the whole set of problems that we have defined are in the scope of this draft, and this is the background and and and the building block for all all the discussions that we are going to have in in the upcoming set of problems. The list of problems in operational areas that we have discussed are basically eight. This is the way the draft is structured. So I will list it here, but we will enter into the details during the rest of the presentation. So I will not read it one by one because we will have time for that. But this is the list, and and you can see it also on the draft. So for each of the problems, the idea is to resolve these kind of questions. If this problem if the scope of onset is correctly framed, it's something missing, can you provide an evidence or an experience that help us to improve the description or find a proper solution for this problem? For each of the areas, we only have four minutes for the discussion. So we will have the mic open for that period of time. So we are pleased to hear you. So if you have an opinion or a a comment, please feel free to comment. And but also, not the last thing, we will, after the session, we will ask in the mailing list a consensus set of questions just to gather more feedback in case the the time is not not enough for the discussions that we will have today. So I will enter to the first problem. So the first problem is the lack of a guidance on how to work with fragmented operational life cycles. So the draft documented operational workflows, in this case, instantiation, monitoring, modification, decommissioning are handled consistently across protocols, vendor, or or tools. The models do not share life cycle semantics, and configuration management remains separated from telemetry. As a working as a working group, on same can work toward consistent life cycle definition and native life cycle attributes in the abstractions. I would like to know if this is captured correctly, if there is anything missing from the draft at this point or that the working group should also address. The way of reading this each of these statement is the the problem description and in the within the brackets, you see the section of the draft that is presented. Well, what is present on on it. So now we have the mic open if you have any comment regarding this problem one.

[00:15:47] **Ian Farrer**: So does anyone have any comments about whether this is something we believe that we should be tackling in the world group in either direction?

[00:16:06] **Mahesh Jethanandani**: Alright. Mahesh, I think what you're asking is those three questions I think you put up front, which is, is this problem statement in scope of Onsen? And I believe there are two more questions. I think that's the question you're asking. And if that's the question you're asking, I believe my as a contributor, I believe this is in scope. Right? So the only question is if is there anything that we probably should not consider? I mean, otherwise, I think we I agree with the problem statement, and I agree that we should be considering it.

[00:17:00] **Joe Clarke**: Joe Clark, Cisco, this to me I mean, this sounds like a problem. It is a problem. It sounds like the mapping exercise that way back in Madrid when we did the side meeting, people said was probably untenable. But but maybe I'm I'm misreading this, but it seems like we've you're saying we have these vendor specific APIs or vendor specific models, and operators want a more consistent way of working with a heterogeneous mix of of of stuff, and that would maybe naturally require a mapping. And is that something that can be done? And if it is, are there people willing to invest time and effort into doing it? Or are there other lower hanging fruit or other things that people are willing to work on now that might lead to what seems like a very big thing to solve, and that should be where the priorities lie.

[00:17:59] **Ian Farrer**: So to without jumping to to solutions, I I envisage this has actually been more of a guidance problem than a a mapping problem, but, yeah, both could be valid. Who knows?

[00:18:20] **Chris Bowers**: Chris, entwined one of the authors on the draft. I do think that guidance is necessary here. I do not necessarily believe that in this room or in the sort of documentation process, is possible to provide a definitive mapping from one to the other. I'd rather say that we have work to do in terms of showing how mappings could be done. I I'm here a proponent here of referencing open source implementations that have done the mapping. That doesn't mean it is the authoritative mapping. It's just here's a few people who have done it in various ways for their networks or their sample networks that they're willing to open source or show, and that's a more realistic way of doing it for me.

[00:19:02] **Ian Farrer**: Okay. Wim, we'll we'll have to cut the line off that, but go ahead, Wim.

[00:19:07] **Wim Henderickx**: I have a I I have more clarification question because I see two questions here. One is the mapping, like, that Chris said. The other thing is I feel that what the the second piece is the life cycle. I what I'm how I'm reading it is that the current models don't have attributes related to life cycle management

[00:19:23] **Chung Feng**: Mhmm.

[00:19:23] **Wim Henderickx**: That help guides with the mapping. So that I see two things in here. One is additional attributes to meant to basically express the desire for the life cycle. Mhmm. And the second is how do you then map it? So I see that as two different things potentially. So you

[00:19:39] **Ian Farrer**: you think that the the formulation of the problem in this may may need some work?

[00:19:44] **Wim Henderickx**: I just wanted to clarify. I how I interpret it, that's how I interpret it, but I just I I want to share that interpretation with the the the audience and with the with the group here. Okay. Thanks. I'm right or wrong.

[00:19:57] **Ian Farrer**: Okay. So we'll we'll take this, and we can discuss it further on the list. Samir, do wanna move on?

[00:20:03] **Samir Varghese**: Yep. So thank you all for your comments. The second problem is inconsistent models at the same abstraction layer. So we have documented that models at the service layer. In this case, for example, it's two SM or L3 SM or network slice service model, evolved independently, leading to inconsistent parameters or sometimes incompatible service representation and an unspecified relationship between them. So Onsen is well positioned to bring this into the alignment, but we want to make sure we are capturing the full scope of inconsistencies here. So we will welcome any gaps or or, yeah, points that you consider we could include. But so far, these are the three that we have documented.

[00:20:57] **Ian Farrer**: Comments for problem two? No. Okay. We will again, we'll take it back onto the list and move on to problem three.

[00:21:21] **Samir Varghese**: Perfect. Problem three is me misalignment between abstraction layer. It's similar to the previous one, but different. The draft describes the absence of a defined mapping between service and model. But I'm like parameters do not correspond across layers when those behaviors are in capturing in the service intent and concepts like cost or performance and are defined differently in in different layers. So this is the precisely the kind of cross layer alignment that working group can can solve. So if you have any comment here, it's also welcome.

[00:22:07] **Italo Busi**: Italo Bousi, I think there's some misalignment is inherent on the fact that you are providing different instruction layers. So there is a from the service model to the network model, you have a controller that has to translate your service into a specific network configuration from the network model to the device model. You have another controller translated to the device configuration. So it cannot be a a strict mapping. Something I fully agree that something may be the same, but something may be inherently differently. So it's good to maybe this is a I think it makes sense to have a similar structure if the things has to be the same in across the a structurally, but a structure may be different on some aspects.

[00:22:50] **Benoit Claise**: Benoit Claise. So, actually, I want to mention something similar to Italo. Yes. Everything that you are telling me so far are problems. Now I know that you're in problem statement, not in the solution, but, actually, since there are different layers and different abstraction, they serve a purpose. So if we said that's a problem, then we're going to have an LXMM at the LXSM with a one to one mapping. And, actually, it's not really the goal. So I could say yes to all of these problems. The point is that you have to think a little bit, is this practical? Is this something that we want to solve even if this is a problem? So a couple of key parameters, keys in the young model, fine. But how far do we go?

[00:23:40] **Ian Farrer**: So yeah. Chair hat off. To echo what Benoit says, I I think what we see here is that it's a lack of clarity about how the things are meant to be used. Oh, that's what my feeling of where this this comment comes from is that that we need to get an understanding of where can you map, where should you map, and where should you not map, what is the purpose of, you know, having this separation between the layers? And how should you look to to bridge that gap? You know, what are the considerations that you have for doing that? And I think that's, you know, that's something that we can tackle about this. But, yeah, if you're gonna do one to one mappings, then where's the abstraction?

[00:24:27] **Mahesh Jethanandani**: Thank you. Alright, Mahesh. So, kind of building up on what Benoit was talking about, the fact that we're going to have to deal with different sets of models at the device level, whether it is vendor specific or it's yet another body that has developed. That's a given. I don't think so we will be able to change that. So when I read this, in my mind, I'm thinking, as Bruno said, that maybe there is an abstraction there that has to come between the service slash network layer and the device layer. Is that a fair statement? Do we agree? I'm trying to get to what Vinod was saying. What is the specific problem you're trying to solve?

[00:25:19] **Ian Farrer**: I I mean, that I think what you're saying could well be a you know, one of the outputs from here. But one of the things I think that that has you know, is is that there isn't a a a common understanding of how these are meant to interwork with each other, what the purpose of layers are, you know, and why some degree of separation is, you know, maybe a desirable thing. But, yes, this is this is certainly stuff that I think needs to be addressed. Okay. We'll need to cut the line after Richard.

[00:25:53] **Richard**: Yeah. So, Richard, so on four three two, just to add to what Benoit and Mahesh were saying, like, it seems to me like there's stuff in the network layer, which is public in terms of API that the services need to be able to program for the services, and there's stuff which are private, which is like the underlay or whatever as an example. So I think we have to distinguish a little bit between there's cases where you don't want to have a mapping, and there's cases where, yes, it's not a one might not be one to one thing. But it's case by case, I think.

[00:26:21] **Ian Farrer**: Yeah. Yeah. Both could happen. Yeah. Okay. Problem four, please, Samir.

[00:26:28] **Samir Varghese**: Perfect. So problem four is the limited observability and feedback within the LXNM and the LXSM. So what we have documented here is that existing abstractions are primarily configuration oriented. There is a limited standardized support for alarms or state reporting or the life cycle feedback. So operation operators in this case can is cannot easily validate whether the service intent is being maintained over the time or what is the actual status of of the service in the network. So here, on sync, can define what the operational status should like in this model, and we will like to confirm this is the shared priority and whether these are the specific feedback mechanics that the draft should or, well, the the drafts that we have on the pipeline should call out more explicitly.

[00:27:29] **Ian Farrer**: Any comments on problem four? Okay. I'll take that one to list then. And on to problem five, please.

[00:27:43] **Samir Varghese**: Yeah. We we are in a good cadence. We stopping Good progress. This is good. Problem five is OSS, BSS interface, and API interoperability within the young model application and devices. So the draft captures that they got between young based models and the northbound interfaces, the operators actually use, in particular, the TMF six forty or TMF six forty one. Gap exists. Today, every operator builds their own adaptation layer, and APIs are generated from similar models are still different or diverse. So once in can provide the guideline, the guidance and alignment for what it's currently missing. So I know this is one of the most relevant points that we have had in the discussion on the past, and we want to make sure we have the documented it properly and the full scope is in within the draft.

[00:28:54] **Ian Farrer**: Any comments on this one?

[00:29:03] **Mahesh Jethanandani**: Mahesh, I'm a little confused by the last statement above, I guess, the block. APIs from similar Yang models differing in service semantics. Are we if you're talking about the interface between OSSPSS layer and whatever comes below it, I thought what this working group was going to do was try to define that interface and

[00:29:34] **Ian Farrer**: Between yeah.

[00:29:36] **Mahesh Jethanandani**: And therefore, APIs from similar young models, plural, is confusing to me. I

[00:29:45] **Ian Farrer**: Can can I ask the authors of this if they do they know where this one came from, where where that that particular requirement or problem statement came from? Okay.

[00:30:05] **Chris Bowers**: Chris Lumbert is one of the authors. I do not, but we will come back on this and It's very fine. It is also with the progeny. It is a confusing statement to me as well, and so I'll Yeah. I'll put you into it.

[00:30:15] **Ian Farrer**: Okay.

[00:30:21] **Italo Busi**: Italo Busi, I think also this is something more in the scope of the implementation of the network controller. If I look at the example you said before, you have a a layer you have this controller that is con configuring the network with a two layer three and m based on the intent in the intent coming from the customer to layer two layer three s m. And we have a situation where instead of using layer two layer three s m, some some OSS implement another interface. So we have two competing standards for the same interface, which unfortunately happens multiple times. And the the only thing that can do is is that your controller needs to implement two MBI standards because you need to talk with the two different type of clients. But then what you have to do is you have to basically create understand the intent and understand how to configure the layer to layer T and M toward the network. I think this man, we can provide guidance, but I think here is merely an implementation issue for the network controller that consume that provides layer to layer TMM as well as TMF online open APIs on its MBI.

[00:31:27] **Ian Farrer**: Question to the room. Are there other operators in here that recognize this gap or the, you know, the TMF to Yang modeled OSS domain that is described here? Is this something that is is commonly observed? Or

[00:31:42] **Oscar Gonzalez de Dios**: Yes. Yes?

[00:31:45] **Ian Farrer**: Okay. So it sounds like it would be a useful thing to tackle then for you. No. Okay.

[00:31:54] **Chris Bowers**: Chris, in response to Italo, I hope that the presentation on my draft a little bit later will clarify why this, from my point of view, is a good draft to have here.

[00:32:07] **Dan**: Dan BHP, which was about five months ago an operator working on this. The trick is, like, depends on it is a problem depending on who's trying to implement the models. If you're coming from the old OSS system, you think TMF is gonna go all the way down to the optical link. Uh-huh. If you're a network operator, you're a network team, you're thinking that Yang is gonna go up to the portal of the user. Mhmm. And at logic, if somebody could decide that TMF six four one is actually a product that's called flying packets or flying frames, and that's the purpose. You have to have to an intent that tells you this is gonna be an l two VPN service model or l three VPN service model.

[00:32:44] **Ian Farrer**: Right. K. Thanks. Hi.

[00:32:48] **Oscar Gonzalez de Dios**: I reckon that there there is a problem, but I don't I do not know if we have the strength enough to to really solve it. And on the one hand, we are working here with data models. TMF is not working with the same kind of data models that they have. They and they work on on APIs for service activation Sure. For some as well. Yeah. Maybe, ideally, what we thought, like, some way back is like, okay. How can we use the data models that we define in ITF inside the APIs of TMF? And then this way, okay, we don't, let's say, compete each other and we are complementary. That that would be ideal, but I don't know if we have the strength enough to do that.

[00:33:29] **Ian Farrer**: That's that's what we I think we'll try to do. But, yeah, we'll we'll see. I will need to cut the line after Nils, please.

[00:33:37] **Nils**: You can arrange a wrench. So I will say similar things like Oscar before. This is clearly an issue, maybe a large problem to solve. So we need to find a reasonable scope on address, maybe based on the priority level, what we can achieve and progress step by step. But it's an actual problem behind. Thanks.

[00:34:05] **Nils Warnke**: So Nils Warnke, Deutsche Telekom. I'll make it very brief. Exactly on this topic, we had a site meeting a couple of years ago in Prague, I believe. There were a lot of operators in the room who acknowledged this to be a key issue. And I believe that the founding of this working group is still a late result of of this site meeting, I believe so, or I like to believe so. So I definitely hope that we will find a way to approach this.

[00:34:34] **Ian Farrer**: Thank you. Can you move on to problem six, please, Samir?

[00:34:39] **Samir Varghese**: Perfect. Problem six is also section 4.6 in our draft. So here is lack of architectural guidance. So the draft notes that the absence of any document explaining how all the abstraction layers that we have defined in l l x n s m or l x n m or the attachment circuit or the service attachment points are intending to work together as a system. So we have drafts and we have YANS and we have APIs available, but and we have an RFC that describes how each layer be participates into the service constructions, but know how those are intended to work together as an entire solution. So here, operators do not know which model to choose, how to combine them, or how to responsibly or how responsibility is divided across the working groups or or the different models, producing that an architectural view that may be on. Want to confirm if this is a recognized gap or this is still a problem for the operators. And, also, the question is if we elaborate more documents or more architectural drafts, if this will solve the problem or we need something else, right, related with the implementations or open source activities or things like that.

[00:36:16] **Med Boucadair**: Cisco Systems. First of all, I think the others have done a good job of compiling all the issues. So that's that's a good thing. One thing I noted was how do you reconcile this with the ACTN architecture? Because ACTN brings in a whole bunch of other abstractions. Right? Yeah. So is that in the scope of this working group?

[00:36:38] **Contributor**: Or

[00:36:39] **Ian Farrer**: Yeah. Access yeah. Access circuits is is one of the yeah. But, I mean, drawing all of these things together is is one of the things we need to get a handle on.

[00:36:46] **Luis Miguel Contreras**: Alright. Thank you.

[00:36:54] **Mahesh Jethanandani**: Mahesh, Sam, this is more a process level question. Is the architectural document a standalone document that talks about how to use these models, or is it going to be a guiding principle for the other pieces of work, other problem statements that have been defined till now?

[00:37:18] **Ian Farrer**: If I recall what's in there, there's there's another document that defines the whole Yang model taxonomy. So the device layer models, network layer models, and service layer models. And then 89 eighty six ninety six tends to tries to draw all these things together and say, okay. This is how these are meant to into work. So, yeah, it's not it's not a standalone piece of work, but, you know, the feeling for you know, we've obviously tried this one before, but these problems keep on coming, getting brought back to saying, I I don't know what to do with it. So the question here is one of, do we have insufficient you know, is there a problem with eighty six ninety six? Do we need to take another swing at that? Is the whole approach the wrong approach? Or, you know, I I I'm not really sure at this stage, but this is obviously something we have we have tried to solve previously and yet the problem persists.

[00:38:10] **Mahesh Jethanandani**: Okay. I mean, if it's great if if these are additive things that we wanna put in the document, but I would imagine that its usefulness would be more if it was tied to actual underlying work that the working group is gonna work on.

[00:38:27] **Ian Farrer**: Yeah. Okay. Thanks.

[00:38:31] **Italo Busi**: It I was speaking and replying to the question about there is already a mapping between ACTN and eighty three zero nine, which is also mapped to what you see. Yeah. ACT 96. So you you can easily be mapped. These models can be easily mapped to the ACTN interfaces. Mhmm. Okay. Thanks.

[00:38:49] **Ian Farrer**: Problem seven, please.

[00:38:52] **Samir Varghese**: Joe, have any comment? Or

[00:38:55] **Ian Farrer**: Oh oh, Joe. Sorry. I I didn't see you, Nikola.

[00:38:58] **Joe Clarke**: Joe Clark. Yep. Looking at the questions, I I think maybe one of the reasons, and it was $89.69, that that, it wasn't effective is maybe the last question. To what extent a given implementation actually supports a full model and which abstractions to use in which scenarios. One of the things, Dhruv and I were collecting or or thought of is it doesn't always have to be a document.

[00:39:22] **Richard**: Yep.

[00:39:23] **Joe Clarke**: Maybe Wiki collections of experience from operators could help make this a little bit more effective. As they learn specific things about specific vendors or interoperability, they can publish that, and that could help answer some of these questions.

[00:39:38] **Ian Farrer**: Yeah. I I think I think you're right. So, you know, another thing that I I think we need to look into is if there are implementations of this is how it's been solved in this particular context. You know? It it may be it may be a better approach than, you know, another RFC that, you know, fails to solve a problem. Okay. Number seven, please.

[00:39:58] **Samir Varghese**: Perfect. Problem number seven is limited support of dynamic life cycle management. Here, this is describing section four one four of the document. So, basically, it's limited support of dynamic lifecycle management on the service instantiation, dynamic bandwidth adjustment, or temporary services suspension. So all the young definitions that we have right now are target well, what are the defining basically, target static configurations instead of these dynamic changing environments. So the these problems will describe that kind of nature of the existing young models. Does

[00:40:51] **Ian Farrer**: anyone have any questions as to kind of what the use case behind this requirement is?

[00:41:03] **Rob**: Not not that. But I have a question exactly what's meant by this. Is this like a femoral configuration? Is that what is or what might be gRuby might be used to all that sort of thing? Was that something different to me?

[00:41:16] **Ian Farrer**: The way the way I understand this is that you may have services which have maybe a prepaid boost that you could have. I have a large data transfer. I send an API call. I flex the bandwidth to whatever I want. When I finish the transfer, I turn it off again. Or maybe you have a situation whereby you have you know, I do the my data transfer at 02:00 on a Tuesday morning or something. So I have a regular two hour time slot where I can, you know, get 75 gig or whatever it happens

[00:41:45] **Rob**: to be. Okay. And then the next question is, is is this then work for this for what's happening in answer for framework, or is this actually work for then someone's gonna be redirected into NetMod to say, you need to support personal operations to do this or

[00:41:58] **Ian Farrer**: something like that? This is a good question. And, you know, I mean, if there is a time based component that we need to start in, you know, a young calendar and who knows what around there, is this a you know, is it just this, or is it a a wider solution? I I don't know, but we've talked about both. K. Thanks. Any further comments on this one? Oh, go ahead, please. Jump in.

[00:42:25] **Chun Feng**: Yes. This problem is is one we witnessed in our network when providing some new services. As mentioned in ITM one twenty five, a service called the data intensive the data intensive transmission service. So we need such the network on demand service initiation and the dynamic adjustment capabilities. So the problem is very clear. Okay.

[00:43:00] **Ian Farrer**: Yeah. Yeah. Go ahead, please. Yeah. I'll then work.

[00:43:02] **Chris Bowers**: Chris, so, yeah, when I saw this sort of problem, I came to the same sort of conclusion as Rob where maybe this is something that needs to be solved in either NetModel or or NetConf, and maybe you sort of need support in the data stores to express temporary or or or changing, intents in various situations or over time. So, yeah, I I think that is worth exploring.

[00:43:37] **Contributor**: I have a question on the dynamic nature. Right? I would assume that the dynamicity is known to the controller. Right? So how different it would be for a controller to make a change on the network and at a certain time. Right? So so what's what's new?

[00:43:59] **Ian Farrer**: It's a good question. And I I mean, I I guess the the it kinda comes down to where what drives that? Is this something that comes from your BSS system to signal it's time to to change this? Is it something that, you know, happens in the OSS layer and, you know, that's it it dealt with there. Obviously, something has to have this this, you know, interface and and and ability to model that stuff where

[00:44:22] **Contributor**: I mean, the thing that that I'm not able to kind of comprehend is that would that information be in something that exists in the intent, which is kind of outside the model, at at least in my mind, or or because because what the intent states is is is the you know, what what you are going to to perform as a target state for the network.

[00:44:45] **Chris Bowers**: Right?

[00:44:46] **Contributor**: While the the l x n m and l x s m gives you the model for what it needs to be. Are we not mixing the intent action with the model?

[00:44:56] **Ian Farrer**: Yeah. But you could also argue when the customer takes out a contract with variable bandwidth in there, that is an intent.

[00:45:05] **Contributor**: Possibly. Possibly. But but is that the the the standard, you know, l three service model?

[00:45:13] **Italo Busi**: I mean, that's that's Yeah.

[00:45:14] **Ian Farrer**: I I I I think this is something that the

[00:45:16] **Contributor**: the discussion was. You know, we are taking things that are problem statement for the intent to problem for the network model. Right? And in in my mind,

[00:45:26] **Ian Farrer**: we are separate. Thanks.

[00:45:28] **Dan**: Again, then we just one comment is that having status in the model to see if the services is up and alive, that's one thing. Like, think about their temporary service suspension. So we didn't pay his bill. So I have to shut down the service because he didn't pay the bill. Will I keep billing in the model? Because it's something that's completely commercial.

[00:45:48] **Ian Farrer**: Oh, yeah.

[00:45:48] **Dan**: It's a besides, say, I paid for a 100 meg, but for now, want 200 megs. This is a service order, billing, all those things. I need a technician on-site. Will I keep the technician, the availability?

[00:45:58] **Ian Farrer**: Yeah. I mean, there are At

[00:45:59] **Dan**: some point, knowing where to stop, I think that's important as well.

[00:46:02] **Ian Farrer**: Okay. So it's it's I think there's more discussion around this one, so we'll we'll take this one to the list. And the final one is number eight. So, Sumeet, over to you.

[00:46:12] **Samir Varghese**: Perfect. Problem eight is lack of templates for common life cycle patterns. So pretty sure operators must manually configure every service instance, and these manual configurations reduce the operational efficiency and can lead to or increase the risk of misconfigurations.

[00:46:39] **Ian Farrer**: Mahesh, think it's I think it's you. Daniel was saying from before.

[00:46:49] **Mahesh Jethanandani**: Mahesh, so if the intent here is more a template based configuration, I think there is a draft that was presented today in NetMod. Take a look at it and see if that fulfills this particular requirement.

[00:47:09] **Ian Farrer**: Okay.

[00:47:11] **Mahesh Jethanandani**: And then I did have a process level question. So I'll wait if to make sure that there's any other discussion of this problem, then I'll come back to the process level question.

[00:47:25] **Ian Farrer**: Okay. Thanks. Any further comments on this one?

[00:47:35] **Dhruv Dhody**: Just a confusion whether this includes when the Yang model themselves have some templates inside it, or is this problem that we are describing in a different context? I think that could be clarified a little bit.

[00:47:47] **Ian Farrer**: Mhmm. Okay. Yeah. Can you look to address that in the next version? Okay. Thanks.

[00:47:55] **Chris Bowers**: Yeah. Just to quickly respond, Chris, as one of the authors, this would have been specific template that would be part of that particular young model is is what was intended here by the Okay.

[00:48:06] **Dhruv Dhody**: So it's more like the guidance. Are working.

[00:48:11] **Chris**: That should yeah.

[00:48:15] **Mahesh Jethanandani**: Okay. If there are no other questions, believe there were two problem statement drafts in front of the working group. I think, Chung, you you are authors of the other one. Has the work group decided what we're gonna do with the other Yeah.

[00:48:34] **Ian Farrer**: What wanted to do and what we what we discussed was to roll all of these up into one single new draft. And so we hope I I think we've captured everything that you you had listed in there, plus the different problem statements from all of the the drafts that's and and really all the all of the other sources that we had. Okay. That was the end with this one and just to start with a fresh document that that combined all of these things.

[00:48:57] **Mahesh Jethanandani**: Great.

[00:48:58] **Ian Farrer**: Okay.

[00:49:07] **Chris**: Sorry, Chris from Huawei. Just I I think I was thinking wondering something similar to to Dhruv. I mean, do you want to you know, when you get into sort of life cycle patterns that can have all kinds of permutations that are dynamic, sort of under user control, do you do you try to come up with permutations of models to capture all that, or do you rely on life cycle negotiation processes around fixed templates to do that? Right? I mean, not a model isn't the right way to a variant of the model is not necessarily the right way to solve every problem.

[00:49:54] **Ian Farrer**: Just a thought. Fair comment. Yeah. Okay. We need to finish that there, but I'd like to move now to use the rest of the time for a shorter than planned open mic session to raise. Are there any other problems that you believe we have not currently captured that you think we should be looking to describe at this stage for consideration by for the work group?

[00:50:21] **Chun Feng**: Yeah. Chun Feng again. And one problem maybe we should consider is about quantum security. Yeah? Because right now, more and more customer need long term data confidential securities and and to meet these requirements. But the current service model do not support Quantum's security. We I think we should be considered in the you know, by ONSEN working group. You have a question? Okay. Quantum.

[00:50:54] **Ian Farrer**: Are are there other operators that see a need for quantum configuration as part of the service models?

[00:51:06] **Chun Feng**: As far as I know, several operators has deployed such kind of service.

[00:51:12] **Ian Farrer**: Okay. Mhmm. Thanks.

[00:51:18] **Benoit Claise**: Benoit, it's not about something missing, but maybe one observation, which is somehow linking to what Joe said. I mean, at the beginning, all the problem statement over the problems are real problems. This is for sure. Now I I want to understand, like, I could say yes to everything, and I could add a longer list. But in the end, we have to do something in the working group. So in between all this and finding a solution, I would like to understand, I mean, who is committed to do that? Who wants to do the job? And can we do it? Because there are some of them material problem, but some of them imply, I want to have an open source controller that will give me all the mapping and get the freelance and everything. So in in the end, you know, we could be telling all of them are in scope, but I can't picture taking all of these problems, surrounding specific solutions, and having everybody happy because it's going to take a lot of resources to do that, a lot of commitment. And I'm not sure how you want to run that. Maybe it's the wrong question, wrong time. But

[00:52:17] **Ian Farrer**: No. I mean, it's I I think there's a you know, what we see is broadly some some structural and some much wider problems, which are the things that we need to tackle. And I think there's also a backlog of maintenance extensions that need to be added in. And, you know, those maintenance extensions may just be, okay. Here's some some new a new container and a small augmentation type of thing. But, certainly, you know, once we've got this stuff together, we need to triage and and see and, you know, some sequencing about how how we can approach those things and, you know, what we can do and and what we can't.

[00:52:52] **Benoit Claise**: Very good. Because the goal is noble. Right?

[00:52:54] **Ian Farrer**: But it's very wide as well. I understand.

[00:52:58] **Wim Henderickx**: Yeah. One problem that I ran into in this space is basically referencing secrets, like secretive information. So sometimes you I when you go to the device at some point, you need to say, this is the password or this is the key for ISIS or something like that. Right? So if you go through your orchestration flow, you somehow need a mechanism to reference data that is obfuscate that somehow is secretive and that you need to resolve in order to get to the device level. And so I ran into this issue, and I I so I'm not sure whether we have to solve it here.

[00:53:33] **Italo Busi**: I I was gonna that

[00:53:34] **Ian Farrer**: was gonna be my question. Is I

[00:53:35] **Wim Henderickx**: just want to bring up the the the issue. Right? And then where we alright. First of all, do we want to solve it is one, and then where we solve it is the second. Right? Okay. But yeah. So it would have been nice if Yang could express some referencing capabilities.

[00:53:50] **Ian Farrer**: Discretion. Yeah.

[00:53:51] **Wim Henderickx**: And yeah. So that's the issue that I see or saw in this space with orchestration, but that doesn't mean we have to solve it here. And and first, do we have to solve it?

[00:54:02] **Ian Farrer**: I'm I mean, I I recognize what you're saying, and it's something that everyone has their own solution to, but it feels like maybe more of a NetMod problem. But

[00:54:10] **Chris Bowers**: Chris, comment on the ChongFing, I I guess, particularly, but in general, I I do think we have to be careful about including an ever expanding amount of parameters in the service model, especially if you're you're wondering, like, does the customer even need to have an influence on that particular thing? They're meant to be customer facing models and maybe in the network levels, models they sort of fit, and you you wanna be able to express stuff like security. But I think otherwise, if you just deploy it by default for most of your customers, then maybe it doesn't belong in that intense.

[00:54:41] **Danielle Ceccarelli**: Daniele Ceccarelli. So there is one thing that I don't know if it's already covered by the previous problem statements or not. It seems to me that is not. So I wanted to bring this which is a problem that we found when deploying mostly service models in in the network, which is the lack of possibility to map the obstruction layer to the underlay layer. There is a draft that Drew and I worked on in in TEAS, was mapping the service layer to the underlay T infrastructure. Mhmm. But that is extremely TEAS specific. So maybe one thing that could be helpful here is to have something that is a little bit more generic and that that does not necessarily provide the capability to map service to, for example, an SRT policy or something like that. Something that is more generic and that can be applicable to to different cases. This is this is a problem that we have found deploying controllers in in the network. I don't know. I mean, it should be operators to say that. I I'm I'm giving voice to the operators that found this problem.

[00:55:50] **Ian Farrer**: Okay. I think that's the end of our time for that session. So can you move on to the next slides, please? Thanks very much for that.

[00:56:00] **Samir Varghese**: Thank you.

[00:56:18] **Luis Miguel Contreras**: Chris? Yes. Where is That's still can push.

[00:56:22] **Ian Farrer**: Yeah. Or or or or that's the Yeah. Go ahead.

[00:56:33] **Chris Bowers**: Let's see how that Nope. Brute force works. This draft is an extensive architecture for service modeling, and it's really based on a couple of years of experience now implementing the various service models, so l two, service model and l three service model in a couple of different networking environments and what we've learned from that. In particular, what we're really seeing there is if you if you look at the Yang, there is actually a significant amount of of duplication, like more than one third of either model is, containing the exact same Yang nodes trees, in the tree. And, of course, then there are l two specific things, l three specific things, but this is not reusability. Right? It's it's actually duplication. And I think particularly as we hear in start looking at, hey. We're gonna maybe add more use cases, other services than than these VPNs, then, well, we're gonna end up creating more and more of this duplication if you just keep copying that pattern. So it is really worth looking at, I think. That is just from the Yang perspective. Right? So that that would sort of make our life hard as we write the models themselves. But this causes a real problem as well for the the implementers and the operators ultimately who have operational data based on these models. First of all, the customer's intent is sort of duplicated. Right? So if you think of an operator who offers both l two VPN and l three VPN on the the same orchestrator at the very top. Well, if if I'm as a customer having the sites that contains both of these VPNs or VPN types, I actually need to duplicate the site information across both models. That is fairly annoying. And then it it gets sort of worse if I'm actually trying to express relationships between intent between these two things. So very specifically, the the models allow you to specify that certain site network accesses have a better placement choices. Right? So you sort of wanna say this particular site network access in that layer two VPN must share or must exactly not share a bearer with that layer three VPN, you cannot actually do that in the current models, which is, certainly something that should have been possible. Therefore, the proposal is to revise how these models are built around a a sort

[00:59:15] **Med Boucadair**: of common

[00:59:15] **Chris Bowers**: core. The idea would be to remove Yang duplication, so no double text that that is equivalent in the models, and simultaneously, yeah, hoping the the the operational issues. And that would give us a very good framework for going forward and then expanding into other, areas of of service models that I know that is, interesting here. Here's a very basic representation of what that could look like. So you might have something like an ITF service, Yang model that just contains the very bare, setup without even any particular implementation specific. So no technology specific things in there. Just we're modeling customer intents, maybe sites, site network accesses as a base premise, but not the technology being used. You might then have extensions or, well, young augmentations that do specific technology specific add ons for the bearers as a next level. And then maybe from there, things for all types of VPNs. And then you sort of get to an entirely revised, ITF l three p n service model that builds on top of that whole core. My question for the working group is therefore really on the network models. So I've, really been looking at the the the service models for all of this. But if we look at the the problem statement, I see well, at least these three, particular statements in there that to me relates directly to do we also not need to look at the network models at the same time, and do we need a common architecture to define all these sort of young models that go into orchestration platforms or domain controllers or whatever you want to call them, not device models.

[01:01:12] **Ian Farrer**: I'm sorry. Oscar, go ahead.

[01:01:17] **Oscar Gonzalez de Dios**: Oscar, Telefonica. So to your first question, if we need to look at the at the same time, yes. Of course. I mean, I think if if we work together, it would be much much better. And when you put the the the VPN common, the VPN common precisely when we created the VPN common working at the network model, we also look at having in mind the service model and with the aim that at some point someone would take them also to the service models. Okay? But we didn't have the strength enough at that point to move it to to there. So so happy to now work in the in the second version, like, because because

[01:01:53] **Chris Bowers**: it's Yeah.

[01:01:53] **Oscar Gonzalez de Dios**: This will require.

[01:01:54] **Ian Farrer**: I mean, I I I think one consideration here is that if we start pulling on a single thread, then we may find that if, you know, the work very, very quickly expands around here. But that's what we need to do, then maybe that's what we have to do. Tyler?

[01:02:22] **Italo Busi**: I have one question and one comment. For the question, when you speak about technology agnostics, sometimes different people have different understanding. Sometimes technology agnostics means packet technology agnostics, and and sometimes it means really technology generosity including packets and security. What is your interpretation?

[01:02:41] **Chris Bowers**: The most obstructed version possible. So I I wanna pre if it's if it's up to me, I would prepare it for any possible technology. Like, what if I wanted to stick optical information into that that model and sort of I wouldn't make any presumptions about what we would put in in further augmentations and and additions.

[01:03:01] **Italo Busi**: Okay. And the comment on your question, I think, as we said before, NM and the same are providing two different instruction. So I don't think you can really have a common model between the two. But what I think already has been already done for the items which which are really in common, And some of them are are we found it in our in in in cCompose, so some are are also common to the device. We can create common groupings that is already in our c for VPN common. I think it will be much better to have a common grouping that you can use in different places of your young model when there is a clear mapping rather than trying to merge the two models that have a completely different abstraction level.

[01:03:38] **Chris Bowers**: Just to clarify, I'm I I don't think I'm arguing for a common module as in young module for, say, service and and network. I would argue for a common architecture of how we do these things. Reusable see. Reusable groupings maybe as we're already brought up.

[01:03:53] **Italo Busi**: I see. I mean, it's a same approach for the for SM and NM where you have a core and technology specific augmentation. Yep. Okay. I understand your point. Thank you. Solution. Yeah.

[01:04:05] **Mahesh Jethanandani**: Alright, Mahesh. If you could go back to slide number five, I think. The diagram that you had. Yes.

[01:04:12] **Chun Feng**: Yep.

[01:04:13] **Mahesh Jethanandani**: I've always believed that this to be true. Right? A customer ordering a service doesn't care whether it's packets, it is pigeons carrying bits of data, or anything else. I think what they probably at best will say, I want a service between these endpoints. And by the way, that's the quality of that service needs to be defined by a certain set of parameters, and that's it. I don't think so customers wanna get into it. No. I want MPLS over s r v six or I want s r v six native. They probably don't care provided the data is being serviced across the network.

[01:05:04] **Ian Farrer**: I think in the general case, you're right. We do have some customers who are very, very prescriptive about how something will be built. But, you know, I think the general case is correct there.

[01:05:16] **Rob**: Robert, you go to the next slide, please? So I think you asked the is the final one. So I would say, I

[01:05:23] **Italo Busi**: think you should definitely look

[01:05:24] **Rob**: at this and have a look and see what the solution looks like or what the solution is shaping out towards. And then depending on that outcome, then decide whether it's a good thing to do or not. Because it's gonna be impactful,

[01:05:35] **Ian Farrer**: I think, because it's gonna break the

[01:05:36] **Rob**: different models. And I don't think now ahead you can know what that impact's gonna be and hence, whether it's worth paying that cost. So I would, yeah, do some investigation. And if it is good, then go that way. If it's not, it's like hands off.

[01:05:48] **Chris Bowers**: Right. So investigate without the commitments that that's actually what we're going to do. Exactly.

[01:05:55] **Ian Farrer**: Kent Watson. I'm one of the coauthors of the Yen configuration templates document in the NetMod working group. If we use common groupings, then that would be something that could be templatized so it could be applied to the different places in the in the various service trees. Okay. Thank you. Thanks, Chris. Oscar, I think you're next, aren't you?

[01:06:28] **Oscar Gonzalez de Dios**: Thank you. Telefonica. So right now, after the looking at the customer service young models, Here, the word that we are going to present is this update or proposed update of the network young models. Even the authors of this are Samir and me. It has all what we are presenting comes from the repository that we set up and people that implemented their models. Adrian, can I click here? That's pass me a slide. That that working the implementing these models. In the last years, they have reported the issues in the of implementation. Okay? So here, this is not not just Samir and me. Okay. Perfect. So first, I'll clarify the scope that we have today. Okay? That and what is not in a scope is especially is more even even more important. Okay? I'm I'm not saying that what is not in a scope, it might be in a scope someday. Okay? But this is what we have compiled from the issues from what people said. Okay? So here, we are talking about missing functionalities. Hey. You have because just to put into context, the the network service model is how an operator would like to deploy a service in their network. But being in a point that is vendor agnostic enough, so from it, you can derive the device configurations. But it is not abstracted enough as the customer service. So all the everything that you need to look in your inventory, etcetera,

[01:08:11] **Nils**: you do it

[01:08:12] **Oscar Gonzalez de Dios**: in this layer. When you come down here, you have already taken the decision. You have already taken your your choices. So here, there are some functionalities that when you say, hey. I want to create the services. There are some functions that you missed them. Some configuration blocks that are directly passing down that are that were not there or aligned, what would you could do in the in the devices? Some operational issues that we will see. So here, everything that is in the scope. What is not in the scope? Here. Here. No mapping between models. No. We are not doing not doing mapping. Mapping to device also. Not doing mapping to device. All the workflows. Also, when we deploy the the models, we saw that you in order to really to to really activate the service, you need to do pre checks. So it's before you do the service. Hey. There are some things that you need to to look if they're if they're in place. After you have created, you do post checks. You do some some tests, some no. Also, this is right now, this is not in scope. I'm not saying that it will be in scope. Sometimes some would say, okay. But it's part of your service. Right? Yeah. But right now, we'll we'll leave them about when but we know when when we need to orchestrate and we we did the workflow to orchestrate everything, and that workflows are very particular. Even I work in Telefonica Global with several operations, and every operation did a different workflow. Okay. So okay. I don't care, but they all use the same network model. Okay? So that was the that is the the spirit. So here, you can find in the draft and also you can find in the repository. This has a set of enhancement that people proposed and that we have already been working with them to to give or to extend the young for it. So for example, some b f d parameterization, some extension to the billing and tag interfaces, some BGP or pointers to ACLs supporting SRV six, which now again, when we did this several years ago, we still would not have SRB6. So now it's just a stupid thing. It's a lift that you need to to add. But without that, you don't you cannot specify, hey. I want my BRA form on that to be deployed using our services or dual. K? This is and now this is something that we have had to to extend. Support for the multicast. So here, l two and m, same thing. We had set of compile. I'm not gonna enter into the technical details of all of them. I think it's relevant people. They are claim and people found a solution. Okay? So people extended the model already to find it. So here is just adding them to to the drafts. So just take a look at at them. I think this part is is more interesting. Some people express that. What about the status of the Internet network service? So are we using the model just as a one shot? So, okay, hey. This is my intended so the operator said, okay. After doing your customer service, you know, hey. This is how the service would like. Send it. Footprint. Okay. It's it's deployed. I'm done. First, we use it like that. But then people say, hey. I mean, I have the model, so I want to really know if if the network if the service is running on the network. K. You you have some operation in some list that says status or or okay, not okay. So is it how how can how can you say, hey. It is working good. Can you send notifications to say, hey. We are partially down. We are not. So people said, okay. Can we use this? So here, what people said, okay. Clarify the status of what does it mean, the operation really the operational status. In some controllers, the operational status, that that means that everything is configured that is as it should be configured. Just that. And in some cases, it means, well, everything is configured as it should be configured, but something is failing there. So your service is failing, but everything is configured good. So we don't know to which the two we are referring when we say the state is is down. Okay? Or the the state is is not good. So here, we will need some clarification. So here, the thing is, does the network model need to take care of this life cycle of the service? So keep on being alive and receiving notification also from the on telemetry from the from the network and reporting if it's okay. Now I'm good. Now I am not good. I am good. Now they are good. Now there are separate documents, and there are separate junk models that take care, for example, of the performance monitoring. There is a VPN. Do remember? We did it in ops. I think the the VPN performance monitoring that so it's a completely separate model for that. Also, Benoit created all the Azure as three. So we also have a separate Azure as three for that. So all that pieces, they are they are outside. So at some point, it's interesting them to have them together or bundle or to glued with the network model. What is something? So looking at all the issues, we found that some some things were common to all the all the models that new technologies for some the the services was was an example. Incomplete support, there were some technologies that were com complicated, so we needed to add the the support. And, also, we saw that there are more more network mod models that are needed. So for example, some network level access control list that people from the security can update, routing policy. So there are more more network models that are required. So here, what we want is people to work and to send more feedback on this engagement that we are required for the network model and helping the prioritization. We have a lot, and we need to to prioritize. Try to at least have an agreement on the operational status and how far do you want to go be beyond that. So I would like to have an agreement first before before moving. Use the repository, the GitHub election repository that I hope that we can move to on soon. And align with the customer service model that you presented before for to ensure all the the consistency. And here, use this to scope the working on. So time for questions and helps.

[01:14:47] **Contributor**: I have a clarifying question, please. Can you if you go back to the one on the state? Yeah. This So is the requirement from a state is to state what is the, you know, the status of the network, whether it's operational up or down, or are you asking whether the deployment succeeded or failed?

[01:15:14] **Oscar Gonzalez de Dios**: Precisely, the question was to clarify what are the different stat the different operational status branches in the in a network model network service model mean. Okay. So it's precisely pointing out to the two things that you mentioned clarify. Say, well, it really this leaf means that that the that the either the configuration is is correct in the device, it was well configured or not. It is looking at the network and something is wrong. So give that clarification and so that it doesn't matter I have two, three implementations. I know that what they are going to say means something. Because right now, it's operational is that it's just a small description in the junk that Okay.

[01:15:57] **Contributor**: I I see what you mean. Yep. Thanks.

[01:16:02] **Joe Clarke**: Joe Clark, at the risk of sounding weird, I think you have a a yang next kind of problem here. I I I really liked this presentation. I like the concrete things that you say we need. I would hate those to be held up for some of the broader changes, but I think listening to Chris's presentation, you've got an opportunity now maybe to you're gonna need a business work, the l LX and M and SM. See what you can do to make it more extensible, but but work fast because operators clearly need some very concrete things to to do better with this.

[01:16:44] **Ian Farrer**: I had a couple of questions on the draft mostly around kind of what you see the scope of this. The draft's called an update to the service and network models.

[01:16:53] **Mahesh Jethanandani**: Right.

[01:16:53] **Ian Farrer**: But but what you're doing at the moment is really capturing requirements.

[01:16:56] **Oscar Gonzalez de Dios**: Yes. Well well and and we focus on the we want to capture everything, but as we were more in the in the network models, we started with those. I mean,

[01:17:04] **Ian Farrer**: it's Okay. So I I there's two comments to the title, and it's it's requirements for an update rather than actual proposal for

[01:17:10] **Italo Busi**: an update.

[01:17:10] **Oscar Gonzalez de Dios**: There there was also a young model young model

[01:17:13] **Ian Farrer**: So you do you do Yeah.

[01:17:14] **Oscar Gonzalez de Dios**: Yeah. Yes.

[01:17:15] **Ian Farrer**: We we took we took care of I

[01:17:16] **Oscar Gonzalez de Dios**: think the ones that we were in the, we had more issues, and I think the ones that we show here are the ones that we already took care of putting actual junk code and so on. There were some pull requests already. Okay. But we have much more code that people is sending us.

[01:17:32] **Ian Farrer**: Yeah. But around you you do plan to confine the scope just being the network models in this doc?

[01:17:37] **Oscar Gonzalez de Dios**: Exactly. So I wanted to align the scope to say to move fast and to say, hey. We can focus on on these ones. Yep. Okay. We ship them, so we want to have to work work quick

[01:17:48] **Italo Busi**: without stop. Okay. Thanks. Italo, Uzi. I have three questions. First, have you if about the ASR poll policy mapping, have you looked at the solution in the service mapping in this? Because there is already a mapping to Yes.

[01:18:02] **Oscar Gonzalez de Dios**: Yes. Yes. But we have not done any new extra mapping for Ah, okay. Okay. It's just the service six is just telling you that this particular node needs to work in a service six. So that that implies that when you go and download the temp the set when you go to the node and

[01:18:18] **Italo Busi**: It's not the mapping to a specific policy.

[01:18:20] **Oscar Gonzalez de Dios**: I understand. No. No. But you and but just just by that, you need to the configuration is different in every also in every vendor is a little bit different. And without going into a specific ASR policy, so just that.

[01:18:32] **Italo Busi**: The second question is when you speak about new technology, are you considering only packets or also other technology like optical for supporting at least layer two services?

[01:18:41] **Oscar Gonzalez de Dios**: We were not looking yet, to be honest, at layer two services so far. We were working more in in packet services, and the case was more for some for the services rather than another thing. But that that was the but something can can come.

[01:18:55] **Italo Busi**: And your question is about one things that keep receiving conflicting domain.

[01:19:01] **Wim Henderickx**: Sorry.

[01:19:01] **Ian Farrer**: We we need to cut the line after. It's it's locked.

[01:19:04] **Italo Busi**: It's whether you are supporting also the case where because in your figure, you show only one controller having control of the end to end network. Can you have or can you use that also when the network is split into multiple controller and the PR under different controllers, or is not yet in the scope?

[01:19:20] **Oscar Gonzalez de Dios**: We have not yet in in the scope. We are assuming a single administrative Yeah. Right now, it's it's like this. Not entering to that space.

[01:19:30] **Ian Farrer**: Thank you. So I think we have Feng Chao next remotely. Can you bring her in,

[01:19:40] **Chung Feng**: Okay. Can you hear me?

[01:19:42] **Ian Farrer**: Yes. We can.

[01:19:44] **Chung Feng**: Yeah.

[01:19:44] **Oscar Gonzalez de Dios**: Yes.

[01:19:46] **Chung Feng**: Okay. I'm on phone call, and I will present, like, speaker stations to the. Our agenda include the motivation and the user cases and the model gaps and the extensions and the open issues. We know RFC 8299 defense l three s m and is widely deployed in our operators' network, And it delivering a unified customer facing abstraction for l three VPN provisioning, but we found some, issues. The problem is that the base l three SM request some extensions. The first reason is that, data intensive transmission service raise some dynamic requirement. And the second reason is that, emerging technologies including SRV six and the Quartum Security expose new features to customers. So let's draft the proposed extensions to AL3SM to fill above gaps. I want to turn to yeah. Sorry. Maybe I need to go to slide three, but the screen is at slide four.

[01:21:28] **Dhruv Dhody**: I

[01:21:31] **Ian Farrer**: think there's just some lag there. It's it's.

[01:21:34] **Chung Feng**: Yeah. Maybe we need to wait for a moment to

[01:21:38] **Ian Farrer**: We have slide four on displayed here. Is that the the correct one?

[01:21:42] **Chung Feng**: Okay. But my in my screen on my screen, it is they are in screen three. Okay.

[01:21:52] **Ian Farrer**: It's now gone to slide five.

[01:21:55] **Chung Feng**: Oh, yeah. How about now? It is slide four in

[01:22:00] **Ian Farrer**: It's slide four. Yeah. We have slide four here.

[01:22:02] **Chung Feng**: Yeah. Yeah. This is our first use case, data intensive transmission service. The challenge is that cross site data transfer volumes range from hundreds of GB to tens of of TB. Most be the VPNs transfer only, but higher bandwidth VPNs cost too much. So the core demand for customers is a balance between cost and the performance. They need temporary virtual high bandwidth connections during data transmission tasks. Here is an example about the transport duration contrast. And here I want to highlight and show you the business value for operators because operators may worry dynamic L3 APM may disrupt their existing APM market and impact impact the income of VPN. But, actually, dynamic, l three VPN can monetize under, underutilized off peak network resources because they can attract customers to use off peak bandwidth resource to barrier dynamic l three VPN through appropriate pricing strategy, such as off peak bandwidth is cheap, where on peak bandwidth is expensive. With this kind of acceleration, they can also avoid come capacity expansion due to their service. I think that this is also very important for, operators to, implement to this service. Okay. Because maybe, many of many people are confusing about what is dynamic L3 VPN. So here I want to clarify the definition of dynamic L3 VPN. It means dynamic networking or dynamic bandwidth or adjustment. Dynamic networking means from make connection low connection to eight GPS connection. It is just an example. And this kind of service is suitable for customers who require a persistent VPN collections. As for dynamic bandwidth adjustment, it means baseline bandwidth to eight GPS boost. It is suitable for customers who require persistent VPN connections for regular use. This two figure illustrate the traffic curve. And to conclude, both this kind of surveys provide similar temporary high bandwidth capacity, but the survey's logic actually differs significantly because the implementation is actually different from our practice operating. Here we gave gaps and the extensions for use case one. Actually, eight two nine nine only support static VPNs, and IFC nine eight three four enables flexible AC banding, but the next support for diverse dynamic provisioning. So our expressions focus on the provisioning of dynamic features where it loads to distinguish persistent and temporary connections and we add loads to specify the time slot for is not straight inostic service ordering. And for bandwidth adjustment, we add loads to distinguish baseline bandwidth and a temporary higher bandwidth. And this is our second use case, emerging tech driven value added service. From the customer's side, they need a traffic solution to guarantee their performance assurance for wide area wide area RDMA training or power grid and such sort of customers. And they also need a post quantum encryption to mitigate quantum computing risks, and they lead end to end performance monitoring for fast for the detections. For operators, here, I want to also share the business value for them. Operators can can offer new various services when customer ordering three l three VPN services so they can generate additional revenue. And this kind of services can also make, they have a better market comp performance. The gap is that, obviously, 08/04/1999 predict predict the maturity of SRV six and post post Quarton crypto. So the lack native support for them. And the networkers network slicing and the PM models are defined in other documents, so without native alignment to L3SM. So we proposed three anchor stations. First is enhanced queues to integration of slicing. And the second is enhanced security with integration of Quaten Security. And the third is performance monitoring with the integration of PM metrics and configurable monitor monitoring parameters. So here we raised open issues. We have proposed the file liquidation requirements as follows and we welcome you feedback on these proposals. Yeah. That's all. Thank you.

[01:28:18] **Ian Farrer**: A couple of questions that I had when I I read through the draft and the presentation. Have you checked the work that's going on in TEAS at the moment regarding network slicing? There's a young a young model that's quite advanced there. Have you have you checked that in line with, I forget which one of your extensions that one was. I think it's extension three that that comes under. And likewise, have you checked RFC ninety four seventeen, the service architecture for intent based networks regarding extension five.

[01:28:57] **Chung Feng**: I've seen nine four one seven. I haven't checked that. Maybe I need to

[01:29:04] **Ian Farrer**: Yeah. I would

[01:29:04] **Chris Bowers**: be good

[01:29:05] **Ian Farrer**: if you could have a look look through that and see if that, you know, makes it has any bearing on particularly on extension five. And likewise, the work in t's for extension three around the network slicing yang module that has been defined there.

[01:29:19] **Chung Feng**: Okay. Actually, I I know the the how to define the networking, slicing, but, I think, network slicing is a various service for operators to deliver the L3 VPN. And I also found that there are some, you know, naming is not the same. So from the operator's perspective, I think it is hard to to to to combine the the n s s m to l three s m.

[01:30:03] **Ian Farrer**: Okay. So it sounds like it might be something that we look need to look right at in the wider models. Okay. We need to we need to finish there. So thank you very much. And can we have the next presenter, please? It's you, Chris. Sorry. Surprise. There we go.

[01:30:28] **Chris Bowers**: Yeah. Thank you. So this draft is about mapping young schemas and their instance data to the TMF data models and their APIs. I'm glad to see all the support encouragement here half an hour ago. It was very cool that there is a lot of operators who clearly have these needs, so couldn't be more timely or maybe a few years late nonetheless. Also already heard during that discussion is sort of operators have different views as to where exactly the TMF space or framework sort of stops in in your network and where Yang picks up or or I've drawn it here in this visual representation of of that problem space as TMF flowing from the top down that I feel like they they sort of start very close to the customer, actual products and and and bundling of those sort of things, and then that sort of goes down into services and resources. And on the other hand, I I think here in the Yang worlds, we we tended to start on the devices and have been modeling up, if you will, into networks and and services. There is, well, a gray zone. I've literally made it gray of what you do exactly. I I don't think for the discussion of this mapping that necessarily matters. That is up to you, I think, an operator where you draw the line, but somewhere around there, I hope you will roughly agree. What is, I think, universally agreed is that that border, and I think it's almost a wall, between the TMF's framework and the Yang world, we have big issues. Right? So as soon as you break out of this modeled worlds, you end up with custom adoptions. You end up with middleware. You end up with two worlds which must interact. Models move on the young end and then, well, you need to constantly update your adapters to get that mapped into, your product's life cycle on on the TMF ends. That's a problem. And so a model to model mapping is a really good idea. It would enable TMF clients, I will call them, to consume young model services from, whether you call that a domain controller or an orchestrator is is, up to you, without any need for custom development. Right? You would sort of be able to expose young models up into what TMF understands as a catalog of of services. We will also be defining the service semantics of of how you consume those things so that, yeah, it it becomes a a system that doesn't require maintenance over time. I heard great skepticism also half an hour ago about, well, who would be willing to do all that sort of stuff? We we looked at it and, well, it's a lot of work and I have some great news for you. We've already done it. This exists. The draft explains well, not for all of RC7950, I'm not going to claim that, but for a good portion of the current Yang, schemas, maybe not any data, that sort of stuff, but for anything that you you would reasonably use in in many of our service models, it's already defined in the draft as how you could map that into the TMF world, and it's already implemented websites on the slides. We have an orchestrator called Satovy that's open source. The draft is implemented there, completely, I think. This works for a good set of young modules that we define here that are part of of Onsen these days. So the UltraVPN service model is entirely mappable and therefore orderable through that implementation. More work is, I'm sure, necessary to look at other things. And we will, of course, keep the implementation up to date as we go through the the process here and and get that, to a standard. On some things that I have received as feedback on the lists, around Shenzhen time, I think is well, actually, I wanna thank Brad and and Vance here. They've they've provided very insightful feedback on, the first version of the draft. First of all, around that drawing of of how these systems fit together in the next revision, I'll definitely do a better job of trying to describe that. The TMF is not really my home. I'm more here in the in the ITF space. So they provided some very good insights as to what the business site looks like. And they've also provided an answer to a question I had in the draft, which is how do you map complex nesting of lists and containers into the TMF data model correctly, and they've pointed me in the right direction there. So yes, thanks again. Finishing with the questions for the working group. First of all, a call for coauthors. We do have some other people at Entwine who have been authoring on this as well or have been thinking about, and they'll be part of the coauthors going forward. But I'm looking for a broader set of, people who might be interested in this work and willing to implement it so on and so forth. The other question I have is around TMF liaison statement possibly. So the way the draft is written, I don't think we necessarily need the TMF to cooperate on here, but I think it's nonetheless a very good idea that they, yeah, if willing, have inputs. Right? So I'm sure they have users and and other things.

[01:36:04] **Luis Miguel Contreras**: So question to that chair.

[01:36:06] **Ian Farrer**: If I can talk on that one. Yeah. I spoke to the liaison office yesterday to kinda discuss the process, and we will be doing something in that area. But we'll need to shape what exactly we're doing, whether this is a a foil or information or a a call for action. It's we'll need to discuss what we think we will want to see from them on that one.

[01:36:25] **Chris Bowers**: And just to finish, what I would bluff even most is interoperability testing, the hackathons, especially if you can bring a consumer site, a team of sites. I'm personally very interested in that to see if interoperability actually works. Right now, I'm just using, you know, a rest client. So

[01:36:44] **Wim Henderickx**: Wim? Yeah. Thanks for the work. I've done something similar. Right? But what I see is that if you go for the full Yang, let's say, schematics, it becomes very difficult. Like, if you look to all the all the Yang definitions, they're mapping that to the open API because that's actually what you're doing here. It becomes, yeah, extremely difficult because some of the validation rules there is some of these things doesn't really exist in open API by default. Right? So I feel we can do the same thing in a much easier way by just if we can map in TM Forum the schema reference of Yang and you use all the Yang tooling assets, by which case we don't have to do any mapping. And I feel that it's a if you look at all the different combinations and permutations we might have to do, it might be an easier way to solve this problem. But that's my personal view. And I can write a draft, or I can I can either comment or we can collaborate on this, but I see two approaches? Either you map two worlds, and the challenge is to map all these permutations. And I know that in OpenAPI, you have restrictions, and you can do extensions and all that stuff, but it's very difficult to get that aligned. And I think we can basically say if we can have one world talk to the other world because that's what we want actually to achieve and just use the tooling as is, it might be a simpler way to solve it. But that's my personal, view. Yeah.

[01:38:15] **Chris Bowers**: Yeah. I comment on that. So I think in the, what what is special here is this is not just an API open API mapping. Right? So the TMF describes schemas inside of their systems. Like, it's a schema discovery system. So you'd have to for them to be able to consume it without, again, more middleware, more specific things, you can't, just do that. So if you wanted TMF to, just adopt open APIs, you'd actually need to go there and get them to build stuff. I I don't Yeah.

[01:38:41] **Wim Henderickx**: You have to extend somewhere. Right? So the question is where so you need somewhere either, to reference, either in ITF, we say, here's an encapsulation that basically refers to Yang, and then you do the Yang capabilities. And and and or you do it in TMF, so you can do it either way in my view. Right?

[01:39:00] **Ian Farrer**: This is the purpose of the liaison. I I I think what we want to get out from this is, you know, can we collaborate on coming up with the best solution, or do we need to solve it here, or are you gonna solve it there? But

[01:39:10] **Wim Henderickx**: But there's two ways to solve it. Right? Yes. Yep. That's only reason. With what Chris is presenting. There's another I think we could have other proposal on how to solve the

[01:39:18] **Ian Farrer**: same problem. But, you know, only one can we do within Yeah.

[01:39:21] **Wim Henderickx**: We, yeah, we have to coordinate. I agree with yeah.

[01:39:23] **Ian Farrer**: That's the purpose of the liaison.

[01:39:27] **Danielle Ceccarelli**: Daniel, Francisco. So I wanted to make a comment which is related to the third question about the since I'm here, I'll answer all of them. So call for authors, absolutely not. Then thanks a lot for doing this job. It's extremely useful, but extremely boring. So kudos for doing it. The informal is on we have two ways of doing it. The first one is this is our our mapping. Please review it, which is, let me say, the basic level, and we we we don't get much from it. I mean, at least a review and acknowledgment would be fine. But identifying the things that where we are not sure and we believe that they could change to, let me say, find a common path that would be great. And then for how do you see this being implemented? So we have the lowest part of the upper layer of the OSS layer, which implements a TMF interfaces. The upper part of the network layer, let's say, for example, the ACT and MDC, which implements young interfaces. So do you foresee another layer there? Who is going to build that? The vendors the upper the vendors that comes from North, the vendor that comes from South, the operator does the implementation itself. How do you see it?

[01:40:52] **Chris Bowers**: The orchestrator or domain controller, whatever you want to call it, that is the utmost one that has Yang. Right? So the the way this draft is written, that one can basically point to a Yang model. You'd includes an augmentation. Well, it's an extension. You include a young extension in onto a a particular model, say, l three VPN service model. It it's generic. Right? It can be any model. You basically say data that becomes a TMF service. Data becomes a TMF resource, and the implementation there can then basically start speaking TMF interfaces north of itself.

[01:41:24] **Ian Farrer**: Yeah. Okay.

[01:41:25] **Danielle Ceccarelli**: So I'm that guy. So you're telling me, please implement the TMF interface using this mapping between your younger and the TMF.

[01:41:34] **Chris Bowers**: If you are working on an orchestrator that's yeah. That is young and currently has a the NetComp, RestComp on its Nordband, then, yes, you're the guy.

[01:41:41] **Oscar Gonzalez de Dios**: Okay. Thank you. Okay.

[01:41:45] **Ian Farrer**: Can I ask you to keep it brief just in the interest of Sure? Please? Sorry about

[01:41:49] **Mahesh Jethanandani**: We have the privilege of having the IAB chair here. So I'm gonna ask him. I looked at the list of liaisons arrangements that we have, and TM Forum is not on that list.

[01:42:04] **Dhruv Dhody**: Yes. I can clarify. You don't need a liaison manager to send a liaison statement. And our aim is first to figure out within this group what is the message that we want to send. When we were putting the milestone, my assumption was that the first message would be just notifying that on send, this is our charter. This is what we are saying. This is the wording for TMF that we have specifically put in our charter. So just be aware that this work is happening and getting that input from them early on will be more useful. And then would be once we have something adopted and once we have something that's a document specifically is on that we could send maybe something in future. Okay. So I think my first reaction would be that let just let them know that we are doing some work here. Yeah. Yeah. Contact me. We'll find out for you. Don't worry.

[01:42:52] **Ian Farrer**: Okay. Thank you. David and no. Okay. Thanks very much, Chris. Can we move on to the next presentation, which I think is Linda?

[01:43:11] **Linda Dunbar**: Okay. Here, a little bit change of the flow, giving a use case and showing how existing young models being developed by ITF can be used for this use case. And the the goal of this is to see that the young models developed by IETF is enough or if there's something new we need to have. That was the goal. So the motivation. Actually, this is really the use case. It's about edge data center hosting AI related functions of agent. And many of them have very predictable traffic. So, since they are, like, inference application or the module exchange parameters or database sync, The cloud is the cloud orchestrator is aware of when the traffic is going to be up and when the traffic going to be down. So instead of having the the permanent connection, they need dynamic change. And when some traffic comes up, especially parameter exchange, there's a very strict latency requirement. So with the network itself being having built for general purpose, for other traffic, they need some way to prioritize those traffic and make other traffic maybe stop or maybe giving them very little available bandwidth. So here are some common characteristics. Very high bandwidth and very strict latency, and is scheduled advanced in advance. And the limitation is limited. The duration is limited. So so that what I need is like, for example, cloud may orchestration may be able to request from two to 02:30 at certain date. I need to provide this much gigabits between those three edge sites. And this really to motivate having some kind of time scoped on equal pass policy activation. Here's some example. You have edge data center a and through the attachment circuit to connect to the PE and then PE to PE through backbone. There are quite a few, yeah, models being defined already. And each of the PE has the their own attachment circuit to come back to their edge data center. So the cloud manager could request, like, I want start time, I want duration, giving them bandwidth, latency, and participating sites, sending this to the network controller. Network controller can configure them, attachment circuit. They can make changes to the PE to PE ASR policy, assuming the backbone is ASR based, and giving the policy and giving the QS. So here, we are really just consider overall service, like, from service perspective. Okay. So here are the existing young models. ITF has developed many, many young models. So here are some of the young models need to be used for this purpose. And this draft itself doesn't define any young models. We're basically showing a example on how do we use those young models for the services. So here's just the sequence of the policy workflow. First of all, you have to identify where are the edge sites. Second step is selecting the participating sites. And then third is sending the request to the network controller. And then controller can install a policy and remove those policy when time expires. So here are some of the gaps through this x workflow exercise, I should say. So, basically, it need explicit activation and deactivation times. And policy life cycles need support for scheduled activation and expiration and be able to roll back. And also need some kind of API, standardized API for the cloud orchestration to send it to the network controller. So this need multiple, yeah, models developed by IETF from AC to TE to SR and QS. Okay. So, basically, this just reiterate what have been said. So this definitely should demonstrate the applicability of existing work and identify some gaps. And the question is for this working group, Has the and then for identified gaps representative of of the work of the edge to edge deployment? Maybe we missed some of the young models, which are already developed to suit this purpose. We would love to have your input on that. And should the time scoped network services configuration being added to the existing model. So we're looking for collaborations and coauthors as well. Thank you. Any questions? No? Then I saved some time for your

[01:49:39] **Wim Henderickx**: Thank you very much.

[01:49:39] **Linda Dunbar**: One. Thank you.

[01:49:40] **Ian Farrer**: Thanks, Linda. And finally, I think is it Louie who's presenting? Oh, you're here. Excellent.

[01:49:56] **Luis Miguel Contreras**: Thank you. So, yeah, I I would go a little bit in the direction in the direction that Linda was presented before. So through this idea of working on obstruction for Telco Cloud scenarios. So the the point is that the Telco cloud scenarios where we will integrate basically different computing capabilities, distributed across the big data centers, small data centers, and so it's not just cloud plus connectivity. So we need essentially to provide the necessary information for doing the the proper cooperation and combined optimization of resources in both cloud and network. So today, essentially, the the organization relies on on fragmenting domains. They're on one hand, the cloud side, on the other hand, the network side. They are independent, but they are they are interdependent. So, basically, the idea here would be to work on mechanisms for facilitating that inter interdependency of both domains. So the present mode of operation, as as said before, so the the the both end environments are working independently. So there is a fragmented resource visibility. So, basically, the decisions are taken independently. There is limited cross domain optimization capabilities. So because of the lack of information, essentially, the decisions are taken only with a partial view of the problem, not with the overall problem. There are problems for scenarios like scalability, scale out, scale out, and and so. And, essentially, in in the in the counterpart as well, because of that fragmentation, we avoid the risk of of too much exposure of information. If we were to a more com integrated view, we would need take we need to take care of of this risk of overexposure of of implementation in the sense of topology data and so on and so far. So this is the present mode of operation. What we would like to explore is mechanisms for facilitating that future mode of operation that will be a more combined work between the cloud and the and the network. So for that, what we are are proposing is some idea of a structure and function. Talking with with Oscar, what in the in the draft, you will see you will see the figure Only a state service orchestrator talking with Oscar probably will be more precise to refer to cloud service orchestrator that would be the the entity that would manage basically, the workloads where the workloads will be placed and and so taking into account the different constraints. And the idea here of this obstruction function that will collect information from different sources will be to to to provide the necessary obstructions for us with, like, connectivity capabilities in terms of capacity constraints, latency, etcetera, etcetera. Compute and storage capabilities that, of course, will not be directly coming from the network side. The network side would need to interact with the cloud for understanding what are the resources that are attached to different points of the network. And other capabilities that could be acceleration, plug capability, resources, etcetera, etcetera. So this instruction function could somehow modernize all this information and basically provide the the the valuable thing for the service orchestrator to do the the the proper life cycle of the of this the Telco Cloud service, which is the provisioning, the assurance, and later on the decommissioning of resources once the service has finished. So I said an important thing to take into account are the security and operational considerations because we are basically handling with different administrative domains in in in in, let's say, the the typical case. Otherwise, I mean, there will be also possibility of the the tech co be the owner of the cloud. But thinking on the big picture, we need to take care of the security and operational considerations. So how to control the level of information that this is posed to the other domain, how to to do the authorization of the authentication, the trust boundaries, and and so on and so forth. The multitenancy isolation and and also how to make all these telco cloud services coexist with the services that are already run running in the telco network that could come from residential services, mobile service, etcetera. So going to the final part. So, basically, the message is that we we consider that the telco cloud could require this combined cloud plus network decisions, that that's instructions could serve for that purpose. And and, basically, our next step would be to to keep working on clarifying what would be the extraction dimensions to be taken into account and align, of course, with the statement and, yep, for today, to check if this is could be of interest for the working group. I there were previous discussions in the mailing list a long time ago, but just to confirm if this is of interest or or not. Thank you.

[01:54:41] **Chris Bowers**: Chris, I read the draft, and and thanks for the presentation. I I think overall, the the problem space is pretty clear to me. I I like where that's going. I think where the data is coming from is also pretty clear to me, but what is not so clear to me is what the obstruction layer is. Like, I it's a zero zero draft, and and that's fine. But it's sort of is it a config false young model, or are you building an entire new IT ecosystem?

[01:55:05] **Luis Miguel Contreras**: Is is a is a zero zero also? The approach will be just to to, let's say, not presume any kind of solution or whatever, just to consider something very high level. Probably, could be part of the well, what is in my mind, especially, it will be something part of the network controller or network orchestrator. So, basically, a component that aggregates all that information and provide the necessary information to the cloud manager. And, also, this this component being interacting with the cloud manager as well for collecting information from the cloud side. So what are the resources that are in location a, b, c, and d, and then aggregating that with the topological view and and offering somehow and extracted view coming back to the cloud manager for taking decisions. But this is my personal view at this stage. We, on purpose, left that kind high level by by now. Okay. Understood. Just one clarifying question. Maybe there is it's

[01:55:53] **Chris Bowers**: not necessarily a passive inventory you think. There might be use cases for the cloud orchestration thing to interact with this layer and of requesting to do stuff for.

[01:56:03] **Luis Miguel Contreras**: Oh, of course. Of course. The phrase that the the there's a scale across a scenario where you're in the the cloud requires to move what rows or instantiate what rows in another point. That decision will be based on on this as and the information provided by this instruction function. But, again, the cloud need to ensure that the connectivity up to that point would have the sufficient capacity, etcetera, etcetera. So the there will be some interactions for the different phases, provisioning, assurance, and and the commissioning. So I I I would foresee that interaction. Yeah.

[01:56:32] **Ian Farrer**: Okay. Thank you.

[01:56:36] **Italo Busi**: Thank you, I think it's a very important work item. I wonder whether there is an

[01:56:40] **Luis Miguel Contreras**: a relationship with CATS, how you have evaluated them. CATS essentially works on on the stealing part, which means that the the all the instances have been already deployed, instantiated, and so on so far. So this will be kind of overarching thing where the steering could be solved by Cuts or not. Maybe a case could be network slicing, so no Cuts at all. So CAS could be a potential solution for the for the steering

[01:57:04] **Italo Busi**: part. Utilization. Okay.

[01:57:05] **Luis Miguel Contreras**: But it's yet provisioning, assurance, and and decommissioning the Yeah. Other parts that I'm not covered. One

[01:57:13] **Ian Farrer**: of the reoccurring things that has come up in us discussions around this this working group is would we need a data center service model or something that we could actually model kind of data center services, data center networking? Do you think that what your kind of you you know, this is one of the things that this could lead to?

[01:57:34] **Luis Miguel Contreras**: This will not enter on the internals of the data center, so my quick answer will be no necessary. So we are considering here these instructions to provide, let's say, the connectivity between PEs or data center gateways.

[01:57:47] **Mahesh Jethanandani**: Okay.

[01:57:47] **Luis Miguel Contreras**: And and and, basically, the the service that could would come from the data center will be, I would just say, a normal service. Only have the the I mean, wouldn't from the first service perspective, at the time of provisioning and providing the assurance and so. Something specific for this will be that we provide the information to the data center for do the placement of the of the workloads. But but thinking on connectivity, I I would say it's a a conventional connectivity service, no more than that. Right.

[01:58:19] **Ian Farrer**: Okay. Thanks.

[01:58:21] **Chun Feng**: Yeah. I think this work is very consistent to what we have done in our network because when we operate the network, also operate the cloud, so we provide a service to our customer. We need a unified model, which includes not only collection features but also computing features. So I think this work is is valuable. Okay.

[01:58:49] **Luis Miguel Contreras**: Thank you.

[01:58:54] **Roberto Manzotti**: Hi. Roberto Manzotti from Cisco. I think it's very interesting, the orchestration of the data center and with the network. We have another pair of draft that are under discussion in the SICAM working group related to the same object for the optical networking. So I wonder if it will make sense to, let's say, look at the problem in a more realistic way. So try to look at it not only for packet and optics and have it Mhmm. A comprehensive view of of the scene.

[01:59:28] **Luis Miguel Contreras**: Okay. Thanks, Of course.

[01:59:30] **Ian Farrer**: Yes. Thank you. And I think we've just about got time for Can Can. If you'd like to come to the line Mike? Remote. Sorry. Oh, remote. Okay.

[01:59:41] **Can Can**: Oh, thank you. As I type in the chat box, the service interaction requirements in the tenant cloud should be four dimensions. I mean, I I suppose to add two dimensions, additional trim dimensions to the abstraction, the resource cost and computing electricity coordination. And I have already give a detailed explanation in the mailing list. And also in the chat box, I just give some give my opinion that cost or revenue can influence the natural solution selection. So one dedicated service model.

[02:00:22] **Ian Farrer**: Sorry, We're we're out of time now. So you said you'd already posted

[02:00:26] **Can Can**: this

[02:00:26] **Ian Farrer**: for this. So, yeah, thank you very much for that. And thank you very much for this, and we'll see you in San Francisco.